From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30997 invoked by alias); 10 Nov 2004 19:01:55 -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 30922 invoked from network); 10 Nov 2004 19:01:50 -0000 Received: from unknown (HELO sccrmhc12.comcast.net) (204.127.202.56) by sourceware.org with SMTP; 10 Nov 2004 19:01:50 -0000 Received: from [10.0.1.2] (h000393256f12.ne.client2.attbi.com[24.61.199.96]) by comcast.net (sccrmhc12) with SMTP id <2004111019014901200sp0v0e> (Authid: schlie); Wed, 10 Nov 2004 19:01:49 +0000 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Wed, 10 Nov 2004 19:01: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: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-SW-Source: 2004-11/txt/msg00204.txt.bz2 > 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?)