This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]