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

["carlos at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

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

--- Comment #33 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Kostya Serebryany from comment #32)
> > Instead of a callback could we use a systemtap probe with the right
> > arguments? We have precedent set for adding probes to libc and it would be
> > easy to do with the current infrastructure and low-overhead.
> 
> I admit I have not investigated systemtap properly (need to install a newer
> Linux distro first). However, from what I see systemtap is not enabled by
> default 
> in glibc build and requires extra packages to be installed on the system.
> Which means that some lsan/msan users will be left behind 
> (those who can't install extra packages) and we'll be forced to keep the hack
> for the fallback, which defeats the purpose of having the right solution. 

For RHEL and Fedora we always enable systemtap. It is a requirement that the
users kernel have kprobes enabled.

The reason I mention systemtap is that it gives you a richer and more flexible
way to look at the internals of glibc in realtime.

> Besides there is a consistency reason (which is not necessary relevant for
> you).
> Sanitizers already heavily rely on interposition for many cases, 
> including all cases where glibc has systemtap hooks, but not limited to that.

That's fine, and you can continue to user interposition. I'm not saying you
shouldn't. I'm just saying that for TLS and stack extents we may wish to create
a probe point that we declare stable for tool usage.

> Even if we used systemtap for pthread events, at least one hook
> is not usable for us (in pthread_create, we actually replace one of the
> parameters, which systemtap does not allow, afaict).

systemtap allows modifying all parameters and having those modifications impact
the running application. In fact I use systemtap all the time to inject
failures into glibc code in realtime for testing.

I hope that I don't sound like I'm telling to use systemtap. Far from it. I'm
just suggesting an option, and trying to figure out if this option is or is not
a good match for what you want.

In summary:
- Needs kprobes.
- Deep introspection with internal glibc probe points.
- Ability to modify arguments.

The in-process function call is probably still faster...

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