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]
On Wed, Oct 08, 2003 at 05:06:35PM -0400, Elena Zannoni wrote:
> Daniel Jacobowitz writes:
> > > I think 'info break' should list the addresses. I don't know how this
> > > should fit into the MI format, but it ought to be MI that changes,
> > > rather than omitting useful behavior.
> > >
> > > In my ideal world, you'd get an explanation for why each address was
> > > chosen, when it's not obvious:
> > >
> > > (gdb) info break
> > > Num Type Disp Enb Address What
> > > 1 breakpoint keep y 0x08048354 in foo::foo (in-charge) at hello.c:8
> > > 0x08048364 in foo::foo (not-in-charge) at hello.c:8
> > > (gdb)
> >
> > Here's the problem that I see.
> >
> > For foo::foo, there are two of these things. Having them both in the
> > list would be nice. Really nice.
> >
> > For inline_accessor_fn there are 3.8 million. In addition to needing
> > to do a whole lot of work on GDB internals before we could survive this
> > (memory usage; ptrace thrashing inserting and removing them; linked
> > lists of breakpoints; and that's just the beginning) this has some
> > severe user interface implications. We don't want to print out all
> > those addresses by default!
> >
> > I'm open to suggestions on how to deal with this.
> >
>
> There is already 'maint info break', how about extending that? Would
> you be able to distinguish between foo::foo breakpoints and inline
> breakpoints so that they can be displayed on separate lists/commands?
Hmm... sure, I suppose so. I haven't thought about how well it scales
and I don't think I can until I have some implementation in front of me
to play with. Something like this?
1 breakpoint keep y 0x08048354 in foo::foo() (in-charge) at hello.c:8
0x08048364 in foo::foo() (not-in-charge) at hello.c:8
2 breakpoint keep y <multiple> in foo::baz at hello.c:12
3 breakpoint keep y <multiple> in foo::foo(int) (in-charge) at hello.c:10
<multiple> in foo::foo(int) (not-in-charge) at hello.c:10
Where the latter two describe inlined copies.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer