From: Andrew Cagney <cagney@gnu.org>
To: Hans-Peter Nilsson <hans-peter.nilsson@axis.com>
Cc: gdb-patches@gcc.gnu.org
Subject: Re: [RFA:] sim-config.c: When having a bfd, don't just check bfd_little_endian
Date: Wed, 10 Nov 2004 15:13:00 -0000 [thread overview]
Message-ID: <41922FBC.7020309@gnu.org> (raw)
In-Reply-To: <200411092201.iA9M1v21018092@ignucius.se.axis.com>
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 <hp@axis.com>
>
> * 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
>
next prev parent reply other threads:[~2004-11-10 15:13 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-09 22:02 Hans-Peter Nilsson
2004-11-10 15:13 ` Andrew Cagney [this message]
2004-11-16 7:19 ` Hans-Peter Nilsson
2004-11-16 16:16 ` Andrew Cagney
2004-11-10 19:01 Paul Schlie
2004-11-10 19:12 ` Paul Schlie
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=41922FBC.7020309@gnu.org \
--to=cagney@gnu.org \
--cc=gdb-patches@gcc.gnu.org \
--cc=hans-peter.nilsson@axis.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox