This is the mail archive of the mailing list for the glibc 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: why Glibc does not build with clang?

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.


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