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

Jim Ingham
2002-08-16T18:34:46Z

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