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

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.

-Dimitry