From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1679 invoked by alias); 20 Feb 2015 15:45:25 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 1664 invoked by uid 89); 20 Feb 2015 15:45:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-qa0-f43.google.com Received: from mail-qa0-f43.google.com (HELO mail-qa0-f43.google.com) (209.85.216.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Fri, 20 Feb 2015 15:45:23 +0000 Received: by mail-qa0-f43.google.com with SMTP id bm13so12979394qab.2 for ; Fri, 20 Feb 2015 07:45:21 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.140.85.9 with SMTP id m9mr23690699qgd.7.1424447121478; Fri, 20 Feb 2015 07:45:21 -0800 (PST) Received: by 10.140.20.228 with HTTP; Fri, 20 Feb 2015 07:45:21 -0800 (PST) In-Reply-To: <54E74F64.9080308@codesourcery.com> References: <54E74F64.9080308@codesourcery.com> Date: Fri, 20 Feb 2015 15:45:00 -0000 Message-ID: Subject: Re: Fwd: Can GDB interact with serial ports on remote targets? From: Brendan J To: lgustavo@codesourcery.com Cc: gdb@sourceware.org Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2015-02/txt/msg00034.txt.bz2 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 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