From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id ce1FF8BCrWdOwC0AWB0awg (envelope-from ) for ; Wed, 12 Feb 2025 19:54:24 -0500 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=rivosinc-com.20230601.gappssmtp.com header.i=@rivosinc-com.20230601.gappssmtp.com header.a=rsa-sha256 header.s=20230601 header.b=j0AI3nak; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 4C2251E105; Wed, 12 Feb 2025 19:54:24 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.0 (2022-12-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-5.3 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED autolearn=ham autolearn_force=no version=4.0.0 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 65C871E08E for ; Wed, 12 Feb 2025 19:54:23 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id D27B03821A1B for ; Thu, 13 Feb 2025 00:54:22 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D27B03821A1B Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=rivosinc-com.20230601.gappssmtp.com header.i=@rivosinc-com.20230601.gappssmtp.com header.a=rsa-sha256 header.s=20230601 header.b=j0AI3nak Received: from mail-yw1-x1135.google.com (mail-yw1-x1135.google.com [IPv6:2607:f8b0:4864:20::1135]) by sourceware.org (Postfix) with ESMTPS id 22D3A3857C5F for ; Thu, 13 Feb 2025 00:52:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 22D3A3857C5F Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=rivosinc.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=rivosinc.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 22D3A3857C5F Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::1135 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1739407957; cv=none; b=Rei1tZ8gCQnzHpM5fUWcOtQ0yfeWZPbgPkxXWkckDiDexZ4/218bPFGEjbDiqnLHcC4aZGTJXLPweniFCCFN7YQxZhDcDf0P7y8i6SuPM0/8sz/ZmbCYC1zFBum+sza1TX2/Ebi6Hu73mwXA2dFA9prRjXNQMF3HS4bpWlUYOhE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1739407957; c=relaxed/simple; bh=01slbsPtO+e6gm+4B80iREmmTPcrhd3hf+clFW14idk=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=i8QOiNfVpWgfrpXqK/qaPAt7PqY8AdWx3w6v0M6cPd60X1LPBy+ICncq0H9+3Ov4LGaFiSU8K1SU+1uCw4kHXrhNZ/wQZfBgM5DPCABzQuAjtIwtWbHEf73mRFaCowt8lo5cUdFSdJCSkKPCqRzmg4kd7w9DaD8OaAvONGGMAN4= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 22D3A3857C5F Received: by mail-yw1-x1135.google.com with SMTP id 00721157ae682-6efe4324f96so3244727b3.1 for ; Wed, 12 Feb 2025 16:52:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1739407956; x=1740012756; darn=sourceware.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=4FHHq3V3HA9ekfP6DFY9jrNScPAuFDVM0Gj7GYVVPIU=; b=j0AI3nake5LFEQYg8IthDgpq3vhAACGdBVRnBsB+MJ4jQEaczNvc2WXtD5oKPhKLPu 1fvxSUb9EFKNp99iYjugykAVE/EE86I9bzUOobr7jaeCH4CLOqLhMZI8/roxzdlJ3HBH 3p8kXMjDMJgEYqgni4yQx/G5P4Led0hZdzoBj9AlUkZkOgd9LKiekMdN009SShheobc3 qeFGhxlO16Squ2V6omH5+t8HRlouwGc/8kqq2YpEUYXkgGDcAYV72NbY9PeXt72OreJv gNxljwduPvyCu+GuVf7CavYUhEr4L5VBMsBCIAO74JfOIorhIzGCl2NsNGe3zY0F4+yh eP8g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739407956; x=1740012756; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=4FHHq3V3HA9ekfP6DFY9jrNScPAuFDVM0Gj7GYVVPIU=; b=KRBDQ5cTv4SNpY6UFypY8jPqwiw3FOwJguHAVA/aqRaX9D/rCY6rkYoyuwx2CpcKoT +Rex87VnstRVOHyfRpWMZr8OxFtJmlRu8tlRO73IBOZr8aMvYOQ7q1LxOLjFABsz+1Xa Zf02shc+pnjAaOpl6txocszD4nYjzsXEE6jVaHLwx5zswAdV76ovDWalN1iJCtFkPakz NFKCiU5rY59zc1s8lmQfbGOewLxccHwaWt7k2cTbo2SOrQby/Gf/wn2GsNLGYtkP9k2k eFTRqVkzucJiZt1Bc/JNhKSQkfJTHME0VQwp2/a3GDL9f7VCNcWc5Vj5Sge+YF1uLZ4C tAag== X-Gm-Message-State: AOJu0Yz8iuE/KRROrQIVCJfCNkDypDTc92OCwjVPMTXKMkh0uY+xg753 ENxEJB3JM0Y4ndvH+1tb1CYPkhZWJEPU6mw+kTBIhjrWdsZ16sIVLQ3cows42xM= X-Gm-Gg: ASbGncsJtRyMG4cKgqhJzgef/P3+qXaG78o2VuqIMFAj+qP2Kg4251ZxyWZHJM/c9h8 uPxj+VP3SEimsxwS1z/VgziUUDFZ/mohvyEjCwP6CpqX9HB3SEaNgwGa4xIKZ8GbfFcbALz4i19 yKxy0eF9Pn5VN+uR1m4V/d8+271l9i9RKftGJbOCEihEGhSySFWCSA58nVhHHIwMtpyUwviwJs3 xYTV+7x/jz5aL3zX5Mnw98DS4YRRux/ojCkUALRWZAikq4hvvRprXdHjDH/Hurzkb2rMrr4Hi7p lx8= X-Google-Smtp-Source: AGHT+IGC8zqhQCWj87Kh5OxdkANeVkguSDGGnV2P73csTRsqhyKh9sB2LsoWSk6VRtHH/f1cQsWipg== X-Received: by 2002:a05:690c:4c03:b0:6f9:acb3:4440 with SMTP id 00721157ae682-6fb21b485e9mr48364187b3.17.1739407956411; Wed, 12 Feb 2025 16:52:36 -0800 (PST) Received: from ghost ([50.146.0.9]) by smtp.gmail.com with ESMTPSA id 00721157ae682-6fb3619cab0sm533957b3.72.2025.02.12.16.52.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Feb 2025 16:52:35 -0800 (PST) Date: Wed, 12 Feb 2025 16:52:34 -0800 From: Charlie Jenkins To: Jan Beulich Cc: gdb-patches , Binutils , jiawei , Nelson Chu , Andrew Burgess Subject: Re: [PATCH 1/2] RISC-V: Fix abort when displaying .dword Message-ID: References: <20250211-fix_gas_abort-v1-0-afd9730f9c51@rivosinc.com> <20250211-fix_gas_abort-v1-1-afd9730f9c51@rivosinc.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 Wed, Feb 12, 2025 at 09:06:43AM +0100, Jan Beulich wrote: > On 12.02.2025 06:08, Charlie Jenkins wrote: > > In the normal case an instruction won't be split into 5, 6, or 7 byte > > sections. However a .dword disassembled with -D can cause an instruction > > to split across the 6 byte boundary. 6 byte instructions were not > > supported so riscv_disassemble_data() would abort. > > > > Forcing instructions to be at most 4 bytes causes other unintented > > side-effects, so instead add entries to the switch statement to handle > > instructions that are 5, 6, or 7 bytes. > > > > Signed-off-by: Charlie Jenkins > > Fixes: 6a04e8230707 ("RISC-V: Fix display of partial instructions") > > --- > > opcodes/riscv-dis.c | 29 ++++++++++++++++++++++++++++- > > 1 file changed, 28 insertions(+), 1 deletion(-) > > > > diff --git a/opcodes/riscv-dis.c b/opcodes/riscv-dis.c > > index 367004d3341e46a5f72253cd70c7c2941912e84d..21bcbd32c7f226d13f1637ad192d8fe3c52e0d7a 100644 > > --- a/opcodes/riscv-dis.c > > +++ b/opcodes/riscv-dis.c > > @@ -1325,6 +1325,33 @@ riscv_disassemble_data (bfd_vma memaddr ATTRIBUTE_UNUSED, > > (info->stream, dis_style_immediate, "0x%08lx", > > (unsigned long) data); > > break; > > + case 5: > > + info->bytes_per_line = 8; > > + (*info->fprintf_styled_func) > > + (info->stream, dis_style_assembler_directive, ".dword"); > > + (*info->fprintf_styled_func) (info->stream, dis_style_text, "\t"); > > + (*info->fprintf_styled_func) > > + (info->stream, dis_style_immediate, "0x%010lx", > > + (unsigned long) data); > > This isn't going to have the intended effect on a 32-bit host. > > > + break; > > + case 6: > > + info->bytes_per_line = 8; > > + (*info->fprintf_styled_func) > > + (info->stream, dis_style_assembler_directive, ".dword"); > > + (*info->fprintf_styled_func) (info->stream, dis_style_text, "\t"); > > + (*info->fprintf_styled_func) > > + (info->stream, dis_style_immediate, "0x%012lx", > > + (unsigned long) data); > > + break; > > + case 7: > > + info->bytes_per_line = 8; > > + (*info->fprintf_styled_func) > > + (info->stream, dis_style_assembler_directive, ".dword"); > > + (*info->fprintf_styled_func) (info->stream, dis_style_text, "\t"); > > + (*info->fprintf_styled_func) > > + (info->stream, dis_style_immediate, "0x%014lx", > > + (unsigned long) data); > > + break; > > While this follows what's done in the 3-byte case, I don't consider this > (or the 3-byte logic) correct. When I see .dword, I expect what's printed > covers full 8 bytes. Imo fake .byte directives (which the assembler > doesn't recognize for non-power-of-2 N) would be more logical to use. That's a good point. I think the simplest thing to do would be to have .short/.word/.dword for the 2/4/8 cases and then for anything outside of that print .byte. Similar to what is done with insn with printing .insn , when it is not identified. - Charlie > > Also, question to the maintainers: Can we perhaps stop this unnecessary > decoration of indirect function calls? E.g. (taking part of the above) > > case 5: > info->bytes_per_line = 8; > info->fprintf_styled_func > (info->stream, dis_style_assembler_directive, ".dword"); > info->fprintf_styled_func (info->stream, dis_style_text, "\t"); > info->fprintf_styled_func > (info->stream, dis_style_immediate, "0x%010lx", > (unsigned long) data); > break; > > has been perfectly fine to write for several decades, and is imo quite > a bit easier to read. > > > @@ -1332,7 +1359,7 @@ riscv_disassemble_data (bfd_vma memaddr ATTRIBUTE_UNUSED, > > (*info->fprintf_styled_func) (info->stream, dis_style_text, "\t"); > > (*info->fprintf_styled_func) > > (info->stream, dis_style_immediate, "0x%016llx", > > - (unsigned long long) data); > > + (unsigned long) data); > > This can't be correct; the compiler will complain about format specifier > disagreeing with type of the value to format, on 32-bit hosts. > > Jan