On Wed, 20 Nov 2013, Venkataramanan Kumar wrote: > > I would like to see a clear description of what happens with all eight > > combinations of (glibc version does or doesn't support this, GCC building > > glibc does or doesn't support this, GCC building user program does or > > doesn't support this). Which of the (GCC building glibc, glibc) > > combinations will successfully build glibc? Will all such glibcs be > > binary-compatible? Will both old and new GCC work for building user > > programs with both old and new glibc? > > Can you please clarify why we need to consider "the gcc compiler that > builds the glibc" in the combinations you want me to describe. I am > not able to understand that.
Let's imagine this support goes in GCC 4.9 and the glibc support goes in glibc 2.19, whereas GCC 4.8 and glibc 2.18 are versions without this support. * Building glibc 2.18 with GCC 4.8 already works (I presume). * Suppose you use GCC 4.9 to build glibc 2.18. Does this work? If it works, it must produce a glibc binary that's ABI compatible with one built with GCC 4.8, meaning same symbols exported at same symbol versions. * Suppose you build glibc 2.19 with GCC 4.8. Does this work? If it does, then it must be ABI compatible with 2.18 (meaning the symbols exported at GLIBC_2.18 or earlier versions must be exactly the same as exported at those versions in 2.18). * Suppose you build glibc 2.19 with GCC 4.9. This needs to work and must again produce a binary compatible with the previous ones. Note: there is no current glibc support for architectures that gained TLS-based stack guards after 2.4 (meaning they need both a TLS-based scheme and backwards compatibility for binaries using __stack_chk_guard), and your glibc patch doesn't seem to add any. It looks to me like your glibc patch would have removed the __stack_chk_guard symbol and so failed ABI tests (this symbol being defined only if THREAD_SET_STACK_GUARD isn't defined) - you didn't make clear if your patch was tested with the glibc testsuite including passing the ABI tests. The normal presumption is that it's not acceptable to remove exported symbols from glibc as some application might be using them. You need to ensure that, when new glibc is built, whatever compiler it's built with, it continues to export the __stack_chk_guard symbol at version GLIBC_2.17. Furthermore, if any released GCC version would generate references to __stack_chk_guard when compiling code for AArch64 with stack protection, you need to ensure __stack_chk_guard is a normal symbol not a compat symbol so that people can continue to link against new glibc when using old GCC. If it's only a limited range of development versions of GCC that could have generated code using __stack_chk_guard because released versions didn't support stack protection on AArch64 at all, a compat symbol would probably be OK (but you should still ensure that the variable gets initialized with the correct value for any applications built with those development versions of GCC). -- Joseph S. Myers jos...@codesourcery.com
