Hi,
At Wed, 30 Jul 2003 09:10:18 +0200,
Harald NordgÂård-Hansen wrote:
> [EMAIL PROTECTED] (Harald NordgÃrd-Hansen) writes:
> > In addition, there seems to be changes in how hardware multiplication
> > and division is handled (umul/udiv/smul/sdiv). In 2.4.21-rc2,
> > do_user_muldiv is only called for sun4 and sun4c architectures, while
> > it is called unconditionally in 2.4.21. Could this be triggered by
> > some combination of gcc and glibc updates? I'll instrument the 2.4.21
> > kernel a bit at that point, and start a kernel rebuild before going
> > home and calling it a day.
>
> I can confirm that this is indeed the problem, the sun4m architecture
> does not (always?) have umul and friends. And at
> __strtod_internal+3624, there is a smul instruction being used.
> Kernels prior to 2.4.21 will trap and emulate this instruction only
> for sun4 and sun4c architectures, while 2.4.21 traps and emulates
> unconditionally. Compile arch/sparc/kernel/traps.c with TRAP_DEBUG
> defined to get a message each time this happens.
>
> Now, wether this is a bug in glibc, gcc or the older kernels I'll
> leave to someone else. :) I would guess that the cause is an updated
> gcc, but the effect is that currently glibc does not work on older
> kernel revisions on (some?) sun4m machines.
If this bug is occured by kernel changes, then this bug should be
reassigned to kernel-image-2.4.21-{sun4*,sparc*} package.
debian-sparc people, do you know that 2.4.21 sparc kernel has incomplete
trap routine? Bugs#203322 and #203324 say something about this:
#203322: python2.2: Python fails with illegal instruction during
postinst on sparc32
#203324: libc6: __strtod_internal fails with illegal instruction on
sparc32.
Regards,
-- gotom
