Re: RFA: Breakpoint infrastructure cleanups [0/8]

[Michael Snyder <msnyder@redhat.com>]

Daniel Jacobowitz wrote:
> On Thu, Oct 16, 2003 at 08:54:05AM +0200, Eli Zaretskii wrote:
> 
>>>From: Elena Zannoni <ezannoni@redhat.com>

>>>2. hit the breakpoint, show line info about where we stopped, and
>>>   breakpoint number. Do we just say the program hit the high level
>>>   breakpoint number, or also which low level breakpoint number?
>>
>>I'd say we show the high-level number and the precise machine address
>>where it breaks.
> 
> Right now we show the breakpoint address for breakpoints which are not
> at the beginning of a source line, and just the breakpoint and line
> numbers for breakpoints which are at the beginning of a line.  How
> would this interact with that?  Show the address always, or for
> breakpoints which either are in the middle of a line or in multiple
> locations?

I think right now we show the address only when it doesn't have
a clear one-to-one relationship with a source location.  For instance
if it falls in the middle of a line, or a function prologue (same
thing, actually, it's just a special case of a line).

In the one-to-many case, I'd say that if the breakpoint has a
fan-out of one (ie. only one location), AND it corresponds to
a specific source line, then we just report the line.  For
mid-lines, we do the same as before (show the address).
If it's a breakpoint with multiple locations, then we need
to qualify it -- distinguish somehow which one was hit.

The way to qualify it might depend on the kind of fan-out.
In many cases, the source file might be enough.  Or maybe
the function signiture.

I'm still in the fog about the machine-generated constructors...



>>>   Hmm, do low level breakpoints have numbers?
>>
>>I don't think we need numbers for them, so let's not have them.
> 
> I actually think that we do need numbers for them.

I suspect so too.

> 
> My hypothetical use case is something like this:
> (gdb) break inline_foo
> Breakpoint 5 set at inline_foo, which has multiple locations.
> Say "info breakpoint 5" for more details.
> (gdb) info break 5
> Num Type          Enb Address    What
> 1   sw breakpoint  y  0x8040222  inlined into foo
> 2   sw breakpoint  y  0x8040822  inlined into bar
> 3   sw breakpoint  y  0x8040852  inlined into boring_loop
> (gdb) disable 5.3
> (gdb) run
> 
> I am not sure about "delete 5.3", though - that makes tracking which
> breakpoints have been set a little trickier, for not much gain.