coff lld relocation out of range error from `tailMergeARM64` chunk to `__delayLoadHelper2`

[zmodem]

I don't have a great reproducer to share yet, but we're hitting lld-link: error: relocation out of range when building Chromium for Win/ARM64.

The relocation in question is from a TailMergeChunkARM64 to the __delayLoadHelper2 symbol:

llvm-project/lld/COFF/DLL.cpp

Line 560 in 4647cd7

applyArm64Branch26(buf + 52, helper->getRVA() - rva - 52);

I suppose __delayLoadHelper2 may have ended up closer to the start of the text section, which is now large engouh that now we can't reach it from .didat directly.

@rnk and @mstorsjo who looked at this in https://reviews.llvm.org/D64288

Do you have ideas on how to best fix this?

Would it be reasonable to change the call sequence, doing something like: zmodem@ed21d8e

Or is there a handy of way of making lld emit a thunk/branch island for the call?

[llvmbot]

@llvm/issue-subscribers-backend-aarch64

Author: Hans Wennborg (zmodem)

I don't have a great reproducer to share yet, but we're hitting `lld-link: error: relocation out of range` when building Chromium for Win/ARM64.

The relocation in question is from a TailMergeChunkARM64 to the __delayLoadHelper2 symbol:

llvm-project/lld/COFF/DLL.cpp

Line 560 in 4647cd7

applyArm64Branch26(buf + 52, helper->getRVA() - rva - 52);

I suppose __delayLoadHelper2 may have ended up closer to the start of the text section, which is now large engouh that now we can't reach it from .didat directly.

@rnk and @mstorsjo who looked at this in https://reviews.llvm.org/D64288

Do you have ideas on how to best fix this?

Would it be reasonable to change the call sequence, doing something like: zmodem@ed21d8e

Or is there a handy of way of making lld emit a thunk/branch island for the call?

[llvmbot]

@llvm/issue-subscribers-lld-coff

Author: Hans Wennborg (zmodem)

I don't have a great reproducer to share yet, but we're hitting `lld-link: error: relocation out of range` when building Chromium for Win/ARM64.

The relocation in question is from a TailMergeChunkARM64 to the __delayLoadHelper2 symbol:

llvm-project/lld/COFF/DLL.cpp

Line 560 in 4647cd7

applyArm64Branch26(buf + 52, helper->getRVA() - rva - 52);

I suppose __delayLoadHelper2 may have ended up closer to the start of the text section, which is now large engouh that now we can't reach it from .didat directly.

@rnk and @mstorsjo who looked at this in https://reviews.llvm.org/D64288

Do you have ideas on how to best fix this?

Would it be reasonable to change the call sequence, doing something like: zmodem@ed21d8e

Or is there a handy of way of making lld emit a thunk/branch island for the call?

[mstorsjo]

I don't have a great reproducer to share yet, but we're hitting lld-link: error: relocation out of range when building Chromium for Win/ARM64.

Are you able to share a -linkrepro: package? I presume it's rather huge in order to trigger this though...

Would it be reasonable to change the call sequence, doing something like: zmodem@ed21d8e

On first glance, that does seem reasonable - nothing strikes me as a big issue with doing that. It makes the code 2 instructions longer, but as this is shared code that isn't duplicated for each delay imported symbol, it should totally be a non-issue. And as concluded in https://reviews.llvm.org/D64288, this isn't very performance critical code, as it only happens once per symbol.

Or is there a handy of way of making lld emit a thunk/branch island for the call?

LLD does have code for injecting range extension thunks in general, for arm/aarch64. But if that doesn't happen here, I wonder if it is a layering issue, where that happens before we add the delay load code?

But from quickly browsing LLD/Writer.cpp, it does seem to me like this code should be generated already at that point (see finalizeAddresses()), so I wonder if there's some other reason, like this linker synthesized code not being picked up and included in that pass?

If we can make the generic branch islands code handle it, that's of course ideal, but if that turns out to be infeasible, your snippet above looks entirely reasonable as well.

[zmodem]

