[illumos-Developer] [REVIEW] 1057 should correctly integrate libdwarf sources

[Richard Lowe]

I'd like review for:

  1057 should correctly integrate libdwarf sources

webrevs:

  Complete: http://richlowe.net/webrevs/il_1057
  Delta      : http://richlowe.net/webrevs/il_1057-delta


Due to an accident of history[1], we have 3 libdwarf binaries in our
source tree, representing the build product from two different
libdwarf source trees.

  usr/src/tools/ctf/dwarf/i386/libdwarf.so.1   -- Believed to be stock
libdwarf, unused
  usr/src/tools/ctf/dwarf/sparc/libdwarf.so.1 -- Believed to be stock
libdwarf, used
  usr/src/tools/ctf/dwarf/i386/libdwarf.a        -- libdwarf modified
to process a subset of i386 relocations, used.

These changes take the libdwarf sources from the libdwarf.cpio.bz2
archive in the source tree, expand them into dwarf/common, and provide
the necessary infrastructure to build them rather than using the
binaries.  This is a precursor to a possible upgrade of libdwarf as
part of a future project (and will greatly ease _any_ such future
project that needs to make changes to our DWARF processing).

The "Delta" webrev is of changes made _after_ extracting the libdwarf
sources into the build, and is much more readable, however you should
note that it is relative to the modified sources from
libdwarf.cpio.bz2, not relative to upstream libdwarf.

Some notes:

  - dwarf_init_finish.c  -- The changes made to allow relocation
processing are plainly i386 specific and were only actually used on
i386 in libdwarf.a (this is almost certainly why i386 used the static
libdwarf).  As such, I have ifdef'd the changes to be i386 only.  This
would be affected by the compiler used during the build and,
specifically, whether and precisely what relocations it produced in
the DWARF sections.  The current code matches what is currently in
use.  Anyone using a different compiler, or upgrading the compiler in
any major way is almost certainly best served by importing a newer
libdwarf, with the upstream relocation processing, in tandem.

   - libdwarf.h/dwarf.h  -- The versions of these headers previously
in the source tree, and the version of these headers previously in the
source _archive_ in the source tree differed.  The copies now placed
in common/ are the merge of these two versions (the copies in the
source archive were the newer).

  - Other changes to libdwarf sources  -- These are all
pointer-integer cast warnings, gagged expediently but not gracefully
(I was shooting to minimize deviation)

  - Build related things -- As explained in Makefile.com, we can't
really include CTF data for libdwarf, as we're need to have built
libdwarf to be able to link the CTF tools.

-- Rich

[1] During either the kernel stabs or amd64 projects some agreement
seems to have existed that DevPro would deliver libdwarf with the OS,
and these binaries were integrated only as a stop-gap measure.  DevPro
never did deliver libdwarf with the OS (It's in the compilers), so the
stop gap has lived on.