Re: vismain failure

[Andreas Jaeger <aj at suse dot de>]

>>>>> Bruno Haible writes:

 > "make check" gives a failure for me:


 > GCONV_PATH=/packages/glibc-20000724-build/iconvdata LC_ALL=C \
 >   LD_PRELOAD=/packages/glibc-20000724-build/elf/vismod3.so /packages/glibc-20000724-build/elf/ld-linux.so.2 --library-path /packages/glibc-20000724-build:/packages/glibc-20000724-build/math:/packages/glibc-20000724-build/elf:/packages/glibc-20000724-build/dlfcn:/packages/glibc-20000724-build/nss:/packages/glibc-20000724-build/nis:/packages/glibc-20000724-build/rt:/packages/glibc-20000724-build/resolv:/packages/glibc-20000724-build/crypt:/packages/glibc-20000724-build/linuxthreads /packages/glibc-20000724-build/elf/vismain  > /packages/glibc-20000724-build/elf/vismain.out
 > Timed out: killed the child process
 > make[2]: *** [/packages/glibc-20000724-build/elf/vismain.out] Fehler 1

 > vismain.out contains only one line of output:

 > `.protected' seems to be handled correctly, good!

 > The child process is burning CPU cycles at

 > #0  0x8048e6c in protinmod () at vismod1.c:69
 > #1  0x804958f in do_test () at vismain.c:125
 > #2  0x8049379 in main (argc=1, argv=0xbffff504) at ../test-skeleton.c:196

 > The forward pointer for protinmod is pointing to itself, yielding an endless
 > loop:

 > (gdb) x/10i $eip
 > 0x8048e6c <protinmod>:  jmp    *0x804b510
 > 0x8048e72 <protinmod+6>:        push   $0x98
 > 0x8048e77 <protinmod+11>:       jmp    0x8048d2c <_init+48>
 > (gdb) print *(void**)0x804b510
 > $1 = (void *) 0x8048e6c

 > I'm using ld from binutils-2.9.5.0.24. Last week, I didn't see the
 > failure; I was using an ld from binutils-2.9.1.0.25 then.

Some binutils versions are buggy (especially 2.9.5.0.24) - there's
nothing we can do about this.  Older binutils versions don't support
the used features and we'll check for this at build time.  But
2.9.5.0.24 has the features but is buggy and we can't (so far at
least) check for this.

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de