This is the mail archive of the
mailing list for the GDB project.
Re: [RFA/PATCH] breakpoint.c: fix until command
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Michael Elizabeth Chastain <mec at shout dot net>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Fri, 3 Jan 2003 10:16:50 -0500
- Subject: Re: [RFA/PATCH] breakpoint.c: fix until command
- References: <200301030649.h036nSq08310@duracef.shout.net>
On Fri, Jan 03, 2003 at 12:49:28AM -0600, Michael Elizabeth Chastain wrote:
> Daniel J says:
> > With a modern compiler, "after $PC" is pretty much meaningless. Not
> > going to fly. It could be re-ordered; there can be out-of-line code in
> > separate sections.
> I'm thinking of a famous promise in the gcc manual:
> Without `-O', the compiler's goal is to reduce the cost of
> compilation and to make debugging produce the expected results.
> Statements are independent: if you stop the program with a
> breakpoint between statements, you can then assign a new value to
> any variable or change the program counter to any other statement
> in the function and get exactly the results you would expect from
> the source code.
> Statements which are independent can could be re-ordered, like moving
> error-handling blocks far away to a different section of the address
> space to improve cache locality. So we might need additional promises.
> I think it would be reasonable for us to ask for them if we decide
> we need them.
I don't. Promises don't mean anything; we have existing code.
> With optimized code, I agree, gdb is just going to degrade, the way
> it does now with stepping through for loops.
Which isn't OK. We need to do something about this; it requires some
substantial planning but with DWARF-2 we really should have all the
information we need to do better.
> > And what it means when LOCATION is not in function is not clear.
> > The problem is, do we know well enough when LOCATION is or is not in
> > FUNCTION to make any statements?
> If we can get more promises from gcc, then we can know this is true
> in un-optimized code.
> We can also know whether LOCATION is in the function if we operate
> on LOCATION while it is in source form before we translate to object
> code location. If we are in foo:67, and the user asks to 'until 70',
> then I bet we can figure out that '70' is in the current function no
> matter where its object code addresses are.
No, we can't. It's a pretty fundamental rule that we can never do
anything except display source lines. Consider code re-organization,
templates, macros, #line directives...
> > I'm still undecided about what to do if LOCATION is not in the
> > function. Maybe you're right and we should make this an error. What
> > if LOCATION is in the frame that called this one?
> I still say, make it an error. I like the idea that 'until' is all
> about the current frame.
> And it seems weird. The user should know it's not in the current
> frame when they type in in LOCATION. And they know that 'until' rolls
> right over function calls. So the user knows that LOCATION is in a
> calling frame. This collides head on with the idea that 'until' has
> a momentary breakpoint on the return location in the caller. Try it.
> It will always take the return-breakpoint. It will never reach LOCATION.
Oh, you're right of course.
MontaVista Software Debian GNU/Linux Developer