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: OndÅej BÃlka <neleai at seznam dot cz>
- Cc: Florian Weimer <fweimer at redhat dot com>, Will Newton <will dot newton at linaro dot org>, Konstantin Serebryany <konstantin dot s dot serebryany at gmail dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Date: Fri, 16 May 2014 19:20:20 -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> <53760025 dot 10204 at redhat dot com> <CANu=DmhF=PZBVHtOPw5ZMCHjcy6vqdCvrRvY+xO9hzfkjTCRQA at mail dot gmail dot com> <53760826 dot 6090203 at redhat dot com> <20140516135304 dot GA29829 at domone dot podge> <20140516190504 dot GF507 at brightrain dot aerifal dot cx> <20140516203140 dot GA16889 at domone dot podge> <20140516213200 dot GG507 at brightrain dot aerifal dot cx> <20140516225608 dot GA17863 at domone dot podge>
On Sat, May 17, 2014 at 12:56:08AM +0200, OndÅej BÃlka wrote:
> > > > The cost of a function call to look up the current stack boundaries
> > > > (or a TLS access to get that info on some archs where TLS access is
> > > > expensive) defeats much of the purpose of using alloca.
> > > >
> > > Oh really? It does not follow malloc also needs tls so you will always
> > > be faster.
> >
> > If TLS is the dominating factor (think old MIPS where the instruction
> > to read the TLS register traps and gets emulated by the kernel), it
> > brings the cost of alloca up on par with malloc, no?
> >
> It does but question is if it will be enabled.
>
> > > Also you could avoid that check most times by checking
> > > request if you crosses page boundary or creating lookup table which page
> > > belongs to which tread.
> >
> > Perhaps, but this gets to be a lot more overhead/complexity for little
> > if any demonstrable gain.
> >
> If there is little gain then you do not have to worry about performance
> degradation in first place.
Obviously originally there was a performance benefit to alloca. The
"little demonstrable gain" was referring to the situation where you've
already made alloca costly (possibly on par with malloc) to deal with
its other flaws.
> > > > Moreover, turning alloca failures into "reliable crashes" is not a
> > > > solution. If an operation requires allocation which could fail, it
> > > > must be able to back out whatever work it already did and report
> > > > failure. Crashing is not an acceptable implementation.
> > > >
> > > No, when it is third party codebase and it does not want to rewrite
> > > existing code do you have a better proposal?
> >
> > I was talking about internal usage of alloca in glibc. I don't think
> > glibc can fix use in third-party software.
> >
> I was not talking about glibc, I was saying how to fix alloca in general.
> This could make check reliably any alloca in system if you recompile
> binaries.
Supposedly GCC already has an option to reliably crash (when expanding
the stack by more than a page, write at least one byte to each page,
in order). I have not teasted it heavily though.
Rich