Are you able to share a -linkrepro: package? I presume it's rather huge in order to trigger this though...

The inputs are about 15 GB uncompressed and it's a ThinLTO link so it's both large and slow to run. Also some files seems to not have been captured in the package. It's pretty terrible and I'm hoping to construct something better.

But from quickly browsing LLD/Writer.cpp, it does seem to me like this code should be generated already at that point (see finalizeAddresses()), so I wonder if there's some other reason, like this linker synthesized code not being picked up and included in that pass?

I think that machinery doesn't catch this because TailMergeChunkARM64 is a NonSectionCodeChunk, which doesn't have relocations, so Writer::createThunks() can't detect the out-of-range relocation.

NonSectionChunk has verifyRanges() and extendRanges() though... Aha, those were added in @cjacek's
#109703 to solve exactly this kind of problem but for ImportThunkChunkARM64EC.

We could try to do something similar. However, that one has an easier job since it's replacing a branch at the end of the thunk, whereas we would need to replace an instruction in the middle.

I suppose we could have two versions of the thunk, one regular and one extended, but that doesn't seem worth the effort?

[mstorsjo]

Are you able to share a -linkrepro: package? I presume it's rather huge in order to trigger this though...

The inputs are about 15 GB uncompressed and it's a ThinLTO link so it's both large and slow to run. Also some files seems to not have been captured in the package. It's pretty terrible and I'm hoping to construct something better.

Right, I see the problem :-)

With a quick back-of-the-envelope calculation - to hit this, you'd need to have a delay load helper function located >128 MB apart from the tail merge chunk. So not an unreasonable size at all, but it's probably easier to hit if most of the contents is LTO'd and non-LTO contents get pulled in early and is at the start of the text section.

But from quickly browsing LLD/Writer.cpp, it does seem to me like this code should be generated already at that point (see finalizeAddresses()), so I wonder if there's some other reason, like this linker synthesized code not being picked up and included in that pass?

I think that machinery doesn't catch this because TailMergeChunkARM64 is a NonSectionCodeChunk, which doesn't have relocations, so Writer::createThunks() can't detect the out-of-range relocation.

Ah, I see, that explains it nicely.

NonSectionChunk has verifyRanges() and extendRanges() though... Aha, those were added in @cjacek's #109703 to solve exactly this kind of problem but for ImportThunkChunkARM64EC.

We could try to do something similar. However, that one has an easier job since it's replacing a branch at the end of the thunk, whereas we would need to replace an instruction in the middle.

Yeah, that sounds complicated...

I suppose we could have two versions of the thunk, one regular and one extended, but that doesn't seem worth the effort?

I agree, it's probably not worth it here.

[zmodem]

Here's a hacky repro. It won't run, but it shows the problem:

C:\src\llvm-project>type \src\temp\b.c
__declspec(dllexport) int foo() { return 42; }

C:\src\llvm-project>build\bin\clang-cl --target=arm64-pc-windows-msvc -fuse-ld=lld \src\temp\b.c /LD /link /nodefaultlib /entry:foo

C:\src\llvm-project>type \src\temp\a.c
// Use a delayloaded symbol.
__declspec(dllimport) int foo();
int main() { return foo(); }

// Put some junk in the middle.
const char arr[129 * (1 << 20)] = {1, 2, 3, 4, 5, 6 };

// Put __delayLoadHelper2 far away from the tail merge chunk in .text.
void __declspec(code_seg("myseg")) __delayLoadHelper2() {}

C:\src\llvm-project>build\bin\clang-cl --target=arm64-pc-windows-msvc -fuse-ld=lld \src\temp\a.c /link /nodefaultlib /entry:main b.lib /delayload:b.dll
lld-link: error: relocation out of range
clang-cl: error: linker command failed with exit code 1 (use -v to see invocation)

Tarball for convenience: 161812.tar.gz

[zmodem]

(Mostly for myself: here's a win/arm64 exe and delayloaded dll linked with the patch: foo.zip )

[zmodem]

(Confirmed that the binary in foo.zip runs successfully on an actual win/arm64 machine.)