This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: bug in mi when setting breakpoint

 > > Unfortunately CLI also uses sub-prompts for several other commands:
 > > queries e.g pending breakpoints, exiting after exevution has started; the
 > > "commands" command.  I don't think that they fit well with the MI
 > > paradigm: MI expects MI output.  With queries, GDB takes affirmative
 > > action, e.g., creates pending breakpoints regardless of the value of "show
 > > breakpoint pending"
 > I don't think that's true. Week old CVS HEAD won't ever create pending
 > breakpoint when using MI. Today's CVS HEAD will create pending breakpoint
 > if you use the -f option to -break-insert. Without that option, pending
 > breakpoint won't ever be created.

It is true with CLI commands in MI:

-interpreter-exec console "break fgfg"
&"Function \"fgfg\" not defined.\n"
~"Breakpoint 1 (fgfg) pending.\n"

 > > and exits regardless of the value of "show confirm".
 > > 
 > > Perhaps, for now, GDB could do something similar, i.e., set all the
 > > breakpoints in the breakpoint menu.
 > In general, I think that any command that requires any interactivity
 > should explicitly document how it would handle that.

We don't appear to have any provision for such commands in MI and ISTR that Jim
Ingham has described difficulties with MI.  In, particular they have
-break-commands to deal with the "commands" command.  I was just proposing a
possible immediate fix, not to solve the general problem.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]