From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id WSrWB+pirGd/DSwAWB0awg (envelope-from ) for ; Wed, 12 Feb 2025 03:59:22 -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=LPNfidpN; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 0DEC91E105; Wed, 12 Feb 2025 03:59:22 -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,HTML_MESSAGE,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 BE9FB1E05C for ; Wed, 12 Feb 2025 03:59:20 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 4969B3858403 for ; Wed, 12 Feb 2025 08:59:20 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4969B3858403 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=LPNfidpN Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) by sourceware.org (Postfix) with ESMTPS id B39A63858C52 for ; Wed, 12 Feb 2025 08:58:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B39A63858C52 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 B39A63858C52 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::102e ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1739350691; cv=none; b=ZaoEE8Ntt0dmrFXqFKex9ZXcZm5iac4R2cZjnTx+EAG9CR9oWkkZqsIOx0DhJuShVcBgBp00jFhv9XpfrzcWfu+LmgSVSd9jET7HAtp06I1YPBeYv6tYnzHZA0q1LuyX8aLS8/sZED2D/FK70kK9ucEeXpiKqIARfokMRKvNUPw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1739350691; c=relaxed/simple; bh=qATV6GZ/4QrRcEVTS9CMQV+li0ANTDbRGNSI9Krv6gE=; h=DKIM-Signature:MIME-Version:From:Date:Message-ID:Subject:To; b=iLUVsu+7VHrnNYNHWEGE8VPnZZCGRRbQuCO5PBoYCG7QOXNGfcyzuQnlLa5MlNHxi2U57eF617SaIlRNTqpNweD68u2hscGvrTgpW3lrofVGIhSN2s6hT6Xf7xqie1jZ/GghrIwXN0rN1rcdBY8FRTBnJYUhoL1ip96/77BejAM= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B39A63858C52 Received: by mail-pj1-x102e.google.com with SMTP id 98e67ed59e1d1-2f9f5caa37cso977380a91.0 for ; Wed, 12 Feb 2025 00:58:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1739350685; x=1739955485; darn=sourceware.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=WiPmiZGk6s882NxXpb2BhACAaSHjteaH+DiPo3y9UBQ=; b=LPNfidpNwRhSnZSeiQihRgrmxGP7kytEHOvBH3TOtMpTgqcvkhZeOLTgF667a4Whub eBV/pZNCGBrLqkK8eY/5Tt/so6uexBqmJ2lK/j33JpvJLoDpQWYoW6fQZtYXfznFAQQ8 K2SSSlvRCVBOtBSnJcyX63t/oqLlvTLf58jUQzZgVccmfjyN5dE5uiLo9DGhRin+jYA6 NjgbZjrdZxza1phy8oGOR48IexayYuFFevXlSjuDSRis/8gChxPyuyIU/jHk9HgwepBp ggt+ZlObEZfN/BR/9VrFlFnndOQIa772UXkxmQMdllA6viNw4wYq7h9jGewrNgDKAk0m symQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739350685; x=1739955485; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=WiPmiZGk6s882NxXpb2BhACAaSHjteaH+DiPo3y9UBQ=; b=XUDljB6Rju6MUuIlUDFU5eag5shJkpHKAcx/m/cwIWA4wXJFr1cVD871NYroTeRi9D krqektH9io9CeypfxFJQ/GNMLHmYCpMerAeYaB3/yg27TkTEl23KFF0zrMRgQnn5AhV9 pqLCUkzWvo0IQxflBTQzhGh+9b8EL9+qOLfQ07eVsqADv+J+50jX8OS+9Sl0CfmbFztU RFJ4XnYSHrTu0F3+Vwd5PbgKF0+/erCY0DC3FdqiDdz2VUSM0Qb+FmAhQ0HYLo5vO6Oa l2/Pe/4IELQrFv+nCugJZy/YgF5qii6bShDfr2iD7EHVObanqHXBdRW2dKp5ShQar6/e FV9w== X-Forwarded-Encrypted: i=1; AJvYcCVLMU4tDcxf3kgm8qks3L+8LFyKIUJEGzOwfUXzls9nCKe7ahnywsff6hstinvEU6J00Y5Q6nMF50a9WQ==@sourceware.org X-Gm-Message-State: AOJu0Yzw3PCgiXQzqjRqA9b1eJ0JGLukHC16aayCS3tL4NZmkTXnwUb/ 1tbiiwzb2BO0oMLL7WIFvUucmNU9M+LRMhmoMwW6PBf7e833mdlBuUUp8Y/HSHP8/SYMewA0tly AovZo7dWQkGq1CBqLC1Ybw3qu4l3doCZ2zv5zZCv9sLP3obJfsbU= X-Gm-Gg: ASbGncsLyL41i0c8GeG4qW0sMwDIoO6EjHDjfijhuuf+qXWsdR43swPoN++utVoaGNi myDKyOsWiBNnmneWezuf11Pdp96yPD/1+kBVKAtjRPKotll1md63i9iIRhD1z9jNAImkS409y5g == X-Google-Smtp-Source: AGHT+IEruEuioVIzWHpt2brTDmeWLaBvNitIZl5X/guIsvP97SlI6uLPxWlqfFACcgMOZ+0wCFDtxsuja4fkqRY6C6A= X-Received: by 2002:a17:90b:5690:b0:2fa:22a2:26a3 with SMTP id 98e67ed59e1d1-2fbf5c0e7a7mr3792971a91.6.1739350684815; Wed, 12 Feb 2025 00:58:04 -0800 (PST) MIME-Version: 1.0 References: <20250211-fix_gas_abort-v1-0-afd9730f9c51@rivosinc.com> <20250211-fix_gas_abort-v1-1-afd9730f9c51@rivosinc.com> In-Reply-To: From: Nelson Chu Date: Wed, 12 Feb 2025 16:57:54 +0800 X-Gm-Features: AWEUYZmsFqjbMcNlv2VbRl0oLadk0UpH3YpWI05IyBZ5tsqOZTK_pclQYDe4-hE Message-ID: Subject: Re: [PATCH 1/2] RISC-V: Fix abort when displaying .dword To: Jan Beulich Cc: Charlie Jenkins , gdb-patches , Binutils , jiawei , Andrew Burgess Content-Type: multipart/alternative; boundary="000000000000b569d5062dee239f" 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 --000000000000b569d5062dee239f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Feb 12, 2025 at 4:06=E2=80=AFPM Jan Beulich wro= te: > 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. > > 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 =3D 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. > Well if I see .word, I also expect to print the full 4 bytes, so probably just remove the case 3, and then make sure that we only have 1/2/4/8 for data, which means .byte/.short/.word/.dword. That is - opcodes/riscv-dis.c | 12 ++++-------- 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/opcodes/riscv-dis.c b/opcodes/riscv-dis.c index d67b2c2aaf0..fc774760f8c 100644 --- a/opcodes/riscv-dis.c +++ b/opcodes/riscv-dis.c @@ -1308,14 +1308,6 @@ riscv_disassemble_data (bfd_vma memaddr ATTRIBUTE_UNUSED, (*info->fprintf_styled_func) (info->stream, dis_style_immediate, "0x%04x", (unsigned) data); break; - case 3: - info->bytes_per_line =3D 7; - (*info->fprintf_styled_func) - (info->stream, dis_style_assembler_directive, ".word"); - (*info->fprintf_styled_func) (info->stream, dis_style_text, "\t"); - (*info->fprintf_styled_func) - (info->stream, dis_style_immediate, "0x%06x", (unsigned) data); - break; case 4: info->bytes_per_line =3D 8; (*info->fprintf_styled_func) @@ -1497,6 +1489,10 @@ print_insn_riscv (bfd_vma memaddr, struct disassemble_info *info) } else if (bytes_fetched !=3D dump_size) { + bytes_fetched =3D bytes_fetched >=3D 8 + ? 8 : bytes_fetched >=3D 4 + ? 4 : bytes_fetched >=3D 2 + ? 2 : bytes_fetched; dump_size =3D bytes_fetched; info->bytes_per_chunk =3D dump_size; riscv_disassembler =3D riscv_disassemble_data; This may make stuff easier, and the logic is similar to riscv_data_length when the length is 3. Nelson --000000000000b569d5062dee239f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Wed, Feb 12, 2025 at 4:06=E2=80=AFPM J= an Beulich <jbeulich@suse.com&g= t; wrote:
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 print= ed
covers full 8 bytes. Imo fake .<N>byte directives (which the assemble= r
doesn't recognize for non-power-of-2 N) would be more logical to use.
Also, question to the maintainers: Can we perhaps stop this unnecessary
decoration of indirect function calls? E.g. (taking part of the above)

=C2=A0 =C2=A0 case 5:
=C2=A0 =C2=A0 =C2=A0 info->bytes_per_line =3D 8;
=C2=A0 =C2=A0 =C2=A0 info->fprintf_styled_func
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (info->stream, dis_style_assembler_directive= , ".dword");
=C2=A0 =C2=A0 =C2=A0 info->fprintf_styled_func (info->stream, dis_sty= le_text, "\t");
=C2=A0 =C2=A0 =C2=A0 info->fprintf_styled_func
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (info->stream, dis_style_immediate, "0x= %010lx",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(unsigned long) data);
=C2=A0 =C2=A0 =C2=A0 break;

has been perfectly fine to write for several decades, and is imo quite
a bit easier to read.

Well if I see .wo= rd, I also expect to print the full 4 bytes, so probably just remove the ca= se 3, and then make sure that we only have 1/2/4/8 for data, which means .b= yte/.short/.word/.dword.=C2=A0 That is -

=C2=A0opcodes/= riscv-dis.c | 12 ++++--------
=C2=A01 file changed, 4 insertions(+), 8 d= eletions(-)

diff --git a/opcodes/riscv-dis.c b/opcodes/riscv-dis.cindex d67b2c2aaf0..fc774760f8c 100644
--- a/opcodes/riscv-dis.c
+++= b/opcodes/riscv-dis.c
@@ -1308,14 +1308,6 @@ riscv_disassemble_data (bf= d_vma memaddr ATTRIBUTE_UNUSED,
=C2=A0 =C2=A0 =C2=A0 =C2=A0(*info->fp= rintf_styled_func)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 (info->stream, dis_sty= le_immediate, "0x%04x", (unsigned) data);
=C2=A0 =C2=A0 =C2=A0= =C2=A0break;
- =C2=A0 =C2=A0case 3:
- =C2=A0 =C2=A0 =C2=A0info->b= ytes_per_line =3D 7;
- =C2=A0 =C2=A0 =C2=A0(*info->fprintf_styled_fun= c)
- =C2=A0 =C2=A0 =C2=A0 (info->stream, dis_style_assembler_directiv= e, ".word");
- =C2=A0 =C2=A0 =C2=A0(*info->fprintf_styled_f= unc) (info->stream, dis_style_text, "\t");
- =C2=A0 =C2=A0 = =C2=A0(*info->fprintf_styled_func)
- =C2=A0 =C2=A0 =C2=A0 (info->s= tream, dis_style_immediate, "0x%06x", (unsigned) data);
- =C2= =A0 =C2=A0 =C2=A0break;
=C2=A0 =C2=A0 =C2=A0case 4:
=C2=A0 =C2=A0 =C2= =A0 =C2=A0info->bytes_per_line =3D 8;
=C2=A0 =C2=A0 =C2=A0 =C2=A0(*in= fo->fprintf_styled_func)
@@ -1497,6 +1489,10 @@ print_insn_riscv (bfd= _vma memaddr, struct disassemble_info *info)
=C2=A0 =C2=A0 =C2=A0}
= =C2=A0 =C2=A0else if (bytes_fetched !=3D dump_size)
=C2=A0 =C2=A0 =C2=A0= {
+ =C2=A0 =C2=A0 =C2=A0bytes_fetched =3D bytes_fetched >=3D 8
+ = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ? 8 := bytes_fetched >=3D 4
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ? 4 : bytes_fetched >=3D 2=
+ =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ? 2 : bytes_fetched;
=C2=A0 = =C2=A0 =C2=A0 =C2=A0dump_size =3D bytes_fetched;
=C2=A0 =C2=A0 =C2=A0 = =C2=A0info->bytes_per_chunk =3D dump_size;
=C2=A0 =C2=A0 =C2=A0 =C2= =A0riscv_disassembler =3D riscv_disassemble_data;

Th= is may make stuff easier, and the logic is similar to riscv_data_length whe= n the length is 3.

Nelson
=C2=A0
--000000000000b569d5062dee239f--