Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 18 May 2022 21:17:58 +0200
From:      Dimitry Andric <dim@FreeBSD.org>
To:        Konstantin Belousov <kostikbel@gmail.com>
Cc:        John Baldwin <jhb@freebsd.org>, Charlie Li <vishwin@freebsd.org>, Brooks Davis <brooks@freebsd.org>, "src-committers@freebsd.org" <src-committers@freebsd.org>, "dev-commits-src-all@freebsd.org" <dev-commits-src-all@freebsd.org>, "dev-commits-src-main@freebsd.org" <dev-commits-src-main@freebsd.org>
Subject:   Re: git: 349cc55c9796 - main - Merge llvm-project main llvmorg-14-init-10186-gff7f2cfa959b
Message-ID:  <698AE22D-5E95-405E-A8BE-AE67A3A7BE36@FreeBSD.org>
In-Reply-To: <YoQ%2B8LupA6XG6F/a@kib.kiev.ua>
References:  <202205141148.24EBmkZd015765@gitrepo.freebsd.org> <e251f1fb-b0c2-1d3a-d9f2-6def1ddb9735@freebsd.org> <C45D4583-C972-426A-88F0-42F475D760D2@FreeBSD.org> <4b61bdc6-fdc7-57df-e9b7-52543fd083be@freebsd.org> <20220516154825.GF15201@spindle.one-eyed-alien.net> <e57160f3-5d34-69cb-c249-f4f0f0665282@freebsd.org> <5e5281b2-a9d1-3751-b09a-c88d210f4f55@FreeBSD.org> <YoQ%2B8LupA6XG6F/a@kib.kiev.ua>

next in thread | previous in thread | raw e-mail | index | archive | help

--Apple-Mail=_31681BFC-1E9A-4C06-B96E-BEC8BD87CBD8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

On 18 May 2022, at 02:33, Konstantin Belousov <kostikbel@gmail.com> =
wrote:
>=20
> 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=3D in src.conf. If you also have =
that, try
>>>>>> removing it and rebuilding.
>>>>>>=20
>>>>> 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.
>>>>=20
>>>> Does that mean we're missing patches in the port? Hopefully =
anything
>>>> this critical can be merged into LLVM 14.0.3.
>>>>=20
>>> Probably:
>>>=20
>>> 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
>>=20
>> These are all type 42:
>>=20
>> #define	R_X86_64_REX_GOTPCRELX	42
>>=20
>> 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.
>>=20
>> 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?
>=20
> I do think this is a toolchain bug, or at least new and undesired =
behavior.
>=20
> 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 said, the lld release notes
=
<https://releases.llvm.org/14.0.0/tools/lld/docs/ReleaseNotes.html#elf-imp=
rovements>
say you can now use --no-relax for this:

> =E2=80=A2 For x86-64, --no-relax now suppresses R_X86_64_GOTPCRELX and
>   R_X86_64_REX_GOTPCRELX GOT optimization (D113615)

So maybe we can use this in sys/conf/kern.mk, or in kmod.mk?

-Dimitry


--Apple-Mail=_31681BFC-1E9A-4C06-B96E-BEC8BD87CBD8
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.2

iF0EARECAB0WIQR6tGLSzjX8bUI5T82wXqMKLiCWowUCYoVGZgAKCRCwXqMKLiCW
o0lzAJ0ch1OSniN8u5/iWXQ0KlrK9RQRGQCdE9pnFW/AZRvq7DtSLMm1Pimtsmw=
=KayD
-----END PGP SIGNATURE-----

--Apple-Mail=_31681BFC-1E9A-4C06-B96E-BEC8BD87CBD8--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?698AE22D-5E95-405E-A8BE-AE67A3A7BE36>