Date: Wed, 17 Oct 2012 09:48:56 +0200 From: musl <b.brezillon.musl@...il.com> To: musl@...ts.openwall.com Subject: Re: TLS (thread-local storage) support On 17/10/2012 03:58, Rich Felker wrote: > On Wed, Oct 17, 2012 at 03:49:33AM +0200, boris brezillon wrote: >> 2012/10/17 Rich Felker <dalias@...ifal.cx>: >>> On Wed, Oct 17, 2012 at 02:08:11AM +0200, boris brezillon wrote: >>>>>> I agree. This should be made optional. But if we don't compile libc >>>>>> with fsplit-stack (-fnosplit-stack). >>>>>> Each call to a libc func from an external func compiled with split >>>>>> stack may lead to a 64K stack chunk alloc. >>>>> Where does this allocation take place from? There should simply be a >>>>> way to inhibit it. >>>> In the linker (gold linker). >>> Well gold isn't running at runtime. I assume you mean it _arranges_ >>> for this allocation to take place somehow, and that's what I'm >>> wondering about whether there's a way to avoid. >> The easiest way to avoid big stack chunk allocation is to compile musl >> with -fno-split-stack option. >> This will not add any overhead to functions (no split stack prolog) >> And this will add a note to the shared object which tells the linker >> to avoid __morestack to __morestack_non_split replacement. > Where is this documented? The GCC manual doesn't mention anything > about -fno-split-stack having special behavior like that, so for lack > of any documentation otherwise, it "should" just be the option to turn > off -fsplit-stack.. You're right, I misunderstood how -fno-split-stack was implemented. I tried to compile a source file with -fno-split-stack and didn't find any 'no-split-stack' note in the generated object file. When I compile it with -fsplit-stack both 'no-split-stack' and 'split-stack' notes are added. > > I'm not claiming you're wrong, just that this all seems poorly > documented. > > Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.