Always build the elf toolchain, ctfconvert, et al as part of buildtools

[ngie]

Summary

Always build the elf toolchain, ctfconvert, et al as part of buildtools

If the host lacks the elf toolchain (unlikely) or ctfconvert/ctfmerge (more
likely), then the build will fail in make buildkernel if ctfconvert/ctfmerge
aren't installed on the build host

Similarly, this fixes issues where build host versions of the tools can be
incorrect/incompatible with build-produced binaries, and can in turn create
corrupt/incompatible dtrace information, as seen at EMC/Isilon (the build
host versions of our ctf tools are more rudimentary than the copies in the
source tree)

[markj]

If the host lacks the elf toolchain (unlikely) or ctfconvert/ctfmerge (more
likely), then the build will fail in make buildkernel if ctfconvert/ctfmerge
aren't installed on the build host

If I'm not mistaken, that's true of all bootstrap tools? It seems like we should detect that case and make it a condition under which _dtrace_tools is built, rather than unconditionally building them. I don't think I've ever heard of this problem happening though.

Similarly, this fixes issues where build host versions of the tools can be
incorrect/incompatible with build-produced binaries, and can in turn create
corrupt/incompatible dtrace information, as seen at EMC/Isilon (the build
host versions of our ctf tools are more rudimentary than the copies in the
source tree)

It's not that they're more rudimentary, it's that we (Isilon) went ahead and actually changed the binary CTF format, so native FreeBSD ctfconvert/ctfmerge choke on our build. But we've are the ones that made that change; I don't think it's reasonable to modify upstream to handle that case, especially since it'll just add to the build time without any benefits for the vast majority of users. If we end up upstreaming those CTF modifications, we'd have to bump __FreeBSD_version and update the ${BOOTSTRAPPING} < X conditional in the diff above. Am I missing something?

In the past I've mentioned a problem that some users ran into around the clang 3.4 upgrade, where it was necessary to rebuild the kernel twice to get proper CTF info. See this thread for example: https://lists.freebsd.org/pipermail/freebsd-dtrace/2014-December/000333.html
In that case, I'm pretty sure the real problem was the handling of libelf/libdwarf in the bootstrap phase of the build - we were rebuilding ctfconvert and ctfmerge as required, but I think they were linking with the host libelf/libdwarf. Unfortunately, some libdwarf changes were needed to handle the DWARF emitted by clang 3.4, so bootstrapping ctfconvert/ctfmerge didn't help. That's a related problem to look into, if you're interested.

[emaste]

As it turns out this is not sufficient: bootstrap-tools does not install headers, so the ctfconvert built here tries to build against /usr/lib/libdwarf.h

I've been discussing this with @imp a bit but don't have a resolution yet. Of these early targets only legacy installs headers.

[emaste]

Can you test the change in D2144

[ngie]

Closing revision superseded by D2144.