[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