Date: Thu, 2 Oct 2014 07:18:18 -0600 From: Will Andrews <will@firepipe.net> To: Kai Wang <kaiw27@gmail.com> Cc: Justin Gibbs <gibbs@freebsd.org>, jkoshy@freebsd.org, freebsd-toolchain@freebsd.org, Dimitry Andric <dim@freebsd.org> Subject: Re: elftoolchain update? Message-ID: <CADBaqmirbEHuL0%2Bg2aNWLJKsHqr_pK=y%2BxbGrFQZdFeM5XPT4w@mail.gmail.com> In-Reply-To: <CAMf2Fe7F-1D6=7xE6toj=H7r2-PEy9RnAZHwtST5s5Etn2-7GA@mail.gmail.com> References: <CADBaqmgasfbP6r09yAsmrw-eVHqm3AWSuBdA5tHf5U5rj8j2HA@mail.gmail.com> <D44FDBD9-F6AF-48B1-A467-9C51C685E750@FreeBSD.org> <CAMf2Fe7F-1D6=7xE6toj=H7r2-PEy9RnAZHwtST5s5Etn2-7GA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Kai, Thanks for checking in. On Thu, Oct 2, 2014 at 3:11 AM, Kai Wang <kaiw27@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADBaqmirbEHuL0%2Bg2aNWLJKsHqr_pK=y%2BxbGrFQZdFeM5XPT4w>