[uml-devel] strace of "ls" under Fedora Core 3

[uml-devel] strace of "ls" under Fedora Core 3

[Marion Bates]

[this is Marion channeling Bill.]

	As a quick reminder, Marion and Bill are trying to get i386 fedora 
core 3 running under uml (2.6.4, with the i386 emulation code) on ford 
(x86_64).  The uml binaries don't have TLS support, so we've renamed 
all of: /lib/tls. /usr/lib/tls, and /usr/X11R6/lib/tls directories.
	Even with that done, we're getting "cannot set up LDT for thread-local 
storage" as an error message when running something as simple as 
/bin/ls.  It appears that there's TLS system calls in the binary 
itself, not just in the */lib/tls libraries:

...
brk(0)                                  = 0x805d000
brk(0x807e000)                          = 0x807e000
brk(0)                                  = 0x807e000
shutdown(1610612264, 81)                = -1 ENOSYS (Function not 
implemented)
modify_ldt(0x1, 0x5ffffe28, 0x10)       = -1 ENOSYS (Function not 
implemented)
write(2, "cannot set up thread-local stora"..., 36cannot set up 
thread-local storage: ) = 36
write(2, "cannot set up LDT for thread-loc"..., 43cannot set up LDT for 
thread-local storage
) = 43
write(2, "\n", 1
)                       = 1
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++

	The "modify_ldt" call looks ominous; In a perfect world, wouldn't the 
/bin/ls binary realize it didn't have any tls library support and not 
use TLS system calls?
	Yeah, right.  We can only hope.  :-)

	Any ideas?
	- A befuddled Marion and Bill




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] strace of "ls" under Fedora Core 3

[Blaisorblade]

On Wednesday 09 February 2005 21:12, Wichmann, Mats D wrote:
> > As a quick reminder, Marion and Bill are trying to get
> >i386 fedora
> >core 3 running under uml (2.6.4, with the i386 emulation code) on ford
> >(x86_64).

Well, the problem is that UML for x86_64 is not yet complete, especially for 
the 32-bit compatibility code, as stated by Jeff. This is what creates you 
those problems.

You should absolutely run a 32-bit UML if you want good support for 32-bit 
programs.

To compile it, either you set up well the compilation environment for 32-bit 
programs or you build the binary on a 32-bit host distro.

> >The uml binaries don't have TLS support, so we've renamed 
> >all of: /lib/tls. /usr/lib/tls, and /usr/X11R6/lib/tls directories.
> > Even with that done, we're getting "cannot set up LDT
> >for thread-local
> >storage" as an error message when running something as simple as
> >/bin/ls.  It appears that there's TLS system calls in the binary
> >itself, not just in the */lib/tls libraries:
>
> I'm not sure this call is a TLS thing.
I can add that it is *not* a TLS thing absolutely for sure...

Also, the code inside UML should absolutely support it (from the code I don't 
see any problem), at least for the x86 UML.
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] strace of 'ls' under Fedora Core 3

[stian]

> Also, the code inside UML should absolutely support it (from the code I
> don't
> see any problem), at least for the x86 UML.

modify_ldt is a x86 syscall aswell, so it will only appear in x86/x86_64
umls. It was implemented and used by dosemu project originally.

What actually uses this syscall as I find the syscall to be badly
documented last time I looked at it.



Stian Skjelstad


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] strace of 'ls' under Fedora Core 3

[Blaisorblade]

On Thursday 10 February 2005 12:42, stian@nixia.no wrote:
> > Also, the code inside UML should absolutely support it (from the code I
> > don't
> > see any problem), at least for the x86 UML.
>
> modify_ldt is a x86 syscall aswell, so it will only appear in x86/x86_64
> umls.
Yes, agreed... x86 UML supports it, but x86_64 UML does not (yet). I maybe was 
not clear that this is a missing feature, or a bug, or a 
put-another-name-for-ants-wasps-and-such-here.

Jeff stated that in 64-bit UML the 32-bit compatibility code is still gross 
(in fact he hasn't yet started merging it).

However, the GDT/LDT on x86_64 have a reduced role.... maybe they are 
supported in the 32-bit userspace / 64-bit kernel case, but surely not for 
the pure 64-bit case (wonder how TLS is done there).
> It was implemented and used by dosemu project originally. 

> What actually uses this syscall as I find the syscall to be badly
> documented last time I looked at it.
The TLS code... (Thread Local Storage).

In short, if you put a certain value in the (let's say) ES (or FS, or GS) 
register (they are segment selectors), it can point to an entry in the LDT 
(which you create with modify_ldt).

It means that if I read the address NNNN inside the ES segment (in assembler 
ES:NNNN in Intel notation), it will point to the NNNN address inside the 
segment (i.e. you have one "base address" to add to NNNN which can be != 0). 
Normal reads are done from the DS (for Data) and CS (for code) segments.

Now, if you switch the entry number in ES for each thread (probably this is 
done at startup and we rely on nobody else modifying the ES value, which is a 
valid guarantee), you get that each thread, with ES:NNNN, will access a 
different var (by creating one area for each thread and putting the base 
addresses of these areas inside various LDT entries).

I can confirm glibc uses modify_ldt() for TLS support on LinuxThreads. With 
NPTL, they use 2.6 host kernel support - instead of having 8192 maximum 
thread number (because this is the size of the LDT), one entry of the GDT is 
used, and for each task the kernel saves the appropriate segment descriptor.
-- 
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729
http://www.user-mode-linux.org/~blaisorblade




-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel