From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2278 invoked by alias); 8 Apr 2002 10:48:37 -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 1788 invoked from network); 8 Apr 2002 10:48:03 -0000 Received: from unknown (HELO beta.dmz-eu.st.com) (164.129.1.35) by sources.redhat.com with SMTP; 8 Apr 2002 10:48:03 -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 39A0249D4 for ; Mon, 8 Apr 2002 10:48:02 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 0) id 2785B6107; Mon, 8 Apr 2002 10:48:02 +0000 (GMT) Received: from thistle.bri.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id BF2441848 for ; Mon, 8 Apr 2002 10:48:00 +0000 (GMT) Received: from [164.129.8.14] (helo=masterwort) by thistle.bristol.st.com with esmtp (Exim 3.03 #5) id 16uWgn-0006Vf-00 for gdb@sources.redhat.com; Mon, 08 Apr 2002 11:47:57 +0100 Received: from [164.129.14.48] (helo=sioux) by masterwort with asmtp (Exim 3.22 #1) id 16uWgn-0004qv-00 for gdb@sources.redhat.com; Mon, 08 Apr 2002 11:47:57 +0100 Message-ID: <005701c1deea$d9cd52b0$300e81a4@bri.st.com> From: "Paul Bartlett" To: Subject: gdbserver, remote serial protocol and endian issues Date: Mon, 08 Apr 2002 03:48: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/msg00092.txt.bz2 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. 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 noticed a brief flurry of posts on the subject about a year ago but nothing since. Does anyone have an opinion on this? Cheers, Paul