This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/11787] Program with large TLS segments fail.
- From: "bugdal at aerifal dot cx" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Sat, 27 Apr 2013 02:02:42 +0000
- Subject: [Bug libc/11787] Program with large TLS segments fail.
- Auto-submitted: auto-generated
- References: <bug-11787-131 at http dot sourceware dot org/bugzilla/>
http://sourceware.org/bugzilla/show_bug.cgi?id=11787
Rich Felker <bugdal at aerifal dot cx> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bugdal at aerifal dot cx
--- Comment #37 from Rich Felker <bugdal at aerifal dot cx> 2013-04-27 02:02:42 UTC ---
For what it's worth, the strategy we're using in musl seems to work well:
1. For implementation-allocated stacks, the requested size is always available
to the application. TLS and guard size are added onto that for the allocation.
2. For application-provided stacks, if the size of TLS is greater than 2k or
greater than 1/8 of the provided stack space, additional space for the
TCB/TLS/etc. is allocated and the provided stack is used only for actual stack.
This ensures that application expectations are met: automatic variables in the
thread have addresses in the specified range, and the amount of stack space
available is "close enough" to what the application requested that, if it
overflows, it's reasonable to say it's the application's fault for not leaving
a better margin of error.
I'm not sure how easy it would be to make glibc/NPTL use separate regions for
the stack and TLS though...
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.