[RFC] gradually moving strace from ptrace to perf
dvlasenk at redhat.com
Wed Oct 2 11:13:21 UTC 2013
On 09/24/2013 03:11 PM, Jan Kratochvil wrote:
> On Tue, 24 Sep 2013 14:51:41 +0200, Denys Vlasenko wrote:
>> What happens here is that traced process exited by the time
>> strace saw open() syscall data. Fetching of filename didn't
>> succeed, strace got ESCRH trying to do that:
> I had some alternative attempt using systemtap instead:
> That download URL is invalid there now:
> git clone git://git.jankratochvil.net/staptrace
> The whole output trace line is created in kernel so it has access to all the
> needed parameters content.
I'm not too familiar with systemtap, please correct me if
I'm wrong anywhere in my musings below:
IIUC, this approach, if implemented fully, would move
most of strace's syscall decoding machinery to kernel,
what would be passed back to userspace are the strings
of generated output.
I don't see this as a bad design outright:
in many difficult debug situations, will people trade
such an intrusion in the kernel space for the large
performance enhancement? Yes, in a heartbeat.
If code size is a concern, it can be a compiled as a module
and insmod'ed only when needed.
To do something like this, I would want to reuse strace's
C code of syscall decoders with as small modifications
as possible (i.e. want to avoid a complete rewrite,
especially to a different language).
Is this achievable with systemtap?
Will it be possible to use systemtap-based
strace by non-root users?
More information about the Strace-devel