[BUG:MI] -break-list doesn't list multiple breakpoints

[BUG:MI] -break-list doesn't list multiple breakpoints

[Nick Roberts]

I have previously mentioned this in

       http://sourceware.org/ml/gdb-patches/2007-11/msg00276.html

breakpoint.c currently has:

      if (b->loc 
	  && (b->loc->next || !b->loc->enabled))
	  && !ui_out_is_mi_like_p (uiout))
	{
	  struct bp_location *loc;
	  int n = 1;
	  for (loc = b->loc; loc; loc = loc->next, ++n)
	    print_one_breakpoint_location (b, loc, n, last_addr);
	}

where presumably the !ui_out_is_mi_like_p (uiout) bit is there because the
testsuite failed without it, i.e., so that -break-insert only reports one
breakpoint (the CLI command "break" doesn't use print_one_breakpoint_location).

Unfortunately -break-list also uses print_one_breakpoint_location which means
for a template function used with int and float you get something like:

(gdb) 
-break-list
^done,BreakpointTable={nr_rows="1",nr_cols="6",hdr=[{width="7",alignment="-1",col_name="number",colhdr="Num"},{width="14",alignment="-1",col_name="type",colhdr="Type"},{width="4",alignment="-1",col_name="disp",colhdr="Disp"},{width="4",alignment="-1",col_name="enabled",colhdr="Enb"},{width="10",alignment="-1",col_name="addr",colhdr="Address"},{width="40",alignment="2",col_name="what",colhdr="What"}],body=[bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="<MULTIPLE>",times="0"}]}

instead of:

(gdb) 
-break-list
^done,BreakpointTable={nr_rows="1",nr_cols="6",hdr=[{width="7",alignment="-1",col_name="number",colhdr="Num"},{width="14",alignment="-1",col_name="type",colhdr="Type"},{width="4",alignment="-1",col_name="disp",colhdr="Disp"},{width="4",alignment="-1",col_name="enabled",colhdr="Enb"},{width="10",alignment="-1",col_name="addr",colhdr="Address"},{width="40",alignment="2",col_name="what",colhdr="What"}],body=[bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="<MULTIPLE>",times="0"},bkpt={number="1.1",type="",disp="",enabled="y",addr="0x08048776",func="int minimum<int>(int, int)",file="template.cc",fullname="/home/nickrob/C++/template.cc",line="11"},bkpt={number="1.2",type="",disp="",enabled="y",addr="0x0804879f",func="float minimum<float>(float, float)",file="template.cc",fullname="/home/nickrob/C++/template.cc",line="11"}]}


So there is currently no way in MI to see these extra breakpoint locations.

While it will take a long time to fully migrate Emacs to MI, I can certainly
start reducing the dependency on CLI commands like "info break" now.  But
only if they have full functionality.

On a more general note, in Emacs, I just just use "info break" after every user
command and will probably just use "-break-list" in the future.  I won't use
the output of -break-insert, although some front end might be clever enough to
do this and that presumably was the intention when the command was written.
In that case it might be necessary to include all the locations in a multiple
breakpoint in the output.

Support for CLI in frontends can only be dropped after MI is fully
functional, it makes no sense to to do it before.

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

Re: [BUG:MI] -break-list doesn't list multiple breakpoints

[Vladimir Prus]

Nick Roberts wrote:

> 
> I have previously mentioned this in
> 
>        http://sourceware.org/ml/gdb-patches/2007-11/msg00276.html
> 
> breakpoint.c currently has:

Yes, we had this conversation before...
 
>       if (b->loc
> && (b->loc->next || !b->loc->enabled))
> && !ui_out_is_mi_like_p (uiout))
> {
> struct bp_location *loc;
> int n = 1;
> for (loc = b->loc; loc; loc = loc->next, ++n)
> print_one_breakpoint_location (b, loc, n, last_addr);
> }
> 
> where presumably the !ui_out_is_mi_like_p (uiout) bit is there because the
> testsuite failed without it, i.e., so that -break-insert only reports one
> breakpoint (the CLI command "break" doesn't use
> print_one_breakpoint_location).

No, merely because I had no time to design MI interface.

