Re: GDB/MI questions

Re: GDB/MI questions

[Marc Khouzam]

> Hi,
> 
> I'm attempting to convert CGDB (a GDB front end) from annotations to MI.
> Two questions I've run up against:
> 
> The first is, with annotations, it's easy to tell when GDB can except
> another command, just wait for the prompt annotation.
> With GDB/MI it seems a little trickier. So far I have this:
>     Wait for the gdb prompt
>     If you have not recieved a *running yet, it's safe to run a command.
>     Otherwise, if you have recieved a *running, you need to wait for
>     the prompt and for *stopped.
> Anyone have a better approach? Does multi target impact this?

In most cases, you don't need to care about this.  You can normally
send other commands even when GDB is blocked and they will be
buffered until GDB unblocks.

Same goes for the prompt, you don't need to wait for it; you can just
send your commands and they will be processed when GDB is ready.
Eclipse never waits for the prompt.

Are you running mi-async?  I recommend doing that.  It implies that
GDB will always be accepting commands even while the inferior is
running.  Some commands may fail, such as looking at memory or
doing an -exec-next on a thread that is running, and you should be
prepared for that, but it is not a big deal.  One of the advantages is 
that you can execute some other commands such as 'info os', listing
threads, changing GDB's configuration, etc.

With mi-async, there are some cases when you need to wait for the 
*stopped event.  For example, enabling 'record' can only be done when
the inferior is stopped, so sending an -exec-interrupt followed by 
'interpreter-exec console record' is too quick and will fail; instead you
must send the -exec-interrupt, wait for *stopped, then enable record.
But the majority of cases don't need to wait.
 
> Second, from the CLI if you run the command "next", then if you hit
> the enter key, GDB will run the "next" command again.
> However, in GDB/MI if you run -interpreter-exec console "next", and then
> follow that with the Enter key, GDB does nothing.
> Is there a way to run the last command?

I don't believe MI supports that.  But that feature is really a console feature,
I don't see why you'd want that in MI.  I assume you don't expect your
user to type MI commands manually, so I don't see why they would 
need to repeat.

But if you really want that for some reason, you can just keep track
of the last command you sent in MI, and then when getting an lone
Enter, you could send it again.  But then you don't have the smarts
of GDB to know which commands should repeat and which should not.
I don't think this is a very good idea.

I hope this helps.

Marc
    

Re: GDB/MI questions

[Bob Rossi]

On Thu, Jan 19, 2017 at 02:30:58PM +0000, Marc Khouzam wrote:
> > Hi,
> > 
> > I'm attempting to convert CGDB (a GDB front end) from annotations to MI.
> > Two questions I've run up against:
> > 
> > The first is, with annotations, it's easy to tell when GDB can except
> > another command, just wait for the prompt annotation.
> > With GDB/MI it seems a little trickier. So far I have this:
> >     Wait for the gdb prompt
> >     If you have not recieved a *running yet, it's safe to run a command.
> >     Otherwise, if you have recieved a *running, you need to wait for
> >     the prompt and for *stopped.
> > Anyone have a better approach? Does multi target impact this?
> 
> In most cases, you don't need to care about this.  You can normally
> send other commands even when GDB is blocked and they will be
> buffered until GDB unblocks.

I understand that your opinion is to just send the commands and let them
buffer. However, it avoids the question. Is there a technique to know
if GDB is ready for input using MI?

Thanks,
Bob Rossi

Re: GDB/MI questions

[Pedro Alves]

On 01/19/2017 02:51 PM, Bob Rossi wrote:

> I understand that your opinion is to just send the commands and let them
> buffer. However, it avoids the question. Is there a technique to know
> if GDB is ready for input using MI?

GDB is ready for input when it prints the MI prompt.  There's one
prompt that is already printed after ^running that you should ignore.
That's an historical wart.

Thanks,
Pedro Alves

Re: GDB/MI questions

[Bob Rossi]

On Thu, Jan 19, 2017 at 02:30:58PM +0000, Marc Khouzam wrote:
> > Second, from the CLI if you run the command "next", then if you hit
> > the enter key, GDB will run the "next" command again.
> > However, in GDB/MI if you run -interpreter-exec console "next", and then
> > follow that with the Enter key, GDB does nothing.
> > Is there a way to run the last command?

...

> But if you really want that for some reason, you can just keep track
> of the last command you sent in MI, and then when getting an lone
> Enter, you could send it again.  But then you don't have the smarts
> of GDB to know which commands should repeat and which should not.
> I don't think this is a very good idea.

I'm just trying to provide the same functionality I did when I was using
annotations. This was one of the noted differences.

Since the MI differs in this area, I've done as you suggested and
that works well. I guess I'll see if there are any downsides here.

Thanks,
Bob Rossi

Re: GDB/MI questions

[Marc Khouzam]

> On Thu, Jan 19, 2017 at 02:30:58PM +0000, Marc Khouzam wrote:
> > > Second, from the CLI if you run the command "next", then if you hit
> > > the enter key, GDB will run the "next" command again.
> > > However, in GDB/MI if you run -interpreter-exec console "next", and then
> > > follow that with the Enter key, GDB does nothing.
> > > Is there a way to run the last command?
> 
> ...
> 
> > But if you really want that for some reason, you can just keep track
> > of the last command you sent in MI, and then when getting an lone
> > Enter, you could send it again.  But then you don't have the smarts
> > of GDB to know which commands should repeat and which should not.
> > I don't think this is a very good idea.
> 
> I'm just trying to provide the same functionality I did when I was using
> annotations. This was one of the noted differences.
> 
> Since the MI differs in this area, I've done as you suggested and
> that works well. I guess I'll see if there are any downsides here.

For the record, I'll add my voice to Pedro's suggestion to try out
the 'new-ui' command and have a separate MI channel from your CLI.
That is such a better user experience.
And it shouldn't be very hard to implement in your frontend since
you were previously handling a GDB CLI anyway.

FYI, Eclipse launches GDB in CLI mode (probably like you did before)
and let's the user interact with that CLI, while it sends MI commands on the
dedicated PTY for the MI channel.

Here is the parameters eclipse uses to launch such a GDB:

gdb.7.12 --nx -q -ex "new-ui mi <some pty>" -ex "set pagination off" -ex show version

Note that the "-q" command along with the last two -ex commands are to make 
sure GDB does not paginate before creating the MI channel, in case the terminal is 
too small to even show the version.

One very important note if you use the new-ui feature, is that you need to run
mi-async because the MI channel does not accept ^C, so you need to use
-exec-interrupt instead.  

Also, it will probably need a bit more work if you target Windows.

Marc

Re: GDB/MI questions

[Jan Vrany]

On Thu, 2017-01-19 at 15:24 +0000, Marc Khouzam wrote:
> > On Thu, Jan 19, 2017 at 02:30:58PM +0000, Marc Khouzam wrote:
> > > > Second, from the CLI if you run the command "next", then if you
> > > > hit
> > > > the enter key, GDB will run the "next" command again.
> > > > However, in GDB/MI if you run -interpreter-exec console "next",
> > > > and then
> > > > follow that with the Enter key, GDB does nothing.
> > > > Is there a way to run the last command?
> > 
> > ...
> > 
> > > But if you really want that for some reason, you can just keep
> > > track
> > > of the last command you sent in MI, and then when getting an lone
> > > Enter, you could send it again.  But then you don't have the
> > > smarts
> > > of GDB to know which commands should repeat and which should not.
> > > I don't think this is a very good idea.
> > 
> > I'm just trying to provide the same functionality I did when I was
> > using
> > annotations. This was one of the noted differences.
> > 
> > Since the MI differs in this area, I've done as you suggested and
> > that works well. I guess I'll see if there are any downsides here.
> 
> For the record, I'll add my voice to Pedro's suggestion to try out
> the 'new-ui' command and have a separate MI channel from your CLI.
> That is such a better user experience.
> And it shouldn't be very hard to implement in your frontend since
> you were previously handling a GDB CLI anyway.
> 
> FYI, Eclipse launches GDB in CLI mode (probably like you did before)
> and let's the user interact with that CLI, while it sends MI commands
> on the
> dedicated PTY for the MI channel.
> 
> Here is the parameters eclipse uses to launch such a GDB:
> 
> gdb.7.12 --nx -q -ex "new-ui mi <some pty>" -ex "set pagination off"
> -ex show version

Would it work the other way round? I mean starting in MI mode and then 
do something like -new-ui console /dev/some/pty ?

