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: [PATCH] Linux Kernel Markers


Mathieu Desnoyers wrote:
* Vara Prasad (prasadav@us.ibm.com) 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.


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