> On a more general note, in Emacs, I just just use "info break" after every
> user
> command and will probably just use "-break-list" in the future.  I won't
> use the output of -break-insert, although some front end might be clever
> enough to do this and that presumably was the intention when the command
> was written. In that case it might be necessary to include all the
> locations in a multiple breakpoint in the output.
> 
> Support for CLI in frontends can only be dropped after MI is fully
> functional, it makes no sense to to do it before.

I am not sure about your point. Clearly, MI needs some work still,
but it's true for several years already.

- Volodya

Re: [BUG:MI] -break-list doesn't list multiple breakpoints

[Nick Roberts]

 > > where presumably the !ui_out_is_mi_like_p (uiout) bit is there because the
 > > testsuite failed without it, i.e., so that -break-insert only reports one
 > > breakpoint (the CLI command "break" doesn't use
 > > print_one_breakpoint_location).
 > 
 > No, merely because I had no time to design MI interface.

I'm not sure of the logic of committing an incomplete patch, but in any case
I think this needs to be fixed before the next release.

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

Re: [BUG:MI] -break-list doesn't list multiple breakpoints

[Daniel Jacobowitz]

On Sat, Jan 12, 2008 at 10:34:13AM +1300, Nick Roberts wrote:
>  > > where presumably the !ui_out_is_mi_like_p (uiout) bit is there because the
>  > > testsuite failed without it, i.e., so that -break-insert only reports one
>  > > breakpoint (the CLI command "break" doesn't use
>  > > print_one_breakpoint_location).
>  > 
>  > No, merely because I had no time to design MI interface.
> 
> I'm not sure of the logic of committing an incomplete patch, but in any case
> I think this needs to be fixed before the next release.

I disagree.  If someone needs this functionality in MI, they are
invited to contribute it.  Unless I'm completely mistaken, what
happened previously in MI was even worse.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [BUG:MI] -break-list doesn't list multiple breakpoints

[Nick Roberts]

 > > I'm not sure of the logic of committing an incomplete patch, but in any
 > > case I think this needs to be fixed before the next release.
 > 
 > I disagree.  If someone needs this functionality in MI, they are
 > invited to contribute it.  Unless I'm completely mistaken, what
 > happened previously in MI was even worse.

Multiple breakpoints are new, so nothing happened in MI previously did it?
The format of CLI output for pending breakpoints has currently changed and
in that context Vladimir said:

    ...And probably the only way to change the situation is to decide that MI
    is the future, and actively discourage use of CLI for anything, to the
    degree of immediately refusing any request mentioning CLI in relation to
    any frontend.

Refusing requests mentioning CLI and not providing functionality in MI seems
to leave the frontend developer between a rock and a hard place.

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

Re: [BUG:MI] -break-list doesn't list multiple breakpoints

[Vladimir Prus]

Nick Roberts wrote:

>  > > I'm not sure of the logic of committing an incomplete patch, but in
>  > > any case I think this needs to be fixed before the next release.
>  > 
>  > I disagree.  If someone needs this functionality in MI, they are
>  > invited to contribute it.  Unless I'm completely mistaken, what
>  > happened previously in MI was even worse.
> 
> Multiple breakpoints are new, so nothing happened in MI previously did it?
> The format of CLI output for pending breakpoints has currently changed and
> in that context Vladimir said:
> 
>     ...And probably the only way to change the situation is to decide that
>     MI is the future, and actively discourage use of CLI for anything, to
>     the degree of immediately refusing any request mentioning CLI in
>     relation to any frontend.
> 
> Refusing requests mentioning CLI and not providing functionality in MI
> seems to leave the frontend developer between a rock and a hard place.

As a meta-comment, I'd like to point out that I'm a frontend developer,
and I'm in no better position than you in anyway.

Now, what do you want -- making sure that all new functionality is available
via MI, or that it's available via CLI? Of course "both CLI and MI" is
a possible answer, but it increases the amount of work and the time till
completion.

- Volodya

Re: [BUG:MI] -break-list doesn't list multiple breakpoints

