elftoolchain update?

[Will Andrews]

Hi Kai,

Thanks for checking in.

On Thu, Oct 2, 2014 at 3:11 AM, Kai Wang <kaiw27 at gmail.com> wrote:
> Thanks for the backtrace and analysis.
>
> I attached a patch for libdwarf and ctfconvert to fix the crash issue.
> The libdwarf patch is the same as Will submitted, it adds check for NULL
> attribute.
> The ctfconvert patch fixes some issue with die_name(). We can't let
> die_name()
> return NULL because we need the empty string "" for type name comparison.
> Instead I added checks for empty string when creating variables and
> functions.

I'm not sure this is the correct approach.  There are many places in
CTF that check for die_name() returning NULL.  I believe the ones that
don't should either generate the empty names themselves or explicitly
check for a missing name.

> However, this patch only fixes the crash issue. ctfconvert will still fail
> and
> complains "unresolved types" when invoked on devd (or other C++ objects)
> The problem is that ctfconvert doesn't understand any C++ DWARF types,
> for example: class, namespace, templates etc. Then I checked the Dtrace
> CTF format:
>
> sys/cddl/contrib/opensolaris/uts/common/sys/ctf.h
>
> It seems to me that CTF can only support ANSI C ? Did anyone ever use
> Dtrace with C++ program and get debugging info?

You are correct, CTF only supports ANSI C.  However, people have
historically used it on C++ programs via pid and USDT probes.  Non-POD
C++ objects are not directly supported, although it is possible to
access their data via pointers and pointer arithmetic.

See, for example:
http://www.oracle.com/technetwork/server-storage/solaris/dtrace-cc-138561.html
(dated February 2005)

Illumos uses the LGPL'd libdwarf, so I assume that is why it works for
them to the extent that it does.  I think there are probably also bugs
in our port of CTF.  I think that on FreeBSD, we should at least get
ctfconvert to store whatever CTF data it can in C++ object files,
instead of crashing or bailing out with errors.  I think proper C++
support would require quite a bit of additional work in the DTrace
stack, and should be considered a separate project.

Thanks!
--Will.