Re: [RFC] breakpoints and function prologues...

[Jim Blandy <jimb@redhat.com>]

Joel Brobecker <brobecker@gnat.com> writes:
> > Don't forget that ``break func'' is is going to change.  It's going to 
> > go back to the start of the function!
> 
> Why this change? This is going to have a negative effect on the 
> Alpha Tru64 platform, since the first 2 instructions of the prologue
> are often optimized out by the linker. If we move "break func" back to
> the start of the function, the breakpoint will never be hit even if the
> function is entered.

If I understand the optimization you're referring to, GDB's prologue
policy accomodates that behavior almost by accident.  It's basically
an entirely separate reason to skip prologues, and I'm not sure it's
germane to the broader debate here.

Let me make sure I understand what the Tru64 linker is doing.  It
recognizes that the first two instructions at some function's entry
point are unnecessary, and then it ... here is where I get vague.
Does it:
a) delete those two instructions from the code stream altogether,
   shifting all subsequent instructions down in memory,
b) leave the instructions there, but adjust the value of the linker
   symbol to point two instructions beyond where it used to, or
c) leave the instructions and the linker symbol value unchanged, but
   tweak certain jumps to that symbol to actually jump two
   instructions beyond the symbol's value?

I assume it's not a), since you wouldn't have a problem in that case.

I kind of think that b) and c) are not entirely GDB's problem: after
performing that optimization, then the entry point in the debug
information is incorrect.  Requiring GDB to skip prologues just to
accomodate this optimization is not the right design.

Prologue skipping is meant to allow GDB to stop the inferior after the
frame pointer has been updated, the return address has been saved, and
register arguments have been spilled to their stack slots.  It exists
to support a simplistic assumption elsewhere in GDB: that saved frame
pointers, return addresses, and variables live in a single place
throughout the function's lifetime.  Removing that assumption (e.g.,
by supporting CFI and location lists) makes prologue analysis
unnecessary.

But what you're describing here is a rather different situation: the
function has multiple entry points, depending on whether (I'm
guessing) it's reached via an intra- or inter-load module call.

It seems to me there should be a separate gdbarch method to handle
that, because its semantics are different.