public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Luis Machado <luis.machado@linaro.org>
To: Omer <omerg681@gmail.com>
Cc: gdb@sourceware.org
Subject: Re: Specifying target endianness via Remote Serial Protocol
Date: Tue, 14 Apr 2020 09:36:57 -0300	[thread overview]
Message-ID: <6addc629-36c9-45ec-ae6d-f300ff810c31@linaro.org> (raw)
In-Reply-To: <CALN5k-NB-PEHZ89EV6cD6DJsZX6qN5fz5n-Jqd4BosB7hB3zxQ@mail.gmail.com>

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?
> 

      reply	other threads:[~2020-04-14 12:37 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-12 12:02 Omer
2020-04-13 13:04 ` Luis Machado
2020-04-14 10:45   ` Omer
2020-04-14 12:36     ` Luis Machado [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6addc629-36c9-45ec-ae6d-f300ff810c31@linaro.org \
    --to=luis.machado@linaro.org \
    --cc=gdb@sourceware.org \
    --cc=omerg681@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).