Makefile.inc1: Don't force LLVM_BINUTILS off for cross-tools

[emaste]

Summary

Because of this we were still using ELF Tool Chain tools for buildworld.
They are largely equivalent and this went unnoticed after commit
1cae7121c667 ("Enable LLVM_BINUTILS by default").

This was discovered recently because ELF Tool Chain objcopy produces
standalone debug files without phdrs and this caused an issue with a
3rd party ELF parser [1].

[1] https://sourceware.org/bugzilla/show_bug.cgi?id=33876

[jhb]

Makefile.inc1

811

I wonder why this was set before. The original log message does not cover this part of the change (and it seems like it should have never been here given your log message?) Maybe @arichardson knows?

[emaste]

Makefile.inc1

811

Good question. There's at least one limitation in LLVM binutils vs ELF Tool Chain -- LLVM objcopy can't convert ELF to PE as we do with the UEFI loaders. Perhaps there were additional, similar issues with LLVM binutils at the time and it was easiest to punt on that for the time being.

[emaste]

Makefile.inc1

811

(ELF Tool Chain's objcopy equivalent is elfcopy. In b885643b63e4df51cc6c74c4ddd4d0b640075678, 7d70f8b482fd1ab82dbea31103be7de5ec3c2c7b, ca0fc8ef2f97709d3dfeac54e2c762e1c6ec6559 I went back to installing it with the upstream name so we can continue using it to build UEFI bits.)

[imp]

Makefile.inc1

811

At one point all the binutils stuff was in-tree, not of llvm origin. This was likely an attempt to firewall the new thing from the old, known to be working things. I've noticed it several times and always thought that was what it was for.

[emaste]

Makefile.inc1

811

Most of the tools (incl objcopy, which is how this was discovered) have been taken from a 3rd party project - first GNU, then ELF Tool Chain, finally LLVM. There are/were a few bespoke exceptions -- ar/ranlib, elfdump.