![]() | |||||||||||||
Messages in this thread |
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/ | ||||||||||||
| Last update: 2006-09-19 22:37 [from the cache] ©2003-2008 | |||||||||||||