From: Luis Machado <luis.machado@arm.com>
To: Jon Wilson <jonwilson030981@googlemail.com>, gdb@sourceware.org
Subject: Re: GDB Stub with ARM BE8 target.
Date: Wed, 1 Jun 2022 09:55:26 +0100 [thread overview]
Message-ID: <1e53e1fe-b470-e392-7560-a5115e174106@arm.com> (raw)
In-Reply-To: <b49371fd-9a4e-1d4f-78b9-dcb54e93fd3d@gmail.com>
Hi Jon,
On 5/31/22 00:03, Jon Wilson via Gdb wrote:
> I am trying to integrate a GDB stub with a ARM BE8 target. However, it would appear that using "set endian big" defaults to BE32 architecture. I cannot seem to find a way to have the debugger interpret memory according to the BE8 architecture. The only support for BE8 mode I can see seems to be for when using BE8 core dumps or processes (https://github.com/bminor/binutils-gdb/blob/9606310bbbf8a2d529b5c2aa71cac48a46f65869/gdb/arm-tdep.c#L9781). I can't seem to find any documentation on the topic (which is pretty forgivable given how niche it is).
The "set endian" command might not do what you'd expect, as it will set the endianness for data accesses only. The "code access" endianness
will be set by the binary's ELF flag EF_ARM_BE8. So once you load a BE8 binary, GDB will know how to deal with it.
>
> I looked at handling the endianness in the stub itself (e.g. inverting the endianness of memory based on permissions), but given the code stream can contain both instructions (which should be little endian in BE8) as well as data (which should be interpretted as big endian), this is not possible.
>
> Have I missed an option somewhere? If this support is missing, then how should it be added? Should it be handled in a similar way to how GDB handles ARM versus Thumb mode? (https://github.com/bminor/binutils-gdb/blob/9606310bbbf8a2d529b5c2aa71cac48a46f65869/gdb/arm-tdep.c#L10589)?
I don't think you've missed an option. Technically GDB should support BE8 mode, but in practice, since it is less exercised, it may have regressed and may need to be fixed.
Basically GDB needs to be aware of data/code endianess when dealing with memory. There might be places that are not dealing with this correctly. Detection of BE8 should happen
through the ELF flag mentioned above, so you wouldn't need to fiddle with GDB option or thumb-like heuristics.
>
> I'd be very grateful for any advice.
>
> Kind Regards.
>
>
> Jon
>
prev parent reply other threads:[~2022-06-01 8:55 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-05-30 23:03 Jon Wilson
2022-05-31 14:38 ` Fwd: " Jon Wilson
2022-06-01 8:55 ` 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=1e53e1fe-b470-e392-7560-a5115e174106@arm.com \
--to=luis.machado@arm.com \
--cc=gdb@sourceware.org \
--cc=jonwilson030981@googlemail.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).