* [RFA:] sim-config.c: When having a bfd, don't just check bfd_little_endian
@ 2004-11-09 22:02 Hans-Peter Nilsson
2004-11-10 15:13 ` Andrew Cagney
0 siblings, 1 reply; 6+ messages in thread
From: Hans-Peter Nilsson @ 2004-11-09 22:02 UTC (permalink / raw)
To: gdb-patches
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))))
prefered_target_byte_order = 0;
else
prefered_target_byte_order = (bfd_little_endian(STATE_PROG_BFD (sd))
brgds, H-P
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [RFA:] sim-config.c: When having a bfd, don't just check bfd_little_endian
2004-11-09 22:02 [RFA:] sim-config.c: When having a bfd, don't just check bfd_little_endian Hans-Peter Nilsson
@ 2004-11-10 15:13 ` Andrew Cagney
2004-11-16 7:19 ` Hans-Peter Nilsson
0 siblings, 1 reply; 6+ messages in thread
From: Andrew Cagney @ 2004-11-10 15:13 UTC (permalink / raw)
To: Hans-Peter Nilsson; +Cc: gdb-patches
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
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFA:] sim-config.c: When having a bfd, don't just check bfd_little_endian
2004-11-10 15:13 ` Andrew Cagney
@ 2004-11-16 7:19 ` Hans-Peter Nilsson
2004-11-16 16:16 ` Andrew Cagney
0 siblings, 1 reply; 6+ messages in thread
From: Hans-Peter Nilsson @ 2004-11-16 7:19 UTC (permalink / raw)
To: cagney; +Cc: hans-peter.nilsson, gdb-patches
> Date: Wed, 10 Nov 2004 10:11:56 -0500
> From: Andrew Cagney <cagney@gnu.org>
> > 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)))
...
> 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
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: [RFA:] sim-config.c: When having a bfd, don't just check bfd_little_endian
2004-11-16 7:19 ` Hans-Peter Nilsson
@ 2004-11-16 16:16 ` Andrew Cagney
0 siblings, 0 replies; 6+ messages in thread
From: Andrew Cagney @ 2004-11-16 16:16 UTC (permalink / raw)
To: Hans-Peter Nilsson; +Cc: gdb-patches
Hans-Peter Nilsson wrote:
>>Date: Wed, 10 Nov 2004 10:11:56 -0500
>>From: Andrew Cagney <cagney@gnu.org>
>
>
>>>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
>
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFA:] sim-config.c: When having a bfd, don't just check bfd_little_endian
@ 2004-11-10 19:01 Paul Schlie
2004-11-10 19:12 ` Paul Schlie
0 siblings, 1 reply; 6+ messages in thread
From: Paul Schlie @ 2004-11-10 19:01 UTC (permalink / raw)
To: gdb-patches
> 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?)
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: [RFA:] sim-config.c: When having a bfd, don't just check bfd_little_endian
2004-11-10 19:01 Paul Schlie
@ 2004-11-10 19:12 ` Paul Schlie
0 siblings, 0 replies; 6+ messages in thread
From: Paul Schlie @ 2004-11-10 19:12 UTC (permalink / raw)
To: gdb-patches
> From: Paul Schlie <schlie@comcast.net>
>
>> 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?
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-11-16 16:16 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-11-09 22:02 [RFA:] sim-config.c: When having a bfd, don't just check bfd_little_endian Hans-Peter Nilsson
2004-11-10 15:13 ` Andrew Cagney
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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox