Tool Chain Migration: objdump users, please test llvm-objdump

[Ed Maste]

Work is in progress to migrate fully to modern and permissively
licensed components for the tool chain. This includes moving away from
the three obsolete binutils components that are still in the base
system (as, ld, objdump). objdump is a tool to report information
about binary objects (such as headers, symbols, etc.), is not required
as a build tool, and in any case many uses of objdump are better
served by readelf.

For FreeBSD 12 I intend to remove GNU objdump 2.17.50. PR 229046[1] is
open to track tasks related to its removal, and users who need GNU
objdump can install an up-to-date version from the ports tree or the
binutils package.

That said, llvm includes a somewhat equivalent llvm-objdump, and it is
built by default in FreeBSD now. If llvm-objdump's command line option
support and output format is "close enough" to GNU objdump for most
users we may decide to install it as /usr/bin/objdump. Therefore, I
would like to ask users of GNU objdump in FreeBSD to give llvm-objdump
a try. Please let me know if it works for your uses, or describe
deficiencies that you found.

[1] https://bugs.freebsd.org/229046
_______________________________________________
freebsd...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"

[Brooks Davis]

On Wed, Jun 20, 2018 at 10:46:46AM -0400, Ed Maste wrote:
> Work is in progress to migrate fully to modern and permissively
> licensed components for the tool chain. This includes moving away from
> the three obsolete binutils components that are still in the base
> system (as, ld, objdump). objdump is a tool to report information
> about binary objects (such as headers, symbols, etc.), is not required
> as a build tool, and in any case many uses of objdump are better
> served by readelf.
>
> For FreeBSD 12 I intend to remove GNU objdump 2.17.50. PR 229046[1] is
> open to track tasks related to its removal, and users who need GNU
> objdump can install an up-to-date version from the ports tree or the
> binutils package.
>
> That said, llvm includes a somewhat equivalent llvm-objdump, and it is
> built by default in FreeBSD now. If llvm-objdump's command line option
> support and output format is "close enough" to GNU objdump for most
> users we may decide to install it as /usr/bin/objdump. Therefore, I
> would like to ask users of GNU objdump in FreeBSD to give llvm-objdump
> a try. Please let me know if it works for your uses, or describe
> deficiencies that you found.

I think we've changed our flag us in CheriBSD to accommodate llvm-objdump
so at least a few months ago flag compatibility was poor. The output is
different, but fine for my uses (producing human readable assembly
output).

-- Brooks

[Shawn Webb]

On Wed, Jun 20, 2018 at 10:46:46AM -0400, Ed Maste wrote:

> Work is in progress to migrate fully to modern and permissively
> licensed components for the tool chain. This includes moving away from
> the three obsolete binutils components that are still in the base
> system (as, ld, objdump). objdump is a tool to report information
> about binary objects (such as headers, symbols, etc.), is not required
> as a build tool, and in any case many uses of objdump are better
> served by readelf.
>
> For FreeBSD 12 I intend to remove GNU objdump 2.17.50. PR 229046[1] is
> open to track tasks related to its removal, and users who need GNU
> objdump can install an up-to-date version from the ports tree or the
> binutils package.
>
> That said, llvm includes a somewhat equivalent llvm-objdump, and it is
> built by default in FreeBSD now. If llvm-objdump's command line option
> support and output format is "close enough" to GNU objdump for most
> users we may decide to install it as /usr/bin/objdump. Therefore, I
> would like to ask users of GNU objdump in FreeBSD to give llvm-objdump
> a try. Please let me know if it works for your uses, or describe
> deficiencies that you found.

In preparation for Cross-DSO CFI support, HardenedBSD switched to
llvm-ar, llvm-nm, and llvm-objdump on 12-CURRENT/arm64 with commit
a3db6f9006499b55c2042faccd0ed6a6777b9d9f (22 Dec 2017).

