From owner-freebsd-dtrace@FreeBSD.ORG Fri Jan 30 06:14:02 2015 Return-Path: Delivered-To: freebsd-dtrace@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 00560A65 for ; Fri, 30 Jan 2015 06:14:01 +0000 (UTC) Received: from mail-pa0-x22b.google.com (mail-pa0-x22b.google.com [IPv6:2607:f8b0:400e:c03::22b]) (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 C33127F3 for ; Fri, 30 Jan 2015 06:14:01 +0000 (UTC) Received: by mail-pa0-f43.google.com with SMTP id eu11so48450089pac.2 for ; Thu, 29 Jan 2015 22:14:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:subject:message-id:mime-version:content-type :content-disposition:user-agent; bh=K1zyLU2KjJPeLL/v8znRtdFizz5iapklAGr8x8JZmdc=; b=yTXz5IYFl9rwu9/u9nHFR8S41rY4eyN8D63UTe0ckKszGjG70NgHdU9q/041yupWw8 /FEqLZsv9XisqR+G3ow9PRD+UcvsVNjpLEMvHMiFgXTyJLS1CR3zF13Cce9zr0KciKhx S1qrUCRVYg7aXoN91Zykp6NKOJHSKbviUZhL31x6xybORBZRsglDMpni8PQEh7MjBhgb e1SBx2pNFvAkyBSL6wYx9cR7BrPCLRPf35Q8DkRyE7GS6ds0DSwDjGptTw6QIhQHgJuN i1D3SB/yFdN6femlE3Y0M3ep5LGjrXJLKatZ+KoGTO3hDhf/NkBZlB2H17zXxyd4wNVl 0kdg== X-Received: by 10.66.66.68 with SMTP id d4mr6687146pat.44.1422598441401; Thu, 29 Jan 2015 22:14:01 -0800 (PST) Received: from raichu (216-243-33-197.users.condointernet.net. [216.243.33.197]) by mx.google.com with ESMTPSA id or4sm9683857pab.30.2015.01.29.22.13.59 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Jan 2015 22:14:00 -0800 (PST) Sender: Mark Johnston Date: Thu, 29 Jan 2015 22:13:55 -0800 From: Mark Johnston To: freebsd-dtrace@freebsd.org Subject: removing USDT's libelf dependency Message-ID: <20150130061355.GA14037@raichu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: "A discussion list for developers working on DTrace in FreeBSD." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jan 2015 06:14:02 -0000 Hello, At the moment, any FreeBSD program containing USDT probes needs to be linked with libelf. This is so that drti.o can find the address of the DOF section within the executable or library. With this, it can extract the DOF and load it into the kernel prior to beginning execution. This requirement is an annoyance since it's specific to FreeBSD and many upstream projects which support DTrace aren't aware of it, so some patching is necessary to get their probes working on FreeBSD. It also increases the startup cost of programs containing USDT probes, which can be significant for e.g. sh(1) or libc/libthr (plockstat). Solaris exploits a feature of its linker to solve this problem - the dtrace -G step emits an object file containing a symbol called __SUNW_dof; the linker knows to fill in the value of this symbol with the address of the DOF section, so drti.o begins execution with the DOF section already available. It turns out that GNU ld implements a similar feature, albeit in a more restrictive manner: a symbol named __start_ will have its value filled in with the address of the section named . The catch is that has to be a valid C identifier, and the DOF section is conventionally named ".SUNW_dof", which of course doesn't quite work. I propose using "SUNW_dof" instead so that we can make use of this linker feature and eliminate the libelf dependency. DOF sections have their own ELF section type (SHT_SUNW_dof), so anything that might want to find a DOF section should already be searching for that rather than the conventional name. Depending on this linker feature is also arguably a portability concern given that lld is on the horizon, but we depend on it already anyway - this feature is used in FreeBSD's linker set implementation (which in turn is used by our SDT code :). So I don't think this would introduce a new problem. Any thoughts? Thanks, -Mark