This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA:] sim-config.c: When having a bfd, don't just checkbfd_little_endian
- From: Paul Schlie <schlie at comcast dot net>
- To: <gdb-patches at sources dot redhat dot com>
- Date: Wed, 10 Nov 2004 14:12:28 -0500
- Subject: Re: [RFA:] sim-config.c: When having a bfd, don't just checkbfd_little_endian
> 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?