This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


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

Re: [RFC] [PATCH, AARCH64] Machine descriptions to support stack smashing protection


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
joseph@codesourcery.com


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