Specifying target endianness via Remote Serial Protocol

Specifying target endianness via Remote Serial Protocol

[Omer]

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?

Omer.

Re: Specifying target endianness via Remote Serial Protocol

[Luis Machado]

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?

Re: Specifying target endianness via Remote Serial Protocol

[Omer]

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.

On Mon, 13 Apr 2020 at 16:04, Luis Machado <luis.machado@linaro.org> 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?
>

Re: Specifying target endianness via Remote Serial Protocol

[Luis Machado]

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 <luis.machado@linaro.org 
> <mailto:luis.machado@linaro.org>> 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?
>