MI: changing breakpoint location

MI: changing breakpoint location

[Vladimir Prus]

Hello!

At the moment, the MI interface does not allow one to change location of
breakpoint, say to move breakpoint from main.cpp:9 to main.cpp:11.
CLI does not support this either, but I'm interested in MI.

Was this an explicit design decision, or it just happened this way? The use
case when it matters if when, in KDevelop, user edits the field of
breakpoint table with the location.

Now, I have to delete the old breakpoint and create the new one, which is
workable, but not convenient. How about adding 'change breakpoint location'
functionality to MI?

- Volodya

Re: MI: changing breakpoint location

[Bob Rossi]

On Thu, Mar 16, 2006 at 06:35:34PM +0300, Vladimir Prus wrote:
> 
> Hello!
> 
> At the moment, the MI interface does not allow one to change location of
> breakpoint, say to move breakpoint from main.cpp:9 to main.cpp:11.
> CLI does not support this either, but I'm interested in MI.
> 
> Was this an explicit design decision, or it just happened this way? The use
> case when it matters if when, in KDevelop, user edits the field of
> breakpoint table with the location.
> 
> Now, I have to delete the old breakpoint and create the new one, which is
> workable, but not convenient. How about adding 'change breakpoint location'
> functionality to MI?

Hi Volodya,

My initial opinion is that this does not make to much sense. The 2
different breakpoint really have nothing to do with each other.

I would think it could be possible to add a new MI command that would
allow you to arbitrarily delete, add or modify (enable/disable) as 
many breakpoints as you want. I think this would be a little more
general purpose.

Bob Rossi

Re: MI: changing breakpoint location

[Vladimir Prus]

Bob Rossi wrote:

>> At the moment, the MI interface does not allow one to change location of
>> breakpoint, say to move breakpoint from main.cpp:9 to main.cpp:11.
>> CLI does not support this either, but I'm interested in MI.
>> 
>> Was this an explicit design decision, or it just happened this way? The
>> use case when it matters if when, in KDevelop, user edits the field of
>> breakpoint table with the location.
>> 
>> Now, I have to delete the old breakpoint and create the new one, which is
>> workable, but not convenient. How about adding 'change breakpoint
>> location' functionality to MI?
> 
> Hi Volodya,
> 
> My initial opinion is that this does not make to much sense. The 2
> different breakpoint really have nothing to do with each other.

Hi Bob,

well, at the very least they have the same condition, enable flag, ignore
count and maybe breakpoint commands. The idea is to change only location
and leave the breakpoint otherwise identical.

> I would think it could be possible to add a new MI command that would
> allow you to arbitrarily delete, add or modify (enable/disable) as
> many breakpoints as you want. I think this would be a little more
> general purpose.

You mean, command that applies the same change to a list of breakpoint? I'm
not sure, this does not seem to be helpful in my case.

- Volodya

Re: MI: changing breakpoint location

[Daniel Jacobowitz]

On Thu, Mar 16, 2006 at 06:35:34PM +0300, Vladimir Prus wrote:
> 
> Hello!
> 
> At the moment, the MI interface does not allow one to change location of
> breakpoint, say to move breakpoint from main.cpp:9 to main.cpp:11.
> CLI does not support this either, but I'm interested in MI.
> 
> Was this an explicit design decision, or it just happened this way? The use
> case when it matters if when, in KDevelop, user edits the field of
> breakpoint table with the location.
> 
> Now, I have to delete the old breakpoint and create the new one, which is
> workable, but not convenient. How about adding 'change breakpoint location'
> functionality to MI?

How much trouble is it, really, to remove and recreate the breakpoint?
Presumably you know all the necessary information about the breakpoint,
since you need it for the GUI.

Almost all of the work of the "break" command is figuring out where the
breakpoint should go.  I don't see an advantage in having more commands
that need to be able to work that out.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: changing breakpoint location

[Vladimir Prus]

On Thursday 16 March 2006 19:05, Daniel Jacobowitz wrote:
> On Thu, Mar 16, 2006 at 06:35:34PM +0300, Vladimir Prus wrote:
> > Hello!
> >
> > At the moment, the MI interface does not allow one to change location of
> > breakpoint, say to move breakpoint from main.cpp:9 to main.cpp:11.
> > CLI does not support this either, but I'm interested in MI.
> >
> > Was this an explicit design decision, or it just happened this way? The
> > use case when it matters if when, in KDevelop, user edits the field of
> > breakpoint table with the location.
> >
> > Now, I have to delete the old breakpoint and create the new one, which is
> > workable, but not convenient. How about adding 'change breakpoint
> > location' functionality to MI?
>
> How much trouble is it, really, to remove and recreate the breakpoint?

In code, something line 28 lines, 7 lines of actual code exclusing comments. 
In development time -- something like an hour, including two failed attempts.
And this assumes the current version is bug free and nobody will break it in 
future.

How much trouble is it to change breakpoint location in gdb?

> Presumably you know all the necessary information about the breakpoint,
> since you need it for the GUI.

Just like gdb knows all the necessary information.

> Almost all of the work of the "break" command is figuring out where the
> breakpoint should go.  I don't see an advantage in having more commands
> that need to be able to work that out.

Can't that logic be factored out into a function?

- Volodya

Re: MI: changing breakpoint location

[Daniel Jacobowitz]

On Thu, Mar 16, 2006 at 07:11:54PM +0300, Vladimir Prus wrote:
> > How much trouble is it, really, to remove and recreate the breakpoint?
> 
> In code, something line 28 lines, 7 lines of actual code exclusing comments. 
> In development time -- something like an hour, including two failed attempts.
> And this assumes the current version is bug free and nobody will break it in 
> future.
> 
> 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.

> > Almost all of the work of the "break" command is figuring out where the
> > breakpoint should go.  I don't see an advantage in having more commands
> > that need to be able to work that out.
> 
> Can't that logic be factored out into a function?

Of course, it already is.  But that's not the point; I don't want a
proliferation of commands with similar functionality, when they aren't
needed.  The larger the MI interface grows, the harder it is to test
and maintain.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: changing breakpoint location

[Vladimir Prus]

Daniel Jacobowitz wrote:

> On Thu, Mar 16, 2006 at 07:11:54PM +0300, Vladimir Prus wrote:
>> > How much trouble is it, really, to remove and recreate the breakpoint?
>> 
>> In code, something line 28 lines, 7 lines of actual code exclusing
>> comments. In development time -- something like an hour, including two
>> failed attempts. And this assumes the current version is bug free and
>> nobody will break it in future.
>> 
>> 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.

I trust you on that, though I don't understand why GUI is in better position
to emit "-break-delete" + "-break-insert" then gdb itself, internally.

>> > Almost all of the work of the "break" command is figuring out where the
>> > breakpoint should go.  I don't see an advantage in having more commands
>> > that need to be able to work that out.
>> 
>> Can't that logic be factored out into a function?
> 
> Of course, it already is.  But that's not the point; I don't want a
> proliferation of commands with similar functionality, when they aren't
> needed.  The larger the MI interface grows, the harder it is to test
> and maintain.

I think there's a tradeoff here -- in this specific case, all frontend
authors will have to implement the same functionality, likely with bugs. If
this is done right once in gdb, all frontends will work correctly.

Of course, frontend maintainers and gdb maintainers are different groups, so
if you mean adding this to gdb will move work from frontend maintainers to
gdb maintainers and you don't like that idea, I understand. Or you object
to the idea even if it will backed up by a patch eventually?

- Volodya

Re: MI: changing breakpoint location

[Daniel Jacobowitz]

On Thu, Mar 16, 2006 at 07:39:42PM +0300, Vladimir Prus wrote:
> >> > Almost all of the work of the "break" command is figuring out where the
> >> > breakpoint should go.  I don't see an advantage in having more commands
> >> > that need to be able to work that out.
> >> 
> >> Can't that logic be factored out into a function?
> > 
> > Of course, it already is.  But that's not the point; I don't want a
> > proliferation of commands with similar functionality, when they aren't
> > needed.  The larger the MI interface grows, the harder it is to test
> > and maintain.
> 
> I think there's a tradeoff here -- in this specific case, all frontend
> authors will have to implement the same functionality, likely with bugs. If
> this is done right once in gdb, all frontends will work correctly.
> 
> Of course, frontend maintainers and gdb maintainers are different groups, so
> if you mean adding this to gdb will move work from frontend maintainers to
> gdb maintainers and you don't like that idea, I understand. Or you object
> to the idea even if it will backed up by a patch eventually?

It's not implementing it in GDB that's a problem.  As I said above,
it's maintaining it and testing it forevermore.  That's why I want to
keep the MI interface well defined and as small as possible (but no
smaller).

-- 
Daniel Jacobowitz
CodeSourcery

MI: changing breakpoint location

[Nick Roberts]

 > Now, I have to delete the old breakpoint and create the new one, which is
 > workable, but not convenient.

I don't find a problem with that, but it would be nice if when a program is
edited and recompiled that GDB could track the line number.  So, for example
if the breakpoint is on line 10, say, and lines 4 and 5 are deleted, then
after recompiling and restarting, its on line 8.  I think Visual Stuio has
this feature.  I have no idea how easy/hard it would be to implement.


-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: MI: changing breakpoint location

[Daniel Jacobowitz]

On Fri, Mar 17, 2006 at 12:07:27PM +1300, Nick Roberts wrote:
>  > Now, I have to delete the old breakpoint and create the new one, which is
>  > workable, but not convenient.
> 
> I don't find a problem with that, but it would be nice if when a program is
> edited and recompiled that GDB could track the line number.  So, for example
> if the breakpoint is on line 10, say, and lines 4 and 5 are deleted, then
> after recompiling and restarting, its on line 8.  I think Visual Stuio has
> this feature.  I have no idea how easy/hard it would be to implement.

Hard.  RMS once asked for a simpler version of this, which is to track
breakpoints by line number relative to the start of the function; but
really we ought to be able to do this very well.

I'm thinking something like "remember a couple lines of context, if you
can find the same context, adjust the breakpoint and warn the user". 
But there's some risk of it landing in the wrong place; I don't know
how to do it reliably but I bet a motivated developer would come up
with something :-)

Of course, then we'd have to let the MI interpreter know about the
change too, so that the editor could refresh.  I have no idea whether
GUIs would want this behavior or not; wouldn't they want to track it
themselves assuming you used the GUI's editor?

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: changing breakpoint location

[David Daney]

Daniel Jacobowitz wrote:
> On Fri, Mar 17, 2006 at 12:07:27PM +1300, Nick Roberts wrote:
> 
>> > Now, I have to delete the old breakpoint and create the new one, which is
>> > workable, but not convenient.
>>
>>I don't find a problem with that, but it would be nice if when a program is
>>edited and recompiled that GDB could track the line number.  So, for example
>>if the breakpoint is on line 10, say, and lines 4 and 5 are deleted, then
>>after recompiling and restarting, its on line 8.  I think Visual Stuio has
>>this feature.  I have no idea how easy/hard it would be to implement.
> 
> 
> Hard.  RMS once asked for a simpler version of this, which is to track
> breakpoints by line number relative to the start of the function; but
> really we ought to be able to do this very well.
> 
> I'm thinking something like "remember a couple lines of context, if you
> can find the same context, adjust the breakpoint and warn the user". 
> But there's some risk of it landing in the wrong place; I don't know
> how to do it reliably but I bet a motivated developer would come up
> with something :-)
> 
> Of course, then we'd have to let the MI interpreter know about the
> change too, so that the editor could refresh.  I have no idea whether
> GUIs would want this behavior or not; wouldn't they want to track it
> themselves assuming you used the GUI's editor?
> 

I can't see why you would want to do it anyplace *other* than the 
editor.  It would know for sure which lines had been added and deleted. 
  Anything else would just be guessing.

David Daney.

Re: MI: changing breakpoint location

[Daniel Jacobowitz]

On Thu, Mar 16, 2006 at 03:23:09PM -0800, David Daney wrote:
> I can't see why you would want to do it anyplace *other* than the 
> editor.  It would know for sure which lines had been added and deleted. 
>  Anything else would just be guessing.

Well, in the CLI GDB, we don't have any interaction with the editor. 
So I can see the benefit in guessing.

I'm not so sure about the MI case though.  Maybe whatever conclusion
we reach should end up in the MI documentation somewhere - this sounds
like the sort of design issue that most frontends would stop to
consider...

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: changing breakpoint location

[Nick Roberts]

> > Of course, then we'd have to let the MI interpreter know about the
 > > change too, so that the editor could refresh.  I have no idea whether
 > > GUIs would want this behavior or not; wouldn't they want to track it
 > > themselves assuming you used the GUI's editor?
 > > 
 > 
 > I can't see why you would want to do it anyplace *other* than the 
 > editor.  It would know for sure which lines had been added and deleted. 
 >   Anything else would just be guessing.

Well in Emacs the breakpoint icon does move according to the editing, of
course.  The problem is getting Emacs and GDB to understand each other: Emacs
needs to tell GDB the new breakpoint locations; GDB needs to tell Emacs that
the changes have indeed been recompiled into the executable and that execution
has restarted.

I guess the advantage of doing it in GDB, assuming its possible, is that it
only need be done once, rather than separately for each front-end.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: MI: changing breakpoint location

[Daniel Jacobowitz]

On Fri, Mar 17, 2006 at 12:07:27PM +1300, Nick Roberts wrote:
>  > Now, I have to delete the old breakpoint and create the new one, which is
>  > workable, but not convenient.
> 
> I don't find a problem with that, but it would be nice if when a program is
> edited and recompiled that GDB could track the line number.  So, for example
> if the breakpoint is on line 10, say, and lines 4 and 5 are deleted, then
> after recompiling and restarting, its on line 8.  I think Visual Stuio has
> this feature.  I have no idea how easy/hard it would be to implement.

BTW, this does make me think about the original request differently; it
does seem a bit awkward to have to delete and recreate breakpoints
every time the user edits a source file.  Maybe it isn't.  I don't
know...

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: changing breakpoint location

[Joel Brobecker]

> BTW, this does make me think about the original request differently; it
> does seem a bit awkward to have to delete and recreate breakpoints
> every time the user edits a source file.  Maybe it isn't.  I don't
> know...

Just my few cents:

To me, it was initially expected and normal. But then there are some
issues GUIs have to be careful of, probably derived from the fact that
the new breakpoint would have a different ID. They have to transfer
over conditions expressions, command lists, etc.

For some reason I can't put my finger on, I feel against such a feature,
but then it would make things simpler for the GUI, and the user would
not be confused by a different breakpoint number when the location
is modified...

Doesn't seem like something that would be too hard to implement either,
right? Something like "move-breakpoint break-id new-location". If it
added to GDB, I would make it available for CLI as well, might as well.

-- 
Joel

Re: MI: changing breakpoint location

[Jim Ingham]

Just a single data point...

The old NeXT gdb had a move breakpoint feature that was there because  
the ProjectBuilder guys had asked for it as some point in the distant  
past.  Maybe Michael remembers about this - it was before my time.   
At one point we were merging from the FSF gdb and the command broke.   
So I went to talk to the guy who worked on the ProjectBuilder  
debugger at the time, and it turned out he had stopped using it a  
while before we broke it.  IIRC, he said that since he already had  
code to set breakpoints with all their conditions, etc; to query out  
all these settings (needed for saving breakpoints between sessions)  
and to delete them, it was cleaner to use that code over than to have  
a different code path for moving breakpoints.

So we dropped it, and we haven't been asked for it again.

Jim

On Mar 16, 2006, at 4:04 PM, Joel Brobecker wrote:

>> BTW, this does make me think about the original request  
>> differently; it
>> does seem a bit awkward to have to delete and recreate breakpoints
>> every time the user edits a source file.  Maybe it isn't.  I don't
>> know...
>
> Just my few cents:
>
> To me, it was initially expected and normal. But then there are some
> issues GUIs have to be careful of, probably derived from the fact that
> the new breakpoint would have a different ID. They have to transfer
> over conditions expressions, command lists, etc.
>
> For some reason I can't put my finger on, I feel against such a  
> feature,
> but then it would make things simpler for the GUI, and the user would
> not be confused by a different breakpoint number when the location
> is modified...
>
> Doesn't seem like something that would be too hard to implement  
> either,
> right? Something like "move-breakpoint break-id new-location". If it
> added to GDB, I would make it available for CLI as well, might as  
> well.
>
> -- 
> Joel

Re: MI: changing breakpoint location

[Vladimir Prus]

Daniel Jacobowitz wrote:

>> Of course, frontend maintainers and gdb maintainers are different groups,
>> so if you mean adding this to gdb will move work from frontend
>> maintainers to gdb maintainers and you don't like that idea, I
>> understand. Or you object to the idea even if it will backed up by a
>> patch eventually?
> 
> It's not implementing it in GDB that's a problem.  As I said above,
> it's maintaining it and testing it forevermore.  That's why I want to
> keep the MI interface well defined and as small as possible (but no
> smaller).

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?

- Volodya

Re: MI: changing breakpoint location

[Vladimir Prus]

Daniel Jacobowitz wrote:

> I'm thinking something like "remember a couple lines of context, if you
> can find the same context, adjust the breakpoint and warn the user".
> But there's some risk of it landing in the wrong place; I don't know
> how to do it reliably but I bet a motivated developer would come up
> with something :-)
> 
> Of course, then we'd have to let the MI interpreter know about the
> change too, so that the editor could refresh.  I have no idea whether
> GUIs would want this behavior or not; wouldn't they want to track it
> themselves assuming you used the GUI's editor?

I think that automatic moving of breakpoints is better done in GUI. GUI has
more data, including specific set of editing operations, and it has more
feedback mechanisms, it can even show dialog box "This breakpoint was
moved, if that OK?", after all.

GDB, on the other hand, can only guess right breakpoint positions based on
analysing the source. And imagine you type in comment right before
breakpoint position. This will break all context-based analysis.

- Volodya

Re: MI: changing breakpoint location

[Eli Zaretskii]

> Date: Thu, 16 Mar 2006 11:05:21 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: gdb@sources.redhat.com
> 
> How much trouble is it, really, to remove and recreate the breakpoint?
> Presumably you know all the necessary information about the breakpoint,
> since you need it for the GUI.

It's probably not hard, but the breakpoint's number changes as a side
effect.  Which I guess causes trouble (i.e. more code needed to be
written) for the front end as far as tracking the current breakpoints
is concerned.

Re: MI: changing breakpoint location

[Eli Zaretskii]

> 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?

Re: MI: changing breakpoint location

[Eli Zaretskii]

> From: Nick Roberts <nickrob@snap.net.nz>
> Date: Fri, 17 Mar 2006 12:07:27 +1300
> Cc: gdb@sources.redhat.com
> 
>  > Now, I have to delete the old breakpoint and create the new one, which is
>  > workable, but not convenient.
> 
> I don't find a problem with that, but it would be nice if when a program is
> edited and recompiled that GDB could track the line number.  So, for example
> if the breakpoint is on line 10, say, and lines 4 and 5 are deleted, then
> after recompiling and restarting, its on line 8.

I agree.  When I saw the first message of this thread, I immediately
thought that this was the reason for Volodya to ask for that feature.

But even if Volodya did not think about this, I think such a feature
will be good to have.

Re: MI: changing breakpoint location

[Eli Zaretskii]

> Date: Thu, 16 Mar 2006 18:12:15 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Vladimir Prus <ghost@cs.msu.su>, gdb@sources.redhat.com
> 
> On Fri, Mar 17, 2006 at 12:07:27PM +1300, Nick Roberts wrote:
> >  > Now, I have to delete the old breakpoint and create the new one, which is
> >  > workable, but not convenient.
> > 
> > I don't find a problem with that, but it would be nice if when a program is
> > edited and recompiled that GDB could track the line number.  So, for example
> > if the breakpoint is on line 10, say, and lines 4 and 5 are deleted, then
> > after recompiling and restarting, its on line 8.  I think Visual Stuio has
> > this feature.  I have no idea how easy/hard it would be to implement.
> 
> Hard.  RMS once asked for a simpler version of this, which is to track
> breakpoints by line number relative to the start of the function; but
> really we ought to be able to do this very well.

If we have a volunteer, the fact that it's hard is not very relevant ;-)

> I'm thinking something like "remember a couple lines of context, if you
> can find the same context, adjust the breakpoint and warn the user". 
> But there's some risk of it landing in the wrong place; I don't know
> how to do it reliably but I bet a motivated developer would come up
> with something :-)

At least the front end could help here, since this happens when
sources are edited.

Re: MI: changing breakpoint location

[Eli Zaretskii]

> Date: Thu, 16 Mar 2006 18:25:33 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Nick Roberts <nickrob@snap.net.nz>, Vladimir Prus <ghost@cs.msu.su>, 	gdb@sources.redhat.com
> 
> On Thu, Mar 16, 2006 at 03:23:09PM -0800, David Daney wrote:
> > I can't see why you would want to do it anyplace *other* than the 
> > editor.  It would know for sure which lines had been added and deleted. 
> >  Anything else would just be guessing.
> 
> Well, in the CLI GDB, we don't have any interaction with the editor. 

But we can ask the CLI users to type the line difference, can we?  I
don't expect this command to be used too frequently from the command
line, so it doesn't seem to harsh a limitation.

Re: MI: changing breakpoint location

[Daniel Jacobowitz]

On Fri, Mar 17, 2006 at 01:42:46PM +0200, Eli Zaretskii wrote:
> > On Thu, Mar 16, 2006 at 03:23:09PM -0800, David Daney wrote:
> > > I can't see why you would want to do it anyplace *other* than the 
> > > editor.  It would know for sure which lines had been added and deleted. 
> > >  Anything else would just be guessing.
> > 
> > Well, in the CLI GDB, we don't have any interaction with the editor. 
> 
> But we can ask the CLI users to type the line difference, can we?  I
> don't expect this command to be used too frequently from the command
> line, so it doesn't seem to harsh a limitation.

Would that be useful?

Here's how I envision this command being useful: the context-sensitive
analysis I described earlier.  Heuristics (i.e. guesses) as to what's
happened to the file, while GDB's back was turned.  The user's rarely
going to know "oh, that breakpoint moved twenty lines".

The alternative command, "oh, that breakpoint should be over here now",
is a lot simpler for a CLI user to use.  Maybe it's still useful?  I
didn't think so originally, but I'm being persuaded.

-- 
Daniel Jacobowitz
CodeSourcery

Re: MI: changing breakpoint location

[Daniel Jacobowitz]

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

Re: MI: changing breakpoint location

[Daniel Jacobowitz]

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

Re: MI: changing breakpoint location

[Eli Zaretskii]

> Date: Fri, 17 Mar 2006 12:22:54 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: David Daney <ddaney@avtrex.com>, Nick Roberts <nickrob@snap.net.nz>,
> 	gdb@sources.redhat.com, Vladimir Prus <ghost@cs.msu.su>
> 
> On Fri, Mar 17, 2006 at 01:42:46PM +0200, Eli Zaretskii wrote:
> > > On Thu, Mar 16, 2006 at 03:23:09PM -0800, David Daney wrote:
> > > > I can't see why you would want to do it anyplace *other* than the 
> > > > editor.  It would know for sure which lines had been added and deleted. 
> > > >  Anything else would just be guessing.
> > > 
> > > Well, in the CLI GDB, we don't have any interaction with the editor. 
> > 
> > But we can ask the CLI users to type the line difference, can we?  I
> > don't expect this command to be used too frequently from the command
> > line, so it doesn't seem to harsh a limitation.
> 
> Would that be useful?

I expect it to be used only very rarely from CLI, but when it is, I
think yes, it would be useful.

> The user's rarely going to know "oh, that breakpoint moved twenty
> lines".

If that same user just inserted N lines in the source file, they would
know.

> The alternative command, "oh, that breakpoint should be over here now",
> is a lot simpler for a CLI user to use.

By ``here'' you mean file:line argument?  If so, I agree that this is
also a possible user interface that is functionally equivalent to
``move by N lines''.