From owner-freebsd-toolchain@FreeBSD.ORG Thu Oct 2 13:18:20 2014 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8D981EEC for ; Thu, 2 Oct 2014 13:18:20 +0000 (UTC) Received: from mail-qa0-f41.google.com (mail-qa0-f41.google.com [209.85.216.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4BC35FDC for ; Thu, 2 Oct 2014 13:18:19 +0000 (UTC) Received: by mail-qa0-f41.google.com with SMTP id n8so1762015qaq.28 for ; Thu, 02 Oct 2014 06:18:18 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ZslzI68vttYMig97G9LxzKcgwjvHYHt/chJL+SgOXcw=; b=jI2IqL41XBVDn4ImQB+fE1432NajuIjgl/yDGU0hsElPGmwkqErogll5CHbxj7htvs 6m94seeMZgnKDNJXfZ9sQWlMqXbiysXSDE5FJbxL7BEbIBe/0Mu9Qdihn1QcsLpvfNul rTgfGSHO0XjpaLddnckjaTBageaf/38Rcrx/gBiXBiXtf2wz/2PKbjoqjZ1tDEZ7X2Xc x9U4UbFTFku0krRHQeSe6B7W7izei0bzXFnxXBIkUOfgikpllwqd4qichBHBwOEUetO+ Utx81+N/D7Cz0uGAz7dhc1mscep5CXegY/dv9B/guACh+IOBZXBm2yHVpyQn0hiWrkXA mwkg== X-Gm-Message-State: ALoCoQmC6F2+PNI5y4LlQoqwFEdQ8q0yOXMsi7fKX4lksKrChcmS+1RXRrM+guiCDPZ5zeRCCJJg MIME-Version: 1.0 X-Received: by 10.140.106.130 with SMTP id e2mr2602364qgf.21.1412255898763; Thu, 02 Oct 2014 06:18:18 -0700 (PDT) Received: by 10.140.31.36 with HTTP; Thu, 2 Oct 2014 06:18:18 -0700 (PDT) In-Reply-To: References: Date: Thu, 2 Oct 2014 07:18:18 -0600 Message-ID: Subject: Re: elftoolchain update? From: Will Andrews To: Kai Wang Content-Type: text/plain; charset=UTF-8 Cc: Justin Gibbs , jkoshy@freebsd.org, freebsd-toolchain@freebsd.org, Dimitry Andric X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 13:18:20 -0000 Hi Kai, Thanks for checking in. On Thu, Oct 2, 2014 at 3:11 AM, Kai Wang 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.