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

[Daniel Jacobowitz <drow@mvista.com>]

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