There are some issues with the ports tree, but I haven't quantified
them, yet. All high-visibility applications (firefox, apache, nginx,
openvpn, etc.) all work with a full llvm toolchain (again: llvm-ar,
llvm-nm, and llvm-objdump).

Some applications break during runtime and not build time. Certain
pidgin plugins break, for example, at runtime due to a full llvm
toolchain, but compile just fine.

Would you like me to quantify the compilation breakages due to the
full llvm toolchain switch? If so, I can do that after July 12th.

Thanks,

--
Shawn Webb
Cofounder and Security Engineer
HardenedBSD

Tor-ified Signal: +1 443-546-8752
Tor+XMPP+OTR: lat...@is.a.hacker.sx
GPG Key ID: 0x6A84658F52456EEE
GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE

[Ed Maste]

On 20 June 2018 at 18:25, Shawn Webb <shawn...@hardenedbsd.org> wrote:
>
> Would you like me to quantify the compilation breakages due to the
> full llvm toolchain switch? If so, I can do that after July 12th.

Thanks Shawn, right now I'm interested specifically in llvm-objdump,
with the goal of sorting it out in advance of FreeBSD 12.

I think it's a worthwhile endeavour to quantify the breakage from
using all of the LLVM tools though, and if you're able to triage the
issues and submit LLVM, FreeBSD, or upstream port issues as
appropriate that would be much appreciated. (It's just not yet on the
critical path for me.)

[Shawn Webb]

On Wed, Jun 20, 2018 at 07:31:21PM -0400, Ed Maste wrote:
> On 20 June 2018 at 18:25, Shawn Webb <shawn...@hardenedbsd.org> wrote:
> >
> > Would you like me to quantify the compilation breakages due to the
> > full llvm toolchain switch? If so, I can do that after July 12th.
>
> Thanks Shawn, right now I'm interested specifically in llvm-objdump,
> with the goal of sorting it out in advance of FreeBSD 12.
>
> I think it's a worthwhile endeavour to quantify the breakage from
> using all of the LLVM tools though, and if you're able to triage the
> issues and submit LLVM, FreeBSD, or upstream port issues as
> appropriate that would be much appreciated. (It's just not yet on the
> critical path for me.)

Sounds good. Can you ping me again after July 12th?

Also, if Tor is available for you, the amd64 Poudriere web UI is
accessible via a Tor v3 Onion Service:
http://3jkjhrvkdbdkqisnwhdpe4afh2j2g3suhsfcewiemsyk5ecd6gadmxyd.onion:8081/index.html

[Alexander Richardson]

When I made the change to use llvm-objdump in CheriBSD I had to change the
objdump flags from -xrsSd to -r -s -p -S -d -h -l -t.

This is because llvm-objdump doesn't support the -x option and doesn't
accept joined single-character options. I've been meaning to submit a patch
upstream for -x but haven't got around to it yet.
Otherwise the only noticeable change was that creating a full dump of any
binary is MUCH faster.

Alex

[Ed Maste]

On 20 June 2018 at 17:26, Alexander Richardson <arich...@freebsd.org> wrote:
>
> When I made the change to use llvm-objdump in CheriBSD I had to change the
> objdump flags from -xrsSd to -r -s -p -S -d -h -l -t.

Ah yes, I recall discussing this now. Per GNU objdump's man page, -x
is equivalent to -a -f -h -p -r -t. llvm-objdump doesn't support
these:

-a archive headers
-f file headers

so we probably want to address those as well. We'll also need a man page.

[Ed Maste]

On 21 June 2018 at 09:09, Ed Maste <ema...@freebsd.org> wrote:
>
> We'll also need a man page.

I took a quick look at this, and in doing so found that the output
from "llvm-objdump --help" appears to be missing a large number of
single-letter options, so one more thing to sort out.

As it happens there are LLVM bugs open for a number of the
llvm-objdump issues (even including some I submitted but forgot
about):
https://bugs.llvm.org/buglist.cgi?component=llvm-objdump&list_id=140941&product=tools&query_format=advanced&resolution=---