This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

TLS errno/h_errno/_res vs old ABI


I have some changes ready to go in that fix the TLS errno changes so that
the new code actually gets used, and change h_errno and _res in the same
way that errno was changed already.  However, I am holding off on checking
these in because I am concerned about how we are changing the ABI.  (I also
have some fixes to the TLS code and I'm holding off on checking any of this
in because the only gcc and binutils patches available that claim to
support TLS and __thread in fact have bugs that louse up the libc build
badly, and there are not yet new patches confirmed to work right.)

The GLIBC_2.0 version set contains errno, _errno, h_errno, _h_errno, and
_res.  In all extant libc.so binaries these are global STT_OBJECT .bss
symbols.  Existing program binaries may refer to these symbols for normal
data accesses, and if they are single-threaded programs this has always
been fine.  With my changes and the TLS support as it stands, the STT_TLS
references in libc.so resolve to the executable's fixed-address .bss
symbols with no complaint, and much fun ensues.  It's not hard to either
flag that mismatch in the dynamic linker or avoid it by renaming.  But
there is no solution within the TLS spec that will behave as these programs
require: having libc's TLS accesses to errno et al refer to the
executable's single .bss location.  We could do a weird hack in the TLS
support to make that possible, but that can never work if we want to
compile libc with the initial-exec model.

In a random sampling (/usr/bin/* on the GNU/Linux machine in front of me),
there are a few dozen programs using errno/_errno, and a couple using _res.
It stands to reason there are some around using h_errno/_h_errno as well.

I don't know off hand if there were or weren't earlier glibc versions in
which errno, h_errno, and _res were not always defined as macros as they
are now.  If there really never were, and it was never officially kosher to
have plain extern or bss decls of these variables, then I won't object to
breaking them if that's what people want.  But I imagine someone will object.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]