public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Charlie Jenkins <charlie@rivosinc.com>
To: Jan Beulich <jbeulich@suse.com>
Cc: Nelson Chu <nelson@rivosinc.com>, jiawei <jiawei@iscas.ac.cn>,
	gdb-patches <gdb-patches@sourceware.org>,
	Binutils <binutils@sourceware.org>,
	Andrew Burgess <aburgess@redhat.com>
Subject: Re: [PATCH v2] RISC-V: Fix disassembly of partial instructions
Date: Fri, 20 Dec 2024 11:27:04 -0800	[thread overview]
Message-ID: <Z2XFCLUA3XeVba_l@ghost> (raw)
In-Reply-To: <2b869ed1-5969-4ac8-890e-5c82f1877543@suse.com>

On Fri, Dec 20, 2024 at 11:38:01AM +0100, Jan Beulich wrote:
> On 19.12.2024 18:37, Nelson Chu wrote:
> > Some minor GNU coding styles as follows.  Also cc Jan and Andrew, hope they
> > still have time in their busy schedules can help to see if there are some
> > side effects.
> 
> I did actually take a look, but then pretty quickly decided I must be missing
> something: There's no disassembly of anything here afaics, and I also can't
> see how a partial insn could be disassembled in the first place. Such can
> only ever be displayed as raw hex data, I think. And that's what the patch

I think this is just an issue with my terminology. I was referring to
raw hex data as the "disassembly". Should the title say "raw hex data"
instead of "disassembly"? I was thinking that "disassembly" included
any instruction data that was being output from objdump.

> appears to be doing, just that it's description says otherwise. That plus the
> lack of a testcase demonstrating the intended behavior made me simply stop
> any effort here.

I should have posted a minimal test case. The test case I was using was
the linux perf test case that I posted. Here is a better example where I
have the output on binutils 2.40, 2.41, and with this patch.

As a summary, on 2.40 the hex of the instruction is shown even if the
full instruction can't be dumped. On 2.41 it errors with "Address <addr> is
out of bounds." in this case. With this patch, it reverts to the 2.40
behavior of showing the hex, but also encodes the partial instruction
using assembler directives instead of printing the "out of bounds" error.

$ cat objdump.s
c.lw a0, 0(a0)
.option push
.option norvc
nop
.option pop

$ riscv64-linux-gnu-gcc -c objdump.s

Example 2.40:
$ ./objdump-2.40 --start-address 0 --stop-address 4 -d -z objdump.o

objdump.o:     file format elf64-littleriscv


Disassembly of section .text:

0000000000000000 <.text>:
   0:	4108                	lw	a0,0(a0)
   2:	13 00             	Address 0x2 is out of bounds.



Example 2.41
$ ./objdump-2.41 --start-address 0 --stop-address 4 -d -z objdump.o

objdump.o:     file format elf64-littleriscv


Disassembly of section .text:

0000000000000000 <.text>:
   0:	4108                	lw	a0,0(a0)
   2:	Address 0x2 is out of bounds.


Example with this patch:
$ ./binutils/objdump --start-address 0 --stop-address 4 -d -z objdump.o                                               [11:20:54]

objdump.o:     file format elf64-littleriscv


Disassembly of section .text:

0000000000000000 <.text>:
   0:   4108                    lw      a0,0(a0)
   2:   0013                    .short  0x0013


The difference here being that "Address <address> is out of bounds" is
replaced by the raw hex data.

> 
> Jan

  reply	other threads:[~2024-12-20 19:27 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-16 22:23 Charlie Jenkins
2024-12-19 17:37 ` Nelson Chu
2024-12-19 18:37   ` Charlie Jenkins
2024-12-20 10:38   ` Jan Beulich
2024-12-20 19:27     ` Charlie Jenkins [this message]
2024-12-24  8:22       ` Jan Beulich
2025-01-02 19:14         ` Charlie Jenkins
2025-01-03  6:22           ` Maciej W. Rozycki
2025-01-03 19:23             ` Charlie Jenkins
2025-01-06  8:22             ` Jan Beulich
2025-01-06 10:30   ` Andrew Burgess
2025-01-09  2:14     ` 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=Z2XFCLUA3XeVba_l@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=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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).