This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/16291] feature request: provide simpler ways to compute stack and tls boundaries
- From: "konstantin.s.serebryany at gmail dot com" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Thu, 23 Jan 2014 15:57:15 +0000
- Subject: [Bug libc/16291] feature request: provide simpler ways to compute stack and tls boundaries
- Auto-submitted: auto-generated
- References: <bug-16291-131 at http dot sourceware dot org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=16291
--- Comment #15 from Kostya Serebryany <konstantin.s.serebryany at gmail dot com> ---
>> You also need to think about what security implications there are about
>> such an API, if any.
I am not a security expert, but looks like getting the information
in a non-portable hackish way is possible today w/o any additional interfaces.
>> Could you suggest an API?
Let me try...
Today we have a global variable __libc_stack_end.
For stack and static TLS we may have thread-local vars that point
to thread/tls bounds.
__libc_thread_stack_begin
__libc_thread_stack_end
__libc_thread_static_tls_begin
__libc_thread_static_tls_end
A function that returns these values for the current thread would
be fine too, as long as that function does not call anything else
(god forbid, malloc)
For the main thread's stack it's ok to have only one of the stack bounds
meaningful.
Dynamic TLS is indeed harder.
Is it possible to register a callback which will be called from glibc whenever
it adds/removes a dynamic TLS slot for every thread?
__libc_register_dynamic_tls_slot_update(
void (*f)(void *beg, void *end,
int created /*1 for creation, 0 for deletion*/));
--
You are receiving this mail because:
You are on the CC list for the bug.