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 <[email protected]> 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
