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

From: John Baldwin <jhb_at_FreeBSD.org>
Date: Wed, 18 May 2022 20:28:25 UTC
On 5/18/22 12:35 PM, Brooks Davis wrote:
> On Wed, May 18, 2022 at 09:17:58PM +0200, Dimitry Andric wrote:
>> On 18 May 2022, at 02:33, Konstantin Belousov <kostikbel@gmail.com> wrote:
>>>
>>> On Tue, May 17, 2022 at 10:56:14AM -0700, John Baldwin wrote:
>>>> On 5/16/22 8:09 PM, Charlie Li wrote:
>>>>> Brooks Davis wrote:
>>>>>> On Mon, May 16, 2022 at 10:47:49AM -0400, Charlie Li wrote:
>>>>>>> Dimitry Andric wrote:
>>>>>>>> This was also reported by another user, and it turned out they were
>>>>>>>> using WITHOUT_CROSS_COMPILER= in src.conf. If you also have that, try
>>>>>>>> removing it and rebuilding.
>>>>>>>>
>>>>>>> Yeah I eventually figured that part out. Worked around (first attempt)
>>>>>>> by building with devel/llvm14 CROSS_TOOLCHAIN, but resulted in certain
>>>>>>> kernel modules (zfs and a few more) with malformed relocations.
>>>>>>> Subsequent rebuild with the new world's toolchain corrected that.
>>>>>>
>>>>>> Does that mean we're missing patches in the port? Hopefully anything
>>>>>> this critical can be merged into LLVM 14.0.3.
>>>>>>
>>>>> Probably:
>>>>>
>>>>> May 15 22:34:08 current-builder kernel: ---<<BOOT>>---
>>>>> May 15 22:34:08 current-builder kernel: Copyright (c) 1992-2022 The
>>>>> FreeBSD Project.
>>>>> May 15 22:34:08 current-builder kernel: Copyright (c) 1979, 1980, 1983,
>>>>> 1986, 1988, 1989, 1991, 1992, 1993, 1994
>>>>> May 15 22:34:08 current-builder kernel: The Regents of the
>>>>> University of California. All rights reserved.
>>>>> May 15 22:34:08 current-builder kernel: FreeBSD is a registered
>>>>> trademark of The FreeBSD Foundation.
>>>>> May 15 22:34:08 current-builder kernel: FreeBSD 14.0-CURRENT #121
>>>>> main-n255657-48a1a6be196: Sun May 15 21:59:12 EDT 2022
>>>>> May 15 22:34:08 current-builder kernel:
>>>>> root@current-builder:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64
>>>>> May 15 22:34:08 current-builder kernel: clang version 14.0.2
>>>>> [...]
>>>>> May 15 22:34:08 current-builder kernel: kldload: unexpected relocation
>>>>> type 42, symbol index 8321
>>>>
>>>> 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?
> 
> I don't believe this is true in all but the weirdest configurations.  I
> just tested on a system with binutils installed (providing
> /usr/local/bin/ld) and clang13 uses /usr/local/llvm13/bin/ld as I'd
> expect.  Because of the foo## wrappers, clang doesn't know it's being
> found via /usr/local/bin so doesn't look there by default.  Instead it's
> invoked as /usr/local/llvm##/bin/clang and looks for
> /usr/local/llvm##/bin/ld.  Maybe if you didn't install LLD it would
> eventually look in PATH and find /usr/local/bin/ld.

It gets more odd if you install amd64-binutils (used by amd64-gcc[69]) as
that installs a x86-64-unknown-freebsd13.0-ld binary that clang will find
and use.  However, Charlie reported he only got this during the transition
where the tree in /usr/obj had LLVM 14 but /usr had LLVM 13, so I'm not
sure what the cause is or if it is even reproducible.

-- 
John Baldwin