This looks more "natural" to me. 

Jan

> 
> Note that the "-q" command along with the last two -ex commands are
> to make 
> sure GDB does not paginate before creating the MI channel, in case
> the terminal is 
> too small to even show the version.
> 
> One very important note if you use the new-ui feature, is that you
> need to run
> mi-async because the MI channel does not accept ^C, so you need to
> use
> -exec-interrupt instead.  
> 
> Also, it will probably need a bit more work if you target Windows.
> 
> Marc
> 
> 

Re: GDB/MI questions

[Pedro Alves]

On 01/19/2017 03:40 PM, Jan Vrany wrote:
> On Thu, 2017-01-19 at 15:24 +0000, Marc Khouzam wrote:
>>> On Thu, Jan 19, 2017 at 02:30:58PM +0000, Marc Khouzam wrote:
>>>>> Second, from the CLI if you run the command "next", then if you
>>>>> hit
>>>>> the enter key, GDB will run the "next" command again.
>>>>> However, in GDB/MI if you run -interpreter-exec console "next",
>>>>> and then
>>>>> follow that with the Enter key, GDB does nothing.
>>>>> Is there a way to run the last command?
>>>
>>> ...
>>>
>>>> But if you really want that for some reason, you can just keep
>>>> track
>>>> of the last command you sent in MI, and then when getting an lone
>>>> Enter, you could send it again.  But then you don't have the
>>>> smarts
>>>> of GDB to know which commands should repeat and which should not.
>>>> I don't think this is a very good idea.
>>>
>>> I'm just trying to provide the same functionality I did when I was
>>> using
>>> annotations. This was one of the noted differences.
>>>
>>> Since the MI differs in this area, I've done as you suggested and
>>> that works well. I guess I'll see if there are any downsides here.
>>
>> For the record, I'll add my voice to Pedro's suggestion to try out
>> the 'new-ui' command and have a separate MI channel from your CLI.
>> That is such a better user experience.
>> And it shouldn't be very hard to implement in your frontend since
>> you were previously handling a GDB CLI anyway.
>>
>> FYI, Eclipse launches GDB in CLI mode (probably like you did before)
>> and let's the user interact with that CLI, while it sends MI commands
>> on the
>> dedicated PTY for the MI channel.
>>
>> Here is the parameters eclipse uses to launch such a GDB:
>>
>> gdb.7.12 --nx -q -ex "new-ui mi <some pty>" -ex "set pagination off"
>> -ex show version
> 
> Would it work the other way round? I mean starting in MI mode and then 
> do something like -new-ui console /dev/some/pty ?
> 
> This looks more "natural" to me. 

That was the original plan for Eclipse, but doing it the other
way around turned out to be much simpler.  The command works
and you do get a console on /dev/some/pty, but readline won't
be active on that console, so it's not the same thing.

Also, ctrl-c's in that "secondary" UI likely don't reach gdb
automatically.  Likely we'd need some thin signal forwarding
gdb agent running on that terminal, plus some other bits of
coordination ("gdb is gone", SIGWINCH/"screen size changed", etc.)
Something similar to emacsclient.

If you start gdb in console mode in the terminal widget, then
it all Just Works.  GDB has no idea it's running inside a GUI
at all.  It's just another terminal emulator, so the
experience is 100% like that of on "the normal command line".

Thanks,
Pedro Alves

Re: GDB/MI questions

[Simon Marchi]

