From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11418 invoked by alias); 8 Apr 2002 15:44:54 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 11073 invoked from network); 8 Apr 2002 15:44:53 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 8 Apr 2002 15:44:53 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 16ubKB-00070c-00; Mon, 08 Apr 2002 11:44:55 -0400 Date: Mon, 08 Apr 2002 08:44:00 -0000 From: Daniel Jacobowitz To: Paul Bartlett Cc: gdb@sources.redhat.com Subject: Re: gdbserver, remote serial protocol and endian issues Message-ID: <20020408114455.A26658@nevyn.them.org> Mail-Followup-To: Paul Bartlett , gdb@sources.redhat.com References: <005701c1deea$d9cd52b0$300e81a4@bristol.st.com> <20020408104522.A24590@nevyn.them.org> <00d501c1df12$ab1bdd60$300e81a4@bri.st.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <00d501c1df12$ab1bdd60$300e81a4@bri.st.com> User-Agent: Mutt/1.3.23i X-SW-Source: 2002-04/txt/msg00096.txt.bz2 On Mon, Apr 08, 2002 at 04:33:01PM +0100, Paul Bartlett wrote: > Hi Daniel, > > > I don't agree. Target registers are in > > target-endianness when you read them off > > the stack; they should be in target endianness > > in memory. GDB has 'set endian little' and > > 'set endian big', and the stub should just pass > > them along however it gets them. gdbserver is > > also meant to run in a native configuration, > > where compile-time checks can tell you the > > endianness. > > Well, maybe I'm guilty of not considering the > general case - haven't thought it through yet. As soon as you try looking through stack frames, you realize that keeping registers in target byte order is a lot simpler for the rest of GDB. > Our application connects to the H-UDI (JTAG) > port of the SH4 for high speed (~20 MBits/s) > access through the back door into the chip. > > The physical implementation includes a 32 bit > shift register. What we notice is that if we > change endianness then we have to endswap the > 32 bit quantity that appears in the register > before transferring it to the target machine > reg. - it never actually gets into memory. That's a property of the board, right? It expects this shift register to be in its own endianness... or is something else going on? > > My first impression is that gdbserver is the > > wrong tool for the job. Gdbserver is meant as > > a remote stub for Unix-like systems. You're > > not running it on a Unix-like system; you're > > using it as a proxy, right? Since GDB already > > has a stub to speak to the hardware monitor > > on SH4 boards, as far as I'm aware. > > This sounds like a job for rproxy > > (http://world.std.com/~qqi) instead. > > Maybe we re-invented the wheel, some. Our > implementation runs on a box equipped with > cpu/flash/ram and ethernet and jtag interfaces. > It does implement the remote protocol in much > the same way that rproxy does, but also adds > facilities like posix i/o through the debug > port. > > Works well. We've used it for debugging both > 'bare machine' embedded and rtos based apps. > (I also brought up a linux kernel with it). Nice job, although I'm not sure gdbserver is the best base for it; like I said, it's generally Unix-based. However, with the other organizational cleanup I've been adding to it lately, I think there's a clean place to integrate this sort of thing now. I don't suppose you're thinking of contributing it? The POSIX I/O stuff especially would be nice to have in gdbserver. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer