This is the mail archive of the systemtap@sources.redhat.com 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: Some notes on translation


Hi, Tom -


> [...]  What I'm thinking of doing is hand-coding a functional kprobe
> handler (not using jprobes) that would look something like what
> would be output from the translation phase, probably a variation on
> one of the probes I outlined here.  [...]

One of the prototypes we built at Red Hat back over the christmas
break was exactly along these lines.


> It would use dwarf2 information to access the probed function
> parameters (I'd have to do some reading of the dwarf2 spec but it
> shouldn't be a big deal to do something simple like figure out where
> an int parameter is for instance), [...]

This part takes more work than is obvious.  One needs to:
- map the probe insertion point (function/address) to the debug
  info entry for that batch of code
- traverse the formal/actual argument list descriptors
- this will generally identify a register, which we can access via
  the kprobes pt_regs struct
- in the absence of full "location list" data, which would give
  multiple positions (registers/stack addresses) of a variable as a 
  function of PC, we need to find another PC address at which the 
  single location (as currently represented by gcc 3.4) is valid
- that is generally just after the function prologue
- so the end of the prologue must be found, perhaps using the same
  heuristics that gdb uses to set function entry breakpoints
- this address is the place the kprobes breakpoint has to be inserted
  at, not at the actual function entry

It would be a lovely contribution to codify this sort of search
algorithm, probably on top of a dwarf library such as libelf's libdw.


> I don't know if it makes sense to try using the 'toy parser' at this
> point - does it output a syntax tree or something that could be used
> to generate code?  [...]

That is the intent.  Within a couple of days, I'll commit more code
that performs the beginnings of semantic checking (resolving symbols,
inferring types).  This should be just about enough to start
traversing the trees and emit actual probes.


- FChE

Attachment: pgp00000.pgp
Description: PGP signature


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