From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30764 invoked by alias); 8 Apr 2002 15:40:28 -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 29973 invoked from network); 8 Apr 2002 15:40:25 -0000 Received: from unknown (HELO beta.dmz-eu.st.com) (164.129.1.35) by sources.redhat.com with SMTP; 8 Apr 2002 15:40:25 -0000 Received: from zeta.dmz-eu.st.com (zeta.dmz-eu.st.com [164.129.230.9]) by beta.dmz-eu.st.com (STMicroelectronics) with SMTP id 88CBF4B3C for ; Mon, 8 Apr 2002 15:40:20 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 0) id 760126171; Mon, 8 Apr 2002 15:40:20 +0000 (GMT) Received: from thistle.bri.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 862FF1845 for ; Mon, 8 Apr 2002 15:40:19 +0000 (GMT) Received: from [164.129.8.14] (helo=masterwort) by thistle.bristol.st.com with esmtp (Exim 3.03 #5) id 16ubFh-0005o6-00 for gdb@sources.redhat.com; Mon, 08 Apr 2002 16:40:17 +0100 Received: from [164.129.14.48] (helo=sioux) by masterwort with asmtp (Exim 3.22 #1) id 16ubFg-0005WD-00 for gdb@sources.redhat.com; Mon, 08 Apr 2002 16:40:17 +0100 Message-ID: <00e501c1df13$b0ec66a0$300e81a4@bri.st.com> From: "Paul Bartlett" To: Subject: Fw: gdbserver, remote serial protocol and endian issues Date: Mon, 08 Apr 2002 08:40:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 X-SW-Source: 2002-04/txt/msg00095.txt.bz2 ----- Original Message ----- From: "Paul Bartlett" To: Sent: Monday, April 08, 2002 4:33 PM Subject: Re: gdbserver, remote serial protocol and endian issues > 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. > > 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. > > > 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). > > Best, > > Paul > >