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

[Luis Machado <lgustavo at codesourcery dot com>]

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