From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id X8YFGFx0rGhQEAwAWB0awg (envelope-from ) for ; Mon, 25 Aug 2025 10:34:04 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=ThurMlcb; dkim=pass header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=qvO2DWRo; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=ThurMlcb; dkim=neutral header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=qvO2DWRo; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 51B8C1E048; Mon, 25 Aug 2025 10:34:04 -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 6299A1E023 for ; Mon, 25 Aug 2025 10:34:03 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id E5DFA3857738 for ; Mon, 25 Aug 2025 14:34:02 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E5DFA3857738 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=ThurMlcb; dkim=pass header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=qvO2DWRo; dkim=pass (1024-bit key) header.d=suse.de header.i=@suse.de header.a=rsa-sha256 header.s=susede2_rsa header.b=ThurMlcb; dkim=neutral header.d=suse.de header.i=@suse.de header.a=ed25519-sha256 header.s=susede2_ed25519 header.b=qvO2DWRo Received: from smtp-out2.suse.de (smtp-out2.suse.de [IPv6:2a07:de40:b251:101:10:150:64:2]) by sourceware.org (Postfix) with ESMTPS id 1888D3858D29 for ; Mon, 25 Aug 2025 14:33:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1888D3858D29 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 1888D3858D29 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a07:de40:b251:101:10:150:64:2 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1756132400; cv=none; b=glla/oKTVwTNOqek8Nj7CUqDKnEzVFnTXmQAN5+/yXPlecu7ioAMTGps1/r/Jmu+nBVWplpyekpcFz48juxsjYT+Gul/GiNntJ41fmE3T9AUwTudRL8pgurRWjbcdsKoMWL6Nre1zojKG6g3hZlFxNLRuaGVE0C1FBe9Nj4/eUM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1756132400; c=relaxed/simple; bh=C2m5NmOEjf6GyyQcCytiNetzNHY7D8c1HMtfWIv9dWU=; h=DKIM-Signature:DKIM-Signature:DKIM-Signature:DKIM-Signature: Message-ID:Date:MIME-Version:Subject:To:From; b=YCfZIi5mCW+eXjm0qaGnAbubEEUYzYInJ1b5g4+xM1+8HX9hybEoTg7a3uEBj52zdG0hqIxFrhIau4SavU8aJTSrEQFWlajb4Dy6PI+h1ZsQgxMT9vjUP4sUOrbeYYby24OXAeR3GMH0Go2kVwMmKBlwwxCUHzMwrVSNwgi9EqU= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1888D3858D29 Received: from imap1.dmz-prg2.suse.org (unknown [10.150.64.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 1BFAD1F788; Mon, 25 Aug 2025 14:33:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1756132399; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=0Nwr5Yf2olwQenOc0IBgDe31NdXImIG4PIrS10km4f8=; b=ThurMlcbvj1czUhpXKNazfnFjBP6JY8ed7A/YoFtdBa5ekBwPfJJvQkW+kuGSWzSVt/WP8 EIehLgFJFQGBr3CkgWy+DoUOqokco+R3la78+p3pq3JUFMzoWfCTvPvpuOIVFt9ih8pisp aw8NAJ5Er2JHtVduYqKBO1z/l0uosTo= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1756132399; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=0Nwr5Yf2olwQenOc0IBgDe31NdXImIG4PIrS10km4f8=; b=qvO2DWRo3idpvARiRQVMq1wN7db0eKn2LwRqLH3jft7jnxiPf7JW+ZJVteRN0Ds3TwN10+ D3vwo+QBqkYoFdBA== Authentication-Results: smtp-out2.suse.de; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1756132399; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=0Nwr5Yf2olwQenOc0IBgDe31NdXImIG4PIrS10km4f8=; b=ThurMlcbvj1czUhpXKNazfnFjBP6JY8ed7A/YoFtdBa5ekBwPfJJvQkW+kuGSWzSVt/WP8 EIehLgFJFQGBr3CkgWy+DoUOqokco+R3la78+p3pq3JUFMzoWfCTvPvpuOIVFt9ih8pisp aw8NAJ5Er2JHtVduYqKBO1z/l0uosTo= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1756132399; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=0Nwr5Yf2olwQenOc0IBgDe31NdXImIG4PIrS10km4f8=; b=qvO2DWRo3idpvARiRQVMq1wN7db0eKn2LwRqLH3jft7jnxiPf7JW+ZJVteRN0Ds3TwN10+ D3vwo+QBqkYoFdBA== Received: from imap1.dmz-prg2.suse.org (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by imap1.dmz-prg2.suse.org (Postfix) with ESMTPS id DAC83136DB; Mon, 25 Aug 2025 14:33:18 +0000 (UTC) Received: from dovecot-director2.suse.de ([2a07:de40:b281:106:10:150:64:167]) by imap1.dmz-prg2.suse.org with ESMTPSA id iDf8My50rGg3NwAAD6G6ig (envelope-from ); Mon, 25 Aug 2025 14:33:18 +0000 Message-ID: <34bc7418-6d00-45f7-b385-55d687307677@suse.de> Date: Mon, 25 Aug 2025 16:33:30 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Inconsistent usage on onebyte_modrm and twobyte_modrm table in x86 disassembler and gdb? To: Alexander Monakov , Sam James Cc: Jan Beulich , "Jiang, Haochen" , Binutils , gdb-patches@sourceware.org, "H.J. Lu" References: <92aea037-9c0e-438f-8a0a-fd52dd2df7bc@suse.com> <87v7mbrdqn.fsf@gentoo.org> <9fe75702-8382-6792-a481-0b22243e3cec@ispras.ru> Content-Language: en-US From: Tom de Vries In-Reply-To: <9fe75702-8382-6792-a481-0b22243e3cec@ispras.ru> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spamd-Result: default: False [-1.80 / 50.00]; BAYES_HAM(-3.00)[100.00%]; SUSPICIOUS_RECIPS(1.50)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_HAM_SHORT(-0.20)[-1.000]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_CC(0.00)[suse.com,intel.com,sourceware.org,gmail.com]; MIME_TRACE(0.00)[0:+]; FUZZY_RATELIMITED(0.00)[rspamd.com]; ARC_NA(0.00)[]; DKIM_SIGNED(0.00)[suse.de:s=susede2_rsa,suse.de:s=susede2_ed25519]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_ALL(0.00)[]; FREEMAIL_ENVRCPT(0.00)[gmail.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; RCPT_COUNT_SEVEN(0.00)[7]; MID_RHS_MATCH_FROM(0.00)[]; TAGGED_RCPT(0.00)[]; DBL_BLOCKED_OPENRESOLVER(0.00)[suse.de:mid, imap1.dmz-prg2.suse.org:helo, suse.com:email] 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 On 8/25/25 11:26, Alexander Monakov wrote: > 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. Hi Alexander, thanks for cc-ing me on this thread. Indeed the PR you filed has been fixed. I grepped a bit in the gas testsuite for VPBLENDW and constructed a gdb unit test that passes with workaround but fails without: ... diff --git a/gdb/amd64-tdep.c b/gdb/amd64-tdep.c index d5ea4aff4cf..251e6932c64 100644 --- a/gdb/amd64-tdep.c +++ b/gdb/amd64-tdep.c @@ -3755,6 +3755,32 @@ test_amd64_get_insn_details (void) = { 0x62, 0xf1, 0x7c, 0x48, 0x28, 0x81, 0x00, 0xfc, 0xff, 0xff }; fixup_riprel (details, insn.data (), ECX_REG_NUM); SELF_CHECK (insn == updated_insn); + + /* INSN: vpblendw $0x7,%xmm4,%xmm6,%xmm2, vex3 prefix. */ + insn = { 0xc4, 0xe3, 0x49, 0x0e, 0xd4, 0x07 }; + amd64_get_insn_details (insn.data (), &details); + SELF_CHECK (details.opcode_len == 3); + SELF_CHECK (details.enc_prefix_offset == 0); + SELF_CHECK (details.opcode_offset == 3); + SELF_CHECK (details.modrm_offset == -1); + + /* INSN: vpblendw $0x7,0xff(%rip),%ymm6,%ymm2. */ + insn = { 0xc4, 0xe3, 0x4d, 0x0e, 0x15, 0xff, 0x00, 0x00, 0x00, 0x07 }; + amd64_get_insn_details (insn.data (), &details); + + if (1 && details.modrm_offset == -1) + { + /* Workaround. */ + details.modrm_offset = 4; + } + + SELF_CHECK (details.modrm_offset != -1); + + /* INSN: vpblendw $0x7,0xff(%ecx),%ymm6,%ymm2. */ + fixup_riprel (details, insn.data (), ECX_REG_NUM); + updated_insn + = { 0xc4, 0xe3, 0x4d, 0x0e, 0x91, 0xff, 0x00, 0x00, 0x00, 0x07 }; + SELF_CHECK (insn == updated_insn); } static void ... because of an incorrect modrm_offset value. I'll try to fix this. Thanks, - Tom