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 B9D82385840A; Wed, 3 Aug 2022 11:49:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B9D82385840A 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 27167300B36D; Wed, 3 Aug 2022 13:49:35 +0200 (CEST) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id 544374001689; Wed, 3 Aug 2022 13:49:33 +0200 (CEST) Message-ID: <62a77a3a304f0088fe75adfb2b2ce3339023a32a.camel@klomp.org> Subject: Re: buildbot vs --enable-targets=all From: Mark Wielaard To: Luis Machado , noloader@gmail.com Cc: Gdb , Binutils Date: Wed, 03 Aug 2022 13:49:33 +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: gdb@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Aug 2022 11:49:38 -0000 Hi Luis, On Wed, 2022-08-03 at 12:35 +0100, Luis Machado wrote: > On 8/3/22 11:38, Mark Wielaard wrote: > > 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. > > >=20 > > > [...] > > > > For ARM, this does not look right (to me): > > > > 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. > >=20 > > 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. > >=20 > > So the following fixes it for me on s390x and ppc64 > >=20 > > 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.gdbarch); > >=20 > > But obviously that breaks things on little-endian architectures. > > We could define the insns[] differently using > >=20 > > #if _BYTE_ORDER =3D=3D _LITTLE_ENDIAN > > 0xee1d, 0x7f70, > > #else > > 0x7f70, 0xee1d, > > #endif > >=20 > > But that might not be what you meant. > >=20 > I wonder what's going wrong here given we're using > gdbarch_byte_order_for_code to read things. >=20 > Technically it should read in the right order. Yes, if the code bytes were in the right order. Like when you read them from disk or from a process running in that byte order. But here they are constructed in memory in the byte order of the host architecture as an uint16_t array. So when using the gdbarch_byte_order_for_code order to reconstruct those instructions it is not using the host byte order (if they don't match). I think what Jeffrey means is that there is a different way to construct the bytes in memory using .inst.n and .inst.w, but I don't fully understand how that works. Cheers, Mark