On Tuesday 17 May 2005 01:17, Nix wrote: > On Tue, 17 May 2005, [EMAIL PROTECTED] yowled: > > On Saturday 14 May 2005 14:00, Nix wrote: > >> At any rate, specifying the paths explicitly won't do any harm > >> anywhere. :) > > > > On 2.6 we just removed -L/usr/lib from the linker command line because > > of some warnings. > > EXPN? What's EXPN? > (Are they serious? What are they?) Guess not normally, however Al Viro dropped that because he wants to do cross build, so that's definitely not to reintroduce.
Also, -lutil is passed to GCC, so what the hell is happening here? And which binutils/GCC versions are you using? However, here's probably the solution (taken from .../tt/Makefile): gcc -print-file-name=libutil.so /usr/lib/gcc/i686-pc-linux-gnu/3.4.3-20050110/../../../libutil.so (We need to choose libutil.a / libutil.so by hand, but that's not bad). I guess that a cross-GCC will make that work well. > > So, we could conditionalize that (maybe -D_SEARCH_PATH=). > > I'm not going to merge it in this form, so send me the cleaned up > > version. > If I could work out what to conditionalize it on, sure. > We could search only /lib, and skip /usr/lib: I think libutil is there > on every Linux platform, at least. (Do we care about portability to > non-Linux hosts? I don't *think* so...) Not for now. > - in libc proper, __errno_location returns, um, the address of the errno > variable. This seems like a waste of time, but it means that the errno > variable can be *hidden* from outside glibc, and its address can > change. And it does. (see glibc/sysdeps/generic/errno-loc.c). Yes, it's to make it TLS. > - under LinuxThreads, in single-threaded programs, `errno' is a real > variable, and in multi-threaded programs on non-TLS platforms or those > not supporting __thread, __errno_location() is overridden by libpthread > to return a value appropriate to the thread using LinuxThreads's nasty > and inefficient approximation to TLS, which requires > (see glibc/linuxthreads/errno.c.) I wondered about this. The other day I saw it implemented in the thread_desc (something like that) struct. > - Under NPTL, and under LinuxThreads on a __thread, TLS-supporting > platform (i.e., on glibc compiled for i686 and above, with GCC 3.4+), > glibc exports a GLIBC_PRIVATE thread_local symbol named errno, > which __errno_location() picks up. This symbol is exported in the > GLIBC_2.0 symbol version set if TLS is not in use: if it is, then > that symbol has no sensible value, and it's not exported at all. > Note that the actual storage of errno under NPTL is a matter of > cooperation between GCC, glibc and GNU ld: glibc declares errno with the > __thread storage class specifier, and GCC proceeds to emit a stereotyped > instruction sequence with suitable relocations Is all this a resume of what "tls.pdf" from Ulrich Drepper site goes describing in detail? If so, I'll study it later. Also, about TLS and such: do you know where I can download the userspace example code? I'd like to use some kind of semaphores in UML for cooperation between host threads. Currently it suspends by read/writing a byte on a pipe (probably like make -j does, since I heard make was broken by recent Linus pipe rework). > > 2) /usr/lib/libpcap.so ships with a global symbol named "vmap" which > > overlaps with the kernel vmap() function. > Joy. Thankfully you have many ways around this: ELF is flexible. Alias > symbols may be the simplest (alias vmap() to something else and refer to > the something else, or use symbol versions to declare vmap() as private > to this executable, or even, ick, #define it to something else. Or the > approach outlined at the end of this mail, which is arguably even > uglier). > (Um, why is UML linking against libpcap? Or don't I want to know?) The net pcap transport. Only when it's enabled UML links with pcap (verify only with 2.4, not with 2.6). > > The questions are: > > - shouldn't common symbols in libraries be forbidden > > Since GCC generates unintialized non-static globals that way (because it > saves space in the executable), er, no. Normally you *want* globals to > be, er, global. :) No, I don't mean BSS, I mean common symbols. It's the linker practice which makes: int i; work like: extern int i; and for which -fno-common exists (and is used by the kernel, btw). > > - I've verified that that symbol could be static (it's a var. of a type > > declared in the object and there are no relocation pointing to it, and > > the linker is not allowed to resolve the relocations there). Isn't that > > stupid? > Yes :/ Feel free to patch libpcap's optimize.c: it's the definer and the > only consumer of vmap, so it should be static. (It doesn't even need to > be hidden!) > > Would this be fixable at distro's level? > Yes. It's arguably a (small) libpcap bug. > > (Note that I already played dirty linker tricks as in > > arch/um/kernel/tt/Makefile). > You can get in the way of that symbol resolution by creating a shared > library (libpcapture.so?) with the -Wl,--auxiliary flag, specifying > libpcap in there and linking against libpcapture: symbols defined in > libpcapture will be used in preference to those in libpcap, so you > could capture vmap() in there and call the original kernel function, > though that means exporting that function from the main executable > and it may get more annoying than it's worth. Wait, I guess we won't install libpcapture.so on the host, and possibly not even link dinamically to it, maybe because I want to link the lib into pcap.o while keeping the latter object as relocatable, and linking it into vmlinux without changing its command line. I guess I'll really prefer -Dvmap=kernel_vmap for this sort of stuff... > (I can send you a trivial example of this sort of weird trickery if you > want, but not in this mail as it's past midnight and I need some > sleep. Alarm goes off at 6:30am. Working for banks sucks sometimes... :/ Banks? It's something I don't want to know about, I guess... -- Paolo Giarrusso, aka Blaisorblade Skype user "PaoloGiarrusso" Linux registered user n. 292729 http://www.user-mode-linux.org/~blaisorblade ------------------------------------------------------- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412&alloc_id=16344&op=click _______________________________________________ User-mode-linux-user mailing list User-mode-linux-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