[Nick Roberts]

 > > Refusing requests mentioning CLI and not providing functionality in MI
 > > seems to leave the frontend developer between a rock and a hard place.
 > 
 > As a meta-comment, I'd like to point out that I'm a frontend developer,
 > and I'm in no better position than you in anyway.

I don't take comfort in your discomfort!

 > Now, what do you want -- making sure that all new functionality is available
 > via MI, or that it's available via CLI? Of course "both CLI and MI" is
 > a possible answer, but it increases the amount of work and the time till
 > completion.

I would like developers to take care in preserving the format of CLI commands
whenever possible.  It's easy for global maintainers to make an executive
decision not to support the use of CLI in frontends because they may not
realise how incomplete MI is.

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

Re: [BUG:MI] -break-list doesn't list multiple breakpoints

[Nick Roberts]

 > > I'm not sure of the logic of committing an incomplete patch, but in any
 > > case I think this needs to be fixed before the next release.
 > 
 > I disagree.  If someone needs this functionality in MI, they are
 > invited to contribute it.  Unless I'm completely mistaken, what
 > happened previously in MI was even worse.

Here's a patch that fixes this but does much more.  The 'fix' works by
removing the frame details in the MI output:

(gdb) 
-break-insert 10
^done

this means that the condition:

	  && !ui_out_is_mi_like_p (uiout))

can be removed from print_one_breakpoint so that -break-list prints
details of all the multiple breakpoint locations.

This may seem extreme but my reasoning is that a front end can keep an up-to
date breakpoint list by running -break-list behind the user's back, which is
presumably relatively inxepensive.  With Emacs, I currently use "info break"
to do this as it easier than trying to parse the output of the breakpoint
commands.  I would probably never use the output of -break-insert because
the user could set a breakpoint using the CLI "break" command from the
GUD buffer, and commands like "enable" and "disable" (and "-break-enable"/
"break-disable") provide no output.

By comparison, it's also interesting to note that frame details get printed
using "--fullname" whenever they change, i.e., when execution stops or with
commands like "up" and "frame", while in MI the details only get printed when
execution stops:

(gdb) 
-stack-select-frame 1
^done
(gdb) 

This necessitates running -stack-info-frame behind the user's back.  Even if
-stack-select-frame did print frame details, Emacs would still have to use
-stack-info-frame because of the GUD buffer again.

This patch has the added attraction of removing the last use of
deprecated_set_gdb_event_hooks and clear_gdb_event_hooks, so they
could also be removed from gdb-events.sh/c.


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


2008-01-14  Nick Roberts  <nickrob@snap.net.nz>

	* mi/mi-cmd-break.c (breakpoint_notify, breakpoint_hooks): Delete.
	(mi_cmd_break_insert): Don't use deprecated_set_gdb_event_hooks.

	* breakpoint.c (struct captured_breakpoint_query_args)
	(do_captured_breakpoint_query, gdb_breakpoint_query): Delete.
	(print_one_breakpoint): Call print_one_breakpoint_location from MI
	too.


