This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFC] breakpoints and function prologues...
- From: Jim Ingham <jingham at apple dot com>
- To: Andrew Cagney <ac131313 at ges dot redhat dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Fri, 16 Aug 2002 11:34:13 -0700
- Subject: Re: [RFC] breakpoints and function prologues...
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