Messages in this thread | | | Date | Tue, 19 Sep 2006 18:27:35 -0400 | From | Satoshi Oshima <> | Subject | 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.
Djprobes don't depend on markers. Actually, markers help to find the safe place to probe, but they are not necessary. At least, instructions that are more than 4 byte are probable.
As Vara pointed out, we are developing the tools that find the safe place for djprobes.
Satoshi OSHIMA
- 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/
| |