From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id RNUCFwYerWdeby0AWB0awg (envelope-from ) for ; Wed, 12 Feb 2025 17:17:42 -0500 Received: by simark.ca (Postfix, from userid 112) id 494AE1E105; Wed, 12 Feb 2025 17:17:42 -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, 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 169EB1E08E for ; Wed, 12 Feb 2025 17:17:41 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 3EF8B385843B for ; Wed, 12 Feb 2025 22:17:40 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 3EF8B385843B Received: from angie.orcam.me.uk (angie.orcam.me.uk [78.133.224.34]) by sourceware.org (Postfix) with ESMTP id 0F5D43858414; Wed, 12 Feb 2025 22:15:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0F5D43858414 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=orcam.me.uk Authentication-Results: sourceware.org; spf=none smtp.mailfrom=orcam.me.uk ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 0F5D43858414 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=78.133.224.34 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1739398535; cv=none; b=RZE+LoIsW7rY4WL+9T8THYsIYBpu+OaCAcLx8YDx/xVxZjOGabRty8OZ4SUQ1EFg9uQH3QVRXx9hhT2m2Kr04KIZI9qdGWSRD1NJK1bkjZsSyoqzEJtWg3LmQ6Ky5IAiYcrfGmZ4yfOm6zNXL08HGOUcCpE3r1XS1JQHsR0GPkw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1739398535; c=relaxed/simple; bh=R+djbsWylF8jrFkNXHv6AA0yop/mveZr0bIjEPLQfDA=; h=Date:From:To:Subject:Message-ID:MIME-Version; b=V6k622OcZq1xXJByQy0OH4x0JtgfMf1LFXrPgvL/NSAD8FgVVqOC4Nr5wScEMic53yqYgPqZ2k5K+v+Y1n9RMogz5qKhlZePfGF9CZ1JIYT2mFodB7b6FZEAaoo7y8aL/Fo5n3NKYqKgTXL9/+ABvhktJe5uATvI46LZZZxYUjs= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0F5D43858414 Received: by angie.orcam.me.uk (Postfix, from userid 500) id F082F92009C; Wed, 12 Feb 2025 23:15:31 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by angie.orcam.me.uk (Postfix) with ESMTP id E999D92009B; Wed, 12 Feb 2025 22:15:31 +0000 (GMT) Date: Wed, 12 Feb 2025 22:15:31 +0000 (GMT) From: "Maciej W. Rozycki" To: Jan Beulich cc: Nelson Chu , Charlie Jenkins , gdb-patches , Binutils , jiawei , Andrew Burgess Subject: Re: [PATCH 1/2] RISC-V: Fix abort when displaying .dword In-Reply-To: Message-ID: References: <20250211-fix_gas_abort-v1-0-afd9730f9c51@rivosinc.com> <20250211-fix_gas_abort-v1-1-afd9730f9c51@rivosinc.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) 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 On Wed, 12 Feb 2025, Jan Beulich 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 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. > > > > 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. > > Except that there is no 4th byte to print in that case. That wants expressing > somehow, without taking a value out of thin air. They could just do what backends for other fixed-length-instruction-word targets do, such as Alpha or MIPS one: $ dd if=/dev/zero of=partial-insn.img bs=1 count=7 $ alpha-linux-gnu-objdump -b binary -m alpha -D partial-insn.img partial-insn.img: file format binary Disassembly of section .data: 0000000000000000 <.data>: 0: 00 00 00 00 halt 4: Address 0x0000000000000004 is out of bounds. $ mips-linux-gnu-objdump -b binary -m mips -D partial-insn.img partial-insn.img: file format binary Disassembly of section .data: 00000000 <.data>: 0: 00000000 nop 4: Address 0x4 is out of bounds. $ There are other means available, such as the `-s' option or `readelf', for dumping trailing partial data that is not a complete instruction and thus has no meaning. I'm not sure if this is a corner case worth putting much effort into, beyond just making sure the tools don't crash or produce utter rubbish. FWIW, Maciej