Specifying target endianness via Remote Serial Protocol

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Specifying target endianness via Remote Serial Protocol

Sourceware - gdb list mailing list
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.
Reply | Threaded
Open this post in threaded view
|

Re: Specifying target endianness via Remote Serial Protocol

Sourceware - gdb list mailing list
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?
Reply | Threaded
Open this post in threaded view
|

Re: Specifying target endianness via Remote Serial Protocol

Sourceware - gdb list mailing list
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 <[hidden email]> 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?
>
Reply | Threaded
Open this post in threaded view
|

Re: Specifying target endianness via Remote Serial Protocol

Sourceware - gdb list mailing list
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 <[hidden email]
> <mailto:[hidden email]>> 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?
>