From owner-freebsd-dtrace@FreeBSD.ORG Fri Jan 30 15:15:31 2015 Return-Path: Delivered-To: freebsd-dtrace@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 41CADF2E; Fri, 30 Jan 2015 15:15:31 +0000 (UTC) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (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 F09EF926; Fri, 30 Jan 2015 15:15:30 +0000 (UTC) Received: by mail-qg0-f52.google.com with SMTP id z107so38540851qgd.11; Fri, 30 Jan 2015 07:15:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=kVL0vvEVrqXwfE1k4spDvWI9vZI6BtxuKdSty/F90NA=; b=OEKRqKXaQOABCVKvlQUzkZAayobqVeSKka0LX7T2ur9JUJ3BknkEghHSG5hSU4FIKt ZMPHqIDZeul12ufgGUvb4CJyKxOn+VDsYzEMJGMydOIrgwPiR2Smf2sTsFZjZvHbHwW6 FgF+dWXOJYovz+wJ01cadszhFdh4uBfho+TQs1kH3uuPk+TALPdODD5brwLfzgREJitl GR1xrqx7lRjjV3fZZOBvmAcoA2q1EIAnFGYNL7xCaWQdupqgk+EngTwJRsZ+wkgZazOj g7oa4NxvREeh9/ns6N9necslPcCSGL0AcVqwgJJiYWh+Wsou0iJmtMgdOH+ekbfb2s8p wKeQ== X-Received: by 10.224.30.145 with SMTP id u17mr13202732qac.46.1422630930156; Fri, 30 Jan 2015 07:15:30 -0800 (PST) MIME-Version: 1.0 Sender: carpeddiem@gmail.com Received: by 10.140.39.209 with HTTP; Fri, 30 Jan 2015 07:15:09 -0800 (PST) In-Reply-To: <20150130061355.GA14037@raichu> References: <20150130061355.GA14037@raichu> From: Ed Maste Date: Fri, 30 Jan 2015 10:15:09 -0500 X-Google-Sender-Auth: lcW8pfKmHUBiKj5zfCpasIJo16w Message-ID: Subject: Re: removing USDT's libelf dependency To: Mark Johnston Content-Type: text/plain; charset=UTF-8 Cc: freebsd-dtrace@freebsd.org 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 15:15:31 -0000 On 30 January 2015 at 01:13, Mark Johnston wrote: > > 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. I'm not worried about issues with lld here - we can make it meet our requirements. I am a little worried that there will be code floating around that does strcmp(foo, ".SUNW_dof") though. A quick search turned up some examples. Most are copies of drti.c but I did find one case in some markjdb Github repo :-) Even if we don't end up changing .SUNW_dof I think we should convert these cases to use the section type instead of name. We could give GNU ld 2.17.50 and lld knowledge of .SUNW_dof and __SUNW_dof. This looks like it would be straightforward, but at the cost of carrying around different FreeBSD-specific changes. I think our best approach will be to find an approach that upstream linker projects (GNU ld, gold, lld) are willing to support. But, until or unless that happens I'd much rather we switch to SUNW_dof than require linking against libelf.