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

[Daniel Jacobowitz <drow@mvista.com>]

On Thu, Aug 22, 2002 at 03:31:52PM -0700, Michael Snyder wrote:
> Daniel Jacobowitz wrote:
> > 
> > On Thu, Aug 15, 2002 at 01:57:13AM -0400, Andrew Cagney wrote:
> > > >I agree with Jim here.  I think most folks are actually surprised to find
> > > >that if they break on the "{" beginning a function (or indeed anywhere
> > > >before the first executable line of code) then their backtrace will not be
> > > >correct.  Understanding why this is so requires you to "pay attention to
> > > >the man behind the curtain", and that we breaks the illusion that source
> > > >code maps straight-forwardly onto the running program.  Where this extra
> > > >knowledge is helpful (like when debugging optimized code) it is fine to
> > > >require folks to have it.  But here, where it really doesn't do any good,
> > > >I think it is just confusing.  And, of course, it causes big heartburn for
> > > >GUIs the varobj code, as I said earlier.
> > > >
> > > >I doubt that "{" breaks on the prologue is a crucial feature of gdb, and
> > > >given that there are other ways to do this, I don't think it is really
> > > >worth supporting...
> > >
> > > Michael is right here.  If a CLI user sets a breakpoint on a line (with
> > > code) then that user clearly wants the breakpoint set on that line.
> > 
> > Sure, if the user knows there's code there.  I don't think most of our
> > users would understand that there is code on the "{", or what it is
> > for -
> 
> I suspect that this is a result of a changing user base.
> There are more and more users who don't know a lot about
> how things work "under the hood".

Absolutely.

> > and I don't think that breaking by line number should break on
> > code inserted by the compiler rather than the user.
> 
> The question is, is there a strong reason to change a behavior
> that has been consistent for a very long time (even if undocumented).
> Even if the ability to debug the prologue is un-important for most
> users, it is important to some, and those users (GCC developers,
> for instance) may be quite accustomed to the current behavior.
> I am, for instance...

I believe there's a strong reason; the change in our user base means
that this confuses more people than it helps.  Most or all of the
people who need to look at the beginning of prologues know about "break
*foo".

> 
> 
> > So I have to agree with Jim (both Jims, I think?).
> > 
> > > If an architecture can't unwind the frame for that breakpoint address
> > > then that is a bug in the architecture and/or GDB.  The main reason the
> > > average prologue analyzer doesn't handle breakpoints in the prologue is,
> > > I think, more a factor of not being tested then of being ``hard''.
> > 
> > Most of our ports don't support it, however.
> 
> Most of mine do.

Enough to provide frame information for local variables and stack
arguments at that point?  I didn't think that was the case.  Without
using CFI or a much more sophisticated prologue analysis mechanism, I
don't see how it could be... but I could certainly be wrong :)

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer