Bug 10762

Summary:	turn off userspace prologue heuristics for recent gcc
Product:	systemtap	Reporter:	Frank Ch. Eigler <fche>
Component:	translator	Assignee:	Unassigned <systemtap>
Status:	RESOLVED DUPLICATE
Severity:	normal
Priority:	P2
Version:	unspecified
Target Milestone:	---
Host:		Target:
Build:		Last reconfirmed:
Bug Depends on:	10601
Bug Blocks:	11179

Description Frank Ch. Eigler 2009-10-13 00:12:01 UTC

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.

Comment 1 Frank Ch. Eigler 2009-10-16 20:00:10 UTC

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.

Comment 2 Mark Wielaard 2009-10-16 20:33:49 UTC

(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.

Comment 3 Frank Ch. Eigler 2009-10-16 21:17:47 UTC

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).

Comment 4 Frank Ch. Eigler 2009-12-21 15:18:10 UTC

(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.

Comment 5 Frank Ch. Eigler 2012-06-16 16:12:26 UTC

See bug #6941 for some recent findings.

*** This bug has been marked as a duplicate of bug 6941 ***