Re: Specifying target endianness via Remote Serial Protocol

Hi,

On 4/14/20 7:45 AM, Omer wrote:
> Will older gdb's really break if we send them fields they don't know? 
> The logical thing to do seems to me to just to discard them.
> I want to use remote gdb without giving it an elf to work with locally 
> (for example if I want to debug some weird embedded system).
> I can somewhat circumvent the problem by giving gdb an empty elf with my 
> wanted endianness, but I don't think it's the optimal solution.

Indeed it seems we properly discard unknown fields. I may have 
misremembered some buggy behavior at some point.

There is some indication in the dtd in gdb/features:

<!-- The osabi and compatible elements were added post GDB 6.8.  The 
version wasn't bumped, since older GDBs silently ignore unknown 
elements.  -->

I also gave it a try by forcing an endian entry in the XML description.

So it seems we only need to tweak the XML machinery to accept such a 
field and pass it on to the architecture initialization code.

> 
> On Mon, 13 Apr 2020 at 16:04, Luis Machado <[email protected] 
> <mailto:[email protected]>> wrote:
> 
>     Hi,
> 
>     On 4/12/20 9:02 AM, Omer via Gdb wrote:
>      > Hi,
>      >
>      > While writing my own gdb stub, I noticed that there is no way to
>     specify
>      > what endianness the target is using (I guess the logical place
>     for that
>      > would be in the target.xml file).
>      > One can use "set endian" manually to fix that, but when debugging
>     an ARM
>      > BE8 target, there is no way to specify that the code is little endian
>      > (currently byte_order_for_code is initialized to little only when
>     loading a
>      > BE8 elf).
>      > Shouldn't there be an additional field for target XML tag to
>     specify that?
> 
>     We could probably extend the XML descriptions to incorporate this, but
>     we may also have backwards compatibility issues with older GDB's by
>     returning new fields the target doesn't know how to parse properly.
> 
>     The way to fix this, right now, would be to teach GDB about other arch
>     variations using little endian, so GDB initializes the proper set of
>     architecture hooks and types.
> 
>     What arch variation are you working with? Doesn't the tools generate a
>     EF_ARM_BE8 flag to let GDB know it needs to assume little endian?
>