From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id FYKsHqFDrWc0wi0AWB0awg (envelope-from ) for ; Wed, 12 Feb 2025 19:58:09 -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=jlE2Ef71; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 6A5851E105; Wed, 12 Feb 2025 19:58:09 -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 F10581E08E for ; Wed, 12 Feb 2025 19:58:08 -0500 (EST) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8EF3B385828E for ; Thu, 13 Feb 2025 00:58:08 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8EF3B385828E 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=jlE2Ef71 Received: from mail-yb1-xb32.google.com (mail-yb1-xb32.google.com [IPv6:2607:f8b0:4864:20::b32]) by sourceware.org (Postfix) with ESMTPS id D9DBE3858027 for ; Thu, 13 Feb 2025 00:51:03 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org D9DBE3858027 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 D9DBE3858027 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2607:f8b0:4864:20::b32 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1739407864; cv=none; b=ryvI2DH5bI2i1CQpVYFE1+Xl6kEP//l9dnmVjmn1rAGE8pVhzEXsWW37Ru4XEkTjF6jqmtPNiTANeXkvp/1INZvQy7Xx8feQZnRrx+oztkaN9eMSb6oM+B/ZcSbubANrJErDoRuDBuD89OV/PeWIZc3C3HONOM2R+60sgspv8Po= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1739407864; c=relaxed/simple; bh=R9S0cC8fJEmy7yCDhQIEBSwcvaq+Q0YcLa8Q/JoDrRg=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=kHQm99GuT8fYptwxClc8Hvv3LfkLwNeikmMVgAX2TuTTTxgZ4idsGIAqW4X5XikATHQxWXAdQOMuON7ac5svWT5Vi8gH/OOwlLld2Dtb2trN27Yf1MdIzQrh8mE4jp/83DwmkawRIHcXo5z8QUnx6xruQFbBZ8bG850AHIbytEg= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org D9DBE3858027 Received: by mail-yb1-xb32.google.com with SMTP id 3f1490d57ef6-e5dab3f37b1so234726276.0 for ; Wed, 12 Feb 2025 16:51:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rivosinc-com.20230601.gappssmtp.com; s=20230601; t=1739407863; x=1740012663; 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=Zw8cp0Bu3j2hv+dSoae/IIJq9xnTFYtRqnHfXDc7YMo=; b=jlE2Ef71NNv6Ppccvg9hkVG334yKqckoDvAeEshOe4kppLWIsSYQYZiWmJ/xlwZYVt NCLJWYnyfunNUvUDRuDYUU7GV9pN5O2opPLVBbl12qoUszCSoZgNm4IqKas6saqSKlrh XglOYDvPZx6TV1Zs+D8Qg0hvH8RqAZUVTsk0DUFoIZZ/sJ6yVdOSTpJAcWn17bQDWu9U AEdlC66GBWmJVqqtB6jaRqiMaHLZ9MUxcm0GPiP8nCCtKd6kU0PqQTf1EpXyZJy8f4Ve zsFZBPvHWo0blqFUMUEJKFi8fxK9hl0sEAti0hD2XQ16JlifmpjJ8Dbbc8HNkrNT8fkw iWWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1739407863; x=1740012663; 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=Zw8cp0Bu3j2hv+dSoae/IIJq9xnTFYtRqnHfXDc7YMo=; b=Bl+amr0g08Q/yBKQm7BpuwuIBvV3WEO+/h/oN1VkzhehAeKa6FMIiVMN1m3P7wXXH6 ZdJb/K7FnkDXML2NiMEY7OTiAKTZiEmvnP9PJPbSHjucQ8Ic7gLrkmeivivOZuG4h71Y /DL62P9pISHr2FNwSQ2nzsD/YXL6jlYCDQMGUyxnqMhQtiAgGMRq4YVzgdvcX5VTJ2s7 e2P4f7lqpnlwHLHbQln6kkc7Fwa2k608PO9sGImOwA5q7+aiTADvTP+jT2DKc756MlfV /l5TW/paV55b4T7bQQIspkNRdrGqM3SDhhxJ4owzfr3Jz4Mc/llbr3HAjibIGwwEliZl lWuQ== X-Forwarded-Encrypted: i=1; AJvYcCWwhlvcbWqr7izohKUqtmpBlURp6QrsJ9dzqLzA9/gXDxuvbIaZwqTIe/9jzWnz2NDDVjRcZJgvokKn7Q==@sourceware.org X-Gm-Message-State: AOJu0YxTmUtgZjvkK6VGn28CgYOuiFpKuKTlcdeRwtwDiutslIvf9+nK 2BCzQ58WJnYqDHZLO8UhGSukOIn3mXKcYRJNRVw+piVprREQlZTcr30L4AfUn60= X-Gm-Gg: ASbGncs9bWVvMTFJvDam9hzeUffAJ1AuTpTxIjd1yT8Hry3X12J0ZYXqyKETSbDHG3o WCaU0bu8x5GqGDjRdT1MdOBc8mnzG7MGxyrM1MiHlDiDvF8F3EnjSR9lVJcyRz4i7p2Vj9JLd3D 3CYWAa2P8GYs+lqlepE84Dqw3kKNmIsFTaNQjxDrIpDFoV/RByshjZltLs/HZvrHgxPXOsUR4AE 9vQRRwXgGtzGglzhPkNbE0UQq86e2CIUS+mteTow7jShW6H5YzdxNVkulGhbsPDnB/MICxNZSYm DSc= X-Google-Smtp-Source: AGHT+IGkOqFzBQxaL9fK1szNUOq2HY/AXAnHX3CLl8V57cnlI11Nhp/uPZqmtvJEBr4v3vKtCvgrAA== X-Received: by 2002:a05:6902:200e:b0:e3a:1735:b24e with SMTP id 3f1490d57ef6-e5d9f0ccb3bmr5846346276.2.1739407863192; Wed, 12 Feb 2025 16:51:03 -0800 (PST) Received: from ghost ([50.146.0.9]) by smtp.gmail.com with ESMTPSA id 3f1490d57ef6-e5dae0da2c3sm45212276.46.2025.02.12.16.51.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 12 Feb 2025 16:51:02 -0800 (PST) Date: Wed, 12 Feb 2025 16:51:00 -0800 From: Charlie Jenkins To: "Maciej W. Rozycki" Cc: Jan Beulich , Nelson Chu , gdb-patches , Binutils , jiawei , 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 10:15:31PM +0000, Maciej W. Rozycki wrote: > 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. It came up because there was a Linux test that was using objdump to check that instructions in memory was equal to the intructions in the binary. It was using --stop-address to bound a region to look at and that was sometimes splitting an instruction down the middle. This used to work fine with binutils 2.41 on riscv, but a change was made that caused this throw an out of bounds on 2.42. My original change was to bring the behavior back in line with other architectures and what riscv used to do. I feel like it's a somewhat useful feature. - Charlie > > FWIW, > > Maciej