From: Charlie Jenkins <charlie@rivosinc.com>
To: "Maciej W. Rozycki" <macro@orcam.me.uk>
Cc: Jan Beulich <jbeulich@suse.com>, Nelson Chu <nelson@rivosinc.com>,
gdb-patches <gdb-patches@sourceware.org>,
Binutils <binutils@sourceware.org>, jiawei <jiawei@iscas.ac.cn>,
Andrew Burgess <aburgess@redhat.com>
Subject: Re: [PATCH 1/2] RISC-V: Fix abort when displaying .dword
Date: Wed, 12 Feb 2025 16:51:00 -0800 [thread overview]
Message-ID: <Z61B9NWRVxhzfgy7@ghost> (raw)
In-Reply-To: <alpine.DEB.2.21.2502122154090.65342@angie.orcam.me.uk>
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 .<N>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
next prev parent reply other threads:[~2025-02-13 0:58 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-12 5:08 [PATCH 0/2] RISC-V: Fix abort when displaying data and add test Charlie Jenkins
2025-02-12 5:08 ` [PATCH 1/2] RISC-V: Fix abort when displaying .dword Charlie Jenkins
2025-02-12 5:27 ` Jiawei
2025-02-12 7:25 ` Alan Modra
2025-02-12 8:06 ` Jan Beulich
2025-02-12 8:57 ` Nelson Chu
2025-02-12 10:06 ` Jan Beulich
2025-02-12 22:15 ` Maciej W. Rozycki
2025-02-13 0:51 ` Charlie Jenkins [this message]
2025-02-13 0:52 ` Charlie Jenkins
2025-02-12 5:08 ` [PATCH 2/2] RISC-V: Add testcase for 6 byte instruction Charlie Jenkins
2025-02-12 5:20 ` [PATCH 0/2] RISC-V: Fix abort when displaying data and add test Nelson Chu
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Z61B9NWRVxhzfgy7@ghost \
--to=charlie@rivosinc.com \
--cc=aburgess@redhat.com \
--cc=binutils@sourceware.org \
--cc=gdb-patches@sourceware.org \
--cc=jbeulich@suse.com \
--cc=jiawei@iscas.ac.cn \
--cc=macro@orcam.me.uk \
--cc=nelson@rivosinc.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox