Re: [RFC PATCH 1/2] kbuild: add CONFIG_LD_IS_BINUTILS

[Sedat Dilek]

On Fri, Apr 24, 2020 at 7:18 AM Fangrui Song <maskray@xxxxxxxxxx> wrote:
>
> On 2020-04-24, Masahiro Yamada wrote:
> >On Fri, Apr 24, 2020 at 3:44 AM Nick Desaulniers
> ><ndesaulniers@xxxxxxxxxx> wrote:
> >>
> >> On Sun, Apr 19, 2020 at 6:19 AM Sedat Dilek <sedat.dilek@xxxxxxxxx> wrote:
> >> >
> >> > This patch is currently not mandatory but a prerequisites for the second one.
> >> >
> >> > Folks from ClangBuiltLinux project like the combination of Clang compiler
> >> > and LLD linker from LLVM project to build their Linux kernels.
> >> >
> >> > Sami Tolvanen <samitolvanen@xxxxxxxxxx> has a patch for using LD_IS_LLD (see [1]).
> >> >
> >> > Documentation/process/changes.rst says and uses "binutils" that's why I called
> >> > it LD_IS_BINUTILS (see [2] and [3]).
> >> >
> >> > The second patch will rename existing LD_VERSION to BINUTILS_VERSION to have
> >> > a consistent naming convention like:
> >> >
> >> > 1. CC_IS_GCC and GCC_VERSION
> >> > 2. CC_IS_CLANG and CLANG_VERSION
> >> > 3. LD_IS_BINUTILS and BINUTILS_VERSION
> >> >
> >> > [1] https://github.com/samitolvanen/linux/commit/61889e01f0ed4f07a9d631f163bba6c6637bfa46
> >> > [2] https://git.kernel.org/linus/tree/Documentation/process/changes.rst#n34
> >> > [3] https://git.kernel.org/linus/tree/Documentation/process/changes.rst#n76
> >> >
> >> > Signed-off-by: Sedat Dilek <sedat.dilek@xxxxxxxxx>
> >>
> >> Just some background on Sami's patch.  Originally we were using
> >> ld.gold (for LTO for Pixel 3) before moving to ld.lld (for LTO for
> >> Pixel 4 and later).  Not sure if Kconfig would be a better place to
> >> check if gold is used, then warn?  I kind of prefer the distinction
> >> that binutils contains two different linkers, though if no one is
> >> supporting ld.gold, and it doesn't work for the kernel, then maybe
> >> that preference is moot?
> >
> >
> >I prefer LD_IS_BFD, like this patch:
> >https://lore.kernel.org/patchwork/patch/1039719/
> >
> >We do not need LD_IS_GOLD, though.
> >
> >--
> >Best Regards
> >Masahiro Yamada
>
> +1 for CONFIG_LD_IS_BFD
>
> Usually GNU ld is also installed as ld.bfd and can be referred to by -fuse-ld=bfd (GCC >= 9, or clang)
>
> The repository binutils-gdb includes two linkers: GNU ld and GNU gold, so CONFIG_LD_IS_BINUTILS would be ambiguous.

Hi,

The last days I was busy with job-hunting, so this is my prio #1.
Thus I was not very responsive.

And I am sorry to mixup different threads in ClangBuiltLinux and elsewhere.

WOW Huh ***Votings***!

Originally the patchset from Nick had LD_IS_BFD, LD_IS_GOLD and LD_IS_LLD.

As pointed out GOLD is no more suitable to link the kernel and thus
deactivated (AFAICS Thomas Gleixner did this).

Personally, I am OK with ***LD_IS_LD*** because we have now
***LD_VERSION*** which was introduced in Linux v5.7-rc1.
We have the pair LD_IS_LD and LD_VERSION like CC_IS_GCC and GCC_VERSION.
The only thing I would like to be changed is the comment in
***scripts/ld-version.sh*** to mention "GNU/ld (binutils)" if you
decide for LD_IS_LD or not.
But I am OK with LD_IS_BFD.
If you ask people what they come into mind when speaking of "ld" - 99%
of the answers of this people will point to GNU/ld from GNU/binutils.
This is simply a fact in the Linux-kernel world.

I am living in my x86 world and do not test with cross-compilation or
any other archs like ARM or MIPS or whatever.
So, I might not catch all corner-cases.

Some bots like kbuild-bot(?) already sent some warnings on my patchset.

My ***main interest*** is to have good support of ***LLD*** which is
my primary linker.

Why?
(Might be off-topic here in this thread)

"Numbers talk, bullshit walks." (Linus Torvalds)

Please, compile yourself (here: Debian/testing AMD64)...

#1: gcc 9.3 with GNU/ld (binutils)
#2: gcc 9.3 with ld.lld-10
#3: clang-10 and ld.lld-10

I have not the same code-base to compare, but first numbers:

Even the combo of gcc-9.3 and ld.lld-10 produces 5GiB more disc-space
in my linux-git.
The debug binaries and the resulting Debian debug packages are
significantly bigger

$ cd stats

$ cat 5.7.0-rc*/disc-usage.txt
23406   linux
1951    archives/5.7.0-rc1-2-amd64-gcc <--- XXX: gcc-9.3 + ld.lld-10
17958   linux
1365    5.7.0-rc2-1-amd64-clang <--- XXX: LLVM/Clang/LLD
10.0.1-git-92d5c1be9ee93850c0a8903f05f36a23ee835dc2

$ cd archives

$ du -m 5.7.0-rc*/linux-image-*-dbg*_amd64.deb
617     5.7.0-rc1-2-amd64-gcc/linux-image-5.7.0-rc1-2-amd64-gcc-dbg_5.7.0~rc1-2~bullseye+dileks1_amd64.deb
424     5.7.0-rc2-1-amd64-clang/linux-image-5.7.0-rc2-1-amd64-clang-dbg_5.7.0~rc2-1~bullseye+dileks1_amd64.deb

$ du -m 5.7.0-rc*/vmlinux*
603     5.7.0-rc1-2-amd64-gcc/vmlinux
7       5.7.0-rc1-2-amd64-gcc/vmlinux.compressed
597     5.7.0-rc1-2-amd64-gcc/vmlinux.o
409     5.7.0-rc2-1-amd64-clang/vmlinux
7       5.7.0-rc2-1-amd64-clang/vmlinux.compressed
404     5.7.0-rc2-1-amd64-clang/vmlinux.o

As said - not the same code and patch base!

This needs definitely to be investigated.

LLD seems to be - seen from the numbers - be a lot of "smarter".

Have more fun!

Regards and happy first day of Ramadan if you celebrate it,
- Sedat -

P.S.: A build of Linux v5.7-rcX with gcc-9.3 as compiler is much much
faster here.