Re: [PATCH] PR debug/47471 (set prologue_end in .debug_line)

[Richard Henderson <rth at redhat dot com>]

On 03/30/2011 11:19 AM, Dodji Seketeli wrote:
> First, it avoids emitting two consecutive .loc that are identical.
> Strictly speaking that should fix this issue in this particular case.

What's the compatibility strategy?  I.e. how does gdb tell that we're
not using the double-loc mechanism?  Does it scan the line ops and if
you see any prologue_end marks assume that double-loc is not in effect?

Are you actually going to be able to delete any code within gdb, due
to the need to interpret older debug info?

> I have noticed that the end_prologue debug hook was being called, but
> the dwarf back-end hasn't implemented it (on non-vms platforms).  Is
> there a particular reason for not implementing this?  Also, I have
> noticed that the patch causes the prologue_end directive to be emitted
> even when we compile with optimizations.  I am not sure how right that
> would be.

Well, the main problem with the existing end_prologue hook is the
definition of the "end of the prologue".

The hook you see is called *after* the last insn that was emitted
by gen_prologue.

I believe that the hook you want would be called *before* the first
insn that was originally emitted after NOTE_INSN_FUNCTION_BEG.
(Note that under certain conditions, the parameters need to be spilled
to their canonical locations, and other similar "prologue-like" stuff
happens after gen_prologue, and before the "real" function begins.)

Stop me now if I'm mistaken in this understanding of what gdb needs.

Without instruction scheduling, and without the need for parameter
spills, etc, these two definitions are (nearly) the same.  I.e. the
existing hook would likely work for -O0 -g, for many parameter lists.

On the other end, the definition the compiler uses for "begin the
epilogue" is also *before* the first insn that was emitted by
gen_epilogue.  And again I believe that what you want is *after*
the last insn that had been part of the main function body.

One possibility for noticing the debugger-definition of end of
prologue is simply to mark the first line number of the function.
None of the gen_prologue or parameter spill instructions will have
location information attached (I believe).  Thus the first insn 
that does generate a line number ought to be the first "active"
insn of the function.

Presumably one could do something similar at the ends of the
function; though that scan may be a tad more complicated.

Another problem is that we're not supporting these other features
without assembler support.  Which is silly.  I'm going to go ahead
and re-vamp how we're recording line number tables for direct output.
That should allow us to generate more-or-less equivalently capable
.debug_line output by hand.


r~