[Sorry for the delay: holiday and illness collide.]
On Tue, 17 May 2005, [EMAIL PROTECTED] announced authoritatively:
> 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?
`Expand', from SMTP. i.e., `what warnings?' :)
> Also, -lutil is passed to GCC, so what the hell is happening here? And which
> binutils/GCC versions are you using?
binutils 2.15.94.0.2.2, 2.16.90.0.3; GCC-3.4.3.
> 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.
Yes, -print-file-name is the right approach, I think.
>> - 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.
Well, it's to make it TLS without bothering the userspace apps with the
fact that it's TLS, and allowing the implementation of TLS to change under
the covers without changing the ABI.
>> - 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.
Yep. Basically it has to hack TLS itself, and the way it does it incurs
extra overhead on every context switch, unlike TLS.
>> - 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.
Well, the tls.pdf site is describing *how TLS is implemented*; this is more
`what errno uses in addition to TLS'. At bottom NPTL errno is a TLS
variable, but glibc goes through considerable dancing so that apps that
link against it don't need to know that.
Alas, that means that you can't portably rely upon the TLS stuff not
changing :(
> Also, about TLS and such: do you know where I can download the userspace
> example code?
Is there any? Given a suitable glibc, you should just be able to declare
a variable __thread and have it Just Work.
> 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
TLS should work --- but last I tried it UML was still allergic to
TLS. (I guess the whole point of all this is to fix that, though.)
>> (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).
Oh gods, I'd quite forgotten about the myriads of non-TUN/TAP network
drivers. (How many people use the non-TUN/TAP stuff, anyway?)
>> > 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).
The default linker scripts for all the shared library variations say
things to the effect of
.bss :
{
*(.dynbss)
*(.bss .bss.* .gnu.linkonce.b.*)
*(COMMON)
/* Align here to ensure that the .bss section occupies space up to
_end. Align after .bss to ensure correct alignment even if the
.bss section disappears because there are no input sections. */
. = ALIGN(8);
}
. = ALIGN(8);
so, as for executables, you won't see common stuff in shared libraries.
(I confused myself because of course you *will* see them in the object
files that go to make those shared libraries up.)
See the node `Input Section Common' in the GNU ld manual.
I'm not sure when this was added, as there's no changelog entry: it's as
old as binutils CVS, so it comes from before 1999.
In light of that, how on earth are any systems managing to create common
symbols in shared libraries?
Or are these copies of libpcap static libraries? If so, I can't see any
way to forbid common symbols in *there* without breaking convenience
libraries for many projects. ar(1) can't tell which it's being called to
create, and given the predominance of shared libraries these days, the
likelihood is that the library is shared.
>> 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.
Oh, right, if the libpcap of reference is not a shared library --- which
it seems it likely isn't --- then you're stuffed, clever ELF tricks
won't work, and you'd have to resort to objcopy --localize-symbol or
kernel-side renaming.
> I guess I'll really prefer -Dvmap=kernel_vmap for this sort of stuff...
Icck.
>> (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...
Working in banking -> come-in-at-9am-or-earlier-or-die :( I'm *not* a
morning person, dammit.
--
`Once again, I must remark on the far-reaching extent of my
ladylike nature.' --- Rosie Taylor
-------------------------------------------------------
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
