Time for glibc 2.1.2 final?

[Andreas Jaeger]

>>>>> Ulrich Drepper writes:

Uli> Andreas Jaeger <aj@arthur.rhein-neckar.de> writes:
Uli> This is no problem with the patch I added.  As rth commented, I also
Uli> don't believe Zack's words that with the -march=i386 flag properly
Uli> used there is a problem.
>> [...]
>> I recompiled the current glibc 2.1.2 with that gcc and got
>> an error message when trying to execute any binary.  For example:

Uli> I have no idea what this is about.  But the problem with crt[in] is
Uli> that the compiler generates different code not understood by the
Uli> script which leads to lik errors undefined symbols).  Something very
Uli> different.
Agreed, this looks really different.  Looking at the generated
crt[in], I didn't notice the problems Zack reported either.

The only debugging method that worked is strace, with gdb I didn't get 
any results:-(

$ strace elf/ld.so string/tester
execve("elf/ld.so", ["elf/ld.so", "string/tester"], [/* 36 vars */]) = 0
getuid()                                = 207
getgid()                                = 100
geteuid()                               = 207
getegid()                               = 100
brk(0)                                  = 0x800149d0
brk(0x800159d0)                         = 0x800159d0
open("string/tester", O_RDONLY)         = 3
fstat(3, {st_mode=S_IFREG|0755, st_size=198117, ...}) = 0
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\2\0\3\0\1\0\0\0\220\213"..., 4096) = 4096
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x40000000
getcwd("/usr/glibc/src/buildreport/19990905", 128) = 36
mmap(0x8048000, 36864, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, -2147398184, 0) = -1 EBADF (Bad file descriptor)
close(-2147398184)                      = -1 EBADF (Bad file descriptor)
write(2, "string/tester", 13string/tester)           = 13
write(2, ": error in loading shared librar"..., 37: error in loading shared libraries: ) = 37
write(2, "", 0)                         = 0
write(2, "", 0)                         = 0
write(2, "failed to map segment from share"..., 40failed to map segment from shared object) = 40
write(2, ": ", 2: )                       = 2
write(2, "Error 9", 7Error 9)                  = 7
write(2, "\n", 1
)                       = 1
_exit(127)                              = ?

The question is why uses the second mmap call a wrong fd?

After recompiling elf/dl-load.* and elf/dl-minimal.* with gcc 2.95.1,
ld.so segfaulted at a different location.

This looks more like a real compiler bug - but I fear my findings are
not enough to nail this down and get it fixed.

Andreas
-- 
 Andreas Jaeger   aj@arthur.rhein-neckar.de    jaeger@informatik.uni-kl.de
  for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de