Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@false.org>
To: Vladimir Prus <ghost@cs.msu.su>, Eli Zaretskii <eliz@gnu.org>
Cc: gdb@sources.redhat.com, gdb@sourceware.org
Subject: Re: MI: changing breakpoint location
Date: Fri, 17 Mar 2006 18:28:00 -0000	[thread overview]
Message-ID: <20060317173403.GC15128@nevyn.them.org> (raw)
In-Reply-To: <uek11pcds.fsf@gnu.org> <dve3ch$qri$1@sea.gmane.org>

On Fri, Mar 17, 2006 at 01:34:57PM +0300, Vladimir Prus wrote:
> Let me try again. Maintaining and testing this in gdb is extra work.
> Maintaining and testing this in frontends is extra work as well, and GUIs
> are less suitable for automatic testing.
> 
> Do you prefer to have this maintained and tested in frontends because that
> means less work for you, or because it's more technically reasonable, in
> your optinion?

I thought it was more technically reasonable.  I wouldn't have said it
just because it was less work!

However, I think I've been persuaded otherwise at this point.

On Fri, Mar 17, 2006 at 12:57:19PM +0200, Eli Zaretskii wrote:
> > Date: Thu, 16 Mar 2006 11:15:56 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> > 
> > > How much trouble is it to change breakpoint location in gdb?
> > 
> > A whole lot more than that.  We'd have to destroy most of the existing
> > breakpoint.
> 
> Can you explain why?  Isn't it enough just to modify the code address
> stored within the breakpoint structure?

Not really.  That might work today, but not for much longer.  Remember
the discussions we keep having about "user breakpoints" mapping to more
than one code location?  Well, now we'll have to remove all the
associated machine-level breakpoints and insert a new set.

But, that's not as complicated as I first thought.  If this would be
useful for front-ends, we might as well.

-- 
Daniel Jacobowitz
CodeSourcery


WARNING: multiple messages have this Message-ID
From: Daniel Jacobowitz <drow@false.org>
To: Vladimir Prus <ghost@cs.msu.su>, Eli Zaretskii <eliz@gnu.org>
Cc: gdb@sources.redhat.com, gdb@sourceware.org
Subject: Re: MI: changing breakpoint location
Date: Fri, 17 Mar 2006 17:43:00 -0000	[thread overview]
Message-ID: <20060317173403.GC15128@nevyn.them.org> (raw)
Message-ID: <20060317174300.Ly-P4q8pnMIDOyX6JxM9GLf85jNbRzb8BtlXpTfKx5g@z> (raw)
In-Reply-To: <uek11pcds.fsf@gnu.org> <dve3ch$qri$1@sea.gmane.org>

On Fri, Mar 17, 2006 at 01:34:57PM +0300, Vladimir Prus wrote:
> Let me try again. Maintaining and testing this in gdb is extra work.
> Maintaining and testing this in frontends is extra work as well, and GUIs
> are less suitable for automatic testing.
> 
> Do you prefer to have this maintained and tested in frontends because that
> means less work for you, or because it's more technically reasonable, in
> your optinion?

I thought it was more technically reasonable.  I wouldn't have said it
just because it was less work!

However, I think I've been persuaded otherwise at this point.

On Fri, Mar 17, 2006 at 12:57:19PM +0200, Eli Zaretskii wrote:
> > Date: Thu, 16 Mar 2006 11:15:56 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> > 
> > > How much trouble is it to change breakpoint location in gdb?
> > 
> > A whole lot more than that.  We'd have to destroy most of the existing
> > breakpoint.
> 
> Can you explain why?  Isn't it enough just to modify the code address
> stored within the breakpoint structure?

Not really.  That might work today, but not for much longer.  Remember
the discussions we keep having about "user breakpoints" mapping to more
than one code location?  Well, now we'll have to remove all the
associated machine-level breakpoints and insert a new set.

But, that's not as complicated as I first thought.  If this would be
useful for front-ends, we might as well.

-- 
Daniel Jacobowitz
CodeSourcery


  reply	other threads:[~2006-03-17 17:34 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-03-16 15:43 Vladimir Prus
2006-03-16 15:48 ` Bob Rossi
2006-03-16 16:05   ` Vladimir Prus
2006-03-16 16:12 ` Daniel Jacobowitz
2006-03-16 16:16   ` Vladimir Prus
2006-03-16 16:40     ` Daniel Jacobowitz
2006-03-16 16:46       ` Vladimir Prus
2006-03-16 17:11         ` Daniel Jacobowitz
2006-03-17 10:46           ` Vladimir Prus
2006-03-17 18:28             ` Daniel Jacobowitz [this message]
2006-03-17 17:43               ` Daniel Jacobowitz
2006-03-17 11:03       ` Eli Zaretskii
2006-03-17 10:57   ` Eli Zaretskii
2006-03-16 23:12 ` Nick Roberts
2006-03-16 23:23   ` Daniel Jacobowitz
2006-03-16 23:25     ` David Daney
2006-03-16 23:54       ` Daniel Jacobowitz
2006-03-17 13:20         ` Eli Zaretskii
2006-03-17 17:34           ` Daniel Jacobowitz
2006-03-18 18:46             ` Eli Zaretskii
2006-03-16 23:56       ` Nick Roberts
2006-03-17 10:55     ` Vladimir Prus
2006-03-17 11:42     ` Eli Zaretskii
2006-03-17  0:04   ` Daniel Jacobowitz
2006-03-17  0:23     ` Joel Brobecker
2006-03-17  3:57       ` Jim Ingham
2006-03-17 11:40   ` Eli Zaretskii

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=20060317173403.GC15128@nevyn.them.org \
    --to=drow@false.org \
    --cc=eliz@gnu.org \
    --cc=gdb@sources.redhat.com \
    --cc=gdb@sourceware.org \
    --cc=ghost@cs.msu.su \
    /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