This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Can GDB interact with serial ports on remote targets?
- From: <Paul_Koning at Dell dot com>
- To: <bhenryj0117 at googlemail dot com>
- Cc: <gdb at sourceware dot org>
- Date: Fri, 20 Feb 2015 16:20:46 +0000
- Subject: Re: Can GDB interact with serial ports on remote targets?
- Authentication-results: sourceware.org; auth=none
- References: <CAJUwWUNyZ=CYr9xL0h5kD0UABpy12LS1hO-hXhwM6-aTh946Zg at mail dot gmail dot com> <CAJUwWUMX_qowt2ePjCbXKcyhmve01L9a-rz5Oa9QdbA1vj9ojA at mail dot gmail dot com> <54E74F64 dot 9080308 at codesourcery dot com> <CAJUwWUMCqSr1ZHWwCCP+Gt6vA_q4fzwRpPhZ5-pHjv8+tDgpag at mail dot gmail dot com>
> 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