[Bug translator/13420] prologue detection fails for function parameters in unoptimized (-g only, no -O) code

["jlebon at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=13420

Jonathan Lebon <jlebon at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jlebon at redhat dot com

--- Comment #6 from Jonathan Lebon <jlebon at redhat dot com> ---
(In reply to Frank Ch. Eigler from comment #4)
> We should attempt to work around the gcc bug in systemtap, but will need
> to improve the prologue-searching heuristics already in effect.

One of the issues here is that our current heuristics rely on srclines to guess
the prologue end. This can cause problems, because line numbers are completely
independent of the prologue. For example, the following examples will cause
different behaviours when run through resolve_prologue_endings(), even though
the prologue ends at the same address in all cases (all variations of the
example given in comment 5):

---------------

// All on different lines
int foo (int j)
{
printf("%d", j);
}
// Result: thinks there's no prologue (naked), because the line advance to
// '{' is for the same addr (as we saw in comment 5). As a result, we get
// bad j values

// Opening brace on same line as decl
int foo (int j) {
printf("%d", j);
}
// Result: correctly finds the prologue end because the first line advance
// occurs at the same time as the addr change

// All on same line
int foo (int j) { printf("%d", j); }
// Result: correctly finds the prologue end (for the wrong reasons). It goes
// through the line records, and seeing no line advances, runs off the 
// function's highpc, so then goes back one step. What saves us here is the
// 0-line advance GCC adds to mark the end of the prologue. We normally ignore
// it since the lineno doesn't change. (The 0-line advance is also mentioned
// here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51358#c1).

// Split lines
int foo (int j) { printf("%d", j);
printf("%d", j*2);
}
// Result: thinks the prologue end is at 0x4005f4, which actually corresponds
to
// the addr of the second printf call. Happens because that's where the first
// line advance occurs.

---------------

I think part of the solution here is to take advantage of the 0-line advance
when it is present (which I think only occurs when the prologue end doesn't
correspond to a line advance). This might mean simply always skipping the first
line record, regardless of actual line advances.

I'm also looking into GDB's way of handling the problem. It seems like there is
also arch-specific code to find specific opcodes in the prologue if line number
information fails to provide a clear answer (see e.g. amd64_analyze_prologue():
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=blob;f=gdb/amd64-tdep.c;h=72d748e;hb=HEAD#l2129).
Depending on how often/likely lineno info can fail, we might not need to go
that far.

To be continued...

-- 
You are receiving this mail because:
You are the assignee for the bug.