[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. 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