On 2017-01-19 10:11, Bob Rossi wrote:
> I'm just trying to provide the same functionality I did when I was 
> using
> annotations. This was one of the noted differences.
> 
> Since the MI differs in this area, I've done as you suggested and
> that works well. I guess I'll see if there are any downsides here.
> 
> Thanks,
> Bob Rossi

 From experience (I'd like to be proven wrong), it will be very difficult 
to accurately re-create the gdb console "experience" when using MI.  The 
commands that should or should not repeat is just one example.  Consider 
history, tab completion, readline bindings (e.g. ctrl-R), pagination, 
etc.  How does that work with the MI version of cgdb?

If I understand correctly how annotations work, when the user types, 
they are interacting directly with gdb.  So when they press tab to get a 
completion, it's handled by gdb.  With MI, the user interacts with the 
front-end, which in turns talk to gdb.  So the front-end would have to 
re-implement all those features.

This is why gdb has this "new-ui" command that Pedro mentioned.  Instead 
of trying to emulate a gdb console, the front-end can start GDB in 
standard console mode (redirecting its i/o to an embedded terminal 
emulator) and open a channel on the side with new-ui for MI commands.  
This way, when using the console, the user interacts directly with gdb, 
and gets the real console experience.

 From what I know, cgdb in entirely controlled by command line, but 
displays some additional info along with the source code.  For example, 
an arrow at the execution point, and red line numbers where there are 
breakpoints.  If you implemented it using the new-ui scheme, cgdb would 
just have to listen to specific events, like *stopped or 
=breakpoint-created to update its UI.  Actually, even if you implement 
the console using "-interpreter-exec-console", you'll probably have to 
listen to those events, unless you want to parse an interpret the gdb 
commands the user types (which doesn't sound like a good idea).  And 
since your UI is "read-only" (the user doesn't do run control from the 
UI), I think you wouldn't even need to send any MI command...  In the 
end it's probably much easier (although there are some pitfalls to be 
aware of), since you offload all the user input management to gdb.

Simon

Re: GDB/MI questions

[Bob Rossi]

On Thu, Jan 19, 2017 at 10:47:21AM -0500, Simon Marchi wrote:
> On 2017-01-19 10:11, Bob Rossi wrote:
> >I'm just trying to provide the same functionality I did when I was using
> >annotations. This was one of the noted differences.
> >
> >Since the MI differs in this area, I've done as you suggested and
> >that works well. I guess I'll see if there are any downsides here.
> >
> >Thanks,
> >Bob Rossi
> 
> From experience (I'd like to be proven wrong), it will be very difficult to
> accurately re-create the gdb console "experience" when using MI.  The
> commands that should or should not repeat is just one example.  Consider
> history, tab completion, readline bindings (e.g. ctrl-R), pagination, etc.
> How does that work with the MI version of cgdb?

CGDB links to readline so the interaction is all very similar.

> If I understand correctly how annotations work, when the user types, they
> are interacting directly with gdb.  So when they press tab to get a
> completion, it's handled by gdb.  With MI, the user interacts with the
> front-end, which in turns talk to gdb.  So the front-end would have to
> re-implement all those features.

Yes, CGDB has supported tab completion for a long time.

> This is why gdb has this "new-ui" command that Pedro mentioned.  Instead of
> trying to emulate a gdb console, the front-end can start GDB in standard
> console mode (redirecting its i/o to an embedded terminal emulator) and open
> a channel on the side with new-ui for MI commands.  This way, when using the
> console, the user interacts directly with gdb, and gets the real console
> experience.

I might give that a try. However, since CGDB already has great terminal
emulation, it's not a huge deal. The other downside is, CGDB works with
lots of GDB's. Using this feature leaves behind many GDBs. Or I'd have
to support two modes. Yuck.

Thanks,
Bob Rossi

Re: GDB/MI questions

[Simon Marchi]

On 2017-01-19 11:03, Bob Rossi wrote:
> On Thu, Jan 19, 2017 at 10:47:21AM -0500, Simon Marchi wrote:
>> On 2017-01-19 10:11, Bob Rossi wrote:
>> >I'm just trying to provide the same functionality I did when I was using
>> >annotations. This was one of the noted differences.
>> >
>> >Since the MI differs in this area, I've done as you suggested and
>> >that works well. I guess I'll see if there are any downsides here.
>> >
>> >Thanks,
>> >Bob Rossi
>> 
>> From experience (I'd like to be proven wrong), it will be very 
>> difficult to
>> accurately re-create the gdb console "experience" when using MI.  The
>> commands that should or should not repeat is just one example.  
>> Consider
>> history, tab completion, readline bindings (e.g. ctrl-R), pagination, 
>> etc.
>> How does that work with the MI version of cgdb?
> 
> CGDB links to readline so the interaction is all very similar.

I'm curious how completion works currently (with annotations) for 
example.  When the user presses tab, does readline call a callback that 
you specified in CGDB in order to get the completion candidates?  Then, 
you get that information from gdb and return it?  If so, how do you get 
it?  The "complete" command?

If it already works fine like that, then I guess it can work

>> If I understand correctly how annotations work, when the user types, 
>> they
>> are interacting directly with gdb.  So when they press tab to get a
>> completion, it's handled by gdb.  With MI, the user interacts with the
>> front-end, which in turns talk to gdb.  So the front-end would have to
>> re-implement all those features.
> 
> Yes, CGDB has supported tab completion for a long time.
> 
>> This is why gdb has this "new-ui" command that Pedro mentioned.  
>> Instead of
>> trying to emulate a gdb console, the front-end can start GDB in 
>> standard
>> console mode (redirecting its i/o to an embedded terminal emulator) 
>> and open
>> a channel on the side with new-ui for MI commands.  This way, when 
>> using the
>> console, the user interacts directly with gdb, and gets the real 
>> console
>> experience.
> 
> I might give that a try. However, since CGDB already has great terminal
> emulation, it's not a huge deal. The other downside is, CGDB works with
> lots of GDB's. Using this feature leaves behind many GDBs. Or I'd have
> to support two modes. Yuck.

You are right, that's the downside of newer stuff...

Re: GDB/MI questions

[Bob Rossi]

On Thu, Jan 19, 2017 at 11:15:10AM -0500, Simon Marchi wrote:
> On 2017-01-19 11:03, Bob Rossi wrote:
> >On Thu, Jan 19, 2017 at 10:47:21AM -0500, Simon Marchi wrote:
> >>On 2017-01-19 10:11, Bob Rossi wrote:
> >>>I'm just trying to provide the same functionality I did when I was using
> >>>annotations. This was one of the noted differences.
> >>>
> >>>Since the MI differs in this area, I've done as you suggested and
> >>>that works well. I guess I'll see if there are any downsides here.
> >>>
> >>>Thanks,
> >>>Bob Rossi
> >>
> >>From experience (I'd like to be proven wrong), it will be very difficult
> >>to
> >>accurately re-create the gdb console "experience" when using MI.  The
> >>commands that should or should not repeat is just one example.  Consider
> >>history, tab completion, readline bindings (e.g. ctrl-R), pagination,
> >>etc.
> >>How does that work with the MI version of cgdb?
> >
> >CGDB links to readline so the interaction is all very similar.
> 
> I'm curious how completion works currently (with annotations) for example.
> When the user presses tab, does readline call a callback that you specified
> in CGDB in order to get the completion candidates?  Then, you get that
> information from gdb and return it?  If so, how do you get it?  The
> "complete" command?
> 
> If it already works fine like that, then I guess it can work

Yes! Exactly.

...

> >I might give that a try. However, since CGDB already has great terminal
> >emulation, it's not a huge deal. The other downside is, CGDB works with
> >lots of GDB's. Using this feature leaves behind many GDBs. Or I'd have
> >to support two modes. Yuck.
> 
> You are right, that's the downside of newer stuff...

I'll have to check out this new functionality...

Thanks,
Bob Rossi

Re: GDB/MI questions

[Pedro Alves]

On 01/19/2017 04:27 PM, Bob Rossi wrote:
>>> I might give that a try. However, since CGDB already has great terminal
>>> emulation, it's not a huge deal. The other downside is, CGDB works with
>>> lots of GDB's. Using this feature leaves behind many GDBs. Or I'd have
>>> to support two modes. Yuck.
>>
>> You are right, that's the downside of newer stuff...
> 
> I'll have to check out this new functionality...

As first step, I'd suggest starting by experimenting with
starting gdb outside cgdb, manually, on the "normal" command line,
using the command Marc showed.  With a few hacks I suspect you'd
be able to make it work quickly.  You may even want to enable that
as supported use case.  If/when cgdb works with that,
then the rest is largely a "GUI" problem.  I.e., make the
frontend's console window a terminal emulator, and make cgdb
start gdb with I/O redirected there.  There are probably
libraries out there one can reuse for that.

Thanks,
Pedro Alves

Re: GDB/MI questions

[Pedro Alves]

On 01/19/2017 03:14 AM, Bob Rossi wrote:
> Anyone have a better approach? Does multi target impact this?

Did you consider using the new "new-ui" command to split off
MI to a separate channel?  With that, you could leave the
console / CLI part to gdb. 

See more info at <https://sourceware.org/gdb/onlinedocs/gdb/Interpreters.html>.

Thanks,
Pedro Alves