[CMake] Check objcopy support for LLVM_SPLIT_DWARF

[jsji]

LLVM_SPLIT_DWARF require new binutils support for objcopy etc.
This is to check the option and error out if binutils is too old.

Still allow use to override the check if they don't need to use objcopy.

[MaskRay]

This check is not necessary. Building LLVM requires GCC 7.4/8.1 (2018), which roughly corresponds to the binutils 2.30 era. The default R_X86_64_REX_GOTPCRELX clang emits requires something like binutils 2.25+.

[jsji]

which roughly corresponds to the binutils 2.30 era

roughly? I don't think we can assume that users are using binutils and GCC from same era. eg: Users can still use an old OS with old binutils, but just install newer GCC.

https://llvm.org/docs/GettingStarted.html#host-c-toolchain-both-compiler-and-standard-library

GNU binutils 2.17: Binutils 2.17 contains a bug which causes huge link times (minutes instead of seconds) when building LLVM. We recommend upgrading to a newer version (2.17.50.0.4 or later).

We actually distinguished GCC and binutils, and only require 2.17 .

The default R_X86_64_REX_GOTPCRELX clang emits requires something like binutils 2.25+.

If this is the case, should we at least update the document above to mention we require 2.25+ ?

[joker-eph]

@MaskRay : on top of what @jsji wrote, don't you think that this check is "low-cost" while providing a safeguard to our users for a behavior that would be hard to figure out for them? (and for whoever has to provide support for when such user will ask for help on Discourse...)?

I mean we require a minimum version of the toolchain and we check for it, so why not do the same for other tools?

[MaskRay]

This change will cause trouble if a system does not provide objcopy. Clang -gsplit-dwarf doesn't need objcopy. I changed it a few years ago to use the internal ELF writer for non-Linux OSes.

GCC 8 is usually shipped with binutils 2.30+. See https://centos.pkgs.org/7/centos-sclo-rh-x86_64/devtoolset-8-binutils-2.30-47.el7.x86_64.rpm.html , far above than the -gsplit-dwarf requirement.

[joker-eph]

GCC 8 is usually shipped with binutils 2.30+

"usually"? When is it not?
Also our supported toolchain includes gcc 7.4.

This change will cause trouble if a system does not provide objcopy. Clang -gsplit-dwarf doesn't need objcopy. I changed it a few years ago to use the internal ELF writer for non-Linux OSes.

But that applies only to clang and not gcc?
What tool from binutils is involved in building LLVM with GCC?
Also what about BFD support?

[MaskRay]

GCC 8 is usually shipped with binutils 2.30+

"usually"? When is it not? Also our supported toolchain includes gcc 7.4.

There is a package devtoolset-7-binutils-2.28-7.el7.x86_64.rpm. I assume that GCC 7 is often used with 2.28, nearly 5 years newer than 2.23. Of course you can claim that there are systems out there that use GCC 7 but much older binutils. I think proponents of the change should show evidence.

This change will cause trouble if a system does not provide objcopy. Clang -gsplit-dwarf doesn't need objcopy. I changed it a few years ago to use the internal ELF writer for non-Linux OSes.

But that applies only to clang and not gcc? What tool from binutils is involved in building LLVM with GCC? Also what about BFD support?

The objcopy requirement is only for GCC. Clang doesn't use objcopy for -gsplit-dwarf.

BFD is part of binutils.

I understand the desire to add some check to prevent any inconvenience, but I strongly believe the objcopy check is not only busy work here but also harmful (for systems not using binutils, etc).

[joker-eph]

The objcopy requirement is only for GCC. Clang doesn't use objcopy for -gsplit-dwarf.

That's fine, we can adjust the check to only being performed if GCC is used...

I understand the desire to add some check to prevent any inconvenience, but I strongly believe the objcopy check is not only busy work here but also harmful (for systems not using binutils, etc).

You seem to understand all the moving pieces here: can you suggest a sequence of checks that would make sense?

[MaskRay]

The objcopy requirement is only for GCC. Clang doesn't use objcopy for -gsplit-dwarf.

That's fine, we can adjust the check to only being performed if GCC is used...

I understand the desire to add some check to prevent any inconvenience, but I strongly believe the objcopy check is not only busy work here but also harmful (for systems not using binutils, etc).

You seem to understand all the moving pieces here: can you suggest a sequence of checks that would make sense?

This patch should be abandoned. The binutils 2.23 version requirement has long been irrelevant.

[joker-eph]

So for all practical purpose, for Linux systems we support, you're saying that all the tools involved in the build will correctly support split dwarf out of the box, regardless of the combination compiler/linker that is enabled?

LGTM then.

[jsji]

abandoned this first per @MaskRay 's requirement. We can reiterate this later if we get some error report.

[dwblaikie]

Yeah, I'm OK waiting to see if this is a problem in practice.

but to answer some of the questions @joker-eph had:

What tool from binutils is involved in building LLVM with GCC?
gcc, when using -gsplit-dwarf, invokes binutils objcopy to split out the file into the .o and .dwo parts (the compiler itself produces one monolithic object file, and the compiler driver uses objcopy to split it into the two products)
You can see these extra actions here https://godbolt.org/z/bcj8d895E:

gcc version 13.2.0 (Compiler-Explorer-Build-gcc--binutils-2.40) 
...cc1plus ... <source> -o /tmp/cc1E3Olm.s
...as ... -o /app/output.s /tmp/cc1E3Olm.s
...objcopy --extract-dwo /app/output.s /app/output.dwo
...objcopy --strip-dwo /app/output.s

I don't know precisely which version of binutils this was introduced in, or what different GCC versions likely ship alongside that binutils version, etc...