From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32184 invoked by alias); 17 Jul 2008 21:57:43 -0000 Received: (qmail 32172 invoked by uid 22791); 17 Jul 2008 21:57:42 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 17 Jul 2008 21:57:22 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 1C13498373; Thu, 17 Jul 2008 21:57:21 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id F14AA982C3; Thu, 17 Jul 2008 21:57:20 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1KJbTU-0002Mc-6D; Thu, 17 Jul 2008 17:57:20 -0400 Date: Thu, 17 Jul 2008 21:57:00 -0000 From: Daniel Jacobowitz To: Bart Veer Cc: gdb@sourceware.org Subject: Re: proposed extension for jtag debugging Message-ID: <20080717215720.GA1061@caradoc.them.org> Mail-Followup-To: Bart Veer , gdb@sourceware.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.17 (2008-05-11) X-IsSubscribed: yes 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 X-SW-Source: 2008-07/txt/msg00197.txt.bz2 On Mon, Jul 07, 2008 at 10:17:12PM +0100, Bart Veer wrote: > These days gdb can interact with many hardware debug solutions based > on jtag or BDM. Most solutions involve the remote protocol and a gdb > server of some sort, including: OpenOCD, m68k-elf-sprite, > nios2-gdb-server, and Abatron BDI units. There are exceptions, for > example http://sourceforge.net/projects/bdm/ which adds a > "target bdm" instead. Some solutions are open source, others are > proprietary. For the record, m68k-elf-sprite in that list supports the file-I/O packets already. > Now, in addition to 'O' packets gdb supports console I/O via the > remote file I/O extension - as well as file I/O if desired. Hence one > approach is to tweak remote-fileio.c so that it can be invoked even > when the remote gdb server is not sending 'F' packets. The target-side > code looks something like this: It seems reasonable. I would recommend a change, personally: avoid working with strings. There's an architecture method in GDB to tell it the location of the first few pointer-sized arguments (gdbarch_fetch_pointer_argument). With this you could use the normal file I/O structures. It just means you need to add a "syscall number" equivalent. It's sad that you need to use the target strata for this. Doing it directly in the remote target would work for all of the above except for "target bdm". But I suppose it's reasonable. > 1) is there any interest in adding functionality along these lines, > i.e. mostly portable console and host file I/O for jtag and BDM > debug solutions, to mainstream gdb? Personally, we (CodeSourcery) add semihosting using the defined protocol to every toolchain we touch. I have neither interest nor objection. -- Daniel Jacobowitz CodeSourcery