This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]