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

    <tr>
        <th>Summary</th>
        <td>
            PIE Metadata Forces Codegenning Illegal Relocations R_X86_64_TPOFF32 and R_X86_64_PC32 for Shared Libraries 
        </td>
    </tr>

    <tr>
      <th>Labels</th>
      <td>
            new issue
      </td>
    </tr>

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

    <tr>
      <th>Reporter</th>
      <td>
          EmmaJaneBonestell
      </td>
    </tr>
</table>

<pre>
    On Ubuntu 22.04 / glibc 2.35/ x86_64 

For the past month or so, give or take a few weeks, I've noticed an intermittent issue with LLVM trying to generate (from bitcode) R_X86_64_TPOFF32  (the local-exec tls model) and R_X86_64_PC32 for shared-libraries, which is improper,so it errors out. 

The short of it is that bitcode with PIE metadata >0 cannot be linked into shared libraries without untenable and unreasonable effort. 

A link to a tar with lld's reproducer output for some very simple test code that will result in both improper relocations is at the bottom. 

I primarily ran into this issue when attempting to build the libLLVM dylib; if any of the dependent third-party libraries are linked in as bitcode, and they contain PIE metadata, it may result in many complaints about the symbols declared with LLVM_THREAD_LOCAL, such as PrettyStackTraceEntry and TimeTraceProfilerInstance having improper relocations, even if those functions themselves do not have PIE metadata. So the problem is almost contagious in a way and very misleading in origin.

E.g.:
```
ld.lld: error: relocation R_X86_64_TPOFF32 against ThreadLocalSigInfoGenerationCounter cannot be used with -shared
>>> defined in lto.tmp
>>> referenced by ld-temp.o
>>>               lto.tmp:(llvm::PrettyStackTraceEntry::PrettyStackTraceEntry())
``` 

These wrong relocation types are only guaranteed to happen when several specific conditions are met:
1. You are using LTO (either thin or full)/LLVM bitcode is part of the link even with "--lto-O0".
2. You are trying to output a shared library from the linker or using --lto-emit-asm and then compiling that to a native object file.  
3. At least some of the bitcode libraries were compiled with/have metadata for PIC and PIE. i.e. the bitcode has modules marked ..."PIE Level", i32 1 or 2;
4. In some code, it will not cause improper relocations, and the link will succeed unless the linker "-z defs" flag is used; othertimes, -z defs causes it to report even more improper relocations than it would without it. 
5. For the R_X86_64_TPOFF32 error, you must obviously be using thread local storage in some fashion.

Other tools, such as llc and opt, will generate a native object file created with the proper relocations when passed the same bitcode.

Extracting the library archives, disassembling the bitcode, replacing the PIE Level with 0, assembling, re-archiving -- the link now succeeded and produced a properly working libLLVM.so 

So, it seems that the link mode is not checked, and upon seeing a non-0 PIE Level metadata, regardless of the PIC metadata, it attempts to relax tls (and maybe sometimes other?) relocations in a way that is unsuitable for shared objects. 

When using lld's --save-temps, disassembly of the resulting  bitcode files shows that they are not specified to use any particular tls-model, just simply "thread_local", and it also shows that the PIC-level metadata is properly set. 

Specifying any of the following during the LLVM build and/or at link time did not fix the issue: -ftls-model=global-dynamic, -mno-relax, manually annotating the respective source code with 
__attribute__((__tls_model__("global-dynamic"))), -femulated-tls, -fno-pie. Only manually changing the PIE Level metadata was successful. 

I'd imagine some sort of check for the output type (shared lib, executable, etc.,) before generating/relaxing relocations would prevent this. 

Reproducers: 

https://drive.google.com/file/d/16JCVXczbbsfgouI-evCzeOqG1y5tNgsw/view?usp=sharing 

It contains the response files/command lines to reproduce both relocation errors at once, each error individually, and a successfully linkable version where the included bitcode library (libedit.a in this example) was manually changed to PIE Level 0. 
</pre>
<img width="1px" height="1px" alt="" src="http://email.email.llvm.org/o/eJytWMty4zgS_Br5giBDpiw_Djq4ZXvWE561o-2dnT0pQBKiMAYBLQBaVn_9ZhVIvdozp41Qy-ILqMrKzCp26ert7NmKf5WdjZ0oinx8IUbFg2iMLitR5JMpHX1eXy4ucWF8Nxrfpu8H50VcKbGWIYrW2bgSOBPcqJiLRn8oOoryXQkplmojNkq9B7r2OCqucNW6qCtVC2mFtlH5VseobBQ6hE6JjcZyT0-__yai32rbiOhEo6zyMiqEd730rhWljpWr1ai4Ed8Xf3CEi7eX54eHSTGaF6PbMd1JIRpXSZOpT1WJaAKCrZWhp6St90--zCeFWFIKK-lVnSF_L71WHPRmpasVYhO6XXu3Vh4ngxM6CuW980G4LuZH8Lxh37ByPgq3pPvwbFzJOASdMnx5vBetirKWUYrR5H4sKmmBjCgRtLbvwAfguD4ksQuJn8aWAkVTVpZGcS6d9UoGl06oJZI5CeqWVyUwJWrjUxDG1ChJEF4htbqrlKds1lid0XCtEh_Kb0VA7lg3KtSbU-B8NtoYPBo6gxytKB1WHEDCeYI-amcDAYDbqRy4J7r2OLJHsfa6RXJmK3zihMPNhHgixEpZPB9Vu449H8pOm5oXBC7MlXqLX6PJN6GXwGNLyNPlWq2VrYlcWNDX2Vr6uD0AE9ju0RYy7Ik1Z1ixxhYZ2yhx-bBkdANK28rtAQIt7Vw5YIXbI1YvqVAUR9i2pQP_alUZrueO5Yu3f3y_v71bPD3Pb59o1dCBbojkxasYt69RVu9vXlbq3kIPHNSbbhWfevFuqY3yjzZEaSslVvKDEPqqCLS0-gCSmpBxQYllZ6tUH0TYBmU-AEjtSJ60kDrKNxevLmneO1Cs5Zqa1jEhAE-jXRcYQ7GRKUxmTquDUbLmqCx8QTfa5ofVv8-bfDTpD0aX4_7Dh6bOiaGT2yQ1-rHP6CfhC9kAdgT0toIW6idS_qtuHu3S_ZL8A0_NHenGH4itC0M5sqS1PpTJffqgZkttE0FMdHls16d3eLVUXlnytBLsqjPiau5ObkvG9P_93kUEBItrYz5a-jW5_ZI8f3epuIYr0ue4Dqe-BtpsvEMxD-oQt-teSc5Cwk0noeKoAAaUupJrKDBpOIB_XhoR1qrSS10Rc2qdKEiPg2s7Jpzn4j-u49NdIPY8vT2TpysUSlH3YTaBw8Zw4A_sAoPDgpyk9MEF2PmY_FznUVFkGYDLnsf42bOx2G-47zu9GcpjF94K7kHDymSavo8yravQ0TIZ2sFCLJuCNrwqOSe7sAV81CvLP1UFw4WQ86F3cUSTXNxGAfWA0mzFfTZDkgctAezrt-i5DEBYwrsOQ37-8phMDbrOhc5VfrTcSnJ77AwWhBuTJeZ5DoDIBp6AHoAu2PYgtXNKuYDfplAvcvFoU5CDe-q-P5DKKgmR_aUr9SClKvEzsMCK-NNZBBMOgabS_SBF4km0bCMbqjVJmLzfETci3JHX7W9MuwcKCLCj01FjZjK0zn8dFRXJcgauM_Wu4-pdS53mYpiBfnKhZFXYfws6tR2K58oPckdooxzYHNmi0nQiQnReNooMhiFcyrBCGEc2-Zxo79BEDpuEMRXj59aRZxVCbzcsfUUxUWHjODheb-in6bNaMdyRM3L3ku2OJ8fm_RlhIakrr9ROHtJXK-zLkdY60EJtaYa7DlosqmFkNVzYES0FN2Zy7J5N92dp7aS1PW2s2wys4cGyFv1Ag4M-Q8C_cf6dnuyHhhxj3GE2r64nblDoh71Shx3a3leYzytVQR8Debu1I3NTtDQwdzYbH-RyODF41UhfM6l7MZMmT2aKftQJia5GfvLkCu-jvTBwgEREE-Z5ovxo8kAz7dHINXRizoI0YkOnI4-H-0m3Z0Y4Hsj-TeVPPB0GxCwLsBPuaydV3Y1aaQyiQiUTG3yFWBdoHt7sId2yzxKUfS9IzYJcgkYo8m5ddZiUKPWsH9rn4k9SE8-iW3KCJKIFi6j3JoKIIDTBnWxJSGfmqCLcJgZuBHUyML9yZNwJDgbKpTPGbehk3fmBuKn38EyKAOC9ABi7poEbZQJcNWe71J_8AA-2NM5ky32Ck7vGuBJvK_XWylZX7GGtdRmTgI4wX3bSGBqvsJrc6Q7QI1iWenCdr5IL982Ok1kswCqvyy6qxYKb_fViga0XvHV_qjjdv-hnAvoglqVqUROYRxaTC2VLRLfWaCTP1Pl34VWwz-ZnVe9w38C5WK0hoIGfvA2Ab6hhi4nSJqLjK7Vylh2zl9btezNNHySOfYfmSRcvfB2znY9ihUY2J42Uakmu33sk28oD46uPhprQW__aU6fgt4cTkXzfvTIFKuThpVWM68ATGWT5UHvUJW-ca9Dg0aRxiiRBV_Dv_PLX-e9_VD_KMiwb1z1m6mP-Qz3_95fz7TT-swkb3POh1QYS7wLGvDvKk2I9wiwO7yhhxwfk0GsPK2DblqQBRqreV_ro01vbwTTXv9SCvg4DLaMn0Wv4NFylhvfWXOVBbvKglGbLpGeXwawXaEE0E5qpiPW2Mh358_EEQ1q-xk-FWTCX5Fz88qc-Jb10UtGIL8fkSn6xp9Y4F2f1bFLfTG7kWdTRqBld_G1gHBSJEMUcu6L0lgB8NAZubMT3g6L__Erx5X8TvCauPe0GsLPOm9lx2RuIryv7gvNgnv5kAJ48F4fsAlSe6fRmfHO2mk2vqvFFUVfV1fV5UU-mF1eyrC7G08sbpapxUZ0ZWSoTZqPpN4jTqk1vJBDq9O5Mz4pxUYwvx1fjyfRqMs2L8npc4Gl5U16dF-fno4uxaqU2OcWRO9-c-RmHVHZNwEWjA1rB7iIMXjdWKd4O68sOY5Cf3YNKv0qrvjlwKSpjzjiIGSfxPxnLM7w">