This is the mail archive of the glibc-bugs@sourceware.org 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]

[Bug libc/11787] Program with large TLS segments fail.


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.


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