From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id /jBeDPQsrGhp6wsAWB0awg (envelope-from ) for ; Mon, 25 Aug 2025 05:29:24 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=ispras.ru header.i=@ispras.ru header.a=rsa-sha256 header.s=default header.b=ENripmEm; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 26CCE1E043; Mon, 25 Aug 2025 05:29:24 -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.8 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 08A8D1E043 for ; Mon, 25 Aug 2025 05:29:22 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 9D60E3858039 for ; Mon, 25 Aug 2025 09:29:21 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9D60E3858039 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=ispras.ru header.i=@ispras.ru header.a=rsa-sha256 header.s=default header.b=ENripmEm Received: from mail.ispras.ru (mail.ispras.ru [83.149.199.84]) by sourceware.org (Postfix) with ESMTPS id 70FEC3857C7F; Mon, 25 Aug 2025 09:26:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 70FEC3857C7F Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=ispras.ru Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=ispras.ru ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 70FEC3857C7F Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=83.149.199.84 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1756114018; cv=none; b=sZrp5RRwFKROqxhaac7E8pRBdl25+2FJbmMOTiBYeDrM4pv5PhhiruuhhtgiZt2eyRwrz/kH0xLsa8i6l4cOfeVfsJTxlTPfSI2zSSYu1TMr8pXP7kvEvg5RCw+OEq4kHX5p093cM6kj9G66hODyfVLHq4bETL3dI0lCKX9OV7Q= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1756114018; c=relaxed/simple; bh=yTDoEjd6Jdp350WJF4P2DhBPZrAF7m6kAi2v+FfKUnE=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=DQfhMsLdkIAcYuDwB8MIQG7c1eD47haUxdej8yBm2n8eGZmaJ9LBufhaK4SEQNOqILeDEAUgSPM6pUrLZ7ayVuXv9CXdHy0yUHlw333DGgNHEZoLvkosi/892e9pPWO0uilYwjkMJ5MLVi4PpqHjk6pEB3fVXJzlLOu7JCCTql8= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 70FEC3857C7F Received: from monopod.intra.ispras.ru (unknown [10.10.3.121]) by mail.ispras.ru (Postfix) with ESMTPSA id 1382A40A327B; Mon, 25 Aug 2025 09:26:56 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 mail.ispras.ru 1382A40A327B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ispras.ru; s=default; t=1756114016; bh=GzMnpUpzJ3EBnb2cdaoRQL0IeUDGyiy/sX+mACgaY48=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=ENripmEmu4oA4vUIm6GBdFleZttkVukQNj6prush46z9q8damkpAszT1t7GUwEyE5 xKo/0ycaLBcX76JGQQcwm6gvln7SsIUE/hfuXuSNc2tBwG8GHo6AKBsTRWKIy/06XE vjjG+n+qysyaEDK+K/jVxhoslmedNiYU7l9pdDo8= Date: Mon, 25 Aug 2025 12:26:53 +0300 (MSK) From: Alexander Monakov To: Sam James cc: Jan Beulich , "Jiang, Haochen" , Binutils , gdb-patches@sourceware.org, "H.J. Lu" , Tom de Vries Subject: Re: Inconsistent usage on onebyte_modrm and twobyte_modrm table in x86 disassembler and gdb? In-Reply-To: <87v7mbrdqn.fsf@gentoo.org> Message-ID: <9fe75702-8382-6792-a481-0b22243e3cec@ispras.ru> References: <92aea037-9c0e-438f-8a0a-fd52dd2df7bc@suse.com> <87v7mbrdqn.fsf@gentoo.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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 Hi, On Mon, 25 Aug 2025, Sam James wrote: > 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. I hope the bug is fixed by a more comprehensive patchset from Tom, which has already landed: https://inbox.sourceware.org/gdb-patches/e5282a4b-5d9f-4891-b9b8-45ded54ec6ee@suse.de/ Haochen's question still stands, I guess. Alexander