Mathieu Desnoyers wrote:
* Vara Prasad ([email protected]) wrote:
Martin Bligh wrote:
[...]
Depends what we're trying to fix. I was trying to fix two things:
1. Flexibility - kprobes seem unable to access all local variables etc
easily, and go anywhere inside the function. Plus keeping low overhead
for doing things like keeping counters in a function (see previous
example I mentioned for counting pages in shrink_list).
Using tools like systemtap on can consult DWARF information and put
probes in the middle of the function and access local variables as well,
that is not the real problem. The issue here is compiler doesn't seem to
generate required DWARF information in some cases due to optimizations.
The other related problem is when there exists debug information, the
way to specify the breakpoint location is using line number which is not
maintainable, having a marker solves this problem as well. Your proposal
still doesn't solve the need for markers if i understood correctly.
His implementation makes a heavy use of a marker mechanism : this is exactly
what permits to create the instrumented objects from the same source code, but
with different #defines.
I don't think it ties us to markers, though I think they're superior for
maintaintance, personally. It could equally well be an out of tree
normal flat patch with all the tracing in, which would make Andrew
happy, even if I think it sucks ;-)
M.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
