From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id E81343858CDB; Wed, 3 Aug 2022 10:38:42 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E81343858CDB Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org Received: from tarox.wildebeest.org (83-87-18-245.cable.dynamic.v4.ziggo.nl [83.87.18.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 122A8300B36D; Wed, 3 Aug 2022 12:38:40 +0200 (CEST) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id B211C4001689; Wed, 3 Aug 2022 12:38:39 +0200 (CEST) Message-ID: Subject: Re: buildbot vs --enable-targets=all From: Mark Wielaard To: noloader@gmail.com Cc: Binutils , Gdb Date: Wed, 03 Aug 2022 12:38:39 +0200 In-Reply-To: References: <94d446556e470859b878bb27eec5e2a52d063673.camel@klomp.org> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-10.el7) Mime-Version: 1.0 X-Spam-Status: No, score=-11.5 required=5.0 tests=BAYES_00, GIT_PATCH_0, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2022 10:38:44 -0000 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 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 > >=20 > > 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 > >=20 > > Which is: > >=20 > > /* 32-bit Thumb-2 instructions. */ > > { > > arm_insn_decode_record arm_record; > >=20 > > memset (&arm_record, 0, sizeof (arm_insn_decode_record)); > > arm_record.gdbarch =3D gdbarch; > >=20 > > static const uint16_t insns[] =3D { > > /* 1d ee 70 7f mrc 15, 0, r7, cr13, cr0, {3} */ > > 0xee1d, 0x7f70, > > }; > >=20 > > enum bfd_endian endian =3D gdbarch_byte_order_for_code (arm_record.= gdbarch); > > instruction_reader_thumb reader (endian, insns); > > int ret =3D decode_insn (reader, &arm_record, THUMB2_RECORD, > > THUMB2_INSN_SIZE_BYTES); > >=20 > > SELF_CHECK (ret =3D=3D 0); > > SELF_CHECK (arm_record.mem_rec_count =3D=3D 0); > > SELF_CHECK (arm_record.reg_rec_count =3D=3D 1); > > SELF_CHECK (arm_record.arm_regs[0] =3D=3D 7); > > } > >=20 > > This seems a big endian issue given the instructions are given as two > > 16bit numbers. > [...] > > For ARM, this does not look right (to me): >=20 > > static const uint16_t insns[] =3D { > > /* 1d ee 70 7f mrc 15, 0, r7, cr13, cr0, {3} */ > > 0xee1d, 0x7f70, > > }; >=20 > 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) =20 static const uint16_t insns[] =3D { /* 1d ee 70 7f mrc 15, 0, r7, cr13, cr0, {3} */ - 0xee1d, 0x7f70, + 0x7f70, 0xee1d, }; =20 enum bfd_endian endian =3D gdbarch_byte_order_for_code (arm_record.gdb= arch); But obviously that breaks things on little-endian architectures. We could define the insns[] differently using #if _BYTE_ORDER =3D=3D _LITTLE_ENDIAN 0xee1d, 0x7f70, #else 0x7f70, 0xee1d, #endif But that might not be what you meant. Thanks, Mark