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] |
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] |