[lld] [lld] More info for aarch64 ldr/str misaligning error (PR #135004)

Wed Apr 9 14:18:30 PDT 2025

mstorsjo wrote:

> Both errors are:
> 
> ```
> FAILED: tools/lld/COFF/CMakeFiles/lldCOFF.dir/Chunks.cpp.obj
> --
>   | sccache C:\BuildTools\VC\Tools\MSVC\14.29.30133\bin\Hostx64\x64\cl.exe  /nologo /TP -DGTEST_HAS_RTTI=0 -DUNICODE -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NONSTDC_NO_WARNINGS -D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS -D_GLIBCXX_ASSERTIONS -D_HAS_EXCEPTIONS=0 -D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS -D_UNICODE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Itools\lld\COFF -IC:\ws\src\lld\COFF -IC:\ws\src\lld\include -Itools\lld\include -Iinclude -IC:\ws\src\llvm\include /DWIN32 /D_WINDOWS   /Zc:inline /Zc:preprocessor /Zc:__cplusplus /Oi /bigobj /permissive- /W4 -wd4141 -wd4146 -wd4244 -wd4267 -wd4291 -wd4351 -wd4456 -wd4457 -wd4458 -wd4459 -wd4503 -wd4624 -wd4722 -wd4100 -wd4127 -wd4512 -wd4505 -wd4610 -wd4510 -wd4702 -wd4245 -wd4706 -wd4310 -wd4701 -wd4703 -wd4389 -wd4611 -wd4805 -wd4204 -wd4577 -wd4091 -wd4592 -wd4319 -wd4709 -wd5105 -wd4324 -wd4251 -wd4275 -w14062 -we4238 /Gw /O2 /Ob2  -MD   -wd4530 -wd4062  /EHs-c- /GR- -UNDEBUG -std:c++17 /showIncludes /Fotools\lld\COFF\CMakeFiles\lldCOFF.dir\Chunks.cpp.obj /Fdtools\lld\COFF\CMakeFiles\lldCOFF.dir\lldCOFF.pdb /FS -c C:\ws\src\lld\COFF\Chunks.cpp
>   | C:\ws\src\lld\COFF\Chunks.cpp(1154): error C2660: 'lld::coff::applyArm64Ldr': function does not take 2 arguments
> ```
> 
> Are these due of old caches? Any clues would be helpful!

No, this isn't due to caches - your PR does not compile; did you try compiling it before submitting the PR?

The reason is that in the latest git version of LLD there's a new call to `applyArm64Ldr` at line 1154 which probably wasn't there, in the version of LLD where you did your modifications initially.

Now as for the change itself. Yes, these errors are frustratingly unactionable in their current form; normally you wouldn't really be hitting them, but when developing a toolchain I guess it is possible to hit them. I have considered improving this diagnostic myself the last time I touched this area.

But most code LLD is very much tuned for linking performance. Digging up info about the symbol name and file name and constructing that into a string (ok `Twine`), for use _if_ we need to report an error, for every single relocation we do, feels quite unusual compared with how things normally are done in LLD. (LLD even takes the liberty and has the design that it is allowed to crash on erroneous inputs - even if printing a diagnostic obviously is nicer.) Although `Twine`s are quite cheap so it doesn't make much of a measurable practical difference. But I still think we'd want to go slightly differently about it, to only dig up and construct info about the location if we actually do need it. Or what do others, e.g. @rnk and @aganea think here?

Then finally, if we are spending effort on prouducing a good diagnostic here, we should probably also make a testcase for it. (We didn't have a test for the previous error message, as it was mostly seen as something like an assert.)

https://github.com/llvm/llvm-project/pull/135004