[llvm-branch-commits] [lld] release/21.x: [lld] Add thunks for hexagon (#111217) (PR #149723)
Jessica Clarke via llvm-branch-commits
llvm-branch-commits at lists.llvm.org
Sun Aug 3 13:18:05 PDT 2025
jrtc27 wrote:
> ```
> /builddir/build/BUILD/llvm-21.1.0_rc2-build/llvm-project-21.1.0-rc2.src/lld/test/ELF/hexagon-thunks-packets.s:20:17: error: CHECK-NONPIC: expected string not found i
> n input
> # CHECK-NONPIC: jump 0x1020110 <myfn_a> }
> ^
> <stdin>:7:50: note: scanning from here
> 200b4: 01 40 10 00 00104001 { immext(#0x1000040)
> ^
> <stdin>:8:30: note: possible intended match here
> 200b8: 58 c0 00 58 5800c058 jump 0x1020120 <myfn_a> }
> ^
> ```
>
> Hmm, if it were an endianness issue I wonder if this patch below might address it? How convenient is it to try this?
>
> ```
> diff --git a/lld/ELF/Thunks.cpp b/lld/ELF/Thunks.cpp
> index 65d0f094c43c..c8d0c91fd8b6 100644
> --- a/lld/ELF/Thunks.cpp
> +++ b/lld/ELF/Thunks.cpp
> @@ -1546,16 +1546,16 @@ void HexagonThunk::writeTo(uint8_t *buf) {
> uint64_t p = getThunkTargetSym()->getVA(ctx);
>
> if (ctx.arg.isPic) {
> - write32(ctx, buf + 0, 0x00004000); // { immext(#0)
> + write32le(buf + 0, 0x00004000); // { immext(#0)
> ctx.target->relocateNoSym(buf, R_HEX_B32_PCREL_X, s - p);
> - write32(ctx, buf + 4, 0x6a49c00e); // r14 = add(pc,##0) }
> + write32le(buf + 4, 0x6a49c00e); // r14 = add(pc,##0) }
> ctx.target->relocateNoSym(buf + 4, R_HEX_6_PCREL_X, s - p);
>
> - write32(ctx, buf + 8, 0x528ec000); // { jumpr r14 }
> + write32le(buf + 8, 0x528ec000); // { jumpr r14 }
> } else {
> - write32(ctx, buf + 0, 0x00004000); // { immext
> + write32le(buf + 0, 0x00004000); // { immext
> ctx.target->relocateNoSym(buf, R_HEX_B32_PCREL_X, s - p);
> - write32(ctx, buf + 4, 0x5800c000); // jump <> }
> + write32le(buf + 4, 0x5800c000); // jump <> }
> ctx.target->relocateNoSym(buf + 4, R_HEX_B22_PCREL_X, s - p);
> }
> ```
That should make no difference. read32 etc use config->endianness, which is the endianness of the ELF file. If Hexagon is always little-endian then it is completely correct to use read32le everywhere instead, but that is an optimisation to make that says "assume the file is little-endian rather than dynamically checking which endianness it is".
https://github.com/llvm/llvm-project/pull/149723
More information about the llvm-branch-commits
mailing list