Bug#203324: unreproducible?
hnh@linpro.no (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.
Exactly what processors does support the hardware
multiplication/division instructions? It is not supported by the
SuperSparc(II) at least. Triggering the kernel trap does have a not
insignificant cost, so I would guess the decision on wether or not to
let gcc use these instructions would depend on current usage-patterns
of the various processors? Is the instructions supported by the
HyperSparc family?
-Harald
--
Harald Nordgård-Hansen, Linpro AS <>< http://harald.nordgard-hansen.net/
Pancoveien 7, NO-1624 Gressvik, Norway ><> Phone/Fax: +47 6935 2424/25
Reply to: