Improve ctfconvert handling of C++ object files.

[will]

Summary

This is an amalgamation of several fixes:

• Undo the default empty string in die_name(); this syncs with upstream. Many things check the return of die_name() for NULL and these cases must trigger or else other bugs will occur.
• die_sou_resolve(): Rather than crash, consider a SOU as unresolvable if its type descriptor references a currently unknown DIE. The top-level will retry until it either finds the type or it will bail.
• die_function_create():
  • Don't require function arguments to have names. C/C++ don't require this, and CTF doesn't care if there isn't one, because it already has arg0/arg1/.../argN and args.
  • Ensure that the variadic argument can't be reached in the second loop.
  • Emit the 'function has %d arguments' debug message even if the function had no arguments, for information purposes and also inform whether the function is variadic.

Test Plan

Run ctfconvert on sbin/devd/devd.cc's object file, note that it still exits
with an error, but does not crash. This checkin is intended as a step
forward, not a full solution.

[markj]

cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c

990

Shouldn't this be

if ((ml->ml_name = die_name(dw, mem)) == NULL)
    ml->ml_name = xstrdup("");

? I see some code in merge.c that expects ml_name to be non-NULL.

(Note that upstream omits the xstrdup call, but that's almost certainly a bug.)

1641

Sorry, I'm a bit confused by this. Is this meant to be a temporary workaround?

[emaste]

ping?

[will]

I don't remember much of the context of this, but apparently I have some unsubmitted comments (probably made nearly 3 years ago).
IIRC, I eventually concluded that running ctfconvert on C++ was a bit of a fool's errand, since DTrace doesn't support C++ symbols, and AFAIK that hasn't changed. You have to use the mangled symbol names to dtrace C++.
I'm fine with dropping this Diff.

cddl/contrib/opensolaris/tools/ctf/cvt/dwarf.c

990

It does look like equiv_su() requires ml->ml_name to be non-NULL. Need to audit callers of die_name() to see if there are other cases.

1641

No, it's effectively an assert. It's a safeguard; it ensures that the loop below doesn't have to check for varargs.

[will]

Dropping this for lack of interest.