From: Nuno S. <nun...@vg...> - 2004-01-09 09:08:05
|
Hi! I've been trying for days and made lots of tests and it seems that the 2.4 UML binary can't run on a host with 2.6 kernel and nptl-enabled glibc. I've made some tests that you can check here: http://sourceforge.net/mailarchive/message.php?msg_id=6897520 This setup without tls+nptl (glibc compiled with --enable-addons=linuxthreads) works fine with UML. Sooner or later everybody will have 2.6 and the new glibc :-) Any tips? Regards, Nuno Silva |
From: La M. H.P. Y. <pi...@ti...> - 2004-01-09 13:19:59
|
Nuno Silva wrote: > Hi! > > I've been trying for days and made lots of tests and it seems that the > 2.4 UML binary can't run on a host with 2.6 kernel and nptl-enabled > glibc. > > I've made some tests that you can check here: > http://sourceforge.net/mailarchive/message.php?msg_id=6897520 > > This setup without tls+nptl (glibc compiled with > --enable-addons=linuxthreads) works fine with UML. > > Sooner or later everybody will have 2.6 and the new glibc :-) > > Any tips? The calls set_thread_area(2) and get_thread_area(2) are not implemented in UML. Both are essential to NPTL. There may be other problems too... Implementing them gets really tricky if you want UML to work with a 2.4.x host. I've been trying to steal enough cycles to learn enough to just implement them on a 2.6.0 host. > > Regards, > Nuno Silva |
From: La M. H.P. Y. <pi...@ti...> - 2004-01-09 13:29:53
|
La Monte H.P. Yarroll wrote: > Nuno Silva wrote: > >> Hi! >> >> I've been trying for days and made lots of tests and it seems that the >> 2.4 UML binary can't run on a host with 2.6 kernel and nptl-enabled >> glibc. >> >> I've made some tests that you can check here: >> http://sourceforge.net/mailarchive/message.php?msg_id=6897520 >> >> This setup without tls+nptl (glibc compiled with >> --enable-addons=linuxthreads) works fine with UML. >> >> Sooner or later everybody will have 2.6 and the new glibc :-) >> >> Any tips? > > > The calls set_thread_area(2) and get_thread_area(2) are not > implemented in UML. > Both are essential to NPTL. There may be other problems too... > > Implementing them gets really tricky if you want UML to work with a > 2.4.x host. > I've been trying to steal enough cycles to learn enough to just > implement them on a 2.6.0 host. I should know better than to post on only one cup of coffee. I remember why I didn't reply before--you are struggling with the dual to my problem. This is bad news for me because it means that even if the host implements TLS it can not use NPTL. Going back through your posting it looks like it probably does not matter if the host kernel implements TLS as long as libc does not use NTPL. Is this a correct interpretation? |
From: Nuno S. <nun...@vg...> - 2004-01-09 13:38:01
|
La Monte H.P. Yarroll wrote: > > Going back through your posting it looks like it probably does not > matter if the host kernel > implements TLS as long as libc does not use NTPL. Is this a correct > interpretation? > The host kernel runs UML fine... UML doesn't run only when system's glibc has nptl+tls support. This same kernel runs UML with the same glibc, compiled without nptl+tls support. So, I can only assume that's nptl :) Regards, Nuno Silva |
From: Nuno S. <nun...@vg...> - 2004-01-09 13:33:50
|
La Monte H.P. Yarroll wrote: > > > The calls set_thread_area(2) and get_thread_area(2) are not implemented > in UML. > Both are essential to NPTL. There may be other problems too... > > Implementing them gets really tricky if you want UML to work with a > 2.4.x host. > I've been trying to steal enough cycles to learn enough to just > implement them on a 2.6.0 host. > Hi! You're talking about running nptl enabled glibc inside UML, aren't you? I'm talking about the host. Any host with kernel 2.6 and glibc-nptl-tls makes the uml executable segfault very early (see the link in my previous message for strace and gdb output. Quick description: ----- puma:/uml# ./linux Checking for the skas3 patch in the host...found Checking for /proc/mm...found [1]+ Stopped ./linux puma:/uml# fg ./linux Segmentation fault puma:/uml# ldd linux linux-gate.so.1 => (0xffffe000) libutil.so.1 => /lib/libutil.so.1 (0x40019000) libc.so.6 => /lib/libc.so.6 (0x4001c000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) puma:/uml# uname -a Linux puma 2.6.0 #2 Mon Jan 5 09:25:45 WET 2004 i686 unknown unknown GNU/Linux ----- Or did I miss anything in your explanation? Regards, Nuno Silva |
From: Oleg D. <gr...@li...> - 2004-01-10 20:25:54
|
Hello! Nuno Silva <nun...@vg...> wrote: NS> I've been trying for days and made lots of tests and it seems that the NS> 2.4 UML binary can't run on a host with 2.6 kernel and nptl-enabled glibc. Hm. I guess you are running some sort of old uml code. The fix was oneliner and included long ago. See the patch below. Apply it and then recompile. I use 2.6.1 + glibc 2.3.2-101 from Fedora Core 1, I hope this is new enough? ;) Bye, Oleg --- linux-2.4.20.orig/arch/um/link.ld.in 2003-10-25 00:35:59.000000000 +0400 +++ linux-2.4.20/arch/um/link.ld.in 2003-10-25 00:36:02.000000000 +0400 @@ -6,7 +6,6 @@ { . = START() + SIZEOF_HEADERS; - . = ALIGN(4096); __binary_start = .; ifdef(`MODE_TT', ` .thread_private : { |
From: BlaisorBlade <bla...@ya...> - 2004-01-11 15:07:50
|
Alle 21:25, sabato 10 gennaio 2004, Oleg Drokin ha scritto: > Hello! > > Nuno Silva <nun...@vg...> wrote: > > NS> I've been trying for days and made lots of tests and it seems that the > NS> 2.4 UML binary can't run on a host with 2.6 kernel and nptl-enabled > glibc. > > Hm. I guess you are running some sort of old uml code. > The fix was oneliner and included long ago. See the patch below. > Apply it and then recompile. I've just looked at 2.4.23-1um and I saw that dyn_link.ld.in has not this fix. Shouldn't it go in there, too? (That fix has been tested for both dynamic and static linking wrt 2.6 guest). Nuno, maybe you compiled a dynamic UML guest? Note: the patch for dyn_link.ld.in must remove the first align, but not the second (this is for 2.6 so it won't apply, but it's good as reference): --- ./arch/um/dyn.lds.S.align 2003-12-25 19:38:35.000000000 +0100 +++ ./arch/um/dyn.lds.S 2003-12-26 17:13:38.000000000 +0100 @@ -10,7 +10,6 @@ { . = START + SIZEOF_HEADERS; .interp : { *(.interp) } - . = ALIGN(4096); __binary_start = .; . = ALIGN(4096); /* Init code and data */ -- cat <<EOSIGN Paolo Giarrusso, aka Blaisorblade Linux Kernel 2.4.23/2.6.0 on an i686; Linux registered user n. 292729 EOSIGN |
From: Oleg D. <gr...@li...> - 2004-01-11 18:45:32
|
Hello! On Sun, Jan 11, 2004 at 11:49:20AM +0100, BlaisorBlade wrote: > > NS> I've been trying for days and made lots of tests and it seems that the > > NS> 2.4 UML binary can't run on a host with 2.6 kernel and nptl-enabled > > glibc. > > Hm. I guess you are running some sort of old uml code. > > The fix was oneliner and included long ago. See the patch below. > > Apply it and then recompile. > I've just looked at 2.4.23-1um and I saw that dyn_link.ld.in has not this fix. Hm. May be someone overlooked possibility to add it there as well? Bye, Oleg |
From: Nuno S. <nun...@vg...> - 2004-01-12 03:46:53
|
Oleg Drokin wrote: > Hello! > > Nuno Silva <nun...@vg...> wrote: > > NS> I've been trying for days and made lots of tests and it seems that the > NS> 2.4 UML binary can't run on a host with 2.6 kernel and nptl-enabled glibc. > > Hm. I guess you are running some sort of old uml code. > The fix was oneliner and included long ago. See the patch below. > Apply it and then recompile. > > I use 2.6.1 + glibc 2.3.2-101 from Fedora Core 1, > I hope this is new enough? ;) Thanks, but this patch is in my tree (2.4.23-um1). And, as BlaisorBlade mentions in the next message, I'm trying to build a dynamic UML -- This is mainly to try to take advantage of sysenter/sysexit. Sysenter could speedup UML a bit :) Also, the version of glibc itself says nothing about this subject. You must make sure that you're using a nptl-tls-enabled one. These optimized libraries are usually in /lib/tls/i686/cmov/* or something similar. One nice way to verify is ldd: ldd on my debian sid instalation: # 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) # ldd in my chroot (only) with optimized glibc: # ldd ./linux linux-gate.so.1 => (0xffffe000) libutil.so.1 => /lib/libutil.so.1 (0x40019000) libc.so.6 => /lib/libc.so.6 (0x4001c000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) # That "linux-gate" thing is the system call multiplexer that enables sysenter. DISCLAIMER: I'm no expert in this linker/sysenter/glibc magic so I might be wrong. The fact is that ./linux doesn't run when ldd reports "linux-gate" in it's output. I'll try BlaisorBlade's /arch/um/dyn.lds.S patch next. Thanks, Nuno Silva > > Bye, > Oleg > > --- linux-2.4.20.orig/arch/um/link.ld.in 2003-10-25 00:35:59.000000000 +0400 > +++ linux-2.4.20/arch/um/link.ld.in 2003-10-25 00:36:02.000000000 +0400 > @@ -6,7 +6,6 @@ > { > . = START() + SIZEOF_HEADERS; > > - . = ALIGN(4096); > __binary_start = .; > ifdef(`MODE_TT', ` > .thread_private : { > |