public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Joseph Faulls <Joseph.Faulls@imgtec.com>
To: Nelson Chu <nelson@rivosinc.com>, "schwab@suse.de" <schwab@suse.de>
Cc: "binutils@sourceware.org" <binutils@sourceware.org>,
	"palmer@rivosinc.com" <palmer@rivosinc.com>
Subject: Re: [PATCH] bfd: check for truncation with R_RISCV_32 relocations
Date: Wed, 31 Jan 2024 14:08:10 +0000	[thread overview]
Message-ID: <CWLP265MB5906D6BE1695D8498FF72595807C2@CWLP265MB5906.GBRP265.PROD.OUTLOOK.COM> (raw)
In-Reply-To: <CAPpQWtC2xzDSHrasv928tcg8=FMW9_HeuQANjydXgUbid7oNDA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4370 bytes --]

Replying to both comments


  *   It's been a long time so I forgot the details, if we add this overflow checks for ADD/SUB/SET relocations, then the regression will fail since we may generate 32-bit debug information for the rv64 toolchain in gcc, and that's why we always silent the truncated error.  Not sure if that also fails for now, we need to make sure of that at first.

Yes, I initially did that and that’s exactly what happens. The debug information doesn’t seem to use R_RISCV_32 so it hasn’t caused any errors in the gcc test suite when the data and/or text is put at a high address. All the failures were truncation of other relocations like R_RISCV_HI20, RISCV_PCREL_HI20 and R_RISCV_GOT_HI20.


  *   The overflow check belongs to the howto table.

For the reason Nelson gave above, I don’t think this is a good idea. We’d see a lot of failures on truncation of debug information.



Thanks,
Joe


From: Nelson Chu <nelson@rivosinc.com>
Sent: Tuesday, January 30, 2024 11:39 PM
To: Joseph Faulls <Joseph.Faulls@imgtec.com>
Cc: binutils@sourceware.org; palmer@rivosinc.com
Subject: [EXTERNAL] Re: [PATCH] bfd: check for truncation with R_RISCV_32 relocations

*** CAUTION: This email originates from a source not known to Imagination Technologies. Think before you click a link or open an attachment ***


It's been a long time so I forgot the details, if we add this overflow checks for ADD/SUB/SET relocations, then the regression will fail since we may generate 32-bit debug information for the rv64 toolchain in gcc, and that's why we always silent the truncated error.  Not sure if that also fails for now, we need to make sure of that at first.

Nelson

On Wed, Jan 31, 2024 at 2:21 AM Joseph Faulls <Joseph.Faulls@imgtec.com<mailto:Joseph.Faulls@imgtec.com>> wrote:
Relevant bug report: https://sourceware.org/bugzilla/show_bug.cgi?id=31318 [sourceware.org]<https://urldefense.com/v3/__https:/sourceware.org/bugzilla/show_bug.cgi?id=31318__;!!KCwjcDI!wulN0Qao5f5Oo-QZuqVs3Oqa3M05CJfg5GTFUC0w5F2ASD-BVSAdYyHz60Izzx94bwpD3ks9VJPpDPvnnZb7$>

With high addresses, these relocations can be truncated. In these cases,
throw an error instead of silently truncating.

bfd/
        * elfnn-riscv.c (perform_relocation): Check for overflow.

ld/
        * ld/testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated.
        * ld/testsuite/ld-riscv-elf/data-reloc-rv64-abs32-truncation.d:
          New test case.
---
bfd/elfnn-riscv.c                                            | 3 +++
ld/testsuite/ld-riscv-elf/data-reloc-rv64-abs32-truncation.d | 4 ++++
ld/testsuite/ld-riscv-elf/ld-riscv-elf.exp                   | 1 +
3 files changed, 8 insertions(+)
create mode 100644 ld/testsuite/ld-riscv-elf/data-reloc-rv64-abs32-truncation.d

diff --git a/bfd/elfnn-riscv.c b/bfd/elfnn-riscv.c
index 8b27e3b8d6a..975b40e5f53 100644
--- a/bfd/elfnn-riscv.c
+++ b/bfd/elfnn-riscv.c
@@ -1865,6 +1865,9 @@ perform_relocation (const reloc_howto_type *howto,
       }

     case R_RISCV_32:
+      if (value & ~howto->dst_mask)
+       return bfd_reloc_overflow;
+      break;
     case R_RISCV_64:
     case R_RISCV_ADD8:
     case R_RISCV_ADD16:
diff --git a/ld/testsuite/ld-riscv-elf/data-reloc-rv64-abs32-truncation.d b/ld/testsuite/ld-riscv-elf/data-reloc-rv64-abs32-truncation.d
new file mode 100644
index 00000000000..925d1cdb662
--- /dev/null
+++ b/ld/testsuite/ld-riscv-elf/data-reloc-rv64-abs32-truncation.d
@@ -0,0 +1,4 @@
+#source: data-reloc.s
+#as: -march=rv64i -mabi=lp64 -defsym __abs__=1
+#ld: -m[riscv_choose_lp64_emul] -Ttext 0x8000 --defsym _start=0x0 --defsym abs=0xc00000100 --defsym abs_local=0x200
+#error: .*relocation truncated to fit: R_RISCV_32
diff --git a/ld/testsuite/ld-riscv-elf/ld-riscv-elf.exp b/ld/testsuite/ld-riscv-elf/ld-riscv-elf.exp
index 7e1281d826b..5a4d8728366 100644
--- a/ld/testsuite/ld-riscv-elf/ld-riscv-elf.exp
+++ b/ld/testsuite/ld-riscv-elf/ld-riscv-elf.exp
@@ -175,6 +175,7 @@ if [istarget "riscv*-*-*"] {
     run_dump_test "uleb128"
     run_dump_test "pr31179"
     run_dump_test "pr31179-r"
+    run_dump_test "data-reloc-rv64-abs32-truncation"
     run_ld_link_tests [list \
        [list "Weak reference 32" "-T weakref.ld -m[riscv_choose_ilp32_emul]" "" \
            "-march=rv32i -mabi=ilp32" {weakref32.s} \
--
2

  reply	other threads:[~2024-01-31 14:08 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-30 18:21 Joseph Faulls
2024-01-30 23:38 ` Nelson Chu
2024-01-31 14:08   ` Joseph Faulls [this message]
2024-02-21 11:02     ` Joseph Faulls
2024-01-31  9:14 ` Andreas Schwab

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=CWLP265MB5906D6BE1695D8498FF72595807C2@CWLP265MB5906.GBRP265.PROD.OUTLOOK.COM \
    --to=joseph.faulls@imgtec.com \
    --cc=binutils@sourceware.org \
    --cc=nelson@rivosinc.com \
    --cc=palmer@rivosinc.com \
    --cc=schwab@suse.de \
    /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).