From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14170 invoked by alias); 8 Apr 2002 14:45: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 14120 invoked from network); 8 Apr 2002 14:45:50 -0000 Received: from unknown (HELO nevyn.them.org) (128.2.145.6) by sources.redhat.com with SMTP; 8 Apr 2002 14:45:50 -0000 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 16uaOY-0006Rw-00; Mon, 08 Apr 2002 10:45:22 -0400 Date: Mon, 08 Apr 2002 07:45:00 -0000 From: Daniel Jacobowitz To: Paul Bartlett Cc: gdb@sources.redhat.com Subject: Re: gdbserver, remote serial protocol and endian issues Message-ID: <20020408104522.A24590@nevyn.them.org> Mail-Followup-To: Paul Bartlett , gdb@sources.redhat.com References: <005701c1deea$d9cd52b0$300e81a4@bri.st.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <005701c1deea$d9cd52b0$300e81a4@bri.st.com> User-Agent: Mutt/1.3.23i X-SW-Source: 2002-04/txt/msg00094.txt.bz2 On Mon, Apr 08, 2002 at 11:47:59AM +0100, Paul Bartlett wrote: > Hi Folks, > > We've developed an implementation of gdbserver that > runs in a box interfacing the debug ports of SuperH > SH4/SH5 targets to ethernet. > > When connecting to a target cpu, various memory mapped > registers must be initialised in order to configure > the external bus interfaces, clock generators and > so forth. > > This achieved by doing pokes from script files. > > The target may be jumper configured to be either big > or little endian. > > Unfortunately, the remote serial protocol makes no > distinction between writes to memory and writes to > memory mapped registers - you just get a byte stream > in target endian order. > > In our case, the registers are not byte addressable > and need to be written variously as 8, 16 and 32 bit > quantities. Again, remote serial protocol does not > provide for access size definition. This one is definitely a shortcoming in the remote protocol. The lack of endianness information may be, also... that's open for discussion. > In order to get things to work at all, we've had to > embed knowledge of specific CPU variants in the > gdbserver code together with an indication of the > target endianness - messy to say the least, and a > pain to maintain. > > On an aesthetic note, when reading and writing CPU > registers, the transfer really ought to be endian > neutral - i.e. in a consistent format that does > not change with the endianness of the target. Network > byte order perhaps? This would also remove the need > for gdbserver to be aware of target endianness. 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. > > I noticed a brief flurry of posts on the subject about > a year ago but nothing since. > > Does anyone have an opinion on this? 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. You definitely did highlight some failures of the remote protocol, though. After I finish my current project I intend to update the documentation of the protocol and see what needs fixing. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer