From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10697 invoked by alias); 8 Apr 2002 16:01:36 -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 10637 invoked from network); 8 Apr 2002 16:01:35 -0000 Received: from unknown (HELO beta.dmz-eu.st.com) (164.129.1.35) by sources.redhat.com with SMTP; 8 Apr 2002 16:01:35 -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 64DEB4CEE; Mon, 8 Apr 2002 16:01:24 +0000 (GMT) Received: by zeta.dmz-eu.st.com (STMicroelectronics, from userid 0) id B2502631A; Mon, 8 Apr 2002 15:59:46 +0000 (GMT) Received: from thistle.bri.st.com (localhost [127.0.0.1]) by zeta.dmz-eu.st.com (STMicroelectronics) with ESMTP id 139FA1845; Mon, 8 Apr 2002 15:59:46 +0000 (GMT) Received: from [164.129.8.14] (helo=masterwort) by thistle.bristol.st.com with esmtp (Exim 3.03 #5) id 16ubYV-0005z2-00; Mon, 08 Apr 2002 16:59:43 +0100 Received: from [164.129.14.48] (helo=sioux) by masterwort with asmtp (Exim 3.22 #1) id 16ubYV-0005YD-00; Mon, 08 Apr 2002 16:59:43 +0100 Message-ID: <00fd01c1df16$685bdd50$300e81a4@bri.st.com> From: "Paul Bartlett" To: Cc: References: <005701c1deea$d9cd52b0$300e81a4@bristol.st.com> <20020408104522.A24590@nevyn.them.org> <00d501c1df12$ab1bdd60$300e81a4@bristol.st.com> <20020408114455.A26658@nevyn.them.org> Subject: Re: gdbserver, remote serial protocol and endian issues Date: Mon, 08 Apr 2002 09:01: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/msg00097.txt.bz2 > > 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. Yes, I can see that though if you pick up, say, a 32 bit quantity off the stack into a machine reg, then the endianness issue is handled for you by the bus interface unit. It's only when copying anonymous bytestreams that you have to explicitly handle endianness. > > 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? > No it's a property of the H-UDI port, the debug port built into the chip itself. We can boot the target through this without having any external memory at all (can't do much with it though ;-)) > > 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. > We (SuperH Inc.) have embraced open-source with gusto. In a matter of a few weeks we had compiler with nice gui in place from an almost standing start. gdbserver seemed to be the closest model to our older proprietary toolchains and provided an environment that existing users are reasonably familiar with. > I don't suppose you're thinking of contributing it? > The POSIX I/O stuff especially would be nice to > have in gdbserver. We're in the process of trying to arrange this. Part of the problem is that Hitachi, who originally designed the chips is nervous about releasing too much detail about the debug port. It's a very powerful way to get into a system through the back door. Although they've assigned the core IP to us, there were a few strings attached. If we open-source the adaptor code, then this will implicitly release much of the information that Hitachi are trying to keep under their hats. It's frustrating :-( Best, Paul