Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@mvista.com>
To: gdb-patches@sources.redhat.com
Subject: Re: RFA: Breakpoint infrastructure cleanups [0/8]
Date: Wed, 08 Oct 2003 20:59:00 -0000	[thread overview]
Message-ID: <20031008205930.GA16426@nevyn.them.org> (raw)
In-Reply-To: <16260.31835.64460.668846@localhost.redhat.com>

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


  reply	other threads:[~2003-10-08 20:59 UTC|newest]

Thread overview: 81+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-10-08 16:55 Daniel Jacobowitz
2003-10-08 17:33 ` Elena Zannoni
2003-10-08 19:04   ` Andrew Cagney
2003-10-08 19:07     ` Daniel Jacobowitz
2003-10-08 19:44       ` David Carlton
2003-10-08 20:36         ` Elena Zannoni
2003-10-08 19:49       ` Andrew Cagney
2003-10-08 18:07 ` Jim Blandy
2003-10-08 18:23   ` Joel Brobecker
2003-10-08 19:05   ` Daniel Jacobowitz
2003-10-08 19:52     ` Andrew Cagney
2003-10-08 20:30       ` Daniel Jacobowitz
2003-10-08 21:09         ` Andrew Cagney
2003-10-08 21:11           ` Daniel Jacobowitz
2003-10-08 21:40             ` Elena Zannoni
2003-10-08 22:28             ` Andrew Cagney
2003-10-09 19:19       ` Michael Snyder
2003-10-14  1:38         ` Daniel Jacobowitz
2003-10-14 15:40           ` Andrew Cagney
2003-10-14 15:46             ` David Carlton
2003-10-14 15:51             ` Daniel Jacobowitz
2003-10-14 16:27               ` Elena Zannoni
2003-10-14 20:45               ` Michael Snyder
2003-10-15 15:02                 ` Andrew Cagney
2003-10-15 18:20                   ` Michael Snyder
2003-10-15 18:30                     ` Andrew Cagney
2003-10-15 22:19                       ` Michael Snyder
2003-10-15 22:23                         ` Andrew Cagney
2003-10-15 22:37                           ` Michael Snyder
2003-10-15 18:56                     ` Elena Zannoni
2003-10-16  6:59                       ` Eli Zaretskii
2003-10-16 13:11                         ` Daniel Jacobowitz
2003-10-16 14:08                           ` Paul Koning
2003-10-16 14:21                           ` Elena Zannoni
2003-10-16 15:54                             ` Eli Zaretskii
2003-10-16 23:20                               ` Michael Snyder
2003-10-16 23:18                             ` Michael Snyder
2003-10-16 15:45                           ` Eli Zaretskii
2003-10-16 23:14                           ` Michael Snyder
2003-10-15 22:41                 ` Daniel Jacobowitz
2003-10-16  6:55                   ` Eli Zaretskii
2003-10-16 14:25                     ` Andrew Cagney
2003-10-16 16:02                       ` Eli Zaretskii
2003-10-16 23:24                         ` Michael Snyder
2003-10-17  6:46                           ` Eli Zaretskii
2003-10-17 21:38                             ` Michael Snyder
2003-10-18  8:43                               ` Eli Zaretskii
2003-10-20 18:48                                 ` Michael Snyder
2003-10-16 16:16                       ` Daniel Jacobowitz
2003-10-16 18:20                         ` Andrew Cagney
2003-10-16 23:26                           ` Totally OT Michael Snyder
2003-10-16 16:03                   ` RFA: Breakpoint infrastructure cleanups [0/8] David Carlton
2003-10-16 16:17                     ` Daniel Jacobowitz
2003-10-08 20:55     ` Elena Zannoni
2003-10-08 20:59       ` Daniel Jacobowitz [this message]
2003-10-09  6:09     ` Eli Zaretskii
2003-10-09 14:08       ` Daniel Jacobowitz
2003-10-09 17:02         ` Eli Zaretskii
2003-10-09 19:41           ` Daniel Jacobowitz
2003-10-19 16:43           ` Andrew Cagney
2003-10-09 19:33         ` Michael Snyder
2003-10-08 19:38   ` David Carlton
2003-10-08 21:00     ` Daniel Jacobowitz
2003-10-09  6:07     ` Eli Zaretskii
2003-10-08 18:26 ` Eli Zaretskii
2003-10-08 19:09   ` Daniel Jacobowitz
2003-10-19 15:55 ` Andrew Cagney
2003-10-19 16:39   ` Eli Zaretskii
2003-10-30  5:49     ` Daniel Jacobowitz
2003-11-03 18:00       ` Daniel Jacobowitz
2003-11-04 19:57       ` Michael Snyder
     [not found] <1065728983.12011.ezmlm@sources.redhat.com>
2003-10-09 20:01 ` Jim Ingham
2003-10-15 19:48 Michael Elizabeth Chastain
2003-10-15 22:00 ` Michael Snyder
2003-10-15 22:14 Michael Elizabeth Chastain
2003-10-15 22:36 ` Michael Snyder
     [not found] <1066321046.18949.ezmlm@sources.redhat.com>
2003-10-16 18:58 ` Jim Ingham
2003-10-16 23:30   ` Michael Snyder
2003-10-16 19:02 ` Jim Ingham
2003-10-17  7:04   ` Eli Zaretskii
2003-10-17 16:55     ` Jim Ingham

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20031008205930.GA16426@nevyn.them.org \
    --to=drow@mvista.com \
    --cc=gdb-patches@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox