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

["earthdok at google dot com" <sourceware-bugzilla at sourceware dot org>]

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

--- Comment #29 from Sergey Matveev <earthdok at google dot com> ---
(In reply to Rich Felker from comment #27)
> I don't see how what you're doing can work at all except by chance unless
> you are completely refraining from using any libc functionality in the
> cloned "thread" which is neither a valid thread nor a valid process from
> libc's perspective. This is making me more and more doubtful that glibc or
> any other libc could provide a suitable permanent API contract suitable to
> your needs without severely constraining its own internals in ways that
> affect large parts of the  implementation.

Ugly as our approach may be, I don't see how it affects us in the context of
our present discussion. If we were to use a proper separate process, that would
not  make the task of discovering the DTLS ranges any easier.

Moreover, the reason why we avoid calling libc functions from the cloned task
is not _just_ because it is not a proper thread. It's also because the other
threads are frozen at arbitrary points while the cloned task runs, and some of
them could be holding libc locks. So even if we took the opposite road of using
a regular posix thread (which is possible - just broker out the ptrace code to
a separate process, make it attach to every thread except the current one, and
do the actual work in the current thread) we still wouldn't want to call libc
functions from it.

So we don't need an interface that we could use from the cloned task. What we
actually need is an interface that would give us the DTLS ranges at some point
prior to launching the cloned task, and somehow ensure they're still valid when
it runs.

Callbacks are a natural fit for this. If glibc cooperates by calling our
callbacks immediately after a DTLS block allocation and immediately before
deallocation, and the callbacks record those events atomically, then we can
freeze the thread at an arbitrary point and be sure that our record of what the
DTLS looks like is up-to-date.

If, on the other hand, we are only allowed to ask glibc about the current state
of the DTLS, then we must query it immediately before launching the cloned
task, while somehow preventing it from changing until the threads are actually
frozen. I don't see a good way to do that, short of having glibc protect the
DTLS code with a global lock.

> As for the need to do these hacks, both ptrace and
> process_vm_readv/process_vm_writev provide access to the traced process's vm
> space. Is the reason you need to share virtual address space with the traced
> process simply for the sake of performance?

Yes. Given that we need to scan most of the memory used by the process, using
PTRACE_PEEKTEXT would be impractical. I wasn't aware of process_vm_readv
before, so I don't have any benchmarks at hand. If we were to switch to this
method, I can think of some ways to _maybe_ get reasonable performance, at the
cost of a substantial increase in complexity.

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