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

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 <[email protected]> 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