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

[Michael Elizabeth Chastain <mec@shout.net>]

> We support other compilers; we support other versions of GCC.  The life
> of a debugger is that making people fix the compiler isn't going to
> fly.

Yeah, I see where you are coming from.

I am talking about a mapping from file:line to source function
without going through PC's at all.  That would not handle the case
of 'until *0x12345678'.  But it would handle other cases.

In your example: the target program is on line 11, "return a * baz()".
The user asks to proceed "until 4", which is the "-complicated" part of
inline function baz().

In my design, gdb would say: "error, line 4 is not in main".  I think your
point is that code from line 4 actually is present in main() because baz()
got inlined into main.  (And in your example, line 4 is present exactly
once in main, whereas in the general case it could be present multiple
times).

What happens right now when the user types "break 4" to break inside
the inline function?  I'm experimenting, and it looks like gdb sets one
breakpoint on one caller to the inline function.  "break 4" does not
work properly.

Once we have mechanism to implement "break 4", we can use the same
mechanism for "until 4".  We can calculate the set of locations for "break
4" and intersect that with the low_pc and high_pc of the current frame.
If that set is null, then error.  Then set momentary breakpoints on those
locations, restricted to the current frame, plus a momentary breakpoint
on the return location, and proceed.

Until "break 4" works, "until 4" can at least refuse to do anything.

> [Similarly, we need to stop assuming a symbol name maps to one PC. 
   This causes us to mess up constructor breakpoints right now.  GDB has
   essentially no support for debugging inline functions, and it's a
   problem there too.]

I agree.  The constructor part is really hurting users.  With inline
functions, the programmer knows "I have copies of the object code
for the function everywhere, I understand why gdb is not smart enough
to handle that yet."  With constructors, the programmer does not know
that they have multiple copies of the object code, so gdb's deficiency
shows up as a surprise.

Michael C