This is the mail archive of the
mailing list for the glibc project.
Re: why Glibc does not build with clang?
- From: Rich Felker <dalias at libc dot org>
- To: David Miller <davem at davemloft dot net>
- 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 14:14:53 -0400
- 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> <20140524 dot 135403 dot 1640156701388971934 dot davem at davemloft dot net>
On Sat, May 24, 2014 at 01:54:03PM -0400, David Miller wrote:
> From: Rich Felker <email@example.com>
> Date: Sat, 24 May 2014 10:51:39 -0400
> > On Sat, May 24, 2014 at 04:46:03PM +0200, Andreas Schwab wrote:
> >> Rich Felker <firstname.lastname@example.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 consider this an implementation detail. *Conceptually*, in the
general case, nested functions require trampolines or a function
pointer representation that includes a hidden data pointer, and
special-casing certain uses is, conceptually, an optimization,
regardless of where the special-casing takes place in the
> I believe that a lot of people reading this thread see your arguments
> as quite a stretch at this point.
Yes, and it's getting pointless to argue over it. I consider nested
functions fundamentally wrong and harmful and I've explained the
reasons. If others disagree, there's nothing really left to discuss
and we should just drop the topic.