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] |
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] |