[PATCH v2 0/4] RISC-V: Fix address printer on the disassembler

Tsukasa OI research_trasio@irq.a4lg.com
Tue Aug 2 05:54:17 GMT 2022


This patchset contains a fix to PR29342.

Tracker on GitHub:

Original Issue as reported by H. Peter Anvin:

[Changes: v1 -> v2]

-   Also allow `gp'-base symbol (__global_pointer$) to be the highest address
-   Add minor optimization (break early if multiple __global_pointer$ is found)
-   Rebase and minor copyediting

[Performance Analysis (Summary)]

This patch alone degrades the disassembler performance a bit (usually about 1%
but around 4% on binary files) but I found my next batch of the disassembler
optimization patchset somehow shadows this.  In fact, Binutils with my
optimization patchset 1 and Binutils with my optimization patchset 1 plus this
patchset has pretty much the same performance.

[Cover Letter from v1]

First of all, this bug is caused by address computation of maybe_print_address
on disassembling RV32 programs.

Let me show the pseudocode of `maybe_print_address':

    if (high part of the register [for address sequence] is set)
        pd->print_addr = (high part) + offset;        // (1)
        unset high part (as used);
    else if (base register == `gp' && __global_pointer$ is available)
        pd->print_addr = __global_pointer$ + offset;  // (2)
    else if (base register == `tp' || base register == `zero')
        pd->print_addr = offset;                      // (3)
    // Sign-extend a 32-bit value to 64-bit
    if (instruction is ADDIW or C.ADDIW)
        pd->print_addr = (bfd_vma)(int32_t)pd->print_addr;

In here, it implicitly sign-extends an `int'-typed variable `offset' to generate
an address.  (3) is the direct cause of PR29342 but other locations have
similar issue.

On an example provided by Peter, IOREG_FOO has an address value of 0xffffff00.
However, due to incorrect sign-extension, the disassembler considers that the
`sw' instruction operates on an incorrect address 0xffffffff_ffffff00 EVEN ON
RV32.  This affects symbol lookup.  So, we have to mask (and zero-extend) the
address on RV32 to get correct address 0xffffff00.

Also, the background provided by Peter gives us a context: highest address space
may be important for some systems/programs.  So, not only fixing PR29342, I
decided to make the address -1 (originally reserved as a non-printing address)
printable by separating (a) the address to print and (b) whether the address
should be printed.  This isn't zero-overhead but close to.

This patchset:

1.  fits an address into a 32-bit value on RV32 (resolves PR29342)
2.  makes the highest address printable
    (0xffffffff can be printed as a real symbol)
3.  clarifies the meaning of the `wide' argument
    (`is_addiw' fits the context).

It also has new testcases and a testcase modification (it seems lla32.d is
affected by this patchset but not harmful so that modifying the testcase
lla32.d seemed better).


Tsukasa OI (4):
  RISC-V: Print highest address on disassembler
  RISC-V: Fix RV32 disassembler address computation
  RISC-V: Break early if RISCV_GP_SYMBOL is found
  RISC-V: Add address printer tests on disassembler

 gas/testsuite/gas/riscv/dis-addr-1-32.d | 29 ++++++++++
 gas/testsuite/gas/riscv/dis-addr-1-64.d | 33 ++++++++++++
 gas/testsuite/gas/riscv/dis-addr-1.s    | 70 +++++++++++++++++++++++++
 gas/testsuite/gas/riscv/dis-addr-2-32.d | 12 +++++
 gas/testsuite/gas/riscv/dis-addr-2-64.d | 12 +++++
 gas/testsuite/gas/riscv/dis-addr-2.s    | 15 ++++++
 gas/testsuite/gas/riscv/lla32.d         |  2 +-
 opcodes/riscv-dis.c                     | 47 +++++++++++------
 8 files changed, 203 insertions(+), 17 deletions(-)
 create mode 100644 gas/testsuite/gas/riscv/dis-addr-1-32.d
 create mode 100644 gas/testsuite/gas/riscv/dis-addr-1-64.d
 create mode 100644 gas/testsuite/gas/riscv/dis-addr-1.s
 create mode 100644 gas/testsuite/gas/riscv/dis-addr-2-32.d
 create mode 100644 gas/testsuite/gas/riscv/dis-addr-2-64.d
 create mode 100644 gas/testsuite/gas/riscv/dis-addr-2.s

base-commit: f493c2174ef99a43c0a5d89179122f857955d738

More information about the Binutils mailing list