From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13139 invoked by alias); 10 Nov 2004 19:12:41 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 13062 invoked from network); 10 Nov 2004 19:12:31 -0000 Received: from unknown (HELO rwcrmhc12.comcast.net) (216.148.227.85) by sourceware.org with SMTP; 10 Nov 2004 19:12:31 -0000 Received: from [10.0.1.2] (h000393256f12.ne.client2.attbi.com[24.61.199.96]) by comcast.net (rwcrmhc12) with SMTP id <2004111019123001400rur4le> (Authid: schlie); Wed, 10 Nov 2004 19:12:30 +0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Wed, 10 Nov 2004 19:12:00 -0000 Subject: Re: [RFA:] sim-config.c: When having a bfd, don't just check bfd_little_endian From: Paul Schlie To: Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-SW-Source: 2004-11/txt/msg00206.txt.bz2 > From: Paul Schlie > >> Hans-Peter Nilsson wrote: >> >> That is, we try and run a binary file with a specified >> architecture and test output as with the ELF. Current behavior >> is to emit: >> >> Target (LITTLE_ENDIAN) and specified (BIG_ENDIAN) byte order in conflict >> 0 >> 0 >> 4 >> 42 >> >> which is clearly wrong; BIG_ENDIAN isn't *specified* neither >> should it be perceived as such for a binary file. > > Unless I misunderstand, the protocol should be endian neutral; as such should > likely default to big-endian just like the the rest of gdb's > serial protocol, and networking in general. (arguably there's shouldn't be any > reason for gdb itself be target encoding dependant, correspondingly all > targets should expect the same, and encode/decode appropriately from/to their > respective endian preference/requirements, I would think?) and since binary files are sequence of bytes, they should be transferred as such, therefore inherently endian neutral; as long as the addresses encoding in unambiguous, which arguably should remain similar to all other encoded messages (i.e. big-endian, sent as it's read). Yes?