<table border="1" cellspacing="0" cellpadding="8">
    <tr>
        <th>Issue</th>
        <td>
            <a href=https://github.com/llvm/llvm-project/issues/135711>135711</a>
        </td>
    </tr>

    <tr>
        <th>Summary</th>
        <td>
            [BOLT][RISC-V] Segmentation Fault in Rewritten RISC-V Executable Due to Incorrect Symbol Relocation in llvm-bolt
        </td>
    </tr>

    <tr>
      <th>Labels</th>
      <td>
            BOLT
      </td>
    </tr>

    <tr>
      <th>Assignees</th>
      <td>
      </td>
    </tr>

    <tr>
      <th>Reporter</th>
      <td>
          Caroline-zou
      </td>
    </tr>
</table>

<pre>
    llvm-project version: 20.0.0

The issue occurs when attempting to use `llvm-bolt` on the RISC-V architecture to rewrite the SPEC2006INT benchmark. Taking the `400.perlbench` testcase as an example, I compiled the testcase using `clang` with the flags `-march=rv64gcv -fuse-ld=lld -O2 -mabi=lp64d -mrvv-vector-bits=scalable -static -Wl,-q ` . After compilation, I used `llvm-bolt` to rewrite the generated executable. However, a segmentation fault occurred when executing the rewritten binary using `qemu-riscv64`.

Upon debugging, I found that the segmentation fault was caused by a symbol that was not correctly loaded at the faulting address（Let's call it `symbol_a`). Analyzing the debug information produced during `llvm-bolt`'s rewriting process revealed that `symbol_a` was loaded 44 times, but in 6 instances, its address was incorrectly loaded. Since `symbol_a` resides in the `.got` section, its address should be consistent across all references in the code. This inconsistency likely led to the segmentation fault.

Digging deeper, I suspect that a redundant relocation entry might be the root cause of the incorrect address resolution. More specifically, when handling *relocations in bolt/lib/Rewrite/RewriteInstance.cpp*,  the offset at which the segmentation fault was caused has 2 different relocation information, thus will load `handleRelocation` twice. The relocation type for the first time is `R_RISCV_NONE` and the second time is `R_RISCV_GOT_HI20`. The second relocation type is correct.

```
void RewriteInstance::readRelocations(const SectionRef &Section) {
        for (const RelocationRef &Rel : Section.relocations())
        handleRelocation(RelocatedSection, Rel);
}
```

However, I'm unsure at which stage during `llvm-bolt`'s rewriting process this relocation entry is introduced. Understanding this could be key to resolving the issue.
</pre>
<img width="1" height="1" alt="" src="http://email.email.llvm.org/o/eJyUVlFv4jgQ_jXmZZQoOCHAAw-0lFukve0JunuPlWMPia-OnbUdWPbXn-wE2m3vpDsJCUg833zz-ZuxmXOy1ogrMrsjs82E9b4xdnXPrFFSY_LT9JPKiMtKqVObdNb8hdzDCa2TRpN8DTRLszQj2Zpk66cGQTrXIxjOe-vg3KAG5j22nZe6Bm-gdwikzCJcZZQnZQZGg28Q9rvDffINmOWN9Mh9bzFEWDxb6TEuOfzxcE-zrNx9eYIKNW9aZl9SeGIvEb6J2EWWpR1aFRcEfI_Oc-YQmAOmAX-wtlNI6D3sgJu2kwpFDL4t7F3AI2XGFdN1wDhL38Q1R8VqF14lbWBK8o09lUXNT5Ace4eJEiTfKCUgeaSQtKyS4X9XFgKS1p5OyQm5NzappHck3zjOFKsUQuI885JD8qci9D75HlJACuujRzuyZD6IHmn3DsUHHd-JVaNGyzwKwB_Iex_SpPDJnPGENsAwcFi3qH0EhiPrlR-2zqIYNm-IvIo7oHvUUEnN7OVVp-_Y9omVjp_KgpRZOhjia2c0CKz6upa6HpgfTa-D2sxHyH9gcGYOOIsVVpdA8tJWRg0h4Z02HrixFrlXF1CGCRQwwkWEwIkJYdE58rAld_dksfiMntB5AFYKpA-cB9xnRsqM0GUKa83U5ee11kgbpD4a2w7sOmtEz1GA6O1Y9lv5I_ygUHjbWcPRhScnZIPB2Pu0sZyxgKIAL1t0QaWq9yA1lCC180zz4an07lpWDJT6vQopHKTm-D6LRScFhoBri6S1iY5xyK-eeovuGtMrARUCN9pJ51F7YNwa5yDoZ_GIFgOvKyY3AlN4auRAawziF1DyBQO_IID5lx0f3bKR0SYgELvBoDtwvevCxIniMbAoei2Y9mBRGT5goPb2Aq2sGx8oR6Oa4JHgITDH-OQm1q1Ii86oPiCk8LuxCCGTPMrgkEvIHhugYVqouNt0_Zoz1h33nW6VrAjd7ofGe_21G7cu5V1H6DoARiLmeHTog1_PjeTNf2iChjmgIOQxiv5L6W_sGRL4pndwlkpFP4SNjvRxf4uIY-IsedwsfAvlLx3C0dihjaR1PvoRZBx2--cwnb89f3n88hAwmBYjc27Cz48rf3t8ev60o1lwW8w1Ln2fUrprM482CK00fLL1yUgB7wQl-Zrka4tMvJblCF0E13k4DI7e4xEILQ9Xfy-BzO8i_jLUeFv-CjFG7FFBONfGyNT-koPQZfhkawAAki0_yEsX4x8Uh9fe2qMKYXlkMN-8K5Jk6zdDeUfovIVeu3D83VziPKvx_w0eH5rxQ5vEBvXjJEvhqxZog65imHtxN8bef8HLcKQ4o07XsRjP93QiVrlY5ks2wdV0XhTlfL7Mp5NmxefLcimKBYp8upjSpcjKPKNlMZ1lrJwvphO5ohmdZeFBVszyaVpl2SLPi2rO5hUrckaKDFsmVRpKTI2tJzHlaprP5tPpRLEKlYvXFUrvHj8_EUrDxcUON5Sqrx0pMiWdd68IXnoVrzgxYLYhs7vhskFmGzi8bb5tbD6pR9OFo268ljzczlDY9PFisruNlMNwQu3fNibctmjSW7VqvO9csC7dErqtpW_6KuWmDQNEna5f1xsWodtYtSN0OxZ-WtG_AwAA__-GqktB">