From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id wrymDtoirGj85QsAWB0awg (envelope-from ) for ; Mon, 25 Aug 2025 04:46:18 -0400 Received: by simark.ca (Postfix, from userid 112) id 248DF1E043; Mon, 25 Aug 2025 04:46:18 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.7 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, MAILING_LIST_MULTI,RCVD_IN_DNSWL_LOW, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED, RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=no autolearn_force=no version=4.0.1 Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id C7F041E043 for ; Mon, 25 Aug 2025 04:46:16 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 4E9163857836 for ; Mon, 25 Aug 2025 08:46:16 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4E9163857836 Received: from smtp.gentoo.org (dev.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) by sourceware.org (Postfix) with ESMTP id 51CFC3858D37; Mon, 25 Aug 2025 08:45:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 51CFC3858D37 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gentoo.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gentoo.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 51CFC3858D37 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2001:470:ea4a:1:5054:ff:fec7:86e4 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1756111545; cv=none; b=EVbFS6k5T5m6ogdvDW0kn9MseF9iIQbcJxPfD0sLf0AhqQSEr7qBZVP2C5KObTohTpveFcaU9+K25HWGMpij01p1WQngnHJpgC5XW9vMb9DZr+FIDY8PhTA5W67PQAmRt+EzUHFpLUednM8qaolgSFAtOlLGCZBNOSueMpr8Uw4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1756111545; c=relaxed/simple; bh=AM6hq8Qe2JMlS1PBtSs14P+PmBeAqtgPXayd6t7/sKs=; h=From:To:Subject:Date:Message-ID:MIME-Version; b=t6gjOuHpGlXtef6N7w3mcsacD0lhOgXnyvs4XUEgp9zdE2LqlnRyR7I+LN/y7mBMBs8LSZwUySsNCy9C1e9oXj005SlkRkFDwiPfscvT25paFGh15MxB/sPPD8XPt0KxAkHrbJ5htakQ3qwl/ax6OPc7UURwj191BUJhg37pUjM= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 51CFC3858D37 Received: from mop.sam.mop (2.8.3.0.0.0.0.0.0.0.0.0.0.0.0.0.a.5.c.d.c.d.9.1.0.b.8.0.1.0.0.2.ip6.arpa [IPv6:2001:8b0:19dc:dc5a::382]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange secp256r1 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: sam) by smtp.gentoo.org (Postfix) with ESMTPSA id 7A347340DF8; Mon, 25 Aug 2025 08:45:40 +0000 (UTC) From: Sam James To: Jan Beulich Cc: "Jiang, Haochen" , Binutils , gdb-patches@sourceware.org, H.J. Lu , Alexander Monakov Subject: Re: Inconsistent usage on onebyte_modrm and twobyte_modrm table in x86 disassembler and gdb? In-Reply-To: <92aea037-9c0e-438f-8a0a-fd52dd2df7bc@suse.com> Organization: Gentoo References: <92aea037-9c0e-438f-8a0a-fd52dd2df7bc@suse.com> User-Agent: mu4e 1.12.12; emacs 31.0.50 Date: Mon, 25 Aug 2025 09:45:36 +0100 Message-ID: <87v7mbrdqn.fsf@gentoo.org> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org Jan Beulich writes: > On 25.08.2025 04:42, Jiang, Haochen wrote: >> Hi all, >> >> Recently I happened to have a look at the gdb code. At gdb/amd64-tdep.c >> L1102 comment, it mentioned that: >> >> /* WARNING: Keep onebyte_has_modrm, twobyte_has_modrm in sync with >> ../opcodes/i386-dis.c (until libopcodes exports them, or an alternative, >> at which point delete these in favor of libopcodes' versions). */ >> >> This means the table content and usage should be the same as gas. >> >> However, when we are using the table in disassembler at opcode/i386-dis.c >> L9877, it is: >> >> /* REX2.M in rex2 prefix represents map0 or map1. */ >> if (ins.last_rex2_prefix < 0 ? *ins.codep == 0x0f : (ins.rex2 & REX2_M)) >> { >> if (!ins.rex2) >> { >> ins.codep++; >> if (!fetch_code (info, ins.codep + 1)) >> goto fetch_error_out; >> } >> >> dp = &dis386_twobyte[*ins.codep]; >> ins.need_modrm = twobyte_has_modrm[*ins.codep]; >> } >> else >> { >> dp = &dis386[*ins.codep]; >> ins.need_modrm = onebyte_has_modrm[*ins.codep]; >> } >> >> It will use the very first byte of the bytecode. >> >> On the other hand, in gdb, let's take VEX prefix as example at >> gdb/amd64-tdep.c L1349, the logic is: >> >> /* Skip REX/VEX instruction encoding prefixes. */ >> ... >> else if (vex2_prefix_p (*insn)) >> { >> details->enc_prefix_offset = insn - start; >> insn += 2; >> } >> else if (vex3_prefix_p (*insn)) >> { >> details->enc_prefix_offset = insn - start; >> insn += 3; >> } >> ... >> if (prefix != nullptr && rex2_prefix_p (*prefix)) >> { >> ... >> } >> else if (prefix != nullptr && vex2_prefix_p (*prefix)) >> { >> need_modrm = twobyte_has_modrm[*insn]; >> details->opcode_len = 2; >> } >> else if (prefix != nullptr && vex3_prefix_p (*prefix)) >> { >> need_modrm = twobyte_has_modrm[*insn]; >> ... >> } >> ... >> >> It will skip the VEX prefix and use twobyte_has_modrm table instead of >> onebyte_has_modrm[0xc4/c5] in disassembler. The table usage are totally >> different although the table itself is the same. It will cause the need_modrm >> value different eventually. For example, opcode for VPBLENDW under 128 bit >> is "VEX.128.66.0F3A.WIG 0E /r ib". The need_modrm would be false in gdb >> since twobyte_has_modrm[0x0e] is false. >> >> Does anyone know the reason on that? It is weird to me. > > Same here; see https://sourceware.org/pipermail/gdb-patches/2019-February/155347.html. > That patch might require re-basing and some work to be up-to-date again, but > fundamentally it still looks applicable. I don't really understand why stuff > like this isn't allowed in. Pedro's desire for a testcase is understandable, > but shouldn't block such a patch (there was a 2nd one s well) for this many > years. I didn't realise a patch was rotting for this. There's Alexander's PR28999 (and a few other either dupes or very-related bugs) too. While I can understand wanting a testcase, tdep is really in a sorry state for x86 anyway, and this clearly makes it better. Perhaps with Haochen's interest, we can finally get it in. But I don't see any specific x86 maintainers for gdb. sam