*** breakpoint.c.~1.296~	2008-01-14 09:33:18.000000000 +1300
--- breakpoint.c	2008-01-14 09:33:38.000000000 +1300
*************** print_one_breakpoint (struct breakpoint 
*** 3619,3626 ****
  	 represent "breakpoint enabled, location disabled"
  	 situation.  */	 
        if (b->loc 
! 	  && (b->loc->next || !b->loc->enabled)
! 	  && !ui_out_is_mi_like_p (uiout))
  	{
  	  struct bp_location *loc;
  	  int n = 1;
--- 3619,3625 ----
  	 represent "breakpoint enabled, location disabled"
  	 situation.  */	 
        if (b->loc 
! 	  && (b->loc->next || !b->loc->enabled))
  	{
  	  struct bp_location *loc;
  	  int n = 1;
*************** print_one_breakpoint (struct breakpoint 
*** 3631,3672 ****
  }
  
  
- struct captured_breakpoint_query_args
-   {
-     int bnum;
-   };
- 
- static int
- do_captured_breakpoint_query (struct ui_out *uiout, void *data)
- {
-   struct captured_breakpoint_query_args *args = data;
-   struct breakpoint *b;
-   CORE_ADDR dummy_addr = 0;
-   ALL_BREAKPOINTS (b)
-     {
-       if (args->bnum == b->number)
- 	{
- 	  print_one_breakpoint (b, &dummy_addr);
- 	  return GDB_RC_OK;
- 	}
-     }
-   return GDB_RC_NONE;
- }
- 
- enum gdb_rc
- gdb_breakpoint_query (struct ui_out *uiout, int bnum, char **error_message)
- {
-   struct captured_breakpoint_query_args args;
-   args.bnum = bnum;
-   /* For the moment we don't trust print_one_breakpoint() to not throw
-      an error. */
-   if (catch_exceptions_with_msg (uiout, do_captured_breakpoint_query, &args,
- 				 error_message, RETURN_MASK_ALL) < 0)
-     return GDB_RC_FAIL;
-   else
-     return GDB_RC_OK;
- }
- 
  /* Return non-zero if B is user settable (breakpoints, watchpoints,
     catchpoints, et.al.). */
  
--- 3630,3635 ----




*** mi-cmd-break.c.~1.18.~	2008-01-04 10:24:34.000000000 +1300
--- mi-cmd-break.c	2008-01-13 23:30:11.000000000 +1300
*************** enum
*** 32,54 ****
      FROM_TTY = 0
    };
  
- /* Output a single breakpoint. */
- 
- static void
- breakpoint_notify (int b)
- {
-   gdb_breakpoint_query (uiout, b, NULL);
- }
- 
- 
- struct gdb_events breakpoint_hooks =
- {
-   breakpoint_notify,
-   breakpoint_notify,
-   breakpoint_notify,
- };
- 
- 
  enum bp_type
    {
      REG_BP,
--- 32,37 ----
*************** mi_cmd_break_insert (char *command, char
*** 70,76 ****
    char *condition = NULL;
    int pending = 0;
    enum gdb_rc rc;
-   struct gdb_events *old_hooks;
    enum opt
      {
        HARDWARE_OPT, TEMP_OPT /*, REGEXP_OPT */ , CONDITION_OPT,
--- 53,58 ----
*************** mi_cmd_break_insert (char *command, char
*** 131,137 ****
    address = argv[optind];
  
    /* Now we have what we need, let's insert the breakpoint! */
-   old_hooks = deprecated_set_gdb_event_hooks (&breakpoint_hooks);
    switch (type)
      {
      case REG_BP:
--- 113,118 ----
*************** mi_cmd_break_insert (char *command, char
*** 161,167 ****
        internal_error (__FILE__, __LINE__,
  		      _("mi_cmd_break_insert: Bad switch."));
      }
-   deprecated_set_gdb_event_hooks (old_hooks);
  
    if (rc == GDB_RC_FAIL)
      return MI_CMD_ERROR;
--- 142,147 ----

Re: [BUG:MI] -break-list doesn't list multiple breakpoints

[Daniel Jacobowitz]

On Mon, Jan 14, 2008 at 10:25:34AM +1300, Nick Roberts wrote:
> Here's a patch that fixes this but does much more.  The 'fix' works by
> removing the frame details in the MI output:
> 
> (gdb) 
> -break-insert 10
> ^done

Which is a backwards incompatible change, and other frontends use this
information; we can't remove it.

> this means that the condition:
> 
> 	  && !ui_out_is_mi_like_p (uiout))
> 
> can be removed from print_one_breakpoint so that -break-list prints
> details of all the multiple breakpoint locations.

I don't understand; how does this follow from the other change?


-- 
Daniel Jacobowitz
CodeSourcery

Re: [BUG:MI] -break-list doesn't list multiple breakpoints

[Nick Roberts]

 > > Here's a patch that fixes this but does much more.  The 'fix' works by
 > > removing the frame details in the MI output:
 > > 
 > > (gdb) 
 > > -break-insert 10
 > > ^done
 > 
 > Which is a backwards incompatible change, and other frontends use this
 > information; we can't remove it.

It's a backwards incompatible change but do other frontends use it?  In
principle you're right, of course, we can't remove it.  In practice, however,
some of the initial design was arbitrary and not born out of experience and
this is a public list where frontend developers can participate and have been
encouraged to do do.  They have an opportunity to object and such changes
might accelerate progress.

 > > this means that the condition:
 > > 
 > > 	  && !ui_out_is_mi_like_p (uiout))
 > > 
 > > can be removed from print_one_breakpoint so that -break-list prints
 > > details of all the multiple breakpoint locations.
 > 
 > I don't understand; how does this follow from the other change?

This code is executed by both -break-list and -break-insert.  By contrast,
ISTR that in CLI, it is executed by "info break" but not break.

As an alternative, I guess this line alone could be removed so that
-break-insert lists the multiple breakpoint locations being set and the
adjust MI documentation to explain this.

In any case, I think deprecated_set_gdb_event_hooks should go.  In CLI,
breakpoint details are printed in mention with say_where=1.  I don't really
understand why things need to differently for MI or why it can't be done
here too.

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

Re: [BUG:MI] -break-list doesn't list multiple breakpoints

[Daniel Jacobowitz]

On Wed, Jan 30, 2008 at 11:50:57AM +1300, Nick Roberts wrote:
> It's a backwards incompatible change but do other frontends use it?

Yes; I checked Eclipse before I wrote back.

> As an alternative, I guess this line alone could be removed so that
> -break-insert lists the multiple breakpoint locations being set and the
> adjust MI documentation to explain this.

We should check what the new MI output looks like, and see if it
breaks Emacs / Eclipse / Kdevelop.  It might be that easy.

> In any case, I think deprecated_set_gdb_event_hooks should go.  In CLI,
> breakpoint details are printed in mention with say_where=1.  I don't really
> understand why things need to differently for MI or why it can't be done
> here too.

I don't know how any of this bit works :-(

-- 
Daniel Jacobowitz
CodeSourcery

Re: [BUG:MI] -break-list doesn't list multiple breakpoints

[Nick Roberts]

 > I don't know how any of this bit works :-(

That's good to hear.  I was starting to think that you had read and understood
every line of GDB!

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

Re: [BUG:MI] -break-list doesn't list multiple breakpoints

[Nick Roberts]

 > > It's a backwards incompatible change but do other frontends use it?
 > 
 > Yes; I checked Eclipse before I wrote back.

That's odd because ISTR that Eclipse has a console.  What happens if you
create a breakpoint from the command line?  Perhaps Marc can comment.

Also isn't DSF meant to replace the debugger frontend that is currently part of
Eclipse CDT?

 > > As an alternative, I guess this line alone could be removed so that
 > > -break-insert lists the multiple breakpoint locations being set and the
 > > adjust MI documentation to explain this.
 > 
 > We should check what the new MI output looks like, and see if it
 > breaks Emacs / Eclipse / Kdevelop.  It might be that easy.

It won't break Emacs becuase it doesn't use the output of -break-insert.
It still needs the line:

     && !ui_out_is_mi_like_p (uiout))

to be removed.

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

Re: [BUG:MI] -break-list doesn't list multiple breakpoints

[Daniel Jacobowitz]

On Wed, Jan 30, 2008 at 02:56:36PM +1300, Nick Roberts wrote:
>  > > It's a backwards incompatible change but do other frontends use it?
>  > 
>  > Yes; I checked Eclipse before I wrote back.
> 
> That's odd because ISTR that Eclipse has a console.  What happens if you
> create a breakpoint from the command line?  Perhaps Marc can comment.

The console is fairly limited.

Xcode has a better one; I think they have breakpoint notifications.

> Also isn't DSF meant to replace the debugger frontend that is currently part of
> Eclipse CDT?

I don't think that's certain yet.

>  > > As an alternative, I guess this line alone could be removed so that
>  > > -break-insert lists the multiple breakpoint locations being set and the
>  > > adjust MI documentation to explain this.
>  > 
>  > We should check what the new MI output looks like, and see if it
>  > breaks Emacs / Eclipse / Kdevelop.  It might be that easy.
> 
> It won't break Emacs becuase it doesn't use the output of -break-insert.

If the new output from -break-list works OK, that is.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [BUG:MI] -break-list doesn't list multiple breakpoints

[Vladimir Prus]

On Wednesday 30 January 2008 06:06:14 Daniel Jacobowitz wrote:
> On Wed, Jan 30, 2008 at 02:56:36PM +1300, Nick Roberts wrote:
> >  > > It's a backwards incompatible change but do other frontends use it?
> >  > 
> >  > Yes; I checked Eclipse before I wrote back.
> > 
> > That's odd because ISTR that Eclipse has a console.  What happens if you
> > create a breakpoint from the command line?  Perhaps Marc can comment.
> 
> The console is fairly limited.
> 
> Xcode has a better one; I think they have breakpoint notifications.
> 
> > Also isn't DSF meant to replace the debugger frontend that is currently part of
> > Eclipse CDT?
> 
> I don't think that's certain yet.
> 
> >  > > As an alternative, I guess this line alone could be removed so that
> >  > > -break-insert lists the multiple breakpoint locations being set and the
> >  > > adjust MI documentation to explain this.
> >  > 
> >  > We should check what the new MI output looks like, and see if it
> >  > breaks Emacs / Eclipse / Kdevelop.  It might be that easy.
> > 
> > It won't break Emacs becuase it doesn't use the output of -break-insert.
> 
> If the new output from -break-list works OK, that is.

It would be nice to actually *see* the examples of that new output ;-)
My theory (and why I did not implemented that for MI), is that frontends
will start showing breakpoint locations as if they were individual
breakpoint which is likely will fail. To begin with, if frontend uses integer
to represent breakpoint id, then "1.1" location id won't be representable.

- Volodya

Re: [BUG:MI] -break-list doesn't list multiple breakpoints

[Nick Roberts]

 > > >  > > As an alternative, I guess this line alone could be removed so that
 > > >  > > -break-insert lists the multiple breakpoint locations being set and
 > > >  > > the adjust MI documentation to explain this.
 > > >  > 
 > > >  > We should check what the new MI output looks like, and see if it
 > > >  > breaks Emacs / Eclipse / Kdevelop.  It might be that easy.
 > > > 
 > > > It won't break Emacs becuase it doesn't use the output of -break-insert.
 > > 
 > > If the new output from -break-list works OK, that is.
 > 
 > It would be nice to actually *see* the examples of that new output ;-)
 > My theory (and why I did not implemented that for MI), is that frontends
 > will start showing breakpoint locations as if they were individual
 > breakpoint which is likely will fail. To begin with, if frontend uses integer
 > to represent breakpoint id, then "1.1" location id won't be representable.

The manual doesn't state that the breakpoint number will be a integer.  Without
the file and line information, the frontend can't display breakpoint icons or
display the relevant source in a window, which must be worse.


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

Re: [BUG:MI] -break-list doesn't list multiple breakpoints

[Vladimir Prus]

Nick Roberts wrote:

>  > > >  > > As an alternative, I guess this line alone could be removed so
>  > > >  > > that -break-insert lists the multiple breakpoint locations
>  > > >  > > being set and the adjust MI documentation to explain this.
>  > > >  > 
>  > > >  > We should check what the new MI output looks like, and see if it
>  > > >  > breaks Emacs / Eclipse / Kdevelop.  It might be that easy.
>  > > > 
>  > > > It won't break Emacs becuase it doesn't use the output of
>  > > > -break-insert.
>  > > 
>  > > If the new output from -break-list works OK, that is.
>  > 
>  > It would be nice to actually *see* the examples of that new output ;-)
>  > My theory (and why I did not implemented that for MI), is that
>  > frontends will start showing breakpoint locations as if they were
>  > individual breakpoint which is likely will fail. To begin with, if
>  > frontend uses integer to represent breakpoint id, then "1.1" location
>  > id won't be representable.
> 
> The manual doesn't state that the breakpoint number will be a integer. 

The manual fails to state lots of things, so frontend naturally make various
assumptions.

> Without the file and line information, the frontend can't display
> breakpoint icons or display the relevant source in a window, which must be
> worse.

Given that such a change has a potential to totally break frontend,
I'm not sure we can talk in the abstract. If you send me the most
recent version of your patch, I can see if KDevelop will be happy,
or not.

- Volodya

Re: [BUG:MI] -break-list doesn't list multiple breakpoints

[Nick Roberts]

 > Given that such a change has a potential to totally break frontend,
 > I'm not sure we can talk in the abstract. If you send me the most
 > recent version of your patch, I can see if KDevelop will be happy,
 > or not.

It's been a long thread and maybe I've lost the plot but I'm just talking
about the simple change below now.

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


*** breakpoint.c.~1.299.~	2008-01-30 11:59:18.000000000 +1300
--- breakpoint.c	2008-01-30 20:32:30.000000000 +1300
*************** print_one_breakpoint (struct breakpoint 
*** 3669,3676 ****
  	 exposed to user.  */
        if (b->loc 
  	  && !is_hardware_watchpoint (b)
! 	  && (b->loc->next || !b->loc->enabled)
! 	  && !ui_out_is_mi_like_p (uiout)) 
  	{
  	  struct bp_location *loc;
  	  int n = 1;
--- 3669,3675 ----
  	 exposed to user.  */
        if (b->loc 
  	  && !is_hardware_watchpoint (b)
! 	  && (b->loc->next || !b->loc->enabled))
  	{
  	  struct bp_location *loc;
  	  int n = 1;

Re: [BUG:MI] -break-list doesn't list multiple breakpoints

[Vladimir Prus]

On Wednesday 30 January 2008 10:35:14 you wrote:
> It's been a long thread and maybe I've lost the plot but I'm just talking
> about the simple change below now.
> 
> -- 
> Nick                                           http://www.inet.net.nz/~nickrob
> 
> 
> *** breakpoint.c.~1.299.~       2008-01-30 11:59:18.000000000 +1300
> --- breakpoint.c        2008-01-30 20:32:30.000000000 +1300
> *************** print_one_breakpoint (struct breakpoint 
> *** 3669,3676 ****
>          exposed to user.  */
>         if (b->loc 
>           && !is_hardware_watchpoint (b)
> !         && (b->loc->next || !b->loc->enabled)
> !         && !ui_out_is_mi_like_p (uiout)) 
>         {
>           struct bp_location *loc;
>           int n = 1;
> --- 3669,3675 ----
>          exposed to user.  */
>         if (b->loc 
>           && !is_hardware_watchpoint (b)
> !         && (b->loc->next || !b->loc->enabled))
>         {
>           struct bp_location *loc;
>           int n = 1;

Thanks, I'll give it a try.

- Volodya

\x16º&Öéj×!zÊÞ¶êçç~øâX¬µªÜ†\a[¥«\…ë

RE: [BUG:MI] -break-list doesn't list multiple breakpoints

[Marc Khouzam]

>>  > > It's a backwards incompatible change but do other frontends use it?
>>  > 
>>  > Yes; I checked Eclipse before I wrote back.
>> 
>> That's odd because ISTR that Eclipse has a console.  What happens if you
>> create a breakpoint from the command line?  Perhaps Marc can comment.
>
>The console is fairly limited.
>
>> Also isn't DSF meant to replace the debugger frontend that is currently part of
>> Eclipse CDT?
>
>I don't think that's certain yet.

The current discussed plan is to offer both CDI (current CDT debugger frontend) and
DSF, in the next CDT release.  It is not official but we are aiming for that.
From what I gather, both will be supported for while. 

From a DSF perspective, the breakpoint handling was just recently finished.
And from what I see, the detailed output of break-insert is being used.
This is also true for CDI.

As for the console, I not sure what the ultimate goal is...
When I tried setting a breakpoint from the console it did not trigger any 
reaction in the UI.  I'll follow up on this within DSF.

>  > > As an alternative, I guess this line alone could be removed so that
>  > > -break-insert lists the multiple breakpoint locations being set and the
>  > > adjust MI documentation to explain this.
>  > 
>  > We should check what the new MI output looks like, and see if it
>  > breaks Emacs / Eclipse / Kdevelop.  It might be that easy.

I'm guessing from the beginning of the thread, that the output will only only
change in the case of template functions?  Is that right?
If that is the case, we don't have a testcase for that :-)
I'll follow up with this too.


Marc