Re: Resolution (Re: [uml-devel] 2.4.22-[67] problems)

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Hi!

Jeff Dike wrote:
> md...@de... said:
> 
>>It turns out that this problem seems to be due to compiler
>>incompatibility. UML had been built with gcc 2.95 due to old breakage,
>>and when built with gcc 3.3 (as glibc is), everything starts working
>>again.  My suspicion is that this is due to certain recent changes in
>>pthreads.
> 
> 
> Is it your opinion that there's no problem in UML itself?  Having a field
> in the sigcontext getting magically munged is somewhat worrying.  I'd be 
> happier knowing what exactly was happening so I can be sure this wasn't
> exposing some subtle UML bug.
> 

I've been doing some tests and I'd say that the problem is something 
regarding the NPTL+TLS+__thread features of recent libc6 (2.3.2 and 
2.3.3cvs)... But I'm clueless about the fix :-)

I'll setup a chroot where I can play around with glibc setups.

OARS, why does linux (the UML executable) doesn't run under 
/lib/ld-linux.so?

Example:
puma:/tmp# ldd /usr/bin/scp
                 libutil.so.1 => /lib/tls/i686/cmov/libutil.so.1 
(0x4002f000)
         libz.so.1 => /usr/lib/libz.so.1 (0x40032000)
         libnsl.so.1 => /lib/tls/i686/cmov/libnsl.so.1 (0x40044000)
         libcrypto.so.0.9.7 => /usr/lib/i686/cmov/libcrypto.so.0.9.7 
(0x40059000)
         libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x40156000)
         libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0x4028f000)
         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

puma:/tmp# ldd ./linux
                 libutil.so.1 => /lib/tls/i686/cmov/libutil.so.1 
(0x40018000)
         libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0x4001b000)
         /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
puma:/tmp#

scp has a superset of linux's shared libs and runs ok:
puma:/tmp# /lib/ld-linux.so.2 --library-path /lib:/usr/lib /usr/bin/scp
usage: scp [-pqrvBC1246] [-F config] [-S program] [-P port]
            [-c cipher] [-i identity] [-l limit] [-o option]
            [[user@]host1:]file1 [...] [[user@]host2:]file2
puma:/tmp#

But linux does not run:
puma:/tmp# /lib/ld-linux.so.2 --library-path /lib:/usr/lib /tmp/linux
Checking for the skas3 patch in the host...found
Checking for /proc/mm...found
Mapping memory: Invalid argument
puma:/tmp#

If linux could run under ld-linux-so helper testing would be easier :)

Regards,
Nuno Silva