From owner-freebsd-dtrace@FreeBSD.ORG Thu Oct 17 15:40:20 2013 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 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 2594F287; Thu, 17 Oct 2013 15:40:20 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qa0-x22e.google.com (mail-qa0-x22e.google.com [IPv6:2607:f8b0:400d:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B7C8A2B3D; Thu, 17 Oct 2013 15:40:19 +0000 (UTC) Received: by mail-qa0-f46.google.com with SMTP id j15so5623489qaq.19 for ; Thu, 17 Oct 2013 08:40:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=4s+M9XlZ6rB4ZqGkRCqOytn9/l7h7YEhLdsYB59h0O8=; b=LZx5ZJGI80mj/OUMeKbwdnaRjZAUZ+zRWaKwMk7ReRuJTZBjsyVeI9+9Y9sYMZrBb3 k73V9Dfw9YXshCI189eSsCFvnxp5qhEV6x2Tja2zk8O/zhTBcLXBa6gCfIm+q22HHEOc 9EVJkz1lqoP9h+ZBVbH2wxiGwvuoqsgZGB3dF3in6TjcWKBf2/SVM3I8Q6nm4CPMqpZY njRW7mChUEvTFeIRMOR0FX7UYOdQ5D+TkxY0naSQW5YCD8WQtgXuRjAOK1STYEKdO/gq Oh4gYlpFOsCv0f/WQTaUl/Q5IZ32TI68fLxXzDmv1yuNK0XdfB2i95P/pQiF8d95Z5fH nbRA== X-Received: by 10.49.76.6 with SMTP id g6mr4850840qew.41.1382024418866; Thu, 17 Oct 2013 08:40:18 -0700 (PDT) Received: from charmander.sandvine.com ([64.7.137.182]) by mx.google.com with ESMTPSA id n7sm179965300qai.1.1969.12.31.16.00.00 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 17 Oct 2013 08:40:18 -0700 (PDT) Sender: Mark Johnston Date: Thu, 17 Oct 2013 11:40:03 -0400 From: Mark Johnston To: Andriy Gapon Subject: Re: dtrace -c doesn't work? Message-ID: <20131017154003.GA2926@charmander.sandvine.com> References: <20131015233219.GZ56872@funkthat.com> <20131017033400.GA31544@charmander> <525F8E64.4020105@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <525F8E64.4020105@FreeBSD.org> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: John-Mark Gurney , Konstantin Belousov , freebsd-dtrace@FreeBSD.org X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.14 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: Thu, 17 Oct 2013 15:40:20 -0000 On Thu, Oct 17, 2013 at 10:14:44AM +0300, Andriy Gapon wrote: > on 17/10/2013 06:34 Mark Johnston said the following: > > My guess is that the /bin/echo on your system is stripped. dtrace(1) on > > FreeBSD will set a breakpoint on main() in the victim process and > > register the script with the kernel when that breakpoint fires. If > > libproc can't find the address of main(), the breakpoint won't fire, and > > your script won't run. If /bin/echo isn't stripped, your example works > > properly on my laptop. Adding '-x evaltime=postinit' to the dtrace(1) > > flags should also allow the script to run properly. > > > > avg@ tried to fix this a little while ago by changing dtrace to > > instead put a breakpoint on r_debug_state in rtld (r248644). This works > > for your example, but breaks USDT since that breakpoint apparently fires > > before ELF ctors run, and thus before dtrace_dof_init() can run (which is > > needed for USDT to work). > > That's exactly what happened. > My idea of fixing that was to move r_debug_state call to after preinit_main. > But Kostik told me that that was a terrible idea. Unfortunately I can't recall > right now why. I suppose this would make it impossible to use gdb to step through init functions? > I've been meaning to restore my knowledge and memory of the code > and discuss the issue again. > > > I'm not sure what the best way to fix this is. Perhaps we could add a > > second breakpoint to rtld for use by dtrace, or maybe there's some way > > to set a breakpoint on the DOF init code. > > Kostik also suggested this. You mean adding a second breakpoint function to rtld? Perhaps something like r_debug_state_postinit(), called after objlist_call_init(). -Mark