This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: aux-syscalls change
Hi -
> > I am a bit surprised by the subject patch (commit fd6324c). Amongst
> > its effects is to always include these lookup tables in a generated
> > object code, if any other part of aux_syscalls is being called.
>
> Yes, but they are small. And they save space overall.
No, they do not, if one compares a plain script-function reference to
aux_syscalls. This part could be fixeed by moving the new lookup
array variable decls into the embedded-C functions bodies as static
variables.
> [...] Why use embedded C instead of scripts? Because the values we
> need to lookup are sometimes architecture or OS version dependent.
> And sometimes we need to do these lookups from other embedded C
> functions. For example, look at the old sources for get_mmap_args
> in aux_syscalls. [...]
OK, these are not bad reasons, but there also does not seem to be a
good reason to keep rewriting this bunch of undesirable code either.
Let us work toward a more complete solution than tiny improvements.
> Why can't something like $argstr be generated automatically?
You're right - it probably can be, once bug #3672 is dealt with.
> If there is an arg "struct timeval __user *tvp" and a script tries
> to print $tvp, could it not automatically be copied from userspace
> and decoded?
As you know, the debugging data does not currently include attributes
like "__user". OTOH, we may be able to apply heuristics that guess,
based upon the pointer value, whether it's user- or kernel-space. Can
there be a version of kta() for data?
- FChE