Fwd: Can GDB interact with serial ports on remote targets?

Fwd: Can GDB interact with serial ports on remote targets?

[Brendan J]

I am using GDB to debug a remote target: I start GDB then type `target
remote foo:1234`. I do I/O with the target via a serial port. So I
have to have two terminals open: one with picocom (connected to
something like /dev/ttyUSB0) and one with GDB (connected to OpenOCD
via a socket). To be clear: the debug connection is *not over the
serial port*, it's over a totally separate JTAG interface.

As you know, when you debug a "normal" (i.e. not "remote") inferior in
GDB, its stdin and stdout are multiplexed into GDB's TTY so that you
can interact with it while it's running [1].

Is it possible to achieve that for a remote target - that is: can GDB
connect to the serial port itself so I can do I/O with the target from
within the GDB session?

If not, is this something that might be feasible? Maybe GDB could
multiplex its I/O so that while the inferior is running it passes
characters to/from an external tool like picocom? (As you can see I'm
fairly ignorant about this whole issue at the moment).

Thanks,
Brendan

PS: I'm using arm-none-eabi-gdb, in case that happens to be relevant.

[1] https://sourceware.org/gdb/onlinedocs/gdb/Input_002fOutput.html

Re: Fwd: Can GDB interact with serial ports on remote targets?

[Luis Machado]

Hi Brendan,

On 02/20/2015 12:27 PM, Brendan J wrote:
> I am using GDB to debug a remote target: I start GDB then type `target
> remote foo:1234`. I do I/O with the target via a serial port. So I
> have to have two terminals open: one with picocom (connected to
> something like /dev/ttyUSB0) and one with GDB (connected to OpenOCD
> via a socket). To be clear: the debug connection is *not over the
> serial port*, it's over a totally separate JTAG interface.
>
> As you know, when you debug a "normal" (i.e. not "remote") inferior in
> GDB, its stdin and stdout are multiplexed into GDB's TTY so that you
> can interact with it while it's running [1].
>
> Is it possible to achieve that for a remote target - that is: can GDB
> connect to the serial port itself so I can do I/O with the target from
> within the GDB session?
>
> If not, is this something that might be feasible? Maybe GDB could
> multiplex its I/O so that while the inferior is running it passes
> characters to/from an external tool like picocom? (As you can see I'm
> fairly ignorant about this whole issue at the moment).
>
> Thanks,
> Brendan
>
> PS: I'm using arm-none-eabi-gdb, in case that happens to be relevant.
>
> [1] https://sourceware.org/gdb/onlinedocs/gdb/Input_002fOutput.html
>
>

It sounds like what you want is semihosting support, an I/O operation 
that is initiated on the remote end, passing through the host and then 
back again to the remote end.

For example, the remote program needs to read a character. In this case 
the remote debug agent issues a vFile request with the right system 
call, GDB receives it, the user enters the character via GDB and then 
GDB sends the reply back to the target. The remote program then reads 
the character and continues executing.

You can check the documentation here:

https://sourceware.org/gdb/current/onlinedocs/gdb/File_002dI_002fO-Remote-Protocol-Extension.html#File_002dI_002fO-Remote-Protocol-Extension

Check this one as well:

https://sourceware.org/gdb/current/onlinedocs/gdb/Console-I_002fO.html#Console-I_002fO

This feature is only available on all-stop mode.

Luis

Re: Fwd: Can GDB interact with serial ports on remote targets?

[Brendan J]

Hi Luis, thanks for your response.

Hmm, yes I now realise I was remotely aware of semihosting.
Unfortunately my project is running on bare-metal (no OS, no u-boot or
UEFI or anything) so I don't think semihosting is quite appropriate.
As I understand it, typical use of semihosting goes like this:

You're debugging an application on a remote target, and that target
has an OS, and that OS has support for semihosting. The application
issues a "read" system call, and the OS handles it by issuing a
semihosting debug call (as opposed to actually reading the file or
UART or whatever).

That is to say, the system under debug needs to be modified to support
semihosting, which I'd really like to avoid doing in my case. Please
correct me if my understanding of semihosting is wrong.

Otherwise, are there any other options?

Thanks again for your help,
Brendan

On Fri, Feb 20, 2015 at 3:14 PM, Luis Machado <lgustavo@codesourcery.com> wrote:
> Hi Brendan,
>
>
> On 02/20/2015 12:27 PM, Brendan J wrote:
>>
>> I am using GDB to debug a remote target: I start GDB then type `target
>> remote foo:1234`. I do I/O with the target via a serial port. So I
>> have to have two terminals open: one with picocom (connected to
>> something like /dev/ttyUSB0) and one with GDB (connected to OpenOCD
>> via a socket). To be clear: the debug connection is *not over the
>> serial port*, it's over a totally separate JTAG interface.
>>
>> As you know, when you debug a "normal" (i.e. not "remote") inferior in
>> GDB, its stdin and stdout are multiplexed into GDB's TTY so that you
>> can interact with it while it's running [1].
>>
>> Is it possible to achieve that for a remote target - that is: can GDB
>> connect to the serial port itself so I can do I/O with the target from
>> within the GDB session?
>>
>> If not, is this something that might be feasible? Maybe GDB could
>> multiplex its I/O so that while the inferior is running it passes
>> characters to/from an external tool like picocom? (As you can see I'm
>> fairly ignorant about this whole issue at the moment).
>>
>> Thanks,
>> Brendan
>>
>> PS: I'm using arm-none-eabi-gdb, in case that happens to be relevant.
>>
>> [1] https://sourceware.org/gdb/onlinedocs/gdb/Input_002fOutput.html
>>
>>
>
> It sounds like what you want is semihosting support, an I/O operation that
> is initiated on the remote end, passing through the host and then back again
> to the remote end.
>
> For example, the remote program needs to read a character. In this case the
> remote debug agent issues a vFile request with the right system call, GDB
> receives it, the user enters the character via GDB and then GDB sends the
> reply back to the target. The remote program then reads the character and
> continues executing.
>
> You can check the documentation here:
>
> https://sourceware.org/gdb/current/onlinedocs/gdb/File_002dI_002fO-Remote-Protocol-Extension.html#File_002dI_002fO-Remote-Protocol-Extension
>
> Check this one as well:
>
> https://sourceware.org/gdb/current/onlinedocs/gdb/Console-I_002fO.html#Console-I_002fO
>
> This feature is only available on all-stop mode.
>
> Luis

Re: Fwd: Can GDB interact with serial ports on remote targets?

[Luis Machado]

Hi,

On 02/20/2015 01:45 PM, Brendan J wrote:
> Hi Luis, thanks for your response.
>
> Hmm, yes I now realise I was remotely aware of semihosting.
> Unfortunately my project is running on bare-metal (no OS, no u-boot or
> UEFI or anything) so I don't think semihosting is quite appropriate.
> As I understand it, typical use of semihosting goes like this:
>
> You're debugging an application on a remote target, and that target
> has an OS, and that OS has support for semihosting. The application
> issues a "read" system call, and the OS handles it by issuing a
> semihosting debug call (as opposed to actually reading the file or
> UART or whatever).
>
> That is to say, the system under debug needs to be modified to support
> semihosting, which I'd really like to avoid doing in my case. Please
> correct me if my understanding of semihosting is wrong.

Yes, unfortunately you need a minimal support in your debugging stub (in 
your case the probe?) to allow semihosting calls.

>
> Otherwise, are there any other options?
>

At this moment i don't recall any other elegant options, just the usual 
brute force ones by means of breakpoints and manually changing memory 
from within the debugger.

I suppose GDB could be instructed to send/receive program input/output 
through a separate channel, but it would need to know when to do so.

Luis

