Re: git: 3a9a9c0ca44e - main - Merge llvm-project release/14.x llvmorg-14.0.3-0-g1f9140064dfb

On Sat, May 14, 2022, 1:40 PM Dimitry Andric <dim@freebsd.org> wrote:

> On 14 May 2022, at 21:07, Warner Losh <imp@bsdimp.com> wrote:
> >
> > On Sat, May 14, 2022, 12:00 PM Dimitry Andric <dim@freebsd.org> wrote:
> > On 14 May 2022, at 19:11, Bjoern A. Zeeb <bz@FreeBSD.org> wrote:
> > ...
> > > I haven't checked where they come from yet (given make -s). Possibly
> ..?
> > >
> > > sys/conf/kmod.mk:LDFLAGS+= -d -warn-common
> >
> > Ah yes, thanks for spotting that. I think I'll just put in a linker
> > version check, and avoid the option for lld >= 14.
> >
> >
> > Two items : do we need it at all?
>
> It's a bit of an obscure option, introduced way back in 2002:
>
>
> https://cgit.freebsd.org/src/commit/?id=0b3178a45cd08a2387bff09a2844deacc97ae1e7
>
> where the original comment had "Disallow common variables, and if we end
> up with commons from somewhere unexpected, allocate storage for them in
> the module itself."
>
> BFD ld's docs
> (
> https://sourceware.org/binutils/docs/ld/Options.html#index-common-allocation
> )
> say:
>
> "assign space to common symbols even if a relocatable output file is
> specified (with '-r'). The script command FORCE_COMMON_ALLOCATION has
> the same effect."
>
> Since lld implements it as a no-op, and everything appears to work just
> fine, I'd only keep it in for now for people that want to use gcc in
> combination with BFD ld for building their modules.
>
>
> > Won't this make build stable/13 noisy in same cases? We can just
> document it since it wouldn't be the mainline build, but it will come up...
>
> It shouldn't, as I'm putting in a check for the lld version. If >= 14,
> it will just not add the option at all.
>

13.1 won't have that check...

Warner

> -Dimitry
>
>