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

Jim Ingham
2002-08-15T22:26:09Z

On Thursday, August 15, 2002, at 02:19 PM,
gdb-patches-digest-help@sources.redhat.com wrote:

> From: Andrew Cagney <ac131313@ges.redhat.com>
> Date: Wed Aug 14, 2002 10:57:13 PM US/Pacific
> To: gdb-patches@sources.redhat.com
> Subject: Re: [RFC] breakpoints and function prologues...
>
>
>> I agree with Jim here. I think most folks are actually surprised to
>> find that if they break on the "{" beginning a function (or indeed
>> anywhere before the first executable line of code) then their
>> backtrace will not be correct. Understanding why this is so requires
>> you to "pay attention to the man behind the curtain", and that we
>> breaks the illusion that source code maps straight-forwardly onto the
>> running program. Where this extra knowledge is helpful (like when
>> debugging optimized code) it is fine to require folks to have it.
>> But here, where it really doesn't do any good, I think it is just
>> confusing. And, of course, it causes big heartburn for GUIs the
>> varobj code, as I said earlier.
>> I doubt that "{" breaks on the prologue is a crucial feature of gdb,
>> and given that there are other ways to do this, I don't think it is
>> really worth supporting...
>
> Michael is right here. If a CLI user sets a breakpoint on a line
> (with code) then that user clearly wants the breakpoint set on that
> line.

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.

Actually a better representation of the truth is "All the users I have
talked to have cussed me out when they found out that these two were
not equivalent".

>
> If an architecture can't unwind the frame for that breakpoint address
> then that is a bug in the architecture and/or GDB. The main reason
> the average prologue analyzer doesn't handle breakpoints in the
> prologue is, I think, more a factor of not being tested then of being
> ``hard''.
>

There is another problem that this causes which is again fixable, but
harder than getting backtraces right, which I mentioned in a previous
note, but is worth repeating.

The varobj system, which is by far the best way to store variables in
gdb for use in an IDE, needs to know the frame in which it is creating
a varobj, when one is made. That is so you can have varobj's for
various stack levels at the same time, and when you go to update them,
they will update themselves in the correct context. You don't want
this to be dependant on frame number since we start numbering at the
top of the stack so the same stack frame changes its number over time,
but it is very useful to have the varobj's persist till the frame
actually goes out of scope.

The way the IDE's I have worked on use varobj's is that the user puts a
breakpoint somewhere. The IDE stops there, and creates varobj's for
each of the local variables, so it can populate its local variables
window. Then each time the user steps, the IDE just tells gdb to
update the varobj's it has lying around.

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...

You could imagine ways to work around this - notice you are in the
prologue when you go to make varobj's and either try to disassemble the
prologue to figure out what you should do to the frame pointer to make
it right (which is not necessarily trivial), or suspend making the
varobj's for real till you happen to end up out of the prologue (though
then you have to explain to the user why when they first stopped in the
function all their local variables have no values...). Or note the
error when it occurs and just blindly remake all the varobj's.

None of these is very satisfactory...

Jim
--
Jim Ingham jingham@apple.com
Developer Tools - gdb
Apple Computer