Re: [RFA/PATCH] breakpoint.c: fix until command

[Daniel Jacobowitz <drow at mvista dot com>]

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.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer