Install llvm-objdump as objdump on Clang-using architectures (RFC review)

[emaste]

Summary

Install LLVM's objdump as /usr/bin/objdump on those architecures which use Clang as the system compiler, as one step in the retirement of the obsolete binutils 2.17.50. It supports many, but not all, of GNU objdump's command line options. Users requiring the full functionality of GNU objdump should install the binutils port.

PR: 229046 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229046

[emaste]

gnu/usr.bin/binutils/Makefile

15

move libbinutils into this block too

[emaste]

See also D13881 (deprecation notice for GNU objdump) and D7338 (old review to disconnect GNU objdump w/o replacement).

[kib]

What are the big non-implemented features ? IMO it is better to keep it named llvm-objdump and might be switch base to use llvm-objdump if it is needed.

[emaste]

In D18307#389445, @kib wrote:

What are the big non-implemented features ?

Some known issues (LLVM PRs):

39101 llvm-objdump does not support --demangle
37895 llvm-objdump --help omits many single-letter options
37151 llvm-objdump does not accept -z option
31679 llvm-objdump does not accept combined args as GNU objdump does
30241 llvm-objdump -p omits dynamic headers (in comparison to GNU objdump)
27249 llvm-objdump --dwarf=frames printing wrong values
26892 llvm-objdump -t includes reserved undefined symbol in output, compared with GNU objdump
25124 llvm-objdump prints unknown for relocation info on PPC
21059 llvm-objdump -r reports relocation against symbol `Unknown' on x86
18293 llvm-objdump: warning: invalid instruction encoding
18154 llvm-objdump should have a option to start disassembly at a specified symbol name

IMO it is better to keep it named llvm-objdump and might be switch base to use llvm-objdump if it is needed.

Nothing in base should currently depend on objdump. My original plan was to just stop installing GNU objdump (D7338) but it is taking quite some time for ports fallout to be addressed.

[arrowd]

Fixed upstream:

• 39101 llvm-objdump does not support --demangle
• 37895 llvm-objdump --help omits many single-letter options
• 37151 llvm-objdump does not accept -z option
• 31679 llvm-objdump does not accept combined args as GNU objdump does
• 30241 llvm-objdump -p omits dynamic headers (in comparison to GNU objdump)
• 27249 llvm-objdump --dwarf=frames printing wrong values
• 26892 llvm-objdump -t includes reserved undefined symbol in output, compared with GNU objdump
• 25124 llvm-objdump prints unknown for relocation info on PPC
• 21059 llvm-objdump -r reports relocation against symbol `Unknown' on x86
• 18293 llvm-objdump: warning: invalid instruction encoding
• 18154 llvm-objdump should have a option to start disassembly at a specified symbol name

[• ian]

I wonder if a good option for this would be to install a symlink rather than hardlink, and don't replace an existing link. That way by default people get an objdump that's mostly compatible with the old one, and if they need full compatibility they can install the pkg and change the symlink to point to it.

It occurred to me... I mentioned on a mailing list that I use objdump frequently. That's true, but I'm almost always using one that was built as a crosstool (runs on amd64 but works on armv7 binary), and that's not the one installed in /usr/bin anyway.

[emaste]

Open bug links:
https://bugs.llvm.org/show_bug.cgi?id=37895
https://bugs.llvm.org/show_bug.cgi?id=27249
https://bugs.llvm.org/show_bug.cgi?id=25124
https://bugs.llvm.org/show_bug.cgi?id=18293
https://bugs.llvm.org/show_bug.cgi?id=18154

[• ian]

When replacing objdump with llvm-objdump came up on a mailing list, there was some opinion expressed that most users don't need objdump at all and should have to install a package to get it. But I find llvm-objdump to be a completely-usable replacement for gnu objdump that we've had in base for years. That leads me to think a knob such as WITH[OUT]_LLVM_OBJDUMP that defaults to WITHOUT might be a good solution for this.

[emaste]

In D18307#506437, @ian wrote:

That leads me to think a knob such as WITH[OUT]_LLVM_OBJDUMP that defaults to WITHOUT might be a good solution for this.

Fair point. I wonder if the path forward is to first remove GNU objdump, ensuring that ports that depend on objdump pick up GNU binutils, and then take a look at adding this. We do install llvm's objdump (as llvm-objdump) today, so maybe WITH[OUT]_LLVM_OBJDUMP_SYMLINK, or essentially that but less of a mouthful.

[arrowd]

https://bugs.llvm.org/show_bug.cgi?id=27249 was fixed upstream: https://github.com/llvm/llvm-project/commit/49cbf4cd85a9ae6b53947fb8cf39ccfb56becc57