From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9648 invoked by alias); 20 Feb 2015 15:56:34 -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 9626 invoked by uid 89); 20 Feb 2015 15:56:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 20 Feb 2015 15:56:32 +0000 Received: from svr-orw-fem-02x.mgc.mentorg.com ([147.34.96.206] helo=SVR-ORW-FEM-02.mgc.mentorg.com) by relay1.mentorg.com with esmtp id 1YOpwL-0003Jb-2v from Luis_Gustavo@mentor.com ; Fri, 20 Feb 2015 07:56:29 -0800 Received: from [172.30.9.230] (147.34.91.1) by svr-orw-fem-02.mgc.mentorg.com (147.34.96.168) with Microsoft SMTP Server id 14.3.224.2; Fri, 20 Feb 2015 07:56:28 -0800 Message-ID: <54E75928.4000609@codesourcery.com> Date: Fri, 20 Feb 2015 15:56:00 -0000 From: Luis Machado Reply-To: User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Brendan J CC: Subject: Re: Fwd: Can GDB interact with serial ports on remote targets? References: <54E74F64.9080308@codesourcery.com> In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2015-02/txt/msg00035.txt.bz2 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 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