Bug#203324: unreproducible?

[GOTO Masanori <gotom@debian.or.jp>]

Hi,

At Wed, 30 Jul 2003 09:10:18 +0200,
Harald Nordg�-Hansen wrote:
> 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.

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