Date: Thu, 9 Jan 2020 20:58:48 +0000 From: Alexander Richardson <arichardson@freebsd.org> To: Ed Maste <emaste@freebsd.org> Cc: freebsd-arch <freebsd-arch@freebsd.org>, FreeBSD Ports <freebsd-ports@freebsd.org> Subject: Re: Retiring GNU objdump 2.17.50 Message-ID: <CA%2BZ_v8p4dDHB6WR6Rq35gSerzqwKzC7frbdoP_uv=JaMsfuqUA@mail.gmail.com> In-Reply-To: <CAPyFy2CJYYkcBRkajEf9miGUDBgpJ-DU3kGuJyHf5u%2BhjrF4uw@mail.gmail.com> References: <CAPyFy2CJYYkcBRkajEf9miGUDBgpJ-DU3kGuJyHf5u%2BhjrF4uw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 9 Jan 2020 at 15:32, Ed Maste <emaste@freebsd.org> 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. Hi Ed, While there is a risk of subtle breakage, I would be in favour of installing llvm-objdump as /usr/bin/objdump. LLVM developers are actively trying to ensure that they can be used as a drop in replacement in most cases. If I remember the discussion at EuroLLVM last year correctly, the goal is to have compatible output for anything used e.g. in configure scripts and only diverge if there is a good reason for it. I also find that bugs reported against binutils in LLVM bugzilla are generally addressed quickly, especially if it's a simple GNU compatibility issue. Additionally, llvm-objdump's disassembler is a lot faster than GNU objdump (at least twice as fast, but my LLVM build is with assertions enabled, so probably even more). However, I would wait until we have imported LLVM 10 before making that change. There have been quite a few commits to LLVM binutils replacements in the past few months that improve compatibility with the GNU versions (not only objdump but also readelf,addr2line,ar,ranlib etc). I'm not sure the LLVM 9 versions are ready yet, but for CheriBSD we use llvm binutils for everything (our fork is roughly up to date with llvm 10). Unrelated to this but we could also install llvm-readobj installed as /usr/bin/readelf to avoid depending on installing the GNU binutils port for projects using readelf? Additionally, I would also very much like to see llvm-ar as /usr/bin/ar and /usr/bin/ranlib so we can start using LTO with clang. Alex > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CA%2BZ_v8p4dDHB6WR6Rq35gSerzqwKzC7frbdoP_uv=JaMsfuqUA>