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/16291] feature request: provide simpler ways to compute stack and tls boundaries


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.


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