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, 30 Jan 2014 05:13:54 +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 #28 from Kostya Serebryany <konstantin.s.serebryany at gmail 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.
You are absolutely right, we are not using anything from libc in that special
"thread".
> 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.
Note that the interface we are asking for is not to be called from the
"special"
thread. We need to call it in regular threads, and not only for LeakSanitizer
which uses this special thread, but also for other tools
that don't do it.
> 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?
Sergey?
--
You are receiving this mail because:
You are on the CC list for the bug.