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?
>
prev parent 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).