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

[Jim Ingham <jingham@apple.com>]

Not to do a pile-on here, but I agree with the other folks.

First off - what benefits do we get from moving "break func" to the 
beginning of the prologue that should make us in a hurry to do it 
before all or at least most of the targets & debug formats support it 
well?  People who actually want to see the prologue are probably savvy 
enough to figure out how to do that (it isn't that hard).  Most folks, 
however, could care less about it.  The majority of the responses we 
got when I explained the varobj bug on the Project Builder Users list 
were along the lines of "What is a prologue, and why should I care 
about it".  The most satisfactory answer for most of them was "You 
really shouldn't care"...

And as a sorry stabs user, I don't see good unwind info coming down the 
pike any time soon.  Sure, I would love to get our toolchain to emit 
Dwarf, but there is a lot of work to get there (among other things, 
until duplicate header information elimination is done no one here is 
going to pay any attention to Dwarf).  In the meantime, we have 
unacceptable behavior from gdb with no easy way to fix it other than 
the solution proposed - move the break for line numbers past the 
prologue.

Jim

On Thursday, August 15, 2002, at 06:05  PM, 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.
>
> enjoy,
> Andrew
>
>
>
--
Jim Ingham                                   jingham@apple.com
Developer Tools - gdb
Apple Computer