Date: Thu, 9 Jan 2020 13:37:14 -0800 (PST) From: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net> To: Ian Lepore <ian@freebsd.org> Cc: Konstantin Belousov <kostikbel@gmail.com>, Ed Maste <emaste@freebsd.org>, FreeBSD Ports <freebsd-ports@freebsd.org>, freebsd-arch <freebsd-arch@freebsd.org> Subject: Re: Retiring GNU objdump 2.17.50 Message-ID: <202001092137.009LbEoM097419@gndrsh.dnsmgr.net> In-Reply-To: <54d1f23bd455269cf33a296e2f95809f21f3341c.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. "Having to install binutils" defeats the purpose of a GNU free BSD system, if we just kicked all the stuff out to ports as the GNU free solution we could of been done 20 years ago. One of the projects long standing claims is "A complete developement system", we are slowly eroding that by using the "kick it out to ports" solution. > > 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. Thanks for that data point Ian. > 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. Isnt the LLVM OBJDUMP source code in the tree already? If so just switch to it, and make the knob "WITHOUT_LLVM_OBJDUMP". And as mentioned someplace out the LLVM folks are working on some of the incompatiblities and should have better code in LVM 10. My favor is for #2, switch to llvm_objdump, llvm is our compiler of choice, so it's matching tool set be also. > -- Ian -- Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202001092137.009LbEoM097419>