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

Daniel Jacobowitz
2002-08-16T02:18:15Z

On Thu, Aug 15, 2002 at 09:05:15PM -0400, Andrew Cagney wrote:
> >
> >Most users I have talked to think that setting a break on the "{" at the
> >beginning of a function means the same thing as setting a breakpoint on
> >the function. But that is not the case. "break funcName" is AFTER the
> >prologue, "break file:<line containing "{"> is the true function
> >beginning.
>
> Don't forget that ``break func'' is is going to change. It's going to
> go back to the start of the function!
>
> >However, suppose the user puts his breakpoint on the "{" beginning a
> >function (this is what most folks do when they want to break on a function
> >generically, BTW.) Then when the IDE stops, it creates the varobjs for
> >the local variables, which naively get their frame context from the frame
> >pointer (which because we stopped at the beginning of the prologue hasn't
> >been updated yet). Then the user steps, and all of the variables fail to
> >evaluate correctly, since their frame pointer actually points to the
> >previous frame, and there is no such variable in the previous frame...
>
> That is a bug in gdb. GDB should be using the debug info that lets it
> set a breakpoint anywhere in the function.

If you are suggesting that someday we'll support accessing local
variables using better unwind information and prologue analysis -
including for targets where no one has written a better prologue
analyzer yet and for debug formats which don't emit terribly good
unwind information, which covers most of our targets twice over - then
I have to say that ``break func'' _shouldn't_ change.

It'd be nice, but I don't think it's realistic.

--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer