From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 64ZfKx9XrGenBCwAWB0awg (envelope-from ) for ; Wed, 12 Feb 2025 03:09:03 -0500 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=suse.com header.i=@suse.com header.a=rsa-sha256 header.s=google header.b=QtKUKHip; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 7F77D1E105; Wed, 12 Feb 2025 03:09:03 -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.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,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 4D9A71E05C for ; Wed, 12 Feb 2025 03:09:02 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id CD3513858416 for ; Wed, 12 Feb 2025 08:09:01 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CD3513858416 Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=suse.com header.i=@suse.com header.a=rsa-sha256 header.s=google header.b=QtKUKHip Received: from mail-ed1-x52f.google.com (mail-ed1-x52f.google.com [IPv6:2a00:1450:4864:20::52f]) by sourceware.org (Postfix) with ESMTPS id B2B343858C31 for ; Wed, 12 Feb 2025 08:06:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org B2B343858C31 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=suse.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org B2B343858C31 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::52f ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1739347607; cv=none; b=WSJQe1QcJAtciQ5Tp0PadSMXP6MGzct2ASY9+8YYld01pRyjEcHiZwgSHA+lAWZZIzzekHfiMexC+48ppOLAgR/slqU7P27irc1wRvLVmck8pqmrpgrYe1BTj0+QW2e9lyzNzCbLPh11bahK8nG9fqLMi3CxydUZPm3DjQdHgb0= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1739347607; c=relaxed/simple; bh=F4Rv1Lobcvy03BZY7AfevKuCoUpC8gh0/B82OklY36Q=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=uW6bB7FqODqBRujiHTHuBAiSta/bib5zVFqH6rL1MlMVPCfalZJecVR9UgoRMcqVpJFep7mlcRH1v9z5aKfpaanL+X6I/UPySCYuNvi/UiL3nJA3OHcy/BtxAtcHN5yZTJpkIP9M30tzGRz+p3ABLXObcA0zuaame3n+uRh9I/g= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org B2B343858C31 Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-5dcdb56c9d3so10306329a12.0 for ; Wed, 12 Feb 2025 00:06:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1739347605; x=1739952405; darn=sourceware.org; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:from:to:cc:subject:date:message-id:reply-to; bh=hQfu66BDtleN/BzRfQDY9XRhHzAKih7uXPl9L6S2Ilg=; b=QtKUKHipTXJJsLNqQyUap9P88gx6NYSHziS8W3tb4sj8GM4RiZ5d5Y7ektEF+9bkzk S0SqVBae+Qk+Wug435YKJLvvgHYCyQ9FzrGhQKMfs5UDjSnsTfLnmnRuWx5SBtjD9MUr Y3dXhAXdBTtWyxIbJoyEE1qGvA+ZgLPyb+vZ7wqG94Yeu95i3nP7ZxyLZghXbr2tygaW Z8hTyu7YhCIh/vXzAVorIuk7HankfmZKeTrn/jZYV92QKXL3vsCQexxCMxJR2dIhDqBg /wVpczjIcY/Puh7FGIxQEW+4ilxi5Kqd1H3iDpZrklGviYcNe0r6I8yO79rqPLhBgpIe tIBg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739347605; x=1739952405; h=content-transfer-encoding:in-reply-to:autocrypt:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=hQfu66BDtleN/BzRfQDY9XRhHzAKih7uXPl9L6S2Ilg=; b=C06y0MovS6L00nzd62Zds4uiqekg/gFQjDxDEeSpHB9usyZN/Oc8zFJR6R/7MHEcuO hW+nTDijVUrlKInG1wfA3mUbOtdry5ff5YD/hahdOIXB1qZN3+EUCRiqoTt/Esq6XUTW Yc6o8Ak3ZVSDLYLzl/3yD7Lx5yK3viVrSXkCwXaC+Ta1kpinCU5mbE3okvirzCrC94xp Nhwn7LBi9E0DpxQOlGRRYiU/2lb1VtnBgHtaiuZWxyLQ47iXjAL47706061q2YdQeLSd /zjveMNaSAGiHR1WUCWDpBc657sv6YCjkV8wz4SGmER3dm6L9bGshwMexFMT1dkChbbn a6NQ== X-Gm-Message-State: AOJu0Yzuxc2fRM+nVm5N0Af0ueQdEn3tOgVUbgaQvXlY5+a87nc/McXH klwlW877Jr7M0wg+s0yreQqqBN8B0iroiFxMzp3+esFxRgvWH9A8areorMzLyQ== X-Gm-Gg: ASbGncsTIIYQEbFGfvMNMwOSYMTYvTxAgXbijHyFgBQhoT3h001ZmkwQYc9htxvx3Gl vzSj6IBxRhilvrVymUP6imC0cQFTB4cEAzEAf8YkaCOYwS+hk8PyqwjTUC7FS9iS6CIsV64lECc SbXw2PVT5UpA21CZhGbRmtUqA5N8stV6PphtlLGhgQlaFOfewgOtFb04QFdmmTLOEZrye9gw4Xr QfZQtNCol7dqWP/MjZ9FjajuUdDVNC+fwsw1UHCPikVtynkuOkHLaigf7KKDx4zk8qC6pTUat0j x5SaUMRoHwmDs/Wfj7n1S+KinoWzCPU2QIdkSatneNvRQtwE3TSGWNv5rdyi5edPjYkXNfGW3gP y X-Google-Smtp-Source: AGHT+IEIgnolgwS1ppRw21xMC//lqh5DHKjjinjLpH3G99whntvJy7Is+G/b4LMTVHWG9T87dLyChw== X-Received: by 2002:a05:6402:13cc:b0:5dc:caab:9447 with SMTP id 4fb4d7f45d1cf-5deadd9d336mr5290751a12.18.1739347605316; Wed, 12 Feb 2025 00:06:45 -0800 (PST) Received: from [10.156.60.236] (ip-037-024-206-209.um08.pools.vodafone-ip.de. [37.24.206.209]) by smtp.gmail.com with ESMTPSA id a640c23a62f3a-ab772f893e9sm1231890666b.65.2025.02.12.00.06.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 12 Feb 2025 00:06:44 -0800 (PST) Message-ID: Date: Wed, 12 Feb 2025 09:06:43 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 1/2] RISC-V: Fix abort when displaying .dword To: Charlie Jenkins Cc: gdb-patches , Binutils , jiawei , Nelson Chu , Andrew Burgess References: <20250211-fix_gas_abort-v1-0-afd9730f9c51@rivosinc.com> <20250211-fix_gas_abort-v1-1-afd9730f9c51@rivosinc.com> Content-Language: en-US From: Jan Beulich Autocrypt: addr=jbeulich@suse.com; keydata= xsDiBFk3nEQRBADAEaSw6zC/EJkiwGPXbWtPxl2xCdSoeepS07jW8UgcHNurfHvUzogEq5xk hu507c3BarVjyWCJOylMNR98Yd8VqD9UfmX0Hb8/BrA+Hl6/DB/eqGptrf4BSRwcZQM32aZK 7Pj2XbGWIUrZrd70x1eAP9QE3P79Y2oLrsCgbZJfEwCgvz9JjGmQqQkRiTVzlZVCJYcyGGsD /0tbFCzD2h20ahe8rC1gbb3K3qk+LpBtvjBu1RY9drYk0NymiGbJWZgab6t1jM7sk2vuf0Py O9Hf9XBmK0uE9IgMaiCpc32XV9oASz6UJebwkX+zF2jG5I1BfnO9g7KlotcA/v5ClMjgo6Gl MDY4HxoSRu3i1cqqSDtVlt+AOVBJBACrZcnHAUSuCXBPy0jOlBhxPqRWv6ND4c9PH1xjQ3NP nxJuMBS8rnNg22uyfAgmBKNLpLgAGVRMZGaGoJObGf72s6TeIqKJo/LtggAS9qAUiuKVnygo 3wjfkS9A3DRO+SpU7JqWdsveeIQyeyEJ/8PTowmSQLakF+3fote9ybzd880fSmFuIEJldWxp Y2ggPGpiZXVsaWNoQHN1c2UuY29tPsJgBBMRAgAgBQJZN5xEAhsDBgsJCAcDAgQVAggDBBYC AwECHgECF4AACgkQoDSui/t3IH4J+wCfQ5jHdEjCRHj23O/5ttg9r9OIruwAn3103WUITZee e7Sbg12UgcQ5lv7SzsFNBFk3nEQQCACCuTjCjFOUdi5Nm244F+78kLghRcin/awv+IrTcIWF hUpSs1Y91iQQ7KItirz5uwCPlwejSJDQJLIS+QtJHaXDXeV6NI0Uef1hP20+y8qydDiVkv6l IreXjTb7DvksRgJNvCkWtYnlS3mYvQ9NzS9PhyALWbXnH6sIJd2O9lKS1Mrfq+y0IXCP10eS FFGg+Av3IQeFatkJAyju0PPthyTqxSI4lZYuJVPknzgaeuJv/2NccrPvmeDg6Coe7ZIeQ8Yj t0ARxu2xytAkkLCel1Lz1WLmwLstV30g80nkgZf/wr+/BXJW/oIvRlonUkxv+IbBM3dX2OV8 AmRv1ySWPTP7AAMFB/9PQK/VtlNUJvg8GXj9ootzrteGfVZVVT4XBJkfwBcpC/XcPzldjv+3 HYudvpdNK3lLujXeA5fLOH+Z/G9WBc5pFVSMocI71I8bT8lIAzreg0WvkWg5V2WZsUMlnDL9 mpwIGFhlbM3gfDMs7MPMu8YQRFVdUvtSpaAs8OFfGQ0ia3LGZcjA6Ik2+xcqscEJzNH+qh8V m5jjp28yZgaqTaRbg3M/+MTbMpicpZuqF4rnB0AQD12/3BNWDR6bmh+EkYSMcEIpQmBM51qM EKYTQGybRCjpnKHGOxG0rfFY1085mBDZCH5Kx0cl0HVJuQKC+dV2ZY5AqjcKwAxpE75MLFkr wkkEGBECAAkFAlk3nEQCGwwACgkQoDSui/t3IH7nnwCfcJWUDUFKdCsBH/E5d+0ZnMQi+G0A nAuWpQkjM1ASeQwSHEeAWPgskBQL In-Reply-To: <20250211-fix_gas_abort-v1-1-afd9730f9c51@rivosinc.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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 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. 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