public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Mark Wielaard <mark@klomp.org>
To: noloader@gmail.com
Cc: Binutils <binutils@sourceware.org>, Gdb <gdb@sourceware.org>
Subject: Re: buildbot vs --enable-targets=all
Date: Wed, 03 Aug 2022 12:38:39 +0200	[thread overview]
Message-ID: <d5363033e3a22a77ff0a84a961400af695d3b611.camel@klomp.org> (raw)
In-Reply-To: <CAH8yC8nD9JQPnRBKrxxKZJsq1OmEyj3duLDp1axG3qh70nrefw@mail.gmail.com>

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

  reply	other threads:[~2022-08-03 10:38 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 [this message]
2022-08-03 10:56     ` Andreas Schwab
2022-08-03 11:35     ` Luis Machado
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=d5363033e3a22a77ff0a84a961400af695d3b611.camel@klomp.org \
    --to=mark@klomp.org \
    --cc=binutils@sourceware.org \
    --cc=gdb@sourceware.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).