We currently force on prologue searching for userspace process files, since widespread gcc produces poor dwarf data to locate incoming $$parms. If we can detect (or have a user assert) that modern (vta-based) debuginfo is available for a given ELF file, we should disable the heuristics. If automatic means are unavailable, perhaps another command line option like "-P" would be needed, or (yikes) a probe point syntax extension. One reason for this is that an instruction somewhat below the prologue is more likely to be within a loop, which could result in false "entry" probe hits at every iteration.
mjw advises that a "readelf --debug-dump=loc a.out | egrep (stack_implicit)_value" might be a usable heuristic that VTA was used to compile a given object file.
(In reply to comment #1) > mjw advises that a "readelf --debug-dump=loc a.out | egrep (stack_implicit)_value" > might be a usable heuristic that VTA was used to compile a given object file. I am afraid it isn't bullet proof in general. I use it in testcases where I am sure there is some constant value being encoded.
Parameters at the function entry seem to hit upon an existing uprobes shortcoming: using pt_regs as it arrived from the kernel trap handler instead of the utrace regset. In other words, our pt_regs currently get corrupt values (specifically for %rsp and sometimes %rax), which precludes correct location. So we're blocked on bug #10601. % cat foo.c int foo(char *p) { while(*p++); return 0; } int main() { foo("hello"); } % gcc -g -fno-inline -fomit-frmae-pointer -O3 foo.c Probing function("foo").call vs. statement("foo") exposes the various problems on i686. function("foo").call will be called five times since the prologue heuristics will fire and place the probe at the head of the loop. On the other hand, statement("foo") will be called once, but print_regs() confirms that some incoming register values are wrong (compare to a gdb breakpoint & info regs at the same address).
(In reply to comment #3) > On the other hand, statement("foo") will be called once, but print_regs() > confirms that some incoming register values are wrong (compare to a gdb > breakpoint & info regs at the same address). With the parts of bug #10601 already committed, .statement("foo") produces correct results.
See bug #6941 for some recent findings. *** This bug has been marked as a duplicate of bug 6941 ***