This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: RFA: Breakpoint infrastructure cleanups [0/8]
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.