From: Luis Machado <luis.machado@arm.com>
To: Mark Wielaard <mark@klomp.org>, noloader@gmail.com
Cc: Gdb <gdb@sourceware.org>, Binutils <binutils@sourceware.org>
Subject: Re: buildbot vs --enable-targets=all
Date: Wed, 3 Aug 2022 12:35:42 +0100 [thread overview]
Message-ID: <f720d209-e85c-ea14-33e8-3e99f1804928@arm.com> (raw)
In-Reply-To: <d5363033e3a22a77ff0a84a961400af695d3b611.camel@klomp.org>
On 8/3/22 11:38, Mark Wielaard wrote:
> Hi Jeffrey,
>
> On Mon, 2022-07-25 at 21:59 -0400, Jeffrey Walton wrote:
>> On Mon, Jul 25, 2022 at 8:26 AM Mark Wielaard <mark@klomp.org> wrote:
>>> On fedora-s390x and debian-ppc64 one of the gdb selftests fails
>>> https://builder.sourceware.org/buildbot/#builders/75/builds/783
>>> https://builder.sourceware.org/buildbot/#builders/76/builds/772
>>>
>>> Running selftest arm-record.
>>> Process record and replay target doesn't support syscall number
>>> -2036195
>>> Process record does not support instruction 0x7f70ee1d at address 0x0.
>>> Self test failed: self-test failed at ../../binutils-gdb/gdb/arm-
>>> tdep.c:14407
>>>
>>> Which is:
>>>
>>> /* 32-bit Thumb-2 instructions. */
>>> {
>>> arm_insn_decode_record arm_record;
>>>
>>> memset (&arm_record, 0, sizeof (arm_insn_decode_record));
>>> arm_record.gdbarch = gdbarch;
>>>
>>> static const uint16_t insns[] = {
>>> /* 1d ee 70 7f mrc 15, 0, r7, cr13, cr0, {3} */
>>> 0xee1d, 0x7f70,
>>> };
>>>
>>> enum bfd_endian endian = gdbarch_byte_order_for_code (arm_record.gdbarch);
>>> instruction_reader_thumb reader (endian, insns);
>>> int ret = decode_insn (reader, &arm_record, THUMB2_RECORD,
>>> THUMB2_INSN_SIZE_BYTES);
>>>
>>> SELF_CHECK (ret == 0);
>>> SELF_CHECK (arm_record.mem_rec_count == 0);
>>> SELF_CHECK (arm_record.reg_rec_count == 1);
>>> SELF_CHECK (arm_record.arm_regs[0] == 7);
>>> }
>>>
>>> This seems a big endian issue given the instructions are given as two
>>> 16bit numbers.
>> [...]
>
>>> For ARM, this does not look right (to me):
>>
>>> static const uint16_t insns[] = {
>>> /* 1d ee 70 7f mrc 15, 0, r7, cr13, cr0, {3} */
>>> 0xee1d, 0x7f70,
>>> };
>>
>> I think you are supposed to use .inst.n and .inst.w because they
>> handle endianness properly.
>
> I couldn't figure out how to do that. Could you give an example?
> It looks like the instruction_reader_thumb only takes an array of
> uint16_t (even though the instructions are 32bit long). But I might be
> looking at the wrong code.
>
> So the following fixes it for me on s390x and ppc64
>
> diff --git a/gdb/arm-tdep.c b/gdb/arm-tdep.c
> index d4c5beb5e06..ef0da73398d 100644
> --- a/gdb/arm-tdep.c
> +++ b/gdb/arm-tdep.c
> @@ -14471,7 +14471,7 @@ arm_record_test (void)
>
> static const uint16_t insns[] = {
> /* 1d ee 70 7f mrc 15, 0, r7, cr13, cr0, {3} */
> - 0xee1d, 0x7f70,
> + 0x7f70, 0xee1d,
> };
>
> enum bfd_endian endian = gdbarch_byte_order_for_code (arm_record.gdbarch);
>
> But obviously that breaks things on little-endian architectures.
> We could define the insns[] differently using
>
> #if _BYTE_ORDER == _LITTLE_ENDIAN
> 0xee1d, 0x7f70,
> #else
> 0x7f70, 0xee1d,
> #endif
>
> But that might not be what you meant.
>
> Thanks,
>
> Mark
I wonder what's going wrong here given we're using gdbarch_byte_order_for_code to read things.
Technically it should read in the right order.
next prev parent reply other threads:[~2022-08-03 11:36 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-25 12:25 Mark Wielaard
2022-07-26 1:24 ` Alan Modra
2022-07-26 11:46 ` Alan Modra
2022-07-26 12:43 ` Alan Modra
2022-07-26 12:55 ` Mark Wielaard
2022-07-26 1:59 ` Jeffrey Walton
2022-08-03 10:38 ` Mark Wielaard
2022-08-03 10:56 ` Andreas Schwab
2022-08-03 11:35 ` Luis Machado [this message]
2022-08-03 11:49 ` Mark Wielaard
2022-08-03 11:54 ` Luis Machado
2022-08-03 11:57 ` Mark Wielaard
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=f720d209-e85c-ea14-33e8-3e99f1804928@arm.com \
--to=luis.machado@arm.com \
--cc=binutils@sourceware.org \
--cc=gdb@sourceware.org \
--cc=mark@klomp.org \
--cc=noloader@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).