[Bug libc/16291] feature request: provide simpler ways to compute stack and tls boundaries

earthdok at google dot com sourceware-bugzilla@sourceware.org
Wed Jan 29 18:50:00 GMT 2014


https://sourceware.org/bugzilla/show_bug.cgi?id=16291

--- Comment #26 from Sergey Matveev <earthdok at google dot com> ---
>> Is there a reason you're not simply using pthread_create to create this thread?

The task must belong to a different process group, because ptrace cannot attach
to tasks within the same process group. We also cannot use a full-blown
separate process for this because we need direct access to the parent's address
space.

Even if we could ptrace between threads, it still wouldn't be safe to call
glibc functions while other threads are frozen at arbitrary points.

>> I also think it may be unsafe to call it from a "thread" created with raw clone, but this really applies to ANY libc function (even the others we're proposing); all libc functions are free to assume they have a valid thread pointer, TCB, TLS, DTV, etc. which LeakSanitizer cannot provide without poking badly at glibc internals.

Right, the difference is that for functions like __libc_get_stack_bounds(), we
don't have to call them during the "stop-the-world" phase. We can query the
stack bounds once (immediately after the thread is created) and store them in
our own thread registry, which we can safely access from the cloned task later.
We cannot reliably do this to DTLS with the "iterator" interface you proposed.
If we queried this information at some point prior to freezing the threads, we
would have no way of knowing that it's not gone out of date by the time we
actually freeze them.

-- 
You are receiving this mail because:
You are on the CC list for the bug.



More information about the Glibc-bugs mailing list