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: David Miller <davem at davemloft dot net>
- To: dalias at libc dot org
- Cc: schwab at linux-m68k dot org, roland at hack dot frob dot com, konstantin dot s dot serebryany at gmail dot com, libc-alpha at sourceware dot org
- Date: Sat, 24 May 2014 13:54:03 -0400 (EDT)
- Subject: Re: why Glibc does not build with clang?
- Authentication-results: sourceware.org; auth=none
- References: <20140524142902 dot GP507 at brightrain dot aerifal dot cx> <874n0fi6ac dot fsf at igel dot home> <20140524145139 dot GQ507 at brightrain dot aerifal dot cx>
From: Rich Felker <dalias@libc.org>
Date: Sat, 24 May 2014 10:51:39 -0400
> 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.
GCC makes this decision at the code generation phase, long before
any optimization passes are run, last time I checked.
I believe that a lot of people reading this thread see your arguments
as quite a stretch at this point.