Re: Retiring GNU objdump 2.17.50
On Thu, 9 Jan 2020, Ed Maste wrote:
world or kernel). It is required to build a limited number of ports,
and is used by some developers.
My use case is troubleshooting tool - I can always ask somebody
on the remote computer to check their binaries with a tool that
is in the base system. ("Can you objdump -T this library?",
"Can you objdump -R something | grep symbolname?").
I think the first use case can be solved with "nm -D", I don't see
the replacement for the latter. Since I also support Mac, Linux users it
nice to have one tool that works the same across all the platforms;
but give I need to take "otool" for older MacOS into account I don't
mind to have something else under a different name, with different
options, as long as it is well known and preferably always available
for troubleshooting (not an additionally installed something).
Haven't worked with llvm-objdump yet.
I like the disassembler feature but for myself I can install
binutils.
Marcin
smime.p7s
Description: S/MIME Cryptographic Signature
Re: Retiring GNU objdump 2.17.50
On Sun, 12 Jan 2020 at 20:40, Slawa Olhovchenkov wrote: > > As long as pmcannotate relies on objdump(1) and pmcstat(8) to > work, it > will fail if one of them is not available. Ah, we could have pmcannotate check for both llvm-objdump and objdump in $PATH. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Retiring GNU objdump 2.17.50
On Thu, Jan 09, 2020 at 05:56:10PM +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 completly agree with kib here. Best regards, Bapt signature.asc Description: PGP signature
Re: Retiring GNU objdump 2.17.50
On 09/01/20 12:56, 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. +1 -- Renato Botelho ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Re: Retiring GNU objdump 2.17.50
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 Hey Ed, In preparation for Cross-DSO CFI, HardenedBSD made the switch to llvm-objdump a long while ago. Therea are, indeed, subtle breakages in ports. Not all options are supported. I added a LLVM_OBJDUMP_UNSAFE flag, and some ports still have trouble with it. Unfortunately, my spare time at this very moment is not large enough to allow me to document HardenedBSD's initial findings with regards to the switch. I wll, however, add that to my todo list. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc signature.asc Description: PGP signature
Re: Retiring GNU objdump 2.17.50
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. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
Retiring GNU objdump 2.17.50
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. ___ freebsd-ports@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org"
