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

[Jim Ingham <jingham@apple.com>]

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