From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21763 invoked by alias); 10 Nov 2004 15:13:14 -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 21736 invoked from network); 10 Nov 2004 15:13:08 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 10 Nov 2004 15:13:08 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id iAAFD279019019; Wed, 10 Nov 2004 10:13:02 -0500 Received: from localhost.redhat.com (to-dhcp51.toronto.redhat.com [172.16.14.151]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id iAAFD1r15705; Wed, 10 Nov 2004 10:13:01 -0500 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 29473129D8C; Wed, 10 Nov 2004 10:11:58 -0500 (EST) Message-ID: <41922FBC.7020309@gnu.org> Date: Wed, 10 Nov 2004 15:13:00 -0000 From: Andrew Cagney User-Agent: Mozilla Thunderbird 0.8 (X11/20041020) MIME-Version: 1.0 To: Hans-Peter Nilsson Cc: gdb-patches@gcc.gnu.org Subject: Re: [RFA:] sim-config.c: When having a bfd, don't just check bfd_little_endian References: <200411092201.iA9M1v21018092@ignucius.se.axis.com> In-Reply-To: <200411092201.iA9M1v21018092@ignucius.se.axis.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-11/txt/msg00195.txt.bz2 Hans-Peter Nilsson wrote: > The testcase for this bug looks like this: > --------------------- > # mach: crisv32 > # output: 0\n0\n4\n42\n > # sim: --cris-naked --target binary --architecture crisv32 > # ld: --oformat binary > > ; Check that we can run a naked binary with the same expected > ; results as an ELF "executable". > > .include "bare1.ms" > --------------------- > > That is, we try and run a binary file with a specified > architecture and test output as with the ELF. Current behaviour > 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. > > Ok to commit? > > 2004-11-09 Hans-Peter Nilsson > > * sim-config.c (sim_config): Recognize when a bfd has unspecified > endian information. > > Index: sim-config.c > =================================================================== > RCS file: /cvs/src/src/sim/common/sim-config.c,v > retrieving revision 1.2 > diff -c -p -r1.2 sim-config.c > *** sim-config.c 23 Nov 2002 01:12:05 -0000 1.2 > --- sim-config.c 9 Nov 2004 19:41:07 -0000 > *************** sim_config (SIM_DESC sd) > *** 146,152 **** > SIM_ASSERT (STATE_MAGIC (sd) == SIM_MAGIC_NUMBER); > > /* extract all relevant information */ > ! if (STATE_PROG_BFD (sd) == NULL) > prefered_target_byte_order = 0; > else > prefered_target_byte_order = (bfd_little_endian(STATE_PROG_BFD (sd)) > --- 146,156 ---- > SIM_ASSERT (STATE_MAGIC (sd) == SIM_MAGIC_NUMBER); > > /* extract all relevant information */ > ! if (STATE_PROG_BFD (sd) == NULL > ! /* If we have a binary input file (presumably with specified > ! "--architecture"), it'll have no endianness. */ > ! || (!bfd_little_endian (STATE_PROG_BFD (sd)) > ! && !bfd_big_endian (STATE_PROG_BFD (sd)))) Yes, although this three way case better expressed using a switch. Change it before committing if you care. Andrew > prefered_target_byte_order = 0; > else > prefered_target_byte_order = (bfd_little_endian(STATE_PROG_BFD (sd)) > > brgds, H-P >