Messages in this thread | | | Date | Sat, 5 Apr 2003 19:02:43 -0300 | From | Werner Almesberger <> | Subject | Re: [RFC/FYI] reliable markers (hooks/probes/taps/...) |
| |
Karim Yaghmour wrote: > We've already got a small program that does this for LTT statements > which we plan to use in the future: genevent.
This looks like a clear improvement, and the markup needed in the kernel is also pretty straightforward.
But my approach actually goes a bit further: I don't even need to know types, because I can extract them from debugging information. Clearly, there is a limit on how useful this is. E.g. if a variable changes its type from "int" to "struct something *", anything using it will need to know. But at least changes like "int" -> "unsigned long" or -> "whatever_t" don't need to be synchronized.
Furthermore, the markers are for desperate cases, where the debugging information does not allow us to find arguments or variables, or even the location for placing the breakpoint. On function entry, it should be possible to access arguments without any markup in the code. I'll examine that part soon.
Generally, my idea is to gather as much useful information from debugging data as possible. A few observations so far (based on using DWARF2 information; all this is on the kernel, with the usual optimizations):
- gcc provides accurate type and name information
- location of static or extern functions is accurate, but there doesn't seem to be a reliable means for determining where the function prologue ends [10000]
- the location of inlined functions is less accurate than for non-inlined functions [10003]
- labels (as in "goto foo;") are completely erratic (that's one reason for markers) [10001, 10002, 10003]
- variable locations information is frequently only useful if we're after the prologue, and it does not accurately reflect register copies, and such (that's another reason for markers) [10005]
- call frame information seems to be almost sufficient for emulating a function return. "Almost" because I also need to analyze the add N,%esp instruction following the call. I'm not sure yet if there isn't a better way, though.
The numbers in square brackets are the gcc PRs I've submitted. (http://gcc.gnu.org/cgi-bin/gnatsweb.pl)
Without optimization, some things look better, of course.
I'm not sure how much help we can expect from the gcc side. Some of these things may just be too hard to fix. And others can't be usefully fixed at all (e.g. the markers tell gcc where the focal points are, where it has to relax optimization for accessibility).
Some thing I haven't looked at yet:
- using line numbers to specify locations. With optimization, I expect total disaster here. Also, line numbers are too volatile for few things but manual debugging.
- passing structures as arguments, or returning them from functions
- unusual (i.e. large) alignment settings. Perhaps I'll eventually need to know CFLAGS in order to reconstruct some things.
> Of course this is just a begining. We're open to suggestions and > contributions.
Same thing here :-) My goal is to reduce the markup that has to be done on the kernel to the bare minimum. The "reliable markers" are the least intrusive way I could think of for handling those cases where nothing else works (e.g. in the middle of a function).
It would be nice to have a "global" clobber, though. I.e. one that flushes and invalidates all values cached in registers, and that forces all evaluations happening prior in the nominal execution flow to be carried out, including initialization of function-local variables. That way, reliable markers wouldn't need the list of things that might be looked at.
- Werner
-- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://www.almesberger.net/____________________________________________/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |