Re: FW: [MI] -break-delete with several breakpoints

Re: FW: [MI] -break-delete with several breakpoints

[Bjarke Viksoe]

> 
>> Vladimir  wrote:
> For reference, which IDE are you using this behaviour in?
> - Volodya

BVRDE; a personal project of mine, yet hosted on sourceforge.
http://sourceforge.net/projects/bvrde/

I don't have the luxury of installing the latest GDB with my tool, and 
because of network latency, small and concise MI messages are 
important.

Please be aware that the majority of MI consumers are not on this 
list. What may seem nifty to the 2-3 IDE implementations that 
discusses MI changes here may not be easy for Apple, Wind River 
or the scores of other tools that have integrated with the current 
MI interface.
I feel confident that you will eventually find the best path, but if you
do introduce breaking changes, please consider putting it in a 
milestone where you can add all, not just the non-stop stuff, pending
breaking changes.
Adding non-stop to MI3 now, then adding MI4 with a few more 
breaking changes a couple of months later, MI5, MI6... well, it going 
to be a mess and you'll end up with a lot of tools hard-coded to MI2 
forever. Surely these changes are needed, just appreciate the 
impact on tool developers.

bjarke


_________________________________________________________________
Invite your mail contacts to join your friends list with Windows Live Spaces. It's easy!
http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mkt=en-us

MI consumers [was Re: FW: [MI] -break-delete with several breakpoints]

[Nick Roberts]

 > Please be aware that the majority of MI consumers are not on this 
 > list. 

You may be right but it is hard to know.  In the manual we say:

      The best way to avoid unexpected changes in MI that might break your
      front end is to make your project known to GDB developers and follow
      development on <gdb@sourceware.org> and <gdb-patches@sourceware.org>.

 >      What may seem nifty to the 2-3 IDE implementations that 
 > discusses MI changes here may not be easy for Apple, Wind River 
 > or the scores of other tools that have integrated with the current 
 > MI interface.

Apple have their own version of Gdb.  The only other debuggers that use GDB/MI
and which are not active on this list, that I am aware of, are Netbeans and
Nemiver.  Scores (= 40+) seems like an exaggeration.  In any case it would be
useful to be aware of them.  Can you list them here?

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

Re: FW: [MI] -break-delete with several breakpoints

[Daniel Jacobowitz]

On Sat, May 03, 2008 at 08:56:07AM +0200, Bjarke Viksoe wrote:
> 
> > 
> >> Vladimir  wrote:
> > For reference, which IDE are you using this behaviour in?
> > - Volodya
> 
> BVRDE; a personal project of mine, yet hosted on sourceforge.
> http://sourceforge.net/projects/bvrde/

Thanks for the link; I decided to start a list of front ends on the
wiki.

So you're running the front end on Windows and the GDB on the remote
Unix system, rather than GDB on Windows and gdbserver on the remote
system?

> I don't have the luxury of installing the latest GDB with my tool, and 
> because of network latency, small and concise MI messages are 
> important.

That doesn't sound quite right... small and concise messages are
important for throughput.  If you are prepared to pipeline multiple
requests latency can be less of an issue.

-- 
Daniel Jacobowitz
CodeSourcery

RE: [MI] -break-delete with several breakpoints

[Bjarke Viksoe]

> Daniel wrote:
>> BVRDE; a personal project of mine, yet hosted on sourceforge.
>> http://sourceforge.net/projects/bvrde/
>
> Thanks for the link; I decided to start a list of front ends on the
> wiki.
>

Do a search on google /codesearch for "-exec-run" and a number of 
opensource IDE and tools that use MI will turn up too.


> So you're running the front end on Windows and the GDB on the remote
> Unix system, rather than GDB on Windows and gdbserver on the remote
> system?
>

This is correct.


>> I don't have the luxury of installing the latest GDB with my tool, and
>> because of network latency, small and concise MI messages are
>> important.
>
> That doesn't sound quite right... small and concise messages are
> important for throughput. If you are prepared to pipeline multiple
> requests latency can be less of an issue.
>

This was discussed to some degree a long time ago:
  http://sourceware.org/ml/gdb/2006-05/msg00063.html
Part of the problem is obviously my lack of skills, some of it because
of the enviroments I wish to support.

bjarke

_________________________________________________________________
News, entertainment and everything you care about at Live.com. Get it now!
http://www.live.com/getstarted.aspx

[MI] -break-delete with several breakpoints

[Vladimir Prus]

I've noticed that right now, both -break-delete and -break-disable
commands accept several breakpoint ids, like:

	-break-disable 1 2 3

This behaviour comes almost by accident, and is not documented anywhere.
The question is -- should we document it and add tests, or should we
declare this behaviour does not exist?

I think that most of the time, making use of this behaviour will require
explicit code in the frontend, and the question is if that makes sense.
Say, for -var-update accepting a list of variable object might be good idea,
since the number of variable object can be significant, and they are updated
on each step. For deleting and disabling breakpoints, I'm actually not sure.
Typically, there are few breakpoints and wholesale delete is not common,
so it's not worth optimizing for.

Opinions?

- Volodya

Re: [MI] -break-delete with several breakpoints

[Bob Rossi]

On Sat, Apr 26, 2008 at 10:08:50PM +0400, Vladimir Prus wrote:
> 
> I've noticed that right now, both -break-delete and -break-disable
> commands accept several breakpoint ids, like:
> 
> 	-break-disable 1 2 3
> 
> This behaviour comes almost by accident, and is not documented anywhere.
> The question is -- should we document it and add tests, or should we
> declare this behaviour does not exist?
> 
> I think that most of the time, making use of this behaviour will require
> explicit code in the frontend, and the question is if that makes sense.
> Say, for -var-update accepting a list of variable object might be good idea,
> since the number of variable object can be significant, and they are updated
> on each step. For deleting and disabling breakpoints, I'm actually not sure.
> Typically, there are few breakpoints and wholesale delete is not common,
> so it's not worth optimizing for.
> 
> Opinions?

The only case I can think that would be nice is something like,
  -break-disable -all

Bob Rossi

Re: [MI] -break-delete with several breakpoints

[Nick Roberts]

 > > Opinions?
 > 
 > The only case I can think that would be nice is something like,
 >   -break-disable -all

-break-disable with no argument will already do this as it just executes
the CLI command "disable".

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

Re: [MI] -break-delete with several breakpoints

[Vladimir Prus]

On Sunday 27 April 2008 02:19:00 Nick Roberts wrote:
>  > > Opinions?
>  > 
>  > The only case I can think that would be nice is something like,
>  >   -break-disable -all
> 
> -break-disable with no argument will already do this as it just executes
> the CLI command "disable".

Which is not guaranteed to be the case in future. That's why I'm trying to
figure what is desired behaviour is.

- Volodya

Re: [MI] -break-delete with several breakpoints

[Nick Roberts]

 > >  > The only case I can think that would be nice is something like,
 > >  >   -break-disable -all
 > > 
 > > -break-disable with no argument will already do this as it just executes
 > > the CLI command "disable".
 > 
 > Which is not guaranteed to be the case in future. That's why I'm trying to
 > figure what is desired behaviour is.

Leave it as it is?  It doesn't really bother me as these commands don't
create any output and Emacs needs to work with the CLI commands in the GUD
buffer anyway.  

I think more important than the input syntax is some kind of output as I
suggested in:

http://sourceware.org/ml/gdb-patches/2008-04/msg00377.html

And it should work with CLI  commands too, i.e., through event notification.

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

Re: [MI] -break-delete with several breakpoints

[Nick Roberts]

 > >  > The only case I can think that would be nice is something like,
 > >  >   -break-disable -all
 > > 
 > > -break-disable with no argument will already do this as it just executes
 > > the CLI command "disable".
 > 
 > Which is not guaranteed to be the case in future. That's why I'm trying to
 > figure what is desired behaviour is.

Leave it as it is?  It doesn't really bother me as these commands don't
create any output and Emacs needs to work with the CLI commands in the GUD
buffer anyway.  

I think more important than the input syntax is some kind of output as I
suggested in:

http://sourceware.org/ml/gdb-patches/2008-04/msg00377.html

And it should work with CLI  commands too, i.e., through event notification.

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

Re: [MI] -break-delete with several breakpoints

[André Pönitz]

On Saturday 26 April 2008 20:08:50 Vladimir Prus wrote:
> 
> I've noticed that right now, both -break-delete and -break-disable
> commands accept several breakpoint ids, like:
> 
> 	-break-disable 1 2 3
> 
> This behaviour comes almost by accident, and is not documented anywhere.
> The question is -- should we document it and add tests, or should we
> declare this behaviour does not exist?

I would disallow it. Keep it simple ;-)

> I think that most of the time, making use of this behaviour will require
> explicit code in the frontend, and the question is if that makes sense.

I doubt it would. I could as well fire off three separate commands.
As that would not require extra roundtrips, that's basically 'free'. 

> Say, for -var-update accepting a list of variable object might be good idea,
> since the number of variable object can be significant, and they are updated
> on each step. For deleting and disabling breakpoints, I'm actually not sure.
> Typically, there are few breakpoints and wholesale delete is not common,
> so it's not worth optimizing for.

I fully agree.

Andre'

Re: [MI] -break-delete with several breakpoints

[Michael Snyder]

On Sat, 2008-04-26 at 22:08 +0400, Vladimir Prus wrote:
> I've noticed that right now, both -break-delete and -break-disable
> commands accept several breakpoint ids, like:
> 
> 	-break-disable 1 2 3
> 
> This behaviour comes almost by accident, and is not documented anywhere.
> The question is -- should we document it and add tests, or should we
> declare this behaviour does not exist?
> 
> I think that most of the time, making use of this behaviour will require
> explicit code in the frontend, and the question is if that makes sense.
> Say, for -var-update accepting a list of variable object might be good idea,
> since the number of variable object can be significant, and they are updated
> on each step. For deleting and disabling breakpoints, I'm actually not sure.
> Typically, there are few breakpoints and wholesale delete is not common,
> so it's not worth optimizing for.
> 
> Opinions?

I'm guessing that this is an artifact of the fact that 
the CLI commands (break, delete, enable, disable...)
are all willing to accept this type of argument list.