> On Fri, Feb 20, 2015 at 3:14 PM, Luis Machado <lgustavo@codesourcery.com> wrote:
>> Hi Brendan,
>>
>>
>> On 02/20/2015 12:27 PM, Brendan J wrote:
>>>
>>> I am using GDB to debug a remote target: I start GDB then type `target
>>> remote foo:1234`. I do I/O with the target via a serial port. So I
>>> have to have two terminals open: one with picocom (connected to
>>> something like /dev/ttyUSB0) and one with GDB (connected to OpenOCD
>>> via a socket). To be clear: the debug connection is *not over the
>>> serial port*, it's over a totally separate JTAG interface.
>>>
>>> As you know, when you debug a "normal" (i.e. not "remote") inferior in
>>> GDB, its stdin and stdout are multiplexed into GDB's TTY so that you
>>> can interact with it while it's running [1].
>>>
>>> Is it possible to achieve that for a remote target - that is: can GDB
>>> connect to the serial port itself so I can do I/O with the target from
>>> within the GDB session?
>>>
>>> If not, is this something that might be feasible? Maybe GDB could
>>> multiplex its I/O so that while the inferior is running it passes
>>> characters to/from an external tool like picocom? (As you can see I'm
>>> fairly ignorant about this whole issue at the moment).
>>>
>>> Thanks,
>>> Brendan
>>>
>>> PS: I'm using arm-none-eabi-gdb, in case that happens to be relevant.
>>>
>>> [1] https://sourceware.org/gdb/onlinedocs/gdb/Input_002fOutput.html
>>>
>>>
>>
>> It sounds like what you want is semihosting support, an I/O operation that
>> is initiated on the remote end, passing through the host and then back again
>> to the remote end.
>>
>> For example, the remote program needs to read a character. In this case the
>> remote debug agent issues a vFile request with the right system call, GDB
>> receives it, the user enters the character via GDB and then GDB sends the
>> reply back to the target. The remote program then reads the character and
>> continues executing.
>>
>> You can check the documentation here:
>>
>> https://sourceware.org/gdb/current/onlinedocs/gdb/File_002dI_002fO-Remote-Protocol-Extension.html#File_002dI_002fO-Remote-Protocol-Extension
>>
>> Check this one as well:
>>
>> https://sourceware.org/gdb/current/onlinedocs/gdb/Console-I_002fO.html#Console-I_002fO
>>
>> This feature is only available on all-stop mode.
>>
>> Luis

Re: Can GDB interact with serial ports on remote targets?

[Paul_Koning]

> On Feb 20, 2015, at 10:45 AM, Brendan J <bhenryj0117@googlemail.com> wrote:
> 
> Hi Luis, thanks for your response.
> 
> Hmm, yes I now realise I was remotely aware of semihosting.
> Unfortunately my project is running on bare-metal (no OS, no u-boot or
> UEFI or anything) so I don't think semihosting is quite appropriate.
> As I understand it, typical use of semihosting goes like this:
> 
> You're debugging an application on a remote target, and that target
> has an OS, and that OS has support for semihosting. The application
> issues a "read" system call, and the OS handles it by issuing a
> semihosting debug call (as opposed to actually reading the file or
> UART or whatever).
> 
> That is to say, the system under debug needs to be modified to support
> semihosting, which I'd really like to avoid doing in my case. Please
> correct me if my understanding of semihosting is wrong.
> 
> Otherwise, are there any other options?
> 
> Thanks again for your help,
> Brendan

Brendan,  what you’re trying to do is similar to what we needed on a dual CPU embedded system (one NetBSD, one custom RTOS).  For our case, it was sufficient to be able to see output while running a debug session.  We did this by making a very small tweak to the GDB remote protocol support: if it sees something that isn’t remote protocol, just display it on stdout.  That allowed the unmodified OS UART code to send stuff, and have it display correctly.  The only trouble is that sometimes output with # in it would get messed up, but that isn’t common in our case.

The other alternative, which is cleaner, is to tweak the OS UART driver slightly so it escapes OS output according to the GDB remote protocol.  That’s pretty simple too.  I’m not sure why we didn’t go that route; perhaps we missed it in the protocol spec.  Or perhaps because the approach we used instead works across boot driver and OS startup code and running OS drivers, since none of them need to change.

If you do need both I and O, it looks like the semihosting stuff is what you need, and in the bare metal case the UART driver is probably the spot that needs to change for this.  Those changes are probably pretty small, order of 100 lines perhaps.  Smaller than the GDB remote protocol stub, most likely.

	paul