Retiring GNU objdump 2.17.50

[Ian Lepore]

On Thu, 2020-01-09 at 17:56 +0200, Konstantin Belousov wrote:
> On Thu, Jan 09, 2020 at 10:31:55AM -0500, Ed Maste wrote:
> > We currently install and use at most three tools from GNU binutils
> > 2.17.50, depending on target architecture:
> > 
> > 1. as - assembler
> > 2. ld - linker
> > 3. objdump - diagnostic / information tool
> > 
> > I hope to retire all use of these obsolete binutils before FreeBSD 13.
> > Here I'd like to discuss objdump. It is a diagnostic tool that
> > provides information about object files, binaries and libraries. It's
> > not required as a bootstrap tool (i.e., not needed to build FreeBSD
> > world or kernel). It is required to build a limited number of ports,
> > and is used by some developers.
> > 
> > I have a tracking PR for GNU objdump's retirement open in PR 229046.
> > https://bugs.freebsd.org/229046.
> > 
> > There are two ways we can proceed with its retirement:
> > 
> > 1. Remove it without replacement. Ports that need objdump to build
> > will have to depend on the binutils package/port, and users who wish
> > to use it will have to install it.
> > 
> > Related links for this path:
> > Ports exp-run: https://bugs.freebsd.org/212319
> > Patch review: https://reviews.freebsd.org/D7338
> > 
> > 2. Install llvm-objdump in its place (perhaps via a symlink).
> > llvm-objdump is broadly compatible in both command-line argument
> > parsing and output format, but there are many small differences and
> > it's not a full drop-in replacement.
> > 
> > Related links for this path:
> > Patch review: https://reviews.freebsd.org/D18307
> > 
> > I am interested in feedback on the preferred approach. Installing
> > llvm's objdump has the advantage that for most use cases everything
> > will "just work", but may also introduce subtle failures.
> 
> IMO no. 1 is preferrable because we do not need to track differences, nor
> we need to explain them.  Having to install binutils port is not a high cost,
> and if somebody needs details about binary at the level provided by objdump,
> including disassembler, she would need binutils port anyway.

I completely disagree with this.  I recently tested llvm-objdump and
found it to be completely compatible with all the ways I normally use
objdump, and objdump is a tool I use multiple times every month.

I have no idea what you mean about needing to install binutils port "if
somebody needs details...".  Objdump is the one and only tool I need
for examining object files and executables.  I have no idea what other
tools you might even be talking about that are part of a binutils port.

I do agree with the idea that objdump is more useful to a developer
than to the average user or sysadmin.  I wouldn't object to something
like a WITH_LLVM_OBJDUMP knob that defaulted to off.

-- Ian