From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11983 invoked by alias); 16 Nov 2004 16:16:08 -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 11862 invoked from network); 16 Nov 2004 16:15:54 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 16 Nov 2004 16:15:54 -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 iAGGFlV1023234; Tue, 16 Nov 2004 11:15:47 -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 iAGGFkr25101; Tue, 16 Nov 2004 11:15:46 -0500 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id ED88E129D8C; Tue, 16 Nov 2004 11:15:37 -0500 (EST) Message-ID: <419A27A9.40002@gnu.org> Date: Tue, 16 Nov 2004 16:16: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: <200411160719.iAG7JeQe002701@ignucius.se.axis.com> In-Reply-To: <200411160719.iAG7JeQe002701@ignucius.se.axis.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-11/txt/msg00336.txt.bz2 Hans-Peter Nilsson wrote: >>Date: Wed, 10 Nov 2004 10:11:56 -0500 >>From: Andrew Cagney > > >>>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. > > > Not one I see, not without looking at bfd private data > abfd->xvec->byteorder or introducing a multi-valued accessor for > the bfd endian data or expressing it awkwardly along the lines of: > switch (2 * (bfd_little_endian (STATE_PROG_BFD (sd) != false)) > + (bfd_big_endian (STATE_PROG_BFD (sd) != false))) > ... Ah, GDB exposes all three states, BFD doesn't :-/ Never mind. Andrew >>Change it before committing if you care. > > > Since you made it optional I committed as-is; I didn't see an > obvious and simple way to better express it as a switch. > > brgds, H-P >