Re: git: 349cc55c9796 - main - Merge llvm-project main llvmorg-14-init-10186-gff7f2cfa959b

Dimitry Andric wrote:
> On 18 May 2022, at 02:33, Konstantin Belousov wrote:
>>
>> On Tue, May 17, 2022 at 10:56:14AM -0700, John Baldwin wrote:
>>> These are all type 42:
>>>
>>> #define	R_X86_64_REX_GOTPCRELX	42
>>>
>>> It's not a LLVM bug so much as it is probably missing support in the kernel and/or
>>> loader for this type of relocation. kldxref might also need updating.
>>>
>>> I suspect due to a mismatch of old lld with new clang or some such that the old
>>> lld failed to resolve these relocations to some other type or something weird like
>>> that?
>>
>> I do think this is a toolchain bug, or at least new and undesired behavior.
>>
>> For practical purposes, R_X86_64_GOTPCRELX and R_X86_64_REX_GOTPCRELX are
>> same as R_X86_64_GOTPCREL64, I believe, but we do not expect GOT relocations
>> in the .o object modules on amd64.
> 
> I don't see this with clang 14.0.3 from base on 14-CURRENT. None of my
> kernel modules has any of these relocations, and I also get no warnings
> from kldxref.
> 
> Btw, I know that clang from ports will use /usr/local/bin/ld if it is
> available, so this might be GNU ld specific behavior? Charlie, do you
> have the binutils port installed?
> 
That particular machine has never had the binutils port installed. 
Further, the LLVM port has the LLD option enabled, and thus with 
CROSS_COMPILER appropriately set in src-env.conf, will have only used 
the LLVM port entirely.

-- 
Charlie Li
…nope, still don't have an exit line.