This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: why Glibc does not build with clang?
- From: Rich Felker <dalias at libc dot org>
- To: Andreas Schwab <schwab at linux-m68k dot org>
- Cc: Roland McGrath <roland at hack dot frob dot com>, Konstantin Serebryany <konstantin dot s dot serebryany at gmail dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Sat, 24 May 2014 10:51:39 -0400
- Subject: Re: why Glibc does not build with clang?
- Authentication-results: sourceware.org; auth=none
- References: <CAGQ9bdw135gBO+cTQx3Ws1GrRgFsi8-j=Y_mZ=ixebpPzB4gXw at mail dot gmail dot com> <20140523214019 dot DA9FF2C3975 at topped-with-meat dot com> <20140524142902 dot GP507 at brightrain dot aerifal dot cx> <874n0fi6ac dot fsf at igel dot home>
On Sat, May 24, 2014 at 04:46:03PM +0200, Andreas Schwab wrote:
> Rich Felker <dalias@libc.org> writes:
>
> > Nested functions are a feature that fundamentally requires producing
> > an insecure executable/library (executable-stack flag)
>
> Only if you pass the address of it out of the containing function.
That's my "_except_ in cases where the compiler optimizes out that
need." I'm quite aware that in the current usage cases in glibc, with
current compiler optimizations, the need is optimized out. What I
object to is relying on this optimization to satisfy a security
contract.
BTW one could imagine "reasonable" uses where the address gets "passed
out" of the containing function to another small static function; in
such cases, whether the resulting code requires executable stack, even
with current compilers, likely depends on the level of inlining and
inter-procedural optimization.
Rich