From owner-freebsd-dtrace@FreeBSD.ORG Mon Feb 24 03:08:43 2014 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 ESMTPS id D1AC1711 for ; Mon, 24 Feb 2014 03:08:43 +0000 (UTC) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9994A15CE for ; Mon, 24 Feb 2014 03:08:43 +0000 (UTC) Received: by mail-ig0-f181.google.com with SMTP id y6so3781913igj.2 for ; Sun, 23 Feb 2014 19:08:43 -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=rDOEl+4OXTZ0yA+RCqaOYSpIhXeOUzS70vRh8BQPlqQ=; b=GLj5d5wrJT+OK27tc8GBZo9ZcqBxh8l3g1iukmQLYArvcNxKsrpJTkmCV2vE83n+g9 eQHCTyazXkDrBM0evEk7kt3/y+Gf5tYxobCGQDG/zy4f45diKyonouKqpkuhkVJez8gy x3rzUzfmYGxozyW+daf4U9VnmeIgsCDh8YbOZEM9mubR5loqY2djwMK52F31gOnQJojQ wlRDsWNgibj2WhuXW9ngC7mQ+shjS8h5uqJUYTT4FKMeR9VIsOihIE4DYahWIkkRUvyc Vy6nSbI9yRt7kxbXuMf0OJvgadx9bfY6rGV/JwJgOcqxTVpZlAl8lAcltWeKuIFCGpc5 pKAA== X-Received: by 10.43.137.5 with SMTP id im5mr12532258icc.55.1393211323084; Sun, 23 Feb 2014 19:08:43 -0800 (PST) Received: from raichu (198-84-185-216.cpe.teksavvy.com. [198.84.185.216]) by mx.google.com with ESMTPSA id m4sm22102437ige.0.2014.02.23.19.08.41 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 23 Feb 2014 19:08:42 -0800 (PST) Sender: Mark Johnston Date: Sun, 23 Feb 2014 22:08:37 -0500 From: Mark Johnston To: freebsd-dtrace@freebsd.org Subject: [patch] enable interrupts before calling fasttrap handlers Message-ID: <20140224030837.GA2720@raichu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.22 (2013-10-16) X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.17 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: Mon, 24 Feb 2014 03:08:43 -0000 Hello, The patch here fixes a problem I've run into while doing some work on fasttrap: http://people.freebsd.org/~markj/patches/breakpoint_intr_enable.diff Specifically, we currently call fasttrap_pid_probe() with interrupts disabled because FreeBSD handles breakpoints through an interrupt gate and doesn't enable interrupts before calling trap(). The patch changes trap() on i386 and amd64 to enable interrupts after hitting a breakpoint if the trap came from usermode. fasttrap should only handle traps from user mode anyway, and the user mode handler for breakpoints already enables interrupts immediately, so the change shouldn't have any effect for breakpoints unrelated to DTrace. The problem with leaving interrupts disabled is that some pid provider probes require DTrace to modify userland memory in fasttrap_pid_probe(), i.e. by calling proc_rwmem() or copyout(). It turns out that this can cause nasty deadlocks if another thread attempts a TLB shootdown with the same pmap as that of the traced process. There are probably other issues as well, but this is the one that I've run into. Would anyone be able to review and/or test this diff? Thanks, -Mark From owner-freebsd-dtrace@FreeBSD.ORG Mon Feb 24 04:14:58 2014 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 ESMTPS id 7EE323D4 for ; Mon, 24 Feb 2014 04:14:58 +0000 (UTC) Received: from mail-ie0-x232.google.com (mail-ie0-x232.google.com [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 4B64E1C75 for ; Mon, 24 Feb 2014 04:14:58 +0000 (UTC) Received: by mail-ie0-f178.google.com with SMTP id ar20so3118900iec.9 for ; Sun, 23 Feb 2014 20:14:57 -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=oBJ9GslXJjBhDUkGWhA1IVj/eNb0adPnRKwWkuoEfyM=; b=zkEZtwBuyaKe9fNMdGCaeiIXMlj2UkeRNjJuRMAFQW1fEgAlH2NWVZfuuvl2vantam B05PICoF+pQMB2ebrcZdMB0wq6qgfxJ6Kc5EUYuC7L2EPRMi4kyLRJpfcV0RTyD9+Sul Hitt8JZHiBR1AwlK/Gk+9y1vixLZsW3LPYmrnImWOWO4NEc5EXfGqmKr7nmGpdLt+Ple kbS9s9EN6G0E0+nDI0YnHKfislEP2Hbe0twxi6RjvhBLJ+F+mByBb4rgOYoZATbl/tfH jegHTx6SO8qPjKTSF5d93m3tUt7OXmRtFxQXV1zP6jYSJXOVohSOZdrChlZiFc6ak5i1 hq2Q== X-Received: by 10.43.156.18 with SMTP id lk18mr12665050icc.77.1393215297307; Sun, 23 Feb 2014 20:14:57 -0800 (PST) Received: from raichu (198-84-185-216.cpe.teksavvy.com. [198.84.185.216]) by mx.google.com with ESMTPSA id iq9sm22621488igb.7.2014.02.23.20.14.56 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 23 Feb 2014 20:14:56 -0800 (PST) Sender: Mark Johnston Date: Sun, 23 Feb 2014 23:14:54 -0500 From: Mark Johnston To: freebsd-dtrace@freebsd.org Subject: [patch] fasttrap process scratch space Message-ID: <20140224041454.GB2720@raichu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.22 (2013-10-16) X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.17 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: Mon, 24 Feb 2014 04:14:58 -0000 Hello, For those not familiar with MD parts of fasttrap, one of the things it has to do is ensure that any userland instruction that it replaces with a breakpoint gets executed in the traced process' context. For several common classes of instructions, fasttrap will emulate the instruction in the breakpoint handler; when it can't do that, it copies the instruction out to some scratch space in the process' address space and sets the PC of the interrupted thread to the address of that instruction, which is followed by a jump to the instruction following the breakpoint. There's a helpful block comment titled "Generic Instruction Tracing" around line 1585 of the x86 fasttrap_isa.c which describes the details of this. This functionality currently doesn't work on FreeBSD, mainly because we don't necessarily have any (per-thread) scratch space available for use in the process' address space. In illumos/Solaris, a small (< 64 byte) block is reserved in each thread's TLS for use by DTrace. It turns out that doing the same thing on FreeBSD is quite easy: http://people.freebsd.org/~markj/patches/fasttrap_scratch_hacky.diff Specifically, we need to ensure that TLS (allocated by the runtime linker) is executable and that we properly extract the offset to the scratch space from the FS segment register. I think this is somewhat hacky though, as it creates a dependency on libthr and rtld internals. A second approach is to have fasttrap dynamically allocate scratch space within the process' address space using vm_map_insert(9). My understanding is that Apple's DTrace implementation does this, and I've implemented this approach for FreeBSD here (which was done without referencing Apple code): http://people.freebsd.org/~markj/patches/fasttrap-scratch-space/fasttrap-scratch-space-1.diff The idea is to map pages of executable memory into the user process as needed, and carve them into scratch space chunks for use by individual threads. If a thread in fasttrap_pid_probe() needs scratch space, it calls a new function, fasttrap_scraddr(). If the thread already has scratch space allocated to it, it's used. Otherwise, if any free scratch space chunks are available in an already-mapped page, one of them is allocated to the thread and used. Otherwise, a new page is mapped using vm_map_insert(9). Threads hold onto their scratch space until they exit. That is, scratch space is never unmapped from the process, even if the controlling dtrace(1) process detaches. I added a handler for thread_dtor event which re-adds any scratch space held by the thread to the free list for that process. Per-process scratch space state is held in the fasttrap process handle (fasttrap_proc_t), since that turns out to be much easier than keeping it in the struct proc. Does anyone have any thoughts or comments on the approach or the patch? Any review or testing would be very much appreciated. For testing purposes, it's helpful to know that tracing memcpy() on amd64 will result in use of this scratch space code, as it starts with a "mov %rdi,%rax" on my machine at least. My main test case has been to run something like # dtrace -n 'pid$target:libc.so.7::entry {@[probefunc] = count()}' -p $(pgrep firefox) Attempting to trace all functions still results in firefox dying with SIGTRAP, but we're getting there. :) Thanks, -- -Mark From owner-freebsd-dtrace@FreeBSD.ORG Mon Feb 24 04:22:50 2014 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 ESMTPS id ED85E4F5 for ; Mon, 24 Feb 2014 04:22:50 +0000 (UTC) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B917E1D1B for ; Mon, 24 Feb 2014 04:22:50 +0000 (UTC) Received: by mail-ie0-f181.google.com with SMTP id rl12so3071903iec.40 for ; Sun, 23 Feb 2014 20:22:50 -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:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=hSKgBnotm9G1cMtSpQE4ArlixGdU9yI0Pl6xGSnKvuM=; b=A6EwDIwhikBGqlYSg3FgCDyvFK0VClEBoDWfXDdxs3WrV+FYCeEq6mXpV0sXf8O3lY DdoXBXLTyLtdokWx6DlSkLFqNxLjBMgpblcQ5kMS0v+nyCLzf45GG73/UbRDKQP+S/ue F+dUCx4hs5ILd9HkDY311nIc1Ry+hixnII/qX0aBS21uzrIK4iQrb7XNldwfWp3Zotuw Y/LPu4clxb9HGmNfrue1PhIq375oPO0M/bbhvL99ZngjTr7CXucBgLZUqh2cHnaiThLr LrSBE7PgoN6Xos2KQ6vdlwnC9MicHi4VBr92c12OKGjR4P3t6J9LWTLxP1FoJM+WupwY Jv5A== X-Received: by 10.50.153.79 with SMTP id ve15mr12025890igb.40.1393215770210; Sun, 23 Feb 2014 20:22:50 -0800 (PST) Received: from raichu (198-84-185-216.cpe.teksavvy.com. [198.84.185.216]) by mx.google.com with ESMTPSA id dz8sm22680708igb.5.2014.02.23.20.22.49 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 23 Feb 2014 20:22:49 -0800 (PST) Sender: Mark Johnston Date: Sun, 23 Feb 2014 23:22:47 -0500 From: Mark Johnston To: freebsd-dtrace@freebsd.org Subject: Re: [patch] fasttrap process scratch space Message-ID: <20140224042247.GC2720@raichu> References: <20140224041454.GB2720@raichu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140224041454.GB2720@raichu> User-Agent: Mutt/1.5.22 (2013-10-16) X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.17 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: Mon, 24 Feb 2014 04:22:51 -0000 On Sun, Feb 23, 2014 at 11:14:54PM -0500, Mark Johnston wrote: > Hello, > > For those not familiar with MD parts of fasttrap, one of the things it > has to do is ensure that any userland instruction that it replaces with > a breakpoint gets executed in the traced process' context. For several > common classes of instructions, fasttrap will emulate the instruction in > the breakpoint handler; when it can't do that, it copies the instruction > out to some scratch space in the process' address space and sets the PC > of the interrupted thread to the address of that instruction, which is > followed by a jump to the instruction following the breakpoint. There's > a helpful block comment titled "Generic Instruction Tracing" around line > 1585 of the x86 fasttrap_isa.c which describes the details of this. > > This functionality currently doesn't work on FreeBSD, mainly because we > don't necessarily have any (per-thread) scratch space available for use > in the process' address space. In illumos/Solaris, a small (< 64 byte) > block is reserved in each thread's TLS for use by DTrace. It turns out > that doing the same thing on FreeBSD is quite easy: > > http://people.freebsd.org/~markj/patches/fasttrap_scratch_hacky.diff > > Specifically, we need to ensure that TLS (allocated by the runtime > linker) is executable and that we properly extract the offset to the > scratch space from the FS segment register. I think this is somewhat > hacky though, as it creates a dependency on libthr and rtld internals. > > A second approach is to have fasttrap dynamically allocate scratch space > within the process' address space using vm_map_insert(9). My > understanding is that Apple's DTrace implementation does this, and I've > implemented this approach for FreeBSD here (which was done without > referencing Apple code): > > http://people.freebsd.org/~markj/patches/fasttrap-scratch-space/fasttrap-scratch-space-1.diff > > The idea is to map pages of executable memory into the user process as > needed, and carve them into scratch space chunks for use by individual > threads. If a thread in fasttrap_pid_probe() needs scratch space, it > calls a new function, fasttrap_scraddr(). If the thread already has > scratch space allocated to it, it's used. Otherwise, if any free scratch > space chunks are available in an already-mapped page, one of them is > allocated to the thread and used. Otherwise, a new page is mapped using > vm_map_insert(9). > > Threads hold onto their scratch space until they exit. That is, scratch > space is never unmapped from the process, even if the controlling > dtrace(1) process detaches. I added a handler for thread_dtor event > which re-adds any scratch space held by the thread to the free list for > that process. Per-process scratch space state is held in the fasttrap > process handle (fasttrap_proc_t), since that turns out to be much easier > than keeping it in the struct proc. > > Does anyone have any thoughts or comments on the approach or the patch? > Any review or testing would be very much appreciated. > > For testing purposes, it's helpful to know that tracing memcpy() on > amd64 will result in use of this scratch space code, as it starts with a > "mov %rdi,%rax" on my machine at least. My main test case has been to > run something like > > # dtrace -n 'pid$target:libc.so.7::entry {@[probefunc] = count()}' -p $(pgrep firefox) > > Attempting to trace all functions still results in firefox dying with > SIGTRAP, but we're getting there. :) I should probably add that the diff described here should also be applied when testing: http://lists.freebsd.org/pipermail/freebsd-dtrace/2014-February/000175.html Otherwise it's quite easy to trigger deadlocks. -Mark From owner-freebsd-dtrace@FreeBSD.ORG Mon Feb 24 17:51:14 2014 Return-Path: Delivered-To: freebsd-dtrace@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A2626E8F for ; Mon, 24 Feb 2014 17:51:14 +0000 (UTC) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 641D512D0 for ; Mon, 24 Feb 2014 17:51:14 +0000 (UTC) Received: by mail-ob0-f169.google.com with SMTP id wn1so2371885obc.28 for ; Mon, 24 Feb 2014 09:51:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphix.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=wCtQ8yt1s3bNgXTsyxWmnO7fU01wd1zFaSfGaLIq070=; b=ZFG6NlJTn0yolfM0RBHInFZ+qTkirjPJzHQrWYgw5sBFEm1ornfUxW9wXkMy3KBeR/ s4RgOeOuwK1Gjhd0RQdy5JCpROBO3AnUpUMGWHEsTWN826GYlopnJSMTfuNJiz2b9UMj xx75FJ80q7naRnizwDVD8VedU9jrYf24hK8jA= 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=wCtQ8yt1s3bNgXTsyxWmnO7fU01wd1zFaSfGaLIq070=; b=PBdDl0Jmqmw99shVu6vyDQysQBYUIeC3plIAaMnv80YpOyrHH2Y3P2h2brysw9AXwY QkGC4/8HRj4y1dGDeumLtj50n9kkeg9/4iCFKprNTGjQL2fg0BAJWEkjN7oYKUAW3kwf Mj7s6lfL1RWY9qmhmFjhT19Kkj+hNTV5bWvdVl2VOLO1sfxENnUQbh8EuJdEFjbSGpP5 CNPTsR6ZiakEbNhR3QNBHIM5BYQri9fm4GGz5d/PIMaLSUW53+2MdAVhG+Xy4zCJ/N0b Vj3oTh2VN7n/VXgG2vWWtG2uedclMADy2n7+0pp6Q/yiSwKdRfsIdNs2B59uNquD1kf3 lLKQ== X-Gm-Message-State: ALoCoQmRd4rIKmPl2f8FzXtgnq1J8squ6sJMdlE1SuedAB9/8X5wk9JNq9pqeQ+Enp2MwhQveXhB MIME-Version: 1.0 X-Received: by 10.60.134.200 with SMTP id pm8mr22315862oeb.40.1393264273430; Mon, 24 Feb 2014 09:51:13 -0800 (PST) Received: by 10.76.169.106 with HTTP; Mon, 24 Feb 2014 09:51:13 -0800 (PST) In-Reply-To: <20140224041454.GB2720@raichu> References: <20140224041454.GB2720@raichu> Date: Mon, 24 Feb 2014 09:51:13 -0800 Message-ID: Subject: Re: [patch] fasttrap process scratch space From: Adam Leventhal To: Mark Johnston Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-dtrace@freebsd.org X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.17 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: Mon, 24 Feb 2014 17:51:14 -0000 Hey Mark, I wanted to provide a little historical perspective when considering the options of a pact with libc/libthread/ld.so.1 vs. the kernel mapping pages for TLS. We considered both but chose the former in Solaris. Solaris/OpenSolaris/illumos have the kernel, libc, and ld.so.1 in the same repository. There are already dependencies between those components, so adding another was not a concern. We felt that having DTrace map pages into the traced process could have a more significant impact on its execution, and we wanted to minimize the chance that DTrace would chase away the very problem users were trying to investigate. Further, we felt that the failure modes would be less clean; for example, in your patch if we fail to map a page while in fasttrap_pid_probe(), we're forced to silently remove the instrumentation. Hope that's helpful. Adam On Sun, Feb 23, 2014 at 8:14 PM, Mark Johnston wrote: > Hello, > > For those not familiar with MD parts of fasttrap, one of the things it > has to do is ensure that any userland instruction that it replaces with > a breakpoint gets executed in the traced process' context. For several > common classes of instructions, fasttrap will emulate the instruction in > the breakpoint handler; when it can't do that, it copies the instruction > out to some scratch space in the process' address space and sets the PC > of the interrupted thread to the address of that instruction, which is > followed by a jump to the instruction following the breakpoint. There's > a helpful block comment titled "Generic Instruction Tracing" around line > 1585 of the x86 fasttrap_isa.c which describes the details of this. > > This functionality currently doesn't work on FreeBSD, mainly because we > don't necessarily have any (per-thread) scratch space available for use > in the process' address space. In illumos/Solaris, a small (< 64 byte) > block is reserved in each thread's TLS for use by DTrace. It turns out > that doing the same thing on FreeBSD is quite easy: > > http://people.freebsd.org/~markj/patches/fasttrap_scratch_hacky.diff > > Specifically, we need to ensure that TLS (allocated by the runtime > linker) is executable and that we properly extract the offset to the > scratch space from the FS segment register. I think this is somewhat > hacky though, as it creates a dependency on libthr and rtld internals. > > A second approach is to have fasttrap dynamically allocate scratch space > within the process' address space using vm_map_insert(9). My > understanding is that Apple's DTrace implementation does this, and I've > implemented this approach for FreeBSD here (which was done without > referencing Apple code): > > http://people.freebsd.org/~markj/patches/fasttrap-scratch-space/fasttrap-scratch-space-1.diff > > The idea is to map pages of executable memory into the user process as > needed, and carve them into scratch space chunks for use by individual > threads. If a thread in fasttrap_pid_probe() needs scratch space, it > calls a new function, fasttrap_scraddr(). If the thread already has > scratch space allocated to it, it's used. Otherwise, if any free scratch > space chunks are available in an already-mapped page, one of them is > allocated to the thread and used. Otherwise, a new page is mapped using > vm_map_insert(9). > > Threads hold onto their scratch space until they exit. That is, scratch > space is never unmapped from the process, even if the controlling > dtrace(1) process detaches. I added a handler for thread_dtor event > which re-adds any scratch space held by the thread to the free list for > that process. Per-process scratch space state is held in the fasttrap > process handle (fasttrap_proc_t), since that turns out to be much easier > than keeping it in the struct proc. > > Does anyone have any thoughts or comments on the approach or the patch? > Any review or testing would be very much appreciated. > > For testing purposes, it's helpful to know that tracing memcpy() on > amd64 will result in use of this scratch space code, as it starts with a > "mov %rdi,%rax" on my machine at least. My main test case has been to > run something like > > # dtrace -n 'pid$target:libc.so.7::entry {@[probefunc] = count()}' -p $(pgrep firefox) > > Attempting to trace all functions still results in firefox dying with > SIGTRAP, but we're getting there. :) > > Thanks, > -- > -Mark > _______________________________________________ > freebsd-dtrace@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-dtrace > To unsubscribe, send any mail to "freebsd-dtrace-unsubscribe@freebsd.org" -- Adam Leventhal CTO, Delphix http://blog.delphix.com/ahl From owner-freebsd-dtrace@FreeBSD.ORG Tue Feb 25 01:31:23 2014 Return-Path: Delivered-To: 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 ESMTPS id 9CB05A0A; Tue, 25 Feb 2014 01:31:23 +0000 (UTC) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 54B501E0C; Tue, 25 Feb 2014 01:31:23 +0000 (UTC) Received: by mail-ig0-f181.google.com with SMTP id y6so171434igj.2 for ; Mon, 24 Feb 2014 17:31:22 -0800 (PST) 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=QHfDELhbtck0TOpNz03J2oU7l1mTsFSgmvaZRvHIZks=; b=KKKrUW1ECDXta8JoYgBBbdqJDCN043TDxIXNwzepBsbGVrBYteYx5MLiYnxStOvV9I 69LGA1ThtP/VXbCjHccro/bP8M3oT5SdZXQKJCSQKIq+oxp1fo3Zmymf1Tn/q0ZuPBWp 3WhVZHhFoOi3+J5oO0iT9V3Tmo0JCKnXhsOtCH4rg4Qd/rzAn2TXrf5KvHxVnOEofr6i fjx779VthKOIYAhpc4Pylv8l/WWn4RDUETXyQbecAv3pYLGBBm0x+WT2QH2qxGyYPSyo iDECksYxhJxcWjD+hebY6Jp+jCDFLcySBVIsN7fONA/ALldD6bL5iA/9PuFJHFZRP+PT fAdQ== X-Received: by 10.42.41.82 with SMTP id o18mr16601163ice.50.1393291881236; Mon, 24 Feb 2014 17:31:21 -0800 (PST) Received: from raichu (198-84-185-216.cpe.teksavvy.com. [198.84.185.216]) by mx.google.com with ESMTPSA id r6sm32261081igg.10.2014.02.24.17.31.20 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Feb 2014 17:31:20 -0800 (PST) Sender: Mark Johnston Date: Mon, 24 Feb 2014 20:31:15 -0500 From: markj@freebsd.org To: Mikolaj Golub Subject: Re: Improvements to bsd.dtrace.mk Message-ID: <20140225013115.GA64934@raichu> References: <20140126162712.GA11086@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140126162712.GA11086@gmail.com> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: Rui Paulo , dtrace@freebsd.org X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.17 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: Tue, 25 Feb 2014 01:31:23 -0000 On Sun, Jan 26, 2014 at 06:27:13PM +0200, Mikolaj Golub wrote: > Hi, > Hi Mikolaj, > Trying to use bsd.dtrace.mk for building userland programs with > statically defined traces, I facesed the following issues: > > 1) To generate a header file (e.g. provider.h) from a dtrace file > (provider.d) you had to explicitly run `make depend'. > > 2) If a makefile included bsd.dtrace.mk and sources contained probe > macros, it would fail to build when WITH_DTRACE was not > defined. I.e. you couldn't build the same sources with and without > dtrace probes. > > 3) It failed to build if you had several provider files (several files > specified in DTRACEOBJS). > > 4) It failed if OBJDIR was not current directory. > > 5) It failed to rebuild dtrace objects if the old ones had not been > removed before, because dtrace(1) refuses to rewrite objects. Note that this behaviour is specific to FreeBSD; see: http://svnweb.freebsd.org/base?view=revision&revision=212358 I'm not sure if it's still necessary. > > 6) It was not possible to specify additional trace(1) options (e.g. > library or header directory paths). > > Here is my attempt to solve most of these issues: > > http://people.freebsd.org/~trociny/patches/bsd.dtrace.mk.3.patch > > The only issue remains is (1) -- necessity to run `make depend' to > generate probider header files. I had also to tweak dt_program.c -- > header files generation. I've been working around this by adding "all: depend" to my Makefiles, but there should be a better way to do it. What do you think of just replacing beforedepend: ${DTRACEHEADERS} with ${SRCS}: ${DTRACEHEADERS} ? It's overkill, but it seems to result in the correct behaviour for me. I spent a bit of time looking other examples of auto-generated headers in the tree, but couldn't find any. > > Note, I didn't have much practice in writing makefiles, so any > suggestions how this can be improved (or should be done properly) are > highly appreciated. It works and looks fine to me, for what that's worth. I tested with some Makefiles that I've written in the past. I'm not aware of any ports that make use of bsd.dtrace.mk. As a side comment, I'm wondering whether it should be necessary to have Makefiles explicitly include bsd.dtrace.mk. Maybe bsd.prog.mk and bsd.lib.mk could always include bsd.dtrace.mk, which will have no effect when DTRACESRCS isn't defined. Thanks, -Mark From owner-freebsd-dtrace@FreeBSD.ORG Tue Feb 25 01:59:06 2014 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 ESMTPS id E4319294 for ; Tue, 25 Feb 2014 01:59:06 +0000 (UTC) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id AB66810DE for ; Tue, 25 Feb 2014 01:59:06 +0000 (UTC) Received: by mail-ie0-f177.google.com with SMTP id rp18so4081000iec.8 for ; Mon, 24 Feb 2014 17:59:06 -0800 (PST) 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=r7yTU2vlqBFEZjPLgadh3QZYwVerCXz4A6z6s5K2fQw=; b=g4y1qxANPXZkb1rBJw74ePVgqr/itzkdeL2trDTNiP5riEMTnvlSt2I2kZFGsxWfvl NPTBE1huPce54P5X1NASrirK8xAGQ2XgMUJoDLCfTYd1NrenLriPbluVh6wzhb+6DA/G orzKBCnn2eFm8KWrljUQVWNI+bY8O4ac5kI2O2l11/YRwt99237uGbAC0r2TAHO7ae7r FmKRr+tFYvF5v5q1fMTmtjTXZKwYJvK6EoQVeMSRtuzMO8GqRtqKL2fUmWdfJNwhOGS8 9INrAzwGfmEh/12YW1voZYpErx1nL4gDLBrbJW4rTKGhJP9i69MiDYuF47paBLRtbpJL aXHA== X-Received: by 10.43.75.9 with SMTP id yy9mr17217628icb.54.1393293546166; Mon, 24 Feb 2014 17:59:06 -0800 (PST) Received: from raichu (198-84-185-216.cpe.teksavvy.com. [198.84.185.216]) by mx.google.com with ESMTPSA id ai4sm32518514igd.3.2014.02.24.17.59.04 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 24 Feb 2014 17:59:05 -0800 (PST) Sender: Mark Johnston Date: Mon, 24 Feb 2014 20:59:03 -0500 From: Mark Johnston To: Adam Leventhal Subject: Re: [patch] fasttrap process scratch space Message-ID: <20140225015903.GB64934@raichu> References: <20140224041454.GB2720@raichu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-dtrace@freebsd.org X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.17 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: Tue, 25 Feb 2014 01:59:07 -0000 On Mon, Feb 24, 2014 at 09:51:13AM -0800, Adam Leventhal wrote: > Hey Mark, > > I wanted to provide a little historical perspective when considering > the options of a pact with libc/libthread/ld.so.1 vs. the kernel > mapping pages for TLS. > > We considered both but chose the former in Solaris. > Solaris/OpenSolaris/illumos have the kernel, libc, and ld.so.1 in the > same repository. There are already dependencies between those > components, so adding another was not a concern. That makes sense. Obviously, the same is true on FreeBSD, but what mostly worried me is the lack of any way to determine whether the traced process does in fact have scratch space available in its TLS. What if the executable is statically-linked with a libthr without my change? What if I'm attempting to trace a Linux binary running in the compatibility layer? In these cases, the program will just crash once it tries to execute instructions in non-executable memory (or it'll corrupt the thread control block), and I don't see any way to detect or prevent that in fasttrap. FreeBSD's DTrace implementation also tries to be somewhat compartmentalized so that it's possible to remove or add DTrace support without too much work. To my knowledge, it's all currently implemented using kernel modules and some userland executables and libraries. Requiring libthr and rtld support would take us in the opposite direction. > We felt that having > DTrace map pages into the traced process could have a more significant > impact on its execution, and we wanted to minimize the chance that > DTrace would chase away the very problem users were trying to > investigate. Further, we felt that the failure modes would be less > clean; for example, in your patch if we fail to map a page while in > fasttrap_pid_probe(), we're forced to silently remove the > instrumentation. That's true. It seemed to me that having to map 4 KB for every 64 threads in the process is not too much overhead, but it'd certainly be preferable to avoid it. In your much wider experience with userland DTrace, do you know of use cases where this might be likely to cause problems? > > Hope that's helpful. It is, I appreciate the explanation. I didn't mean to imply that the solution used in Solaris is inferior to the approch I followed; I just felt that it's not so well-suited to FreeBSD. Thanks! -Mark > > Adam > > On Sun, Feb 23, 2014 at 8:14 PM, Mark Johnston wrote: > > Hello, > > > > For those not familiar with MD parts of fasttrap, one of the things it > > has to do is ensure that any userland instruction that it replaces with > > a breakpoint gets executed in the traced process' context. For several > > common classes of instructions, fasttrap will emulate the instruction in > > the breakpoint handler; when it can't do that, it copies the instruction > > out to some scratch space in the process' address space and sets the PC > > of the interrupted thread to the address of that instruction, which is > > followed by a jump to the instruction following the breakpoint. There's > > a helpful block comment titled "Generic Instruction Tracing" around line > > 1585 of the x86 fasttrap_isa.c which describes the details of this. > > > > This functionality currently doesn't work on FreeBSD, mainly because we > > don't necessarily have any (per-thread) scratch space available for use > > in the process' address space. In illumos/Solaris, a small (< 64 byte) > > block is reserved in each thread's TLS for use by DTrace. It turns out > > that doing the same thing on FreeBSD is quite easy: > > > > http://people.freebsd.org/~markj/patches/fasttrap_scratch_hacky.diff > > > > Specifically, we need to ensure that TLS (allocated by the runtime > > linker) is executable and that we properly extract the offset to the > > scratch space from the FS segment register. I think this is somewhat > > hacky though, as it creates a dependency on libthr and rtld internals. > > > > A second approach is to have fasttrap dynamically allocate scratch space > > within the process' address space using vm_map_insert(9). My > > understanding is that Apple's DTrace implementation does this, and I've > > implemented this approach for FreeBSD here (which was done without > > referencing Apple code): > > > > http://people.freebsd.org/~markj/patches/fasttrap-scratch-space/fasttrap-scratch-space-1.diff > > > > The idea is to map pages of executable memory into the user process as > > needed, and carve them into scratch space chunks for use by individual > > threads. If a thread in fasttrap_pid_probe() needs scratch space, it > > calls a new function, fasttrap_scraddr(). If the thread already has > > scratch space allocated to it, it's used. Otherwise, if any free scratch > > space chunks are available in an already-mapped page, one of them is > > allocated to the thread and used. Otherwise, a new page is mapped using > > vm_map_insert(9). > > > > Threads hold onto their scratch space until they exit. That is, scratch > > space is never unmapped from the process, even if the controlling > > dtrace(1) process detaches. I added a handler for thread_dtor event > > which re-adds any scratch space held by the thread to the free list for > > that process. Per-process scratch space state is held in the fasttrap > > process handle (fasttrap_proc_t), since that turns out to be much easier > > than keeping it in the struct proc. > > > > Does anyone have any thoughts or comments on the approach or the patch? > > Any review or testing would be very much appreciated. > > > > For testing purposes, it's helpful to know that tracing memcpy() on > > amd64 will result in use of this scratch space code, as it starts with a > > "mov %rdi,%rax" on my machine at least. My main test case has been to > > run something like > > > > # dtrace -n 'pid$target:libc.so.7::entry {@[probefunc] = count()}' -p $(pgrep firefox) > > > > Attempting to trace all functions still results in firefox dying with > > SIGTRAP, but we're getting there. :) > > > > Thanks, > > -- > > -Mark > > _______________________________________________ > > freebsd-dtrace@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-dtrace > > To unsubscribe, send any mail to "freebsd-dtrace-unsubscribe@freebsd.org" > > > > -- > Adam Leventhal > CTO, Delphix > http://blog.delphix.com/ahl -- -Mark From owner-freebsd-dtrace@FreeBSD.ORG Tue Feb 25 14:16:38 2014 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 ESMTPS id B3AC6980 for ; Tue, 25 Feb 2014 14:16:38 +0000 (UTC) Received: from mail-qa0-x233.google.com (mail-qa0-x233.google.com [IPv6:2607:f8b0:400d:c00::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 73D271D63 for ; Tue, 25 Feb 2014 14:16:38 +0000 (UTC) Received: by mail-qa0-f51.google.com with SMTP id j7so283508qaq.10 for ; Tue, 25 Feb 2014 06:16:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:content-type; bh=sJS5an8CrBse1q7CNkR2lcyf20g7wCxG6gmO96TLjCE=; b=zmbkWkjBUZBCzijLypm0sQ2auS9LLpVlXx393MeXAh2yNGOGBoPuTWv1w26wN0GMYj rDqm9w64EofoJMdjGc4fyFgBwz92MKHdcyyclCRnpteoS0d7mSfzPzZOrcHtDtAPaGXr b+ycvvc0vsY1c4x+QDFfNgrxdc8okborlgkrJE+5keDoOjqzY95WUX6kkNv5U4uR1JnV fcqU3BqOnHI2VBLGlL76UpE3CDBSZGLBFkVxSuId8wlElAxKPLwAn5NY3qugq93QI26I EwWuEATjXamsfE9Ci0SByZb9BST+ndYERW2P14E+DTvdClKzI5WNsNz339ZNp4pqwG6J 7YiA== X-Received: by 10.229.183.200 with SMTP id ch8mr2363331qcb.17.1393337796616; Tue, 25 Feb 2014 06:16:36 -0800 (PST) MIME-Version: 1.0 Sender: fedor.indutny@gmail.com Received: by 10.96.127.74 with HTTP; Tue, 25 Feb 2014 06:16:15 -0800 (PST) From: Fedor Indutny Date: Tue, 25 Feb 2014 18:16:15 +0400 X-Google-Sender-Auth: _mCl9JmZBx4HVdlsbi5LgrCz73o Message-ID: Subject: DTrace fixes for node.js To: freebsd-dtrace@freebsd.org Content-Type: text/plain; charset=ISO-8859-1 X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.17 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: Tue, 25 Feb 2014 14:16:38 -0000 Hello devs! I have made some fixes to fix DTrace support for node.js in FreeBSD: * http://www.freebsd.org/cgi/query-pr.cgi?pr=186821 * http://www.freebsd.org/cgi/query-pr.cgi?pr=187027 Here is a blog post with a bit of explanation of why this is needed and what is fixed: https://blog.indutny.com/7.freebsd-dtrace Please let me know if I could be any help in reviewing it. Cheers, Fedor. From owner-freebsd-dtrace@FreeBSD.ORG Tue Feb 25 17:46:55 2014 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 ESMTPS id 4BD201CB for ; Tue, 25 Feb 2014 17:46:55 +0000 (UTC) Received: from mail-oa0-x22b.google.com (mail-oa0-x22b.google.com [IPv6:2607:f8b0:4003:c02::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0D89C13DC for ; Tue, 25 Feb 2014 17:46:54 +0000 (UTC) Received: by mail-oa0-f43.google.com with SMTP id i7so796541oag.2 for ; Tue, 25 Feb 2014 09:46:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphix.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EZX4QvUB0fVEANu09pn4DZFfO+jxBmFc6hjmAnDc1bE=; b=LY6tQLQs5Umj4mAJSFTREk5c6ffHbMXgD2ykQOhruCibVsP/r/UIQOpVxQGoqHauhd kzw98p3ZPK8lEwSWQoYAV9p7lDW6Rho9rN6FgOVpvZOgVRL1YuUg0lfLKyKxnnax5uZq gmY9dlwuY67VDHsdecQbGKSfm4Ho/dh2U7zTA= 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=EZX4QvUB0fVEANu09pn4DZFfO+jxBmFc6hjmAnDc1bE=; b=fH2e5Y2s02B1kCZ1Ppwct2oA/O/1o/HFSFWdihtWN7O0zlTbKMeRFFLyu0xZztcHEW wNUmcG0sX5T1j6RrPnHh2N+5wdFZccRkazUnN1vieJZubANxB6VrRsVDGCg/aB3gqxaj G4sMfU78z4X7+uVsdNfxWafNzluE8BA7zEC6MRJspzdEXj9/FYGn9DUTmyCfCVb/QjPF VNLuQ+Xa3unXc8hf85+3CRuMuE6jhfvBo7gxzLgdIU0V9610DsOdgWggN+LzJ5E3s8CM J3/9bFdtts2EHyR0oU5b9JS/bSeWARmS1/0Owdl/Z4nERXhS42EKvjTV+iYWw3ahtamq wSVg== X-Gm-Message-State: ALoCoQksEQVHTBDLwMNcRnH6W9f0vsZDP5FUPf5Q+85UpsF5Mses3X8nucMw46PPSgj+KO6oK6H0 MIME-Version: 1.0 X-Received: by 10.60.145.197 with SMTP id sw5mr2467475oeb.58.1393350414231; Tue, 25 Feb 2014 09:46:54 -0800 (PST) Received: by 10.76.169.106 with HTTP; Tue, 25 Feb 2014 09:46:54 -0800 (PST) In-Reply-To: <20140225015903.GB64934@raichu> References: <20140224041454.GB2720@raichu> <20140225015903.GB64934@raichu> Date: Tue, 25 Feb 2014 09:46:54 -0800 Message-ID: Subject: Re: [patch] fasttrap process scratch space From: Adam Leventhal To: Mark Johnston Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-dtrace@freebsd.org X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.17 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: Tue, 25 Feb 2014 17:46:55 -0000 Hey Mark, > That makes sense. Obviously, the same is true on FreeBSD, but what > mostly worried me is the lack of any way to determine whether the > traced process does in fact have scratch space available in its TLS. > What if the executable is statically-linked with a libthr without my > change? In Solaris we decided not to support statically linked binaries (in Solaris 10 I think), so didn't need to worry about this case. (For background, we wanted to have the flexibility to change the syscall interfaces.) > What if I'm attempting to trace a Linux binary running in > the compatibility layer? In Solaris "Branded Zones" we still had libc living in a linkmap in the Linux binary. http://dtrace.org/blogs/ahl/2005/12/13/dtrace-for-linux/ > In these cases, the program will just crash > once it tries to execute instructions in non-executable memory (or it'll > corrupt the thread control block), and I don't see any way to detect or > prevent that in fasttrap. You could consider "blessing" dynamically linked processes in some communication between rtld/libthr and the kernel. > FreeBSD's DTrace implementation also tries to be somewhat > compartmentalized so that it's possible to remove or add DTrace support > without too much work. To my knowledge, it's all currently implemented > using kernel modules and some userland executables and libraries. > Requiring libthr and rtld support would take us in the opposite > direction. I understand and appreciate that design goal -- it makes sense. Fasttrap has the most "sprawl" of any of the DTrace components... > That's true. It seemed to me that having to map 4 KB for every 64 > threads in the process is not too much overhead, but it'd certainly be > preferable to avoid it. In your much wider experience with userland > DTrace, do you know of use cases where this might be likely to cause > problems? Agreed that the actual memory overhead is insignificant. My concern about the actual mappings would be affecting the placement of other mappings and how that might impact a program's execution in terms of chasing away a bug. >> Hope that's helpful. > > It is, I appreciate the explanation. I didn't mean to imply that the > solution used in Solaris is inferior to the approch I followed; I just > felt that it's not so well-suited to FreeBSD. And I didn't infer as much. I agree that each has different goals and design constraints. When presented with the same options it's understandable that FreeBSD might choose a different approach. I wanted to give my perspective on those options and how we had weighed them. Adam > Thanks! > -Mark > >> >> Adam >> >> On Sun, Feb 23, 2014 at 8:14 PM, Mark Johnston wrote: >> > Hello, >> > >> > For those not familiar with MD parts of fasttrap, one of the things it >> > has to do is ensure that any userland instruction that it replaces with >> > a breakpoint gets executed in the traced process' context. For several >> > common classes of instructions, fasttrap will emulate the instruction in >> > the breakpoint handler; when it can't do that, it copies the instruction >> > out to some scratch space in the process' address space and sets the PC >> > of the interrupted thread to the address of that instruction, which is >> > followed by a jump to the instruction following the breakpoint. There's >> > a helpful block comment titled "Generic Instruction Tracing" around line >> > 1585 of the x86 fasttrap_isa.c which describes the details of this. >> > >> > This functionality currently doesn't work on FreeBSD, mainly because we >> > don't necessarily have any (per-thread) scratch space available for use >> > in the process' address space. In illumos/Solaris, a small (< 64 byte) >> > block is reserved in each thread's TLS for use by DTrace. It turns out >> > that doing the same thing on FreeBSD is quite easy: >> > >> > http://people.freebsd.org/~markj/patches/fasttrap_scratch_hacky.diff >> > >> > Specifically, we need to ensure that TLS (allocated by the runtime >> > linker) is executable and that we properly extract the offset to the >> > scratch space from the FS segment register. I think this is somewhat >> > hacky though, as it creates a dependency on libthr and rtld internals. >> > >> > A second approach is to have fasttrap dynamically allocate scratch space >> > within the process' address space using vm_map_insert(9). My >> > understanding is that Apple's DTrace implementation does this, and I've >> > implemented this approach for FreeBSD here (which was done without >> > referencing Apple code): >> > >> > http://people.freebsd.org/~markj/patches/fasttrap-scratch-space/fasttrap-scratch-space-1.diff >> > >> > The idea is to map pages of executable memory into the user process as >> > needed, and carve them into scratch space chunks for use by individual >> > threads. If a thread in fasttrap_pid_probe() needs scratch space, it >> > calls a new function, fasttrap_scraddr(). If the thread already has >> > scratch space allocated to it, it's used. Otherwise, if any free scratch >> > space chunks are available in an already-mapped page, one of them is >> > allocated to the thread and used. Otherwise, a new page is mapped using >> > vm_map_insert(9). >> > >> > Threads hold onto their scratch space until they exit. That is, scratch >> > space is never unmapped from the process, even if the controlling >> > dtrace(1) process detaches. I added a handler for thread_dtor event >> > which re-adds any scratch space held by the thread to the free list for >> > that process. Per-process scratch space state is held in the fasttrap >> > process handle (fasttrap_proc_t), since that turns out to be much easier >> > than keeping it in the struct proc. >> > >> > Does anyone have any thoughts or comments on the approach or the patch? >> > Any review or testing would be very much appreciated. >> > >> > For testing purposes, it's helpful to know that tracing memcpy() on >> > amd64 will result in use of this scratch space code, as it starts with a >> > "mov %rdi,%rax" on my machine at least. My main test case has been to >> > run something like >> > >> > # dtrace -n 'pid$target:libc.so.7::entry {@[probefunc] = count()}' -p $(pgrep firefox) >> > >> > Attempting to trace all functions still results in firefox dying with >> > SIGTRAP, but we're getting there. :) >> > >> > Thanks, >> > -- >> > -Mark >> > _______________________________________________ >> > freebsd-dtrace@freebsd.org mailing list >> > https://lists.freebsd.org/mailman/listinfo/freebsd-dtrace >> > To unsubscribe, send any mail to "freebsd-dtrace-unsubscribe@freebsd.org" >> >> >> >> -- >> Adam Leventhal >> CTO, Delphix >> http://blog.delphix.com/ahl > > -- > -Mark -- Adam Leventhal CTO, Delphix http://blog.delphix.com/ahl From owner-freebsd-dtrace@FreeBSD.ORG Tue Feb 25 19:18:38 2014 Return-Path: Delivered-To: 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 ESMTPS id 4CFD675F; Tue, 25 Feb 2014 19:18:38 +0000 (UTC) Received: from mail-lb0-x22a.google.com (mail-lb0-x22a.google.com [IPv6:2a00:1450:4010:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 7030B1DC8; Tue, 25 Feb 2014 19:18:37 +0000 (UTC) Received: by mail-lb0-f170.google.com with SMTP id s7so743669lbd.29 for ; Tue, 25 Feb 2014 11:18:35 -0800 (PST) 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=YlGJarbF6OhQ2ZsI4p4T+O3dpPwN28N28UzeUu6lV4g=; b=uzXNUoE1zoY9itVhtTxBeiHwLaMHKEO3l97t1/GYj8dcD7qp+otZvsFVnMiqDsp4sb FVz70Gj37zc0Muq9j5wzLl2i/2Ff0q1SbGHObQMkKkU6IO/EY5vxsrxyHhaJra9AT4Wz oZ/Stx43OB4IadFEomfIXQILhmT7QZwHvZAzGjEZ84FlXIUfgiUVEMDTo1IBKrxmnki2 h9cEEbpqw92a+F4m3AAJyfnI/dem/gQiQze/wJVpdmd1OOe8yzCXh09XDWbfjslCAWIZ rYawM04PfUo6Z48+jU2gVKOX0pbm/ZB4XXxcWEMxsn5IPZ9wIuyIBQXaB343IsTeRU8S px7w== X-Received: by 10.112.158.230 with SMTP id wx6mr776642lbb.62.1393355915450; Tue, 25 Feb 2014 11:18:35 -0800 (PST) Received: from localhost ([178.150.115.244]) by mx.google.com with ESMTPSA id 10sm1329850lan.5.2014.02.25.11.18.33 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Feb 2014 11:18:34 -0800 (PST) Sender: Mikolaj Golub Date: Tue, 25 Feb 2014 21:18:31 +0200 From: Mikolaj Golub To: markj@freebsd.org Subject: Re: Improvements to bsd.dtrace.mk Message-ID: <20140225191830.GA4483@gmail.com> References: <20140126162712.GA11086@gmail.com> <20140225013115.GA64934@raichu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140225013115.GA64934@raichu> User-Agent: Mutt/1.5.22 (2013-10-16) Cc: Rui Paulo , dtrace@freebsd.org X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.17 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: Tue, 25 Feb 2014 19:18:38 -0000 On Mon, Feb 24, 2014 at 08:31:15PM -0500, markj@freebsd.org wrote: > On Sun, Jan 26, 2014 at 06:27:13PM +0200, Mikolaj Golub wrote: > > Trying to use bsd.dtrace.mk for building userland programs with > > statically defined traces, I facesed the following issues: > > > > 1) To generate a header file (e.g. provider.h) from a dtrace file > > (provider.d) you had to explicitly run `make depend'. > > > > 2) If a makefile included bsd.dtrace.mk and sources contained probe > > macros, it would fail to build when WITH_DTRACE was not > > defined. I.e. you couldn't build the same sources with and without > > dtrace probes. > > > > 3) It failed to build if you had several provider files (several files > > specified in DTRACEOBJS). > > > > 4) It failed if OBJDIR was not current directory. > > > > 5) It failed to rebuild dtrace objects if the old ones had not been > > removed before, because dtrace(1) refuses to rewrite objects. > > Note that this behaviour is specific to FreeBSD; see: > http://svnweb.freebsd.org/base?view=revision&revision=212358 > > I'm not sure if it's still necessary. Interesting. Thank you for the link! > > > > > 6) It was not possible to specify additional trace(1) options (e.g. > > library or header directory paths). > > > > Here is my attempt to solve most of these issues: > > > > http://people.freebsd.org/~trociny/patches/bsd.dtrace.mk.3.patch > > > > The only issue remains is (1) -- necessity to run `make depend' to > > generate probider header files. I had also to tweak dt_program.c -- > > header files generation. > > I've been working around this by adding "all: depend" to my Makefiles, > but there should be a better way to do it. What do you think of just > replacing > > beforedepend: ${DTRACEHEADERS} > > with > > ${SRCS}: ${DTRACEHEADERS} > > ? > > It's overkill, but it seems to result in the correct behaviour for me. I > spent a bit of time looking other examples of auto-generated headers in > the tree, but couldn't find any. > > > > > Note, I didn't have much practice in writing makefiles, so any > > suggestions how this can be improved (or should be done properly) are > > highly appreciated. > > It works and looks fine to me, for what that's worth. I tested with some > Makefiles that I've written in the past. I'm not aware of any ports that > make use of bsd.dtrace.mk. It is rather strange, because when I tried this last version recently it actually stopped work for me :-). Anyway, it still needs many improvements. > > As a side comment, I'm wondering whether it should be necessary to have > Makefiles explicitly include bsd.dtrace.mk. Maybe bsd.prog.mk and > bsd.lib.mk could always include bsd.dtrace.mk, which will have no effect > when DTRACESRCS isn't defined. Yes, I came to the same conclusion later. I was also considering a possibility to remove bsd.dtrace.mk at all and just extend bsd.prog.mk and bsd.lib.mk. Futher, it might be better to make users specify DTRACESRCS instead of DTRACEOBJS, or just add *.d files to SRCS, as we do e.g. with *.y files. Did not have much time to experiment yet though. Thanks for the comments. -- Mikolaj Golub From owner-freebsd-dtrace@FreeBSD.ORG Wed Feb 26 03:36:23 2014 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 ESMTPS id E98ADCBB for ; Wed, 26 Feb 2014 03:36:23 +0000 (UTC) Received: from mail-ig0-x230.google.com (mail-ig0-x230.google.com [IPv6:2607:f8b0:4001:c05::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B625A1441 for ; Wed, 26 Feb 2014 03:36:23 +0000 (UTC) Received: by mail-ig0-f176.google.com with SMTP id uy17so1178795igb.3 for ; Tue, 25 Feb 2014 19:36:23 -0800 (PST) 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=3MKToARG8lrAQmTOvhrFf0sGCUqwrgB8u5XgvrGnnrc=; b=YdX5gjCvs1roW/sSW9/h3l66e8jBokJDRXE9sJfQmrCS6BjoG00AeQL19559i1Z4TC 9yEEbUFtHXTGVLXu/jdPu0kFIG75AFcJ/au5V+qTOInv57jv5/0pOFExqvjEDOiRGXnU af76Rn88WqIoS27XS1Qc5OUWInQ5aJxoYMZTT6nnle5XNNw9BMFCbke7H9ssy/5+CIve G/6CKgywtviyEI0WRP8EUkP52miCwz9fSllKZrLBjExU8NCeXCP4FeD0OuqaGd510JQX oXIuFtHkvR+s5ZSFdW7RW7yXuf7VJ84i2bli3qYJ5FSLrRlIRKcTYOWLQwNy6gq9NmGB CjaQ== X-Received: by 10.43.4.2 with SMTP id oa2mr3405681icb.4.1393385783213; Tue, 25 Feb 2014 19:36:23 -0800 (PST) Received: from raichu (198-84-185-216.cpe.teksavvy.com. [198.84.185.216]) by mx.google.com with ESMTPSA id dz8sm44342418igb.5.2014.02.25.19.36.21 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 25 Feb 2014 19:36:22 -0800 (PST) Sender: Mark Johnston Date: Tue, 25 Feb 2014 22:36:19 -0500 From: Mark Johnston To: Fedor Indutny Subject: Re: DTrace fixes for node.js Message-ID: <20140226033619.GB16841@raichu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-dtrace@freebsd.org X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.17 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: Wed, 26 Feb 2014 03:36:24 -0000 On Tue, Feb 25, 2014 at 06:16:15PM +0400, Fedor Indutny wrote: > Hello devs! > > I have made some fixes to fix DTrace support for node.js in FreeBSD: > > * http://www.freebsd.org/cgi/query-pr.cgi?pr=186821 > * http://www.freebsd.org/cgi/query-pr.cgi?pr=187027 > > Here is a blog post with a bit of explanation of why this is needed > and what is fixed: https://blog.indutny.com/7.freebsd-dtrace > > Please let me know if I could be any help in reviewing it. Hi Fedor, Thanks for the PRs. I've grabbed them and will work on them soon. -Mark From owner-freebsd-dtrace@FreeBSD.ORG Wed Feb 26 09:02:16 2014 Return-Path: Delivered-To: freebsd-dtrace@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 65A4B65E; Wed, 26 Feb 2014 09:02:16 +0000 (UTC) Received: from mail-qa0-x236.google.com (mail-qa0-x236.google.com [IPv6:2607:f8b0:400d:c00::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 11A6C1D1F; Wed, 26 Feb 2014 09:02:15 +0000 (UTC) Received: by mail-qa0-f54.google.com with SMTP id i13so1928537qae.13 for ; Wed, 26 Feb 2014 01:02:15 -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=dLEMxJlk5vE3N8qZcbAtnILjebb7I50yO9Yyl8f38LA=; b=n8l9HoKb97INC7aYJ6y093smZWbI31tg5kcyF1J99Cu/z4mgD/TCDcspcm8tuRu33K SCUmek1kUPZKhW4+ZeDBtv9Krn7gbbF/+q8Iq/rLhLo6kR3wXgztbqE5oawkrnT2tnxV Yk5inEGZPO738iC31KFwVtR6Fq4kgOvRFcpS6g2V41qh8DM6Uxuf28NahkW1fiIT3R9B Vr4gEauJM2nTeFCAW4Xc1ohCwf4zmxkhuwFNAgssGmctw57qFEH83++fFBw/WRCZ+iRD 8vWrRyUzGkn+9xgUIQyYXCg90LRQEmFgm7BpWzmg144PjKKSTdsYhMcGC3ntwCgzyXwJ Uhxg== X-Received: by 10.224.53.198 with SMTP id n6mr6137253qag.41.1393405335221; Wed, 26 Feb 2014 01:02:15 -0800 (PST) MIME-Version: 1.0 Sender: fedor.indutny@gmail.com Received: by 10.96.127.74 with HTTP; Wed, 26 Feb 2014 01:01:55 -0800 (PST) In-Reply-To: <20140226033619.GB16841@raichu> References: <20140226033619.GB16841@raichu> From: Fedor Indutny Date: Wed, 26 Feb 2014 13:01:55 +0400 X-Google-Sender-Auth: 3nWeeh6nFyv08Kiu7OAfXNlyYP4 Message-ID: Subject: Re: DTrace fixes for node.js To: Mark Johnston Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-dtrace@freebsd.org X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.17 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: Wed, 26 Feb 2014 09:02:16 -0000 Thank you, Mark! On Wed, Feb 26, 2014 at 7:36 AM, Mark Johnston wrote: > On Tue, Feb 25, 2014 at 06:16:15PM +0400, Fedor Indutny wrote: >> Hello devs! >> >> I have made some fixes to fix DTrace support for node.js in FreeBSD: >> >> * http://www.freebsd.org/cgi/query-pr.cgi?pr=186821 >> * http://www.freebsd.org/cgi/query-pr.cgi?pr=187027 >> >> Here is a blog post with a bit of explanation of why this is needed >> and what is fixed: https://blog.indutny.com/7.freebsd-dtrace >> >> Please let me know if I could be any help in reviewing it. > > Hi Fedor, > > Thanks for the PRs. I've grabbed them and will work on them soon. > > -Mark From owner-freebsd-dtrace@FreeBSD.ORG Thu Feb 27 05:01:40 2014 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 ESMTPS id 3ABBC81E for ; Thu, 27 Feb 2014 05:01:40 +0000 (UTC) Received: from mail-ig0-x236.google.com (mail-ig0-x236.google.com [IPv6:2607:f8b0:4001:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E87E015B6 for ; Thu, 27 Feb 2014 05:01:39 +0000 (UTC) Received: by mail-ig0-f182.google.com with SMTP id l13so3246596iga.3 for ; Wed, 26 Feb 2014 21:01:39 -0800 (PST) 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=bWCIQPodrZXPGoC0VYSbI5rb2EnOpBhanxvwIdbkydY=; b=FHdTSM41XPUWDPWjItJ0aV26xUaMqg+avCPgGyiv2ZM0hZMA4cswt3RR/JJdCk+82g rVwrd/RLe9JgNVzix6/2FkuipCqmThCHsOc7YxdTeCArD0+0crwjQ+WG94Pc15PCBRlV hSXH9FxfYcjLcblxEXE6XVqu9zANZ+7aSbnNmgE2QPDRhV6wLsrLcfH8LIi1TqV9Ntdy vRCnH0mRcZlqfFvlXj0h1Eg7VLJrdRMFKt3fT7M5tx8dqHoEI3sPAsq7rcZkYT1JVUJX 8WckuA6UuX4q3YpW8MZjrAvonwikFKdnpkbKUu/UcQ7us1aJg8h7MFEXYXcxABug5A4W Qb8g== X-Received: by 10.42.50.3 with SMTP id y3mr3309803icf.12.1393477299312; Wed, 26 Feb 2014 21:01:39 -0800 (PST) Received: from raichu (198-84-185-216.cpe.teksavvy.com. [198.84.185.216]) by mx.google.com with ESMTPSA id c17sm55897965igo.4.2014.02.26.21.01.38 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 26 Feb 2014 21:01:38 -0800 (PST) Sender: Mark Johnston Date: Thu, 27 Feb 2014 00:01:36 -0500 From: Mark Johnston To: Fedor Indutny Subject: Re: DTrace fixes for node.js Message-ID: <20140227050136.GB28089@raichu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.22 (2013-10-16) Cc: freebsd-dtrace@freebsd.org X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.17 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, 27 Feb 2014 05:01:40 -0000 On Tue, Feb 25, 2014 at 06:16:15PM +0400, Fedor Indutny wrote: > Hello devs! > > I have made some fixes to fix DTrace support for node.js in FreeBSD: > > * http://www.freebsd.org/cgi/query-pr.cgi?pr=186821 > * http://www.freebsd.org/cgi/query-pr.cgi?pr=187027 > > Here is a blog post with a bit of explanation of why this is needed > and what is fixed: https://blog.indutny.com/7.freebsd-dtrace > > Please let me know if I could be any help in reviewing it. Hi Fedor, The DOF limit change looks fine to me. I note that the illumos guys have just pushed a change to illumos-gate which bumps dtrace_dof_maxsize, but it's good to have the sysctl as well. The drti change looks mostly good to me. The real problem there is that our linker doesn't know how to merge DOF, so it just concatenates the tables into one SUNW_dof section. So we should really fix our linker, but it doesn't hurt to also handle the problem in drti.o. There are a couple of bugs in the patch. First, the "break" added after finding the DOF section causes problems if we haven't yet seen the symbol table. Second, fixedprobes needs to be reset at the beginning of each iteration of the while loop that you added, else we may not try searching the dynamic symbol table when fixing the probe addresses. I've pasted a patch below; could you test it and make sure things still work properly with node? Thanks for the detailed blog post and problem description, they were very helpful. :) -Mark diff --git a/cddl/contrib/opensolaris/lib/libdtrace/common/drti.c b/cddl/contrib/opensolaris/lib/libdtrace/common/drti.c index e47cfb4d..bb02d8c 100644 --- a/cddl/contrib/opensolaris/lib/libdtrace/common/drti.c +++ b/cddl/contrib/opensolaris/lib/libdtrace/common/drti.c @@ -162,7 +162,7 @@ dtrace_dof_init(void) char *dofstrtabraw; size_t shstridx, symtabidx = 0, dynsymidx = 0; unsigned char *buf; - int fixedprobes = 0; + int fixedprobes; #endif if (getenv("DTRACE_DOF_INIT_DISABLE") != NULL) @@ -214,7 +214,6 @@ dtrace_dof_init(void) if (s && strcmp(s, ".SUNW_dof") == 0) { dofdata = elf_getdata(scn, NULL); dof = dofdata->d_buf; - break; } } } @@ -226,6 +225,7 @@ dtrace_dof_init(void) } while ((char *) dof < (char *) dofdata->d_buf + dofdata->d_size) { + fixedprobes = 0; dof_next = (void *) ((char *) dof + dof->dofh_filesz); #endif From owner-freebsd-dtrace@FreeBSD.ORG Thu Feb 27 08:31:03 2014 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 ESMTPS id 438AED38; Thu, 27 Feb 2014 08:31:03 +0000 (UTC) Received: from mail-qc0-x235.google.com (mail-qc0-x235.google.com [IPv6:2607:f8b0:400d:c01::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E843E1968; Thu, 27 Feb 2014 08:31:02 +0000 (UTC) Received: by mail-qc0-f181.google.com with SMTP id c9so2821119qcz.26 for ; Thu, 27 Feb 2014 00:31:01 -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=7peado/iBHPfVfvbYC+hynEqjuitcTtTJX1CC5jir9Y=; b=oNbh8NzKNmFP6X/TnAPWxaxWqiACWyQ3fenw/rES4yCvr0F8qDgmoKa06dlYz7ZwLn DUoWa0Vlu8lFMufTkl5aUDs4hMv7E2dyZIU6S8eiSa3dZi3E2NmNcsmNjqwxb6ssBosj RbJPSjPPOFNiNCXm1lm3HebU89f6R0hC0CSoRsbzzKVs33cGGNaZBHlZmOBQY7Z4wLYQ lLAuhfk6Emh+7ImpXV+BtcsKMZr4pDK6eYdaJ2SmA/MON0saTsCoN3Paw3aH5+xKgMzF OaKMsqGjyqUw+USgObn+VvGwX0u5iMm/WbrUWi8ELsvOY7/D4Dtnpe/8pl/hWEl8Fc0O b1qA== X-Received: by 10.224.80.201 with SMTP id u9mr14306317qak.5.1393489861852; Thu, 27 Feb 2014 00:31:01 -0800 (PST) MIME-Version: 1.0 Sender: fedor.indutny@gmail.com Received: by 10.96.127.74 with HTTP; Thu, 27 Feb 2014 00:30:41 -0800 (PST) In-Reply-To: <20140227050136.GB28089@raichu> References: <20140227050136.GB28089@raichu> From: Fedor Indutny Date: Thu, 27 Feb 2014 12:30:41 +0400 X-Google-Sender-Auth: y1JvPUGVXkIci4CNSEBlvUfheeg Message-ID: Subject: Re: DTrace fixes for node.js To: Mark Johnston Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-dtrace@freebsd.org X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.17 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, 27 Feb 2014 08:31:03 -0000 Mark, Thanks for looking into this. I just tried your patch and it (no surprise) builds fine. Node.js DOF symbols seems to be resolving properly too! Do you want me to squash this changes into my patch, and post them on that ticket? Cheers, Fedor. On Thu, Feb 27, 2014 at 9:01 AM, Mark Johnston wrote: > On Tue, Feb 25, 2014 at 06:16:15PM +0400, Fedor Indutny wrote: >> Hello devs! >> >> I have made some fixes to fix DTrace support for node.js in FreeBSD: >> >> * http://www.freebsd.org/cgi/query-pr.cgi?pr=186821 >> * http://www.freebsd.org/cgi/query-pr.cgi?pr=187027 >> >> Here is a blog post with a bit of explanation of why this is needed >> and what is fixed: https://blog.indutny.com/7.freebsd-dtrace >> >> Please let me know if I could be any help in reviewing it. > > Hi Fedor, > > The DOF limit change looks fine to me. I note that the illumos guys have > just pushed a change to illumos-gate which bumps dtrace_dof_maxsize, but > it's good to have the sysctl as well. > > The drti change looks mostly good to me. The real problem there is that > our linker doesn't know how to merge DOF, so it just concatenates the > tables into one SUNW_dof section. So we should really fix our linker, > but it doesn't hurt to also handle the problem in drti.o. > > There are a couple of bugs in the patch. First, the "break" added after > finding the DOF section causes problems if we haven't yet seen the > symbol table. Second, fixedprobes needs to be reset at the beginning of > each iteration of the while loop that you added, else we may not try > searching the dynamic symbol table when fixing the probe addresses. I've > pasted a patch below; could you test it and make sure things still work > properly with node? > > Thanks for the detailed blog post and problem description, they were > very helpful. :) > > -Mark > > diff --git a/cddl/contrib/opensolaris/lib/libdtrace/common/drti.c b/cddl/contrib/opensolaris/lib/libdtrace/common/drti.c > index e47cfb4d..bb02d8c 100644 > --- a/cddl/contrib/opensolaris/lib/libdtrace/common/drti.c > +++ b/cddl/contrib/opensolaris/lib/libdtrace/common/drti.c > @@ -162,7 +162,7 @@ dtrace_dof_init(void) > char *dofstrtabraw; > size_t shstridx, symtabidx = 0, dynsymidx = 0; > unsigned char *buf; > - int fixedprobes = 0; > + int fixedprobes; > #endif > > if (getenv("DTRACE_DOF_INIT_DISABLE") != NULL) > @@ -214,7 +214,6 @@ dtrace_dof_init(void) > if (s && strcmp(s, ".SUNW_dof") == 0) { > dofdata = elf_getdata(scn, NULL); > dof = dofdata->d_buf; > - break; > } > } > } > @@ -226,6 +225,7 @@ dtrace_dof_init(void) > } > > while ((char *) dof < (char *) dofdata->d_buf + dofdata->d_size) { > + fixedprobes = 0; > dof_next = (void *) ((char *) dof + dof->dofh_filesz); > #endif > From owner-freebsd-dtrace@FreeBSD.ORG Thu Feb 27 14:39:06 2014 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 ESMTPS id DFEFE740 for ; Thu, 27 Feb 2014 14:39:05 +0000 (UTC) Received: from mail-ve0-x231.google.com (mail-ve0-x231.google.com [IPv6:2607:f8b0:400c:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9707E10CF for ; Thu, 27 Feb 2014 14:39:05 +0000 (UTC) Received: by mail-ve0-f177.google.com with SMTP id sa20so581098veb.22 for ; Thu, 27 Feb 2014 06:39:04 -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:date:message-id:subject :from:to:cc:content-type; bh=+THNUcuVbEKYf0RnUPF650RjWiowYTPV2fHw9NHY7mg=; b=LNlaSe7y0KKjznJ6Isyo0fUS1WZmNDzyJF5vh2JKFa4de2ZIf/L1T8kbIFri+taBS2 W+C6gSp/RBYnXrPuBb7HlfWxEkptfhYTm5wj0jUHMeb6Sft6Em5SLgp4KfcOy72Wtr7s XecrBYHeFCqMs3DTgvgAhek/90qLXNFyMScjf8okokdyS0S2gHA8t3NKlUFo2or5MFcT Lfra8Z1YYn+s5+d0/Y86dwT57Y5pZgTADZTaWhH11NGKf3bFdhKz5sQUtyMFNYaYi0B6 8uLePfPcv3/wgvmxzW66IRgzfA7fpquqlSfsNA6vyJZL/JfHMDVBTYn63pcmPZy6/aA0 pdxg== MIME-Version: 1.0 X-Received: by 10.220.95.139 with SMTP id d11mr10948796vcn.21.1393511944598; Thu, 27 Feb 2014 06:39:04 -0800 (PST) Sender: markjdb@gmail.com Received: by 10.220.162.68 with HTTP; Thu, 27 Feb 2014 06:39:04 -0800 (PST) In-Reply-To: References: <20140227050136.GB28089@raichu> Date: Thu, 27 Feb 2014 09:39:04 -0500 X-Google-Sender-Auth: wGZIKjfrFN2rPTGyr2TPaxxSQQU Message-ID: Subject: Re: DTrace fixes for node.js From: Mark Johnston To: Fedor Indutny Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-dtrace@freebsd.org" X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.17 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, 27 Feb 2014 14:39:06 -0000 On Thu, Feb 27, 2014 at 3:30 AM, Fedor Indutny wrote: > Mark, > > Thanks for looking into this. I just tried your patch and it (no > surprise) builds fine. Node.js DOF symbols seems to be resolving > properly too! > > Do you want me to squash this changes into my patch, and post them on > that ticket? > That would be good, thanks. When I have some time I'll do more testing and commit the change. -Mark > On Thu, Feb 27, 2014 at 9:01 AM, Mark Johnston wrote: >> On Tue, Feb 25, 2014 at 06:16:15PM +0400, Fedor Indutny wrote: >>> Hello devs! >>> >>> I have made some fixes to fix DTrace support for node.js in FreeBSD: >>> >>> * http://www.freebsd.org/cgi/query-pr.cgi?pr=186821 >>> * http://www.freebsd.org/cgi/query-pr.cgi?pr=187027 >>> >>> Here is a blog post with a bit of explanation of why this is needed >>> and what is fixed: https://blog.indutny.com/7.freebsd-dtrace >>> >>> Please let me know if I could be any help in reviewing it. >> >> Hi Fedor, >> >> The DOF limit change looks fine to me. I note that the illumos guys have >> just pushed a change to illumos-gate which bumps dtrace_dof_maxsize, but >> it's good to have the sysctl as well. >> >> The drti change looks mostly good to me. The real problem there is that >> our linker doesn't know how to merge DOF, so it just concatenates the >> tables into one SUNW_dof section. So we should really fix our linker, >> but it doesn't hurt to also handle the problem in drti.o. >> >> There are a couple of bugs in the patch. First, the "break" added after >> finding the DOF section causes problems if we haven't yet seen the >> symbol table. Second, fixedprobes needs to be reset at the beginning of >> each iteration of the while loop that you added, else we may not try >> searching the dynamic symbol table when fixing the probe addresses. I've >> pasted a patch below; could you test it and make sure things still work >> properly with node? >> >> Thanks for the detailed blog post and problem description, they were >> very helpful. :) >> >> -Mark >> >> diff --git a/cddl/contrib/opensolaris/lib/libdtrace/common/drti.c b/cddl/contrib/opensolaris/lib/libdtrace/common/drti.c >> index e47cfb4d..bb02d8c 100644 >> --- a/cddl/contrib/opensolaris/lib/libdtrace/common/drti.c >> +++ b/cddl/contrib/opensolaris/lib/libdtrace/common/drti.c >> @@ -162,7 +162,7 @@ dtrace_dof_init(void) >> char *dofstrtabraw; >> size_t shstridx, symtabidx = 0, dynsymidx = 0; >> unsigned char *buf; >> - int fixedprobes = 0; >> + int fixedprobes; >> #endif >> >> if (getenv("DTRACE_DOF_INIT_DISABLE") != NULL) >> @@ -214,7 +214,6 @@ dtrace_dof_init(void) >> if (s && strcmp(s, ".SUNW_dof") == 0) { >> dofdata = elf_getdata(scn, NULL); >> dof = dofdata->d_buf; >> - break; >> } >> } >> } >> @@ -226,6 +225,7 @@ dtrace_dof_init(void) >> } >> >> while ((char *) dof < (char *) dofdata->d_buf + dofdata->d_size) { >> + fixedprobes = 0; >> dof_next = (void *) ((char *) dof + dof->dofh_filesz); >> #endif >> From owner-freebsd-dtrace@FreeBSD.ORG Thu Feb 27 14:50:28 2014 Return-Path: Delivered-To: freebsd-dtrace@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1D82DFFE; Thu, 27 Feb 2014 14:50:28 +0000 (UTC) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id BA4261215; Thu, 27 Feb 2014 14:50:27 +0000 (UTC) Received: by mail-qa0-f47.google.com with SMTP id w5so3936644qac.20 for ; Thu, 27 Feb 2014 06:50:26 -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=+EECZ/m1+tM9Lzr/mkRd4cqoAXxmqhEFLhjJAsklp58=; b=Zi24WgNViEQrgTLVkoVR34QKG+aM56k8fXWivewBV8tUr2ocuGqQUY/+6KVy/3O8Go VTxNxaS1TFm+QU3obbqkfEuwBXaZWIqS3SzIoNtmUUT30PI26hsncs1docj8gDNNH4n7 rBt8Y+GUGoD/NKPJaFUbC2GK7ryJWB6b/wzPK+YE2nfHoyWEZDR/OBYDnHeAeZv9oYuI EgvPi58MmyvrnY1We5Rj+ufpGcWQNbfHiJGjWK24Yh74c+T/IpG9h+1peamZgevJiDIj wWaTwbThdGLEhbxn5zIu4G8YPL9rZrVBlJR7j8y6kyHASSjfTMzJBxqeZecsE3uxdJzI NRCQ== X-Received: by 10.140.83.203 with SMTP id j69mr7878458qgd.42.1393512626686; Thu, 27 Feb 2014 06:50:26 -0800 (PST) MIME-Version: 1.0 Sender: fedor.indutny@gmail.com Received: by 10.96.127.74 with HTTP; Thu, 27 Feb 2014 06:50:06 -0800 (PST) In-Reply-To: References: <20140227050136.GB28089@raichu> From: Fedor Indutny Date: Thu, 27 Feb 2014 18:50:06 +0400 X-Google-Sender-Auth: fz2VX5XMY1zVr0oqZ60RPaEj7NM Message-ID: Subject: Re: DTrace fixes for node.js To: Mark Johnston Content-Type: text/plain; charset=ISO-8859-1 Cc: "freebsd-dtrace@freebsd.org" X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.17 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, 27 Feb 2014 14:50:28 -0000 Update sent, thank you! On Thu, Feb 27, 2014 at 6:39 PM, Mark Johnston wrote: > On Thu, Feb 27, 2014 at 3:30 AM, Fedor Indutny wrote: >> Mark, >> >> Thanks for looking into this. I just tried your patch and it (no >> surprise) builds fine. Node.js DOF symbols seems to be resolving >> properly too! >> >> Do you want me to squash this changes into my patch, and post them on >> that ticket? >> > > That would be good, thanks. When I have some time I'll do more testing > and commit the change. > > -Mark > >> On Thu, Feb 27, 2014 at 9:01 AM, Mark Johnston wrote: >>> On Tue, Feb 25, 2014 at 06:16:15PM +0400, Fedor Indutny wrote: >>>> Hello devs! >>>> >>>> I have made some fixes to fix DTrace support for node.js in FreeBSD: >>>> >>>> * http://www.freebsd.org/cgi/query-pr.cgi?pr=186821 >>>> * http://www.freebsd.org/cgi/query-pr.cgi?pr=187027 >>>> >>>> Here is a blog post with a bit of explanation of why this is needed >>>> and what is fixed: https://blog.indutny.com/7.freebsd-dtrace >>>> >>>> Please let me know if I could be any help in reviewing it. >>> >>> Hi Fedor, >>> >>> The DOF limit change looks fine to me. I note that the illumos guys have >>> just pushed a change to illumos-gate which bumps dtrace_dof_maxsize, but >>> it's good to have the sysctl as well. >>> >>> The drti change looks mostly good to me. The real problem there is that >>> our linker doesn't know how to merge DOF, so it just concatenates the >>> tables into one SUNW_dof section. So we should really fix our linker, >>> but it doesn't hurt to also handle the problem in drti.o. >>> >>> There are a couple of bugs in the patch. First, the "break" added after >>> finding the DOF section causes problems if we haven't yet seen the >>> symbol table. Second, fixedprobes needs to be reset at the beginning of >>> each iteration of the while loop that you added, else we may not try >>> searching the dynamic symbol table when fixing the probe addresses. I've >>> pasted a patch below; could you test it and make sure things still work >>> properly with node? >>> >>> Thanks for the detailed blog post and problem description, they were >>> very helpful. :) >>> >>> -Mark >>> >>> diff --git a/cddl/contrib/opensolaris/lib/libdtrace/common/drti.c b/cddl/contrib/opensolaris/lib/libdtrace/common/drti.c >>> index e47cfb4d..bb02d8c 100644 >>> --- a/cddl/contrib/opensolaris/lib/libdtrace/common/drti.c >>> +++ b/cddl/contrib/opensolaris/lib/libdtrace/common/drti.c >>> @@ -162,7 +162,7 @@ dtrace_dof_init(void) >>> char *dofstrtabraw; >>> size_t shstridx, symtabidx = 0, dynsymidx = 0; >>> unsigned char *buf; >>> - int fixedprobes = 0; >>> + int fixedprobes; >>> #endif >>> >>> if (getenv("DTRACE_DOF_INIT_DISABLE") != NULL) >>> @@ -214,7 +214,6 @@ dtrace_dof_init(void) >>> if (s && strcmp(s, ".SUNW_dof") == 0) { >>> dofdata = elf_getdata(scn, NULL); >>> dof = dofdata->d_buf; >>> - break; >>> } >>> } >>> } >>> @@ -226,6 +225,7 @@ dtrace_dof_init(void) >>> } >>> >>> while ((char *) dof < (char *) dofdata->d_buf + dofdata->d_size) { >>> + fixedprobes = 0; >>> dof_next = (void *) ((char *) dof + dof->dofh_filesz); >>> #endif >>> From owner-freebsd-dtrace@FreeBSD.ORG Fri Mar 7 05:58:30 2014 Return-Path: Delivered-To: freebsd-dtrace@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CD80AE89 for ; Fri, 7 Mar 2014 05:58:30 +0000 (UTC) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 418ABE52 for ; Fri, 7 Mar 2014 05:58:29 +0000 (UTC) Received: from ur.gsoft.com.au (Ur.gsoft.com.au [203.31.81.34]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id s275nUQp070934 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 7 Mar 2014 16:19:36 +1030 (CST) (envelope-from doconnor@gsoft.com.au) From: "Daniel O'Connor" Content-Type: multipart/signed; boundary="Apple-Mail=_09D1CA48-B8A9-4396-89DB-4DB1C7A97BF6"; protocol="application/pgp-signature"; micalg=pgp-sha1 Date: Fri, 7 Mar 2014 16:19:30 +1030 Subject: dtracing static symbols To: freebsd-dtrace@freebsd.org Message-Id: <76CD6999-EE43-4E67-9DFD-D86835EFE47A@gsoft.com.au> Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-Spam-Score: -2.51 () ALL_TRUSTED,BAYES_00,T_RP_MATCHES_RCVD X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.17 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, 07 Mar 2014 05:58:30 -0000 --Apple-Mail=_09D1CA48-B8A9-4396-89DB-4DB1C7A97BF6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, I have been experimenting with DTrace on 9.2 and I was wondering if = there was some way to trace static symbols in binaries? I did some testing on OSX and apparently Solaris can also do it but not = [yet?] FreeBSD. Unfortunately I haven't had much luck finding the code which does it in = Solaris (so I can't check if it's in a later version of FreeBSD). Thanks. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --Apple-Mail=_09D1CA48-B8A9-4396-89DB-4DB1C7A97BF6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFTGV3q5ZPcIHs/zowRApv5AJ4ygZelBGzzCG46TwMV33tkcEDa2gCghcuw aawxJa+vlHd7V7MhA7tYiWI= =5MgE -----END PGP SIGNATURE----- --Apple-Mail=_09D1CA48-B8A9-4396-89DB-4DB1C7A97BF6-- From owner-freebsd-dtrace@FreeBSD.ORG Tue Mar 11 05:04:31 2014 Return-Path: Delivered-To: freebsd-dtrace@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 825B278 for ; Tue, 11 Mar 2014 05:04:31 +0000 (UTC) Received: from nm5-vm1.bullet.mail.sg3.yahoo.com (nm5-vm1.bullet.mail.sg3.yahoo.com [106.10.148.144]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id CCB3BFEE for ; Tue, 11 Mar 2014 05:04:24 +0000 (UTC) Received: from [106.10.166.123] by nm5.bullet.mail.sg3.yahoo.com with NNFMP; 11 Mar 2014 05:04:16 -0000 Received: from [106.10.150.29] by tm12.bullet.mail.sg3.yahoo.com with NNFMP; 11 Mar 2014 05:04:16 -0000 Received: from [127.0.0.1] by omp1030.mail.sg3.yahoo.com with NNFMP; 11 Mar 2014 05:04:16 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 557622.7924.bm@omp1030.mail.sg3.yahoo.com Received: (qmail 97235 invoked by uid 60001); 11 Mar 2014 05:04:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.in; s=s1024; t=1394514256; bh=08sk1VSGOBdOKAqpXOlp6l0qk/MiWBEw20AY09Uj4xQ=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=RI53t+mLtic0nhGsV9eump1klaUcEcEr1ecr98NTyFxWLEgKwYgDiO3hIKPpBzYQNP+aGbcPhnR9Ij3GsF9OUikWVfVntloabs/HeVPMAf2t8eZwvE5sTylYtXRFT6vW8CIEYUAMYelbQcN7TmW4yV6OC6MqVVb9v8wReDuW9Bo= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=YqLqXtPW8k0uTz2RLPE74ZPtlZ1bLlaevnUc5TmvEsYerxdYKRgmIesw/mWlSvh6+0M6LseRWJiYwesuDttXHA+uD5uzNI7Y2lkLsVjDoGFkpk9GV1nL7GQ2mLatFwtoWfTvtG+56Lx4mCTawhLCMRQOs1pVz3CSjyBNE7rQPFQ=; X-YMail-OSG: DUYEb0AVM1lQNADhQfhcijGWgWchokD4I_mWFQJ8yq1hB._ O9OCm9qjUde988WygN8SmMeZcgCFzkWwj.M7yrj7HNNPGYiymbPVXSYzuaP_ HSlnkDbPdVpuqKK34S6IqPlLS.fBb_1h8r7rz_UtOU8vkFiEtJBfVw3cK4fS 4vLaPvnax_43wLZN0xh_9XHJ_M_cDaOxWQL4wajdnOyyCTDt4.PweCwQdw2R fPF4SGRQfN.d1u4uRKhp650.Nso3SqoRHcs_8IP0ho4dzX6VSpgdHhoTp2oR 57T8by0xBhTgAayMRt6YFHD6KFKAnr6as6GlRazYtPOoohwt96mhE0nSoTeN tqM9NoCRo.8h2lcBnVyDPPm.Wcr1lI4F17mmL0C3N4EmA6QKXxPIAkagt.1a IFvEEtDr17zMpUqMj0a93VlfyWlgYxpINKccBEhZ2nnGYiMgcnFrl2vUNDc2 oB7pUw5MRPcwrSyyzAmPf60qsqth3d23E9.RLPqtQ0F4v_.ZCbwpLkRC4owd UcWuCioMpuM7X8MviWIfUhrce2UoGEzAcPnSnLBkqFTPue1TtfT788Npk2bY fjqjxuw06qyy9j5mrf7Rbze3fpOB_TyuIfQ4nWeM.26a9LQ-- Received: from [2.50.30.175] by web192604.mail.sg3.yahoo.com via HTTP; Tue, 11 Mar 2014 13:04:16 SGT X-Rocket-MIMEInfo: 002.001, SGksDQoNCklmIHRoZSBiaW5hcnkgYmVpbmcgdHJhY2VkIGhhcyBzdGF0aWMgc3ltYm9scyBpbiBpdHMgc3ltYm9sIHRhYmxlLCBEVHJhY2Ugc2hvdWxkDQpiZSBhYmxlIHRvIHRyYWNlIHRoZSBmdW5jdGlvbi4gQ2FuIHlvdSBkZXNjcmliZSB0aGUgZXhhbXBsZSB3aGVyZSB5b3UgZm91bmQgdGhpcw0KZGlmZmVyZW5jZSBpbiBGcmVlQlNEIGFuZCBPU1g_DQoNCnJnZHMNClByYXNoYW50aA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCk9uIEZyaSwgNy8zLzE0LCBEYW5pZWwBMAEBAQE- X-Mailer: YahooMailClassic/448 YahooMailWebService/0.8.177.636 Message-ID: <1394514256.45492.YahooMailBasic@web192604.mail.sg3.yahoo.com> Date: Tue, 11 Mar 2014 13:04:16 +0800 (SGT) From: Prashanth Kumar Subject: Re: dtracing static symbols To: freebsd-dtrace@freebsd.org, Daniel O'Connor In-Reply-To: <76CD6999-EE43-4E67-9DFD-D86835EFE47A@gsoft.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.17 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: Tue, 11 Mar 2014 05:04:31 -0000 Hi, If the binary being traced has static symbols in its symbol table, DTrace s= hould be able to trace the function. Can you describe the example where you found= this difference in FreeBSD and OSX? rgds Prashanth -------------------------------------------- On Fri, 7/3/14, Daniel O'Connor wrote: Subject: dtracing static symbols To: freebsd-dtrace@freebsd.org Date: Friday, 7 March, 2014, 11:19 AM =20 Hi, I have been experimenting with DTrace on 9.2 and I was wondering if there was some way to trace static symbols in binaries? =20 I did some testing on OSX and apparently Solaris can also do it but not [yet?] FreeBSD. =20 Unfortunately I haven't had much luck finding the code which does it in Solaris (so I can't check if it's in a later version of FreeBSD). =20 Thanks. =20 -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." =A0 -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C =20 =20 =20 =20 =20 =20 From owner-freebsd-dtrace@FreeBSD.ORG Tue Mar 11 05:34:58 2014 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 ESMTPS id ED2E06EC for ; Tue, 11 Mar 2014 05:34:57 +0000 (UTC) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 800A32A3 for ; Tue, 11 Mar 2014 05:34:56 +0000 (UTC) Received: from ur.gsoft.com.au (Ur.gsoft.com.au [203.31.81.34]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id s2B5YVis022289 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 11 Mar 2014 16:04:41 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Subject: Re: dtracing static symbols Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Content-Type: multipart/signed; boundary="Apple-Mail=_C881AA60-5F55-42C6-8A24-F625A6763A22"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: "Daniel O'Connor" In-Reply-To: <1394514256.45492.YahooMailBasic@web192604.mail.sg3.yahoo.com> Date: Tue, 11 Mar 2014 16:04:31 +1030 Message-Id: <7C202659-0BD9-4F93-8886-24DD7AEB495F@gsoft.com.au> References: <1394514256.45492.YahooMailBasic@web192604.mail.sg3.yahoo.com> To: Prashanth Kumar X-Mailer: Apple Mail (2.1874) X-Spam-Score: -2.51 () ALL_TRUSTED,BAYES_00,T_RP_MATCHES_RCVD X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: freebsd-dtrace@freebsd.org X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.17 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: Tue, 11 Mar 2014 05:34:58 -0000 --Apple-Mail=_C881AA60-5F55-42C6-8A24-F625A6763A22 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 11 Mar 2014, at 15:34, Prashanth Kumar wrote: > If the binary being traced has static symbols in its symbol table, = DTrace should > be able to trace the function. Can you describe the example where you = found this > difference in FreeBSD and OSX? Unfortunately the static symbols don't show up in the symbol table (as = shown by nm). Is there a compile or link flag which will change that? Here is an example.. [ur 15:43] ~ >cat static.c #include static void foo(void) { printf("Foo\n"); } void bar(void) { printf("Boo\n"); } int main(int argc, char **argv) { foo(); bar(); return 0; } [ur 15:43] ~ >cc static.c -o static [ur 15:43] ~ >sudo dtrace -Ppid\$target -l -c ./static|less On OSX you see.. ... 956613 pid46749 static foo = return 956614 pid46749 static foo = entry 956615 pid46749 static foo 0 956616 pid46749 static foo 1 956617 pid46749 static foo 4 956618 pid46749 static foo 8 956619 pid46749 static foo f 956620 pid46749 static foo 11 956621 pid46749 static foo 16 956622 pid46749 static foo 19 956623 pid46749 static foo 1d 956624 pid46749 static foo 1e .. (I'm not sure what the various numbers mean) However on FreeBSD you don't see any thing for the binary itself, only = the libraries. This is true even if you build with.. [mdtest 5:22] ~ >cc static.o -o static [mdtest 5:22] ~ >ctfconvert -g -L labelenv static.o [mdtest 5:22] ~ >cc -g static.c -o static.o -c Curiously you also can't run it with -c, I had to put a usleep() at the = start and then use -p. Trying to use -c fails with.. [mdtest 5:25] ~ >sudo dtrace -Ppid\$target -l -c ./static Foo Bar dtrace: failed to control pid 52006: process exited with status 0 FWIW nm on the binary shows both symbols (foo and bar) [mdtest 5:33] ~ >nm static|egrep '(foo|bar)' 0000000000400700 T bar 00000000004006f0 t foo Finally, while -c doesn't work on FreeBSD but actually runs the binary, = -c on OSX works (but the binary isn't executed - or at least you don't = see its output) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --Apple-Mail=_C881AA60-5F55-42C6-8A24-F625A6763A22 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFTHqBn5ZPcIHs/zowRAusOAJ9Jo+QUuvnkEWXQvmKGgC5rPYqa/gCfdmjZ UFyYHVj04G71HGtwvVpJsPY= =cMQD -----END PGP SIGNATURE----- --Apple-Mail=_C881AA60-5F55-42C6-8A24-F625A6763A22-- From owner-freebsd-dtrace@FreeBSD.ORG Tue Mar 11 16:00:14 2014 Return-Path: Delivered-To: freebsd-dtrace@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C9351872 for ; Tue, 11 Mar 2014 16:00:14 +0000 (UTC) Received: from mail-pb0-f49.google.com (mail-pb0-f49.google.com [209.85.160.49]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 9E2188A0 for ; Tue, 11 Mar 2014 16:00:14 +0000 (UTC) Received: by mail-pb0-f49.google.com with SMTP id jt11so8956431pbb.36 for ; Tue, 11 Mar 2014 09:00:06 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=gkH9936h57oUQ5+++BJkXyyWZNirMTKDmLB25qghtwY=; b=hOC69YQfrlp28guJOo0DbFnOcjfQCJqUgBPNNsAfHxgzPc5l0Z0+SLThmSP/iSLhqY DnobhhDZhmX7o3YRdbdDoDpy8f7Qm4f5HdwChyrwpmHqKN6V8JNG7iDBTMlUFhOPmnDa PlaeMh49m02l0KGzd9EeizBmTjJG6BH4g4CokMSTPg6At4CYt4iBTK9nbrjZyLEnB//t 9wMmlqUgWzmGpH44uHzhdjlHVNEVIIktMfDSKrp6rCxTrcy2vLWn3HoYoB9VoeZFizBH mjV/X/29ZVALnclyCY35QBpFcYaDZ6Fdb+jj900B/Vf/PFo+YURED/PrVAb/Udvaslof IP4Q== X-Gm-Message-State: ALoCoQkyfGzbF2DKLk/V+KSYHu4nbABXacWGTzGJ+Gu3vvUX+eAj75Xko7w9uduqUBerGtA+cykG X-Received: by 10.68.170.36 with SMTP id aj4mr48863064pbc.54.1394553605920; Tue, 11 Mar 2014 09:00:05 -0700 (PDT) Received: from [10.138.0.3] (c-67-180-178-113.hsd1.ca.comcast.net. [67.180.178.113]) by mx.google.com with ESMTPSA id q7sm75620270pbc.20.2014.03.11.09.00.02 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Mar 2014 09:00:03 -0700 (PDT) Message-ID: <531F3302.8010106@joyent.com> Date: Tue, 11 Mar 2014 09:00:02 -0700 From: Robert Mustacchi User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-dtrace@freebsd.org Subject: Re: dtracing static symbols References: <1394514256.45492.YahooMailBasic@web192604.mail.sg3.yahoo.com> <7C202659-0BD9-4F93-8886-24DD7AEB495F@gsoft.com.au> In-Reply-To: <7C202659-0BD9-4F93-8886-24DD7AEB495F@gsoft.com.au> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.17 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: Tue, 11 Mar 2014 16:00:14 -0000 On 03/10/2014 10:34 PM, Daniel O'Connor wrote: > > On 11 Mar 2014, at 15:34, Prashanth Kumar wrote: >> If the binary being traced has static symbols in its symbol table, DTrace should >> be able to trace the function. Can you describe the example where you found this >> difference in FreeBSD and OSX? > > Unfortunately the static symbols don't show up in the symbol table (as shown by nm). > > Is there a compile or link flag which will change that? Because it's a static function the compiler may inline it, which may be why you don't actually see an entry in nm nor that it can be found by DTrace. You'll want to look at the disassembled output of your program to see if it was inlined. Different compilers can and will do different things. There generally are flags you can pass to the compiler to tell it not to inline it, but that's compiler specific. > On OSX you see.. > ... > 956613 pid46749 static foo return > 956614 pid46749 static foo entry > 956615 pid46749 static foo 0 > 956616 pid46749 static foo 1 > 956617 pid46749 static foo 4 > 956618 pid46749 static foo 8 > 956619 pid46749 static foo f > 956620 pid46749 static foo 11 > 956621 pid46749 static foo 16 > 956622 pid46749 static foo 19 > 956623 pid46749 static foo 1d > 956624 pid46749 static foo 1e > .. > > (I'm not sure what the various numbers mean) The pid provider can instrument any instruction in a function, those are the instruction offsets. Robert From owner-freebsd-dtrace@FreeBSD.ORG Tue Mar 11 21:24:55 2014 Return-Path: Delivered-To: freebsd-dtrace@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 54F715D3 for ; Tue, 11 Mar 2014 21:24:55 +0000 (UTC) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id B9A7939F for ; Tue, 11 Mar 2014 21:24:54 +0000 (UTC) Received: from ur.dons.net.au (ppp118-210-56-74.lns20.adl2.internode.on.net [118.210.56.74]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id s2BLOMac083181 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Mar 2014 07:54:28 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Subject: Re: dtracing static symbols Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Content-Type: multipart/signed; boundary="Apple-Mail=_BB85BE5D-8D31-4A80-94D5-1CD619D02118"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: "Daniel O'Connor" In-Reply-To: <531F3302.8010106@joyent.com> Date: Wed, 12 Mar 2014 07:54:22 +1030 Message-Id: <4DCD0848-F635-4CAE-B109-9941395B6AB8@gsoft.com.au> References: <1394514256.45492.YahooMailBasic@web192604.mail.sg3.yahoo.com> <7C202659-0BD9-4F93-8886-24DD7AEB495F@gsoft.com.au> <531F3302.8010106@joyent.com> To: Robert Mustacchi X-Mailer: Apple Mail (2.1874) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: freebsd-dtrace@freebsd.org X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.17 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: Tue, 11 Mar 2014 21:24:55 -0000 --Apple-Mail=_BB85BE5D-8D31-4A80-94D5-1CD619D02118 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 12 Mar 2014, at 2:30, Robert Mustacchi wrote: > On 03/10/2014 10:34 PM, Daniel O'Connor wrote: >>=20 >> On 11 Mar 2014, at 15:34, Prashanth Kumar = wrote: >>> If the binary being traced has static symbols in its symbol table, = DTrace should >>> be able to trace the function. Can you describe the example where = you found this >>> difference in FreeBSD and OSX? >>=20 >> Unfortunately the static symbols don't show up in the symbol table = (as shown by nm). >>=20 >> Is there a compile or link flag which will change that? >=20 > Because it's a static function the compiler may inline it, which may = be > why you don't actually see an entry in nm nor that it can be found by > DTrace. You'll want to look at the disassembled output of your program > to see if it was inlined. Different compilers can and will do = different > things. There generally are flags you can pass to the compiler to tell > it not to inline it, but that's compiler specific. I just realised that my test contradicted the statement I made earlier.. However I checked my test program (static.c) and it the functions = definitely appear in the symbol table. [mdtest 21:13] ~ >nm static|egrep '(foo|bar)' 0000000000400600 T bar 0000000000400620 t foo I also added the noinline attribute for good measure. It seems that _nothing_ shows up for executables, only shared libraries, = this is OK for me since my code resides in a library but it is a bit = surprised nonetheless.. >> (I'm not sure what the various numbers mean) >=20 > The pid provider can instrument any instruction in a function, those = are > the instruction offsets. Ahh, thanks. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --Apple-Mail=_BB85BE5D-8D31-4A80-94D5-1CD619D02118 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFTH38G5ZPcIHs/zowRAvGvAKCBvfjbhb/YiYMzlXOXmGaMI4K0MQCeOdSB qQv3Ka8ftX2+ddVfeE+qZpQ= =tKS3 -----END PGP SIGNATURE----- --Apple-Mail=_BB85BE5D-8D31-4A80-94D5-1CD619D02118-- From owner-freebsd-dtrace@FreeBSD.ORG Wed Mar 12 04:48:42 2014 Return-Path: Delivered-To: freebsd-dtrace@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 763AAFE9 for ; Wed, 12 Mar 2014 04:48:42 +0000 (UTC) Received: from nm24-vm6.bullet.mail.sg3.yahoo.com (nm24-vm6.bullet.mail.sg3.yahoo.com [106.10.151.85]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id DEDC58F for ; Wed, 12 Mar 2014 04:48:36 +0000 (UTC) Received: from [106.10.166.63] by nm24.bullet.mail.sg3.yahoo.com with NNFMP; 12 Mar 2014 04:45:42 -0000 Received: from [106.10.151.252] by tm20.bullet.mail.sg3.yahoo.com with NNFMP; 12 Mar 2014 04:45:42 -0000 Received: from [127.0.0.1] by omp1001.mail.sg3.yahoo.com with NNFMP; 12 Mar 2014 04:45:42 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 587833.19024.bm@omp1001.mail.sg3.yahoo.com Received: (qmail 82773 invoked by uid 60001); 12 Mar 2014 04:45:42 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.in; s=s1024; t=1394599542; bh=0J3vmxF1jtvG2pKBCFx+78JVKSccZFh9bQl7SlmaJ9Q=; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=GvRyucTi5GJcdSHu5dJRWAH+iyZoF/u0A9SRpZYvo0azkggtfy8wd7AfH+d8mP/A6kiov2qatVjIwYMeHPpIp7qOE6CRAMpgSC2P+gj6MbusScCJOMQZZyK0NBG4NWB03zcSnwKxRWpFnR5x21uJKd+p9fVdGBSH5TdmWHxBw1Y= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.in; h=X-YMail-OSG:Received:X-Rocket-MIMEInfo:X-Mailer:Message-ID:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=xbD6ckrjrfP/NWiOTq+MoR2fb7HKQBwm64+Hv4DONYyqnP2c+9ZKLxktKfT8Is0F5ihsnKvat6ddBvzsdj4+2/3+JXRuIKhIvEP2quNQwjJBATecJuDBQgJvF9H72uue91pVgGEdzPHvgSCC0Y0ye4TeA6iFiQhYy5yh7WIj0/E=; X-YMail-OSG: 1VD1xg4VM1mzOzrtpT4_Yq1YWENstGCeJlYatXCYG6K1CqP mMk_eJ46ahBPwjtKHURQ5322q130y3MCWt5GjrD8pPU7vTRuxijF01UM9XLn .xjcK_anvzKHqZnb5r6FBBiowJ7U7YudW6TCR0ROtapCP1_Xl8wczefqycXa RNr6bRkJiMlHg03qWcEGD.GNxeorA_i6Vmscpf09BXAgILSJ.Hvg7UFCAcwu ypeONPb9s_Dua10WUxbyGUUTIyqjC.aa6yvIGx_MnC01d2qNEJ_W9vlgrZ.z b68n5Pwr5p_5l3x9XEAdyzcboNJ0vl9wY2N2iKJlmoxU_BdDv7bUs9LExk9z Y9ueKdGdv4mKc7zRWwCHRaOfznC.stP1_aAetJi__ONs6Yzjbjgos9Y9waZ7 PpPcfE5cSHds1rF8EUu3rIwcxE.Qn7e_H39dSZtHlWZ8tPnMw6kwt1azJhyn Bzz5GvVfA80Tk.goiNm7bTz4GTJ5pzEqX45O70ka0UQen4aPD9tMldMBw90G GSpWnDOhQNgiwj2FxqYJAyucwt9WqDJSgPihWI35rsqU1jyj0yOlZfpJ5d8P 6ktkTrT5JX2Wl2.Dr7VXFhwrxCKQO3RveMtbDRi6TCl0r.A-- Received: from [2.50.30.175] by web192602.mail.sg3.yahoo.com via HTTP; Wed, 12 Mar 2014 12:45:42 SGT X-Rocket-MIMEInfo: 002.001, SWYgeW91IHJ1biANCiMgZW52IERUUkFDRV9ERUJVRz0xIGR0cmFjZSAtUHBpZFwkdGFyZ2V0IC1sICAtYyAuL3N0YXRpYw0KeW91IHdpbGwgbm90aWNlIHRoYXQgbG90IG9mIHByb2JlIGNyZWF0aW9uIHdpbGwgZmFpbCwgYWxzbyBubyBwcm9iZXMgYXJlIGNyZWF0ZWQgZm9yIGluc3RydWN0aW9uIG9mZnNldHMuDQogICAgeW91IHdpbGwgaGF2ZSB0byB1cGRhdGUgdGhlIGxpYnByb2MgbGlicmFyeSBhbmQgZmFzdHRyYXAgY29kZSB0byB0cmFjZSBhbGwgdGhlIA0KZnVuY3Rpb25zLiANCi0tLS0tLS0tLS0tLS0BMAEBAQE- X-Mailer: YahooMailClassic/451 YahooMailWebService/0.8.177.636 Message-ID: <1394599542.80116.YahooMailBasic@web192602.mail.sg3.yahoo.com> Date: Wed, 12 Mar 2014 12:45:42 +0800 (SGT) From: Prashanth Kumar Subject: Re: dtracing static symbols To: Robert Mustacchi , Daniel O'Connor In-Reply-To: <4DCD0848-F635-4CAE-B109-9941395B6AB8@gsoft.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-dtrace@freebsd.org X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.17 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: Wed, 12 Mar 2014 04:48:42 -0000 If you run=20 # env DTRACE_DEBUG=3D1 dtrace -Ppid\$target -l -c ./static you will notice that lot of probe creation will fail, also no probes are cr= eated for instruction offsets. you will have to update the libproc library and fasttrap code to trace = all the=20 functions.=20 -------------------------------------------- On Wed, 12/3/14, Daniel O'Connor wrote: Subject: Re: dtracing static symbols To: "Robert Mustacchi" Cc: freebsd-dtrace@freebsd.org Date: Wednesday, 12 March, 2014, 2:54 AM =20 =20 On 12 Mar 2014, at 2:30, Robert Mustacchi wrote: > On 03/10/2014 10:34 PM, Daniel O'Connor wrote: >>=20 >> On 11 Mar 2014, at 15:34, Prashanth Kumar wrote: >>> If the binary being traced has static symbols in its symbol table, DTrace should >>> be able to trace the function. Can you describe the example where you found this >>> difference in FreeBSD and OSX? >>=20 >> Unfortunately the static symbols don't show up in the symbol table (as shown by nm). >>=20 >> Is there a compile or link flag which will change that? >=20 > Because it's a static function the compiler may inline it, which may be > why you don't actually see an entry in nm nor that it can be found by > DTrace. You'll want to look at the disassembled output of your program > to see if it was inlined. Different compilers can and will do different > things. There generally are flags you can pass to the compiler to tell > it not to inline it, but that's compiler specific. =20 I just realised that my test contradicted the statement I made earlier.. However I checked my test program (static.c) and it the functions definitely appear in the symbol table. [mdtest 21:13] ~ >nm static|egrep '(foo|bar)' 0000000000400600 T bar 0000000000400620 t foo =20 I also added the noinline attribute for good measure. =20 It seems that _nothing_ shows up for executables, only shared libraries, this is OK for me since my code resides in a library but it is a bit surprised nonetheless.. =20 >> (I'm not sure what the various numbers mean) >=20 > The pid provider can instrument any instruction in a function, those are > the instruction offsets. =20 Ahh, thanks. =20 -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." =A0 -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C =20 =20 =20 =20 =20 =20 From owner-freebsd-dtrace@FreeBSD.ORG Wed Mar 12 04:50:51 2014 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 ESMTPS id A23A5129 for ; Wed, 12 Mar 2014 04:50:51 +0000 (UTC) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EF5CA136 for ; Wed, 12 Mar 2014 04:50:50 +0000 (UTC) Received: from ur.dons.net.au (ppp118-210-56-74.lns20.adl2.internode.on.net [118.210.56.74]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id s2C4oIuP025262 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Mar 2014 15:20:26 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Subject: Re: dtracing static symbols Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Content-Type: multipart/signed; boundary="Apple-Mail=_32394B83-8C01-47BD-B503-BE1BCB65F7C7"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: "Daniel O'Connor" In-Reply-To: <1394599542.80116.YahooMailBasic@web192602.mail.sg3.yahoo.com> Date: Wed, 12 Mar 2014 15:20:17 +1030 Message-Id: References: <1394599542.80116.YahooMailBasic@web192602.mail.sg3.yahoo.com> To: Prashanth Kumar X-Mailer: Apple Mail (2.1874) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: Robert Mustacchi , freebsd-dtrace@freebsd.org X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.17 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: Wed, 12 Mar 2014 04:50:51 -0000 --Apple-Mail=_32394B83-8C01-47BD-B503-BE1BCB65F7C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 12 Mar 2014, at 15:15, Prashanth Kumar wrote: > If you run=20 > # env DTRACE_DEBUG=3D1 dtrace -Ppid\$target -l -c ./static > you will notice that lot of probe creation will fail, also no probes = are created for instruction offsets. > you will have to update the libproc library and fasttrap code to = trace all the=20 > functions.=20 I don't really care about the function offsets, just static functions.=20= Or are you suggesting updating libproc and the fasttrap code will allow = that (as well as instruction offsets)? THanks. > -------------------------------------------- > On Wed, 12/3/14, Daniel O'Connor wrote: >=20 > Subject: Re: dtracing static symbols > To: "Robert Mustacchi" > Cc: freebsd-dtrace@freebsd.org > Date: Wednesday, 12 March, 2014, 2:54 AM >=20 >=20 > On 12 Mar 2014, at 2:30, Robert Mustacchi > wrote: >> On 03/10/2014 10:34 PM, Daniel O'Connor wrote: >>>=20 >>> On 11 Mar 2014, at 15:34, Prashanth Kumar > wrote: >>>> If the binary being traced has static symbols > in its symbol table, DTrace should >>>> be able to trace the function. Can you describe > the example where you found this >>>> difference in FreeBSD and OSX? >>>=20 >>> Unfortunately the static symbols don't show up in > the symbol table (as shown by nm). >>>=20 >>> Is there a compile or link flag which will change > that? >>=20 >> Because it's a static function the compiler may inline > it, which may be >> why you don't actually see an entry in nm nor that it > can be found by >> DTrace. You'll want to look at the disassembled output > of your program >> to see if it was inlined. Different compilers can and > will do different >> things. There generally are flags you can pass to the > compiler to tell >> it not to inline it, but that's compiler specific. >=20 > I just realised that my test contradicted the statement I > made earlier.. > However I checked my test program (static.c) and it the > functions definitely appear in the symbol table. > [mdtest 21:13] ~ >nm static|egrep '(foo|bar)' > 0000000000400600 T bar > 0000000000400620 t foo >=20 > I also added the noinline attribute for good measure. >=20 > It seems that _nothing_ shows up for executables, only > shared libraries, this is OK for me since my code resides in > a library but it is a bit surprised nonetheless.. >=20 >>> (I'm not sure what the various numbers mean) >>=20 >> The pid provider can instrument any instruction in a > function, those are >> the instruction offsets. >=20 > Ahh, thanks. >=20 > -- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 > 7B3F CE8C >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --Apple-Mail=_32394B83-8C01-47BD-B503-BE1BCB65F7C7 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFTH+eJ5ZPcIHs/zowRAgd5AJ9uSBR0jNitu1oozlz3ibCi6FQ5awCfe/Hy 1Y7etC62aJM3DRnZD9uHkW4= =xdSy -----END PGP SIGNATURE----- --Apple-Mail=_32394B83-8C01-47BD-B503-BE1BCB65F7C7-- From owner-freebsd-dtrace@FreeBSD.ORG Wed Mar 12 04:52:27 2014 Return-Path: Delivered-To: freebsd-dtrace@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 39621174 for ; Wed, 12 Mar 2014 04:52:27 +0000 (UTC) Received: from mail-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0D23E142 for ; Wed, 12 Mar 2014 04:52:26 +0000 (UTC) Received: by mail-pa0-f53.google.com with SMTP id ld10so549915pab.12 for ; Tue, 11 Mar 2014 21:52:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=T9ybrsQYl3tjZv/5IQFpbNs3SibplBchMSqbWB/0XAQ=; b=MtnosHTYhD7lJtO/C+AqxAmEvUK6c9mIx8EM5yadIFp9tHi9j/Dmrdrwbz4WXSBwDU UZqxvyfAOPlGgfgP4izla3pBSC0HWEMbhYK/JEAY5SM7gk0OL5bgWcmd1JUSac71dowa F6rbVzIs8lTsbsgezpMjV+TrYiyBOi/pZyyFnazfrKatyKSHD4qzavaJEUBHBWp7qwTm 4td6dyoEDJIAoG+UztR7RYpProqbW8gCltskcHqgsanVN8UpDK16Dq25vJ5PPkHlKDiG t4JZXaNbXuMSXj6f6Ql6Kmf7ube/29qD+3jzPCaa0g5CzIfrkC7Eepclqppba+rDYQ0a joug== X-Gm-Message-State: ALoCoQnqIF7VCm2nOmzag+Jl+63Y7K0vy+cruYd4IXOto67akZHZxzEw324nrglY2/HY46QUnZmC X-Received: by 10.66.158.132 with SMTP id wu4mr2392869pab.66.1394599940369; Tue, 11 Mar 2014 21:52:20 -0700 (PDT) Received: from zanarkand.local (c-67-180-178-113.hsd1.ca.comcast.net. [67.180.178.113]) by mx.google.com with ESMTPSA id jd5sm2828955pbb.18.2014.03.11.21.52.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Mar 2014 21:52:19 -0700 (PDT) Message-ID: <531FE803.9030702@joyent.com> Date: Tue, 11 Mar 2014 21:52:19 -0700 From: Robert Mustacchi User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: freebsd-dtrace@freebsd.org Subject: Re: dtracing static symbols References: <1394599542.80116.YahooMailBasic@web192602.mail.sg3.yahoo.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.17 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: Wed, 12 Mar 2014 04:52:27 -0000 On 3/11/14 21:50 , Daniel O'Connor wrote: > > On 12 Mar 2014, at 15:15, Prashanth Kumar wrote: >> If you run >> # env DTRACE_DEBUG=1 dtrace -Ppid\$target -l -c ./static >> you will notice that lot of probe creation will fail, also no probes are created for instruction offsets. >> you will have to update the libproc library and fasttrap code to trace all the >> functions. > > I don't really care about the function offsets, just static functions. > > Or are you suggesting updating libproc and the fasttrap code will allow that (as well as instruction offsets)? libdtrace uses libproc to iterate and find symbols and addresses to instrument, at least on illumos. Robert From owner-freebsd-dtrace@FreeBSD.ORG Wed Mar 12 04:52:53 2014 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 ESMTPS id 3B20018B for ; Wed, 12 Mar 2014 04:52:53 +0000 (UTC) Received: from mail-ve0-x231.google.com (mail-ve0-x231.google.com [IPv6:2607:f8b0:400c:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id EAE52143 for ; Wed, 12 Mar 2014 04:52:52 +0000 (UTC) Received: by mail-ve0-f177.google.com with SMTP id sa20so9470588veb.22 for ; Tue, 11 Mar 2014 21:52:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=dOUO2u4NjzCOFPkVLbj3Lp9pKJIDRNV/tTupOAab+VY=; b=i6Wi1CFCVND72v8eRwUuRp25Mcz9elKEO10InJXwgzyrMTxwa7MnUNa0oPzTcwUXgy IhtKz2VZbicu6xwXlDEIFUcvkhTttmG7CF0LxenkX1gM7L58HhYYcMyCI9P4J6PHhTAm Rh9n0NdC0YHcrSi3QG2dN0NW++zWsfgKcRXXkPdbO+AU/EQhgiKOb/pkFAYtW5qlhamj QkLXgshxgHhO941QCg7FijWSbT5or5EztYCfCLAnuxLKZPwXaBylpyxEMOByBNUbOFyE Ez2kPLmI/D60k2h2SKbkCI5JjszVbx45xpbTCNUdrtKfPxnTmBpfWuQbR3tgeuOEVUXI ZNqQ== MIME-Version: 1.0 X-Received: by 10.220.10.2 with SMTP id n2mr61897vcn.26.1394599971971; Tue, 11 Mar 2014 21:52:51 -0700 (PDT) Sender: markjdb@gmail.com Received: by 10.220.162.68 with HTTP; Tue, 11 Mar 2014 21:52:51 -0700 (PDT) In-Reply-To: References: <1394599542.80116.YahooMailBasic@web192602.mail.sg3.yahoo.com> Date: Wed, 12 Mar 2014 00:52:51 -0400 X-Google-Sender-Auth: 5pskDVIFaD36iCubks6taSEpft8 Message-ID: Subject: Re: dtracing static symbols From: Mark Johnston To: "Daniel O'Connor" Content-Type: text/plain; charset=ISO-8859-1 Cc: Robert Mustacchi , "freebsd-dtrace@freebsd.org" X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.17 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: Wed, 12 Mar 2014 04:52:53 -0000 On Wed, Mar 12, 2014 at 12:50 AM, Daniel O'Connor wrote: > > On 12 Mar 2014, at 15:15, Prashanth Kumar wrote: >> If you run >> # env DTRACE_DEBUG=1 dtrace -Ppid\$target -l -c ./static >> you will notice that lot of probe creation will fail, also no probes are created for instruction offsets. >> you will have to update the libproc library and fasttrap code to trace all the >> functions. > > I don't really care about the function offsets, just static functions. > > Or are you suggesting updating libproc and the fasttrap code will allow that (as well as instruction offsets)? I'd suggest updating to 9-STABLE. There have been quite a few fixes to fasttrap and libproc since 9.2. -Mark > > THanks. > >> -------------------------------------------- >> On Wed, 12/3/14, Daniel O'Connor wrote: >> >> Subject: Re: dtracing static symbols >> To: "Robert Mustacchi" >> Cc: freebsd-dtrace@freebsd.org >> Date: Wednesday, 12 March, 2014, 2:54 AM >> >> >> On 12 Mar 2014, at 2:30, Robert Mustacchi >> wrote: >>> On 03/10/2014 10:34 PM, Daniel O'Connor wrote: >>>> >>>> On 11 Mar 2014, at 15:34, Prashanth Kumar >> wrote: >>>>> If the binary being traced has static symbols >> in its symbol table, DTrace should >>>>> be able to trace the function. Can you describe >> the example where you found this >>>>> difference in FreeBSD and OSX? >>>> >>>> Unfortunately the static symbols don't show up in >> the symbol table (as shown by nm). >>>> >>>> Is there a compile or link flag which will change >> that? >>> >>> Because it's a static function the compiler may inline >> it, which may be >>> why you don't actually see an entry in nm nor that it >> can be found by >>> DTrace. You'll want to look at the disassembled output >> of your program >>> to see if it was inlined. Different compilers can and >> will do different >>> things. There generally are flags you can pass to the >> compiler to tell >>> it not to inline it, but that's compiler specific. >> >> I just realised that my test contradicted the statement I >> made earlier.. >> However I checked my test program (static.c) and it the >> functions definitely appear in the symbol table. >> [mdtest 21:13] ~ >nm static|egrep '(foo|bar)' >> 0000000000400600 T bar >> 0000000000400620 t foo >> >> I also added the noinline attribute for good measure. >> >> It seems that _nothing_ shows up for executables, only >> shared libraries, this is OK for me since my code resides in >> a library but it is a bit surprised nonetheless.. >> >>>> (I'm not sure what the various numbers mean) >>> >>> The pid provider can instrument any instruction in a >> function, those are >>> the instruction offsets. >> >> Ahh, thanks. >> >> -- >> Daniel O'Connor software and network engineer >> for Genesis Software - http://www.gsoft.com.au >> "The nice thing about standards is that there >> are so many of them to choose from." >> -- Andrew Tanenbaum >> GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 >> 7B3F CE8C >> >> >> >> >> >> >> >> > > -- > Daniel O'Connor software and network engineer > for Genesis Software - http://www.gsoft.com.au > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C > > > > > > From owner-freebsd-dtrace@FreeBSD.ORG Wed Mar 12 04:54:07 2014 Return-Path: Delivered-To: freebsd-dtrace@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D20451AF; Wed, 12 Mar 2014 04:54:07 +0000 (UTC) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 0A42514C; Wed, 12 Mar 2014 04:54:06 +0000 (UTC) Received: from ur.dons.net.au (ppp118-210-56-74.lns20.adl2.internode.on.net [118.210.56.74]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id s2C4rt5R025401 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Mar 2014 15:24:01 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Subject: Re: dtracing static symbols Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Content-Type: multipart/signed; boundary="Apple-Mail=_00D1FADF-1C5C-4564-8585-FC5FF2625082"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: "Daniel O'Connor" In-Reply-To: Date: Wed, 12 Mar 2014 15:23:55 +1030 Message-Id: <8848829A-0520-4602-9D8B-1260E0FD9A87@gsoft.com.au> References: <1394599542.80116.YahooMailBasic@web192602.mail.sg3.yahoo.com> To: Mark Johnston X-Mailer: Apple Mail (2.1874) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: Robert Mustacchi , "freebsd-dtrace@freebsd.org" X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.17 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: Wed, 12 Mar 2014 04:54:07 -0000 --Apple-Mail=_00D1FADF-1C5C-4564-8585-FC5FF2625082 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 12 Mar 2014, at 15:22, Mark Johnston wrote: > On Wed, Mar 12, 2014 at 12:50 AM, Daniel O'Connor = wrote: >>=20 >> On 12 Mar 2014, at 15:15, Prashanth Kumar = wrote: >>> If you run >>> # env DTRACE_DEBUG=3D1 dtrace -Ppid\$target -l -c ./static >>> you will notice that lot of probe creation will fail, also no probes = are created for instruction offsets. >>> you will have to update the libproc library and fasttrap code to = trace all the >>> functions. >>=20 >> I don't really care about the function offsets, just static = functions. >>=20 >> Or are you suggesting updating libproc and the fasttrap code will = allow that (as well as instruction offsets)? >=20 > I'd suggest updating to 9-STABLE. There have been quite a few fixes to > fasttrap and libproc since 9.2. OK, I'll give it a try. Have things change substantially in 10? Updating to that is probably = going to be as easy (famous last words :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --Apple-Mail=_00D1FADF-1C5C-4564-8585-FC5FF2625082 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFTH+hj5ZPcIHs/zowRAnYaAJ4p/R5bpLPTVNlyEzrrraEs+MA/LgCbBzMD lAJwX5sepmdvojJvxtsOUME= =Q9Y+ -----END PGP SIGNATURE----- --Apple-Mail=_00D1FADF-1C5C-4564-8585-FC5FF2625082-- From owner-freebsd-dtrace@FreeBSD.ORG Wed Mar 12 04:56:57 2014 Return-Path: Delivered-To: freebsd-dtrace@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 44B6F1DD; Wed, 12 Mar 2014 04:56:57 +0000 (UTC) Received: from mail-ve0-x22b.google.com (mail-ve0-x22b.google.com [IPv6:2607:f8b0:400c:c01::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id E093C15F; Wed, 12 Mar 2014 04:56:56 +0000 (UTC) Received: by mail-ve0-f171.google.com with SMTP id cz12so9591518veb.16 for ; Tue, 11 Mar 2014 21:56:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=rbV8+CmQ4gBikrwFsPpRnkY5LNsbTmsGlSGEHbK5LGE=; b=uCtk3ik/CjcLWuFwftbZeCji3SvvKpi/xHYE0M1efFlOnOHNZJTNOK3iEidWvCyPId oqvK30Uui9R2x/0NZng7bCKt5QBUHS8wpFTpvFW/FU+9/shkzlv4BiAiecdW89HgoQyG YfwYnkoohxDJ9zkPL3f2ATmvCzgpblKqCDrEpKY0mqTJPnXhJTFbbbbqhCU8HAGhEeFX KIgnTvL6TE6kEwwiT4NziUahmzN8TfWnPYbv8CaQGhya9aMQnafyYmXJo6fIUxQ/znlh YwAblSwPoSdZ49Yqp5JDLaxeIxqndBkwymVHxVYwNqF55lLTExV/IHma+P1HKT5COvcg BhLA== MIME-Version: 1.0 X-Received: by 10.220.109.1 with SMTP id h1mr30644970vcp.20.1394600216065; Tue, 11 Mar 2014 21:56:56 -0700 (PDT) Sender: markjdb@gmail.com Received: by 10.220.162.68 with HTTP; Tue, 11 Mar 2014 21:56:56 -0700 (PDT) In-Reply-To: <8848829A-0520-4602-9D8B-1260E0FD9A87@gsoft.com.au> References: <1394599542.80116.YahooMailBasic@web192602.mail.sg3.yahoo.com> <8848829A-0520-4602-9D8B-1260E0FD9A87@gsoft.com.au> Date: Wed, 12 Mar 2014 00:56:56 -0400 X-Google-Sender-Auth: PpO2Gt7Z3Vz03vE8A9yRGPkyfdw Message-ID: Subject: Re: dtracing static symbols From: Mark Johnston To: "Daniel O'Connor" Content-Type: text/plain; charset=ISO-8859-1 Cc: Robert Mustacchi , "freebsd-dtrace@freebsd.org" X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.17 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: Wed, 12 Mar 2014 04:56:57 -0000 On Wed, Mar 12, 2014 at 12:53 AM, Daniel O'Connor wrote: > > On 12 Mar 2014, at 15:22, Mark Johnston wrote: >> On Wed, Mar 12, 2014 at 12:50 AM, Daniel O'Connor wrote: >>> >>> On 12 Mar 2014, at 15:15, Prashanth Kumar wrote: >>>> If you run >>>> # env DTRACE_DEBUG=1 dtrace -Ppid\$target -l -c ./static >>>> you will notice that lot of probe creation will fail, also no probes are created for instruction offsets. >>>> you will have to update the libproc library and fasttrap code to trace all the >>>> functions. >>> >>> I don't really care about the function offsets, just static functions. >>> >>> Or are you suggesting updating libproc and the fasttrap code will allow that (as well as instruction offsets)? >> >> I'd suggest updating to 9-STABLE. There have been quite a few fixes to >> fasttrap and libproc since 9.2. > > OK, I'll give it a try. > > Have things change substantially in 10? Updating to that is probably going to be as easy (famous last words :) No, STABLE-9 and STABLE-10 should be more or less identical as far as userland DTrace is concerned. There are some extra changes on CURRENT, but I don't think they'd affect the behaviour you're seeing. -Mark From owner-freebsd-dtrace@FreeBSD.ORG Wed Mar 12 12:28:55 2014 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 ESMTPS id 7581889F; Wed, 12 Mar 2014 12:28:55 +0000 (UTC) Received: from cain.gsoft.com.au (cain.gsoft.com.au [203.31.81.10]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id D6FA6391; Wed, 12 Mar 2014 12:28:54 +0000 (UTC) Received: from ur.dons.net.au (ppp118-210-56-74.lns20.adl2.internode.on.net [118.210.56.74]) (authenticated bits=0) by cain.gsoft.com.au (8.14.4/8.14.3) with ESMTP id s2CCSZaX058259 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 12 Mar 2014 22:58:41 +1030 (CST) (envelope-from doconnor@gsoft.com.au) Subject: Re: dtracing static symbols Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Content-Type: multipart/signed; boundary="Apple-Mail=_62FEE2EA-B77D-4B2A-95AD-A26766E6C04A"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: "Daniel O'Connor" In-Reply-To: Date: Wed, 12 Mar 2014 22:58:35 +1030 Message-Id: References: <1394599542.80116.YahooMailBasic@web192602.mail.sg3.yahoo.com> <8848829A-0520-4602-9D8B-1260E0FD9A87@gsoft.com.au> To: Mark Johnston X-Mailer: Apple Mail (2.1874) X-Spam-Score: 0.163 () BAYES_00,RDNS_DYNAMIC X-Scanned-By: MIMEDefang 2.67 on 203.31.81.10 Cc: Robert Mustacchi , "freebsd-dtrace@freebsd.org" X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.17 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: Wed, 12 Mar 2014 12:28:55 -0000 --Apple-Mail=_62FEE2EA-B77D-4B2A-95AD-A26766E6C04A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On 12 Mar 2014, at 15:26, Mark Johnston wrote: > On Wed, Mar 12, 2014 at 12:53 AM, Daniel O'Connor = wrote: >>=20 >> On 12 Mar 2014, at 15:22, Mark Johnston wrote: >>> On Wed, Mar 12, 2014 at 12:50 AM, Daniel O'Connor = wrote: >>>>=20 >>>> On 12 Mar 2014, at 15:15, Prashanth Kumar = wrote: >>>>> If you run >>>>> # env DTRACE_DEBUG=3D1 dtrace -Ppid\$target -l -c ./static >>>>> you will notice that lot of probe creation will fail, also no = probes are created for instruction offsets. >>>>> you will have to update the libproc library and fasttrap code to = trace all the >>>>> functions. >>>>=20 >>>> I don't really care about the function offsets, just static = functions. >>>>=20 >>>> Or are you suggesting updating libproc and the fasttrap code will = allow that (as well as instruction offsets)? >>>=20 >>> I'd suggest updating to 9-STABLE. There have been quite a few fixes = to >>> fasttrap and libproc since 9.2. >>=20 >> OK, I'll give it a try. >>=20 >> Have things change substantially in 10? Updating to that is probably = going to be as easy (famous last words :) >=20 > No, STABLE-9 and STABLE-10 should be more or less identical as far as > userland DTrace is concerned. There are some extra changes on CURRENT, > but I don't think they'd affect the behaviour you're seeing. OK, I upgraded to r263061 and I can now see static variables, thanks! -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C --Apple-Mail=_62FEE2EA-B77D-4B2A-95AD-A26766E6C04A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iD8DBQFTIFLz5ZPcIHs/zowRAq3xAJ9LVk8/qpMAT7qUUsvVkUA59MOy5QCffv/3 tnHZndnP2Ka6DedcKYv2VgU= =jSRy -----END PGP SIGNATURE----- --Apple-Mail=_62FEE2EA-B77D-4B2A-95AD-A26766E6C04A-- From owner-freebsd-dtrace@FreeBSD.ORG Wed Apr 16 00:35:19 2014 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 ESMTPS id 95ED0912 for ; Wed, 16 Apr 2014 00:35:19 +0000 (UTC) Received: from mail-oa0-x22c.google.com (mail-oa0-x22c.google.com [IPv6:2607:f8b0:4003:c02::22c]) (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 62987118A for ; Wed, 16 Apr 2014 00:35:19 +0000 (UTC) Received: by mail-oa0-f44.google.com with SMTP id n16so11781194oag.31 for ; Tue, 15 Apr 2014 17:35:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=X/Wl68ASQXyye442pNMMh0zM6Fxz9fsekcAg5GAPK8A=; b=FRJo+wucRfnR4SYYOZfIkJDNUnjWqcMuZWzKp3UxAUuDdyynDWvC3x87HGOE1rHI4y nTOnSrEG6kxDIBbD1zXO8mCy4lFpeyA1zOugMezzQHLjbz9EI660m9AjIw3GSt6tpYIu NMWzmvBEmDcEPP5uN2YXtEV3s7IZk42HI6chHwJ904MKiq/7MaqaYs3Y+kVv1HxrZr2H asFHvCIZbCu6FqK0KGy28MYwvUHeGI7JpXHtHC+N6EUQzMjIBx26kwHVW6/s6Y8Vddhj AAySdjxXnWAV6YzF+ROgyxursEz/3Ls8+7N7nMxdvZzdqkEAwjdz7ofoFeUHGYFr49U0 VvPw== MIME-Version: 1.0 X-Received: by 10.182.105.1 with SMTP id gi1mr4073762obb.9.1397608518719; Tue, 15 Apr 2014 17:35:18 -0700 (PDT) Received: by 10.182.172.105 with HTTP; Tue, 15 Apr 2014 17:35:18 -0700 (PDT) Date: Tue, 15 Apr 2014 21:35:18 -0300 Message-ID: Subject: uaddr and friends From: carlos antonio neira bustos To: freebsd-dtrace@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.17 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: Wed, 16 Apr 2014 00:35:19 -0000 Hi All, I was looking at Dtrace todo list from https://wiki.freebsd.org/DTraceTODO and started to work on : Get uaddr(), ufunc(), umod(), and usym() action funtions working. I have the data recording action (uaddr) working now, here is an example: root@bsd:/home/cneira # dtrace -n 'pid$target::main:{uaddr(uregs[R_PC])}' -c ./test dtrace: description 'pid$target::main:' matched 2 probes abCPU ID FUNCTION:NAME 0 56282 main:entry test`main+0x1 0 56281 main:return test`main+0x23 dtrace: pid 9687 has exited Here is the output of nm from the test binary I have used to check this change. U _init_tls@@FBSD_1.0 08048380 T _start 080483a0 t _start1 0804814c r abitag U atexit@@FBSD_1.0 08048164 r crt_noinit_tag 080485c0 T dosomething 08049764 B environ U exit@@FBSD_1.0 080484f0 t finalizer 08048560 t frame_dummy 08048590 T main U putchar@@FBSD_1.0 root@bsd:/home/cneira # dtrace -c ./test -n 'pid$target::main:entry{ uaddr(0x080485c0); }' dtrace: description 'pid$target::main:entry' matched 1 probe abCPU ID FUNCTION:NAME 0 56281 main:entry test`dosomething dtrace: pid 9736 has exited I'll continue working on the rest, how do I submit a patch with these changes ? Bests From owner-freebsd-dtrace@FreeBSD.ORG Wed Apr 16 01:09:04 2014 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 ESMTPS id 156D57B6 for ; Wed, 16 Apr 2014 01:09:04 +0000 (UTC) Received: from mail-ig0-x235.google.com (mail-ig0-x235.google.com [IPv6:2607:f8b0:4001:c05::235]) (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 D987B14A8 for ; Wed, 16 Apr 2014 01:09:03 +0000 (UTC) Received: by mail-ig0-f181.google.com with SMTP id h18so477287igc.8 for ; Tue, 15 Apr 2014 18:09:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=Htbtq5Qv/fJFnMgdgiaLpTzho9jPRwDIVx7OvLQIe3c=; b=uDPBaE9mLWsUi0NKY/3AwyCgcZq1+sUVfPtcWnDL2dciEQBWZMXQB+8fHnshMPJhGo AdBhGl6j8gVdcdQxHN0ldysrKJ1WaA8iEwlxTKuAdO/dV6BuRmBVQd3pBuvVT7ob43jB +CGJmeU3icAfV6TFyt6SgWO5vCR3Vou/+GcdSb50gw77nohPIcPFDEQJ+UdOXjooaBgQ 7j6Hkr3vsmuMbIAgGDi5wL87EwW0NHGBM6wsS8JRkqDIpu3SLvv/QX8CkSfSGHwAj2h5 kijAXktafwLZNz/OYDK4iBDb6HbZjd+F3iOi4yumiT5utxWvaR2iBDHpkUW9dGPYAVSb fWpg== MIME-Version: 1.0 X-Received: by 10.50.30.170 with SMTP id t10mr1545432igh.7.1397610543352; Tue, 15 Apr 2014 18:09:03 -0700 (PDT) Sender: markjdb@gmail.com Received: by 10.64.19.241 with HTTP; Tue, 15 Apr 2014 18:09:03 -0700 (PDT) In-Reply-To: References: Date: Tue, 15 Apr 2014 21:09:03 -0400 X-Google-Sender-Auth: LtXWADW-H5eB4SR4IqWw3w_j-xM Message-ID: Subject: Re: uaddr and friends From: Mark Johnston To: carlos antonio neira bustos Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-dtrace@freebsd.org" X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.17 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: Wed, 16 Apr 2014 01:09:04 -0000 On Tue, Apr 15, 2014 at 8:35 PM, carlos antonio neira bustos wrote: > Hi All, > > I was looking at Dtrace todo list from https://wiki.freebsd.org/DTraceTODO > and started to work on : Get uaddr(), ufunc(), umod(), and usym() action > funtions working. > I have the data recording action (uaddr) working now, here is an > example: Hi! Hm, these should have been (at least mostly) working since r258902: http://svnweb.freebsd.org/base?view=revision&revision=258902 > > root@bsd:/home/cneira # dtrace -n 'pid$target::main:{uaddr(uregs[R_PC])}' > -c ./test > dtrace: description 'pid$target::main:' matched 2 probes > abCPU ID FUNCTION:NAME > 0 56282 main:entry > test`main+0x1 > > 0 56281 main:return > test`main+0x23 > > dtrace: pid 9687 has exited > > Here is the output of nm from the test binary I have used to check this > change. > > U _init_tls@@FBSD_1.0 > 08048380 T _start > 080483a0 t _start1 > 0804814c r abitag > U atexit@@FBSD_1.0 > 08048164 r crt_noinit_tag > 080485c0 T dosomething > 08049764 B environ > U exit@@FBSD_1.0 > 080484f0 t finalizer > 08048560 t frame_dummy > 08048590 T main > U putchar@@FBSD_1.0 > > > root@bsd:/home/cneira # dtrace -c ./test -n 'pid$target::main:entry{ > uaddr(0x080485c0); }' > dtrace: description 'pid$target::main:entry' matched 1 probe > abCPU ID FUNCTION:NAME > 0 56281 main:entry > test`dosomething > > dtrace: pid 9736 has exited > > I'll continue working on the rest, how do I submit a patch with these > changes ? Pasting it inline is generally fine if it's not too large. It's also ok to put it in a public directory somewhere and post a link to it. -Mark From owner-freebsd-dtrace@FreeBSD.ORG Wed Apr 16 02:15:59 2014 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 ESMTPS id BEDF11DC; Wed, 16 Apr 2014 02:15:59 +0000 (UTC) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) (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 797161AED; Wed, 16 Apr 2014 02:15:59 +0000 (UTC) Received: by mail-ob0-f172.google.com with SMTP id wo20so1916900obc.17 for ; Tue, 15 Apr 2014 19:15:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=bucD8QdyMlk+03kLkPdoE1snO+Y0SlZtAHMf7qNRW8g=; b=gmWmiGyJXF1VI8mLNbG8JYHiRA/iCwxsxH2TTv9Vl/b8weK2G0atwqTd6z5ABbiMRG h28HpaBA6BV31cJdUHwdBKoKHYBkfnRTiHtoGp/Q+DGgDejaCQugfjZzv+vAVVLQq47H 9fDSWkcxgbqyfE3YV88Fjn2V1kStLurnea9IjT9NYKakU2n1qRRtwxo06M25ourHn0DV 2tFgPq7+A7U32dFxrwmvFdUFjhSvJ/epQJemMzUAaf7grqDLwdgJ/ljfJQQyKmCDoLuh vXG21OOq4Ghs967ahaosiSvbSxbpsLGlDANi7FctTpjgV3pusOfDe0TP7JlAxBRiW9CI ug6g== MIME-Version: 1.0 X-Received: by 10.182.153.226 with SMTP id vj2mr4420086obb.26.1397614558640; Tue, 15 Apr 2014 19:15:58 -0700 (PDT) Received: by 10.182.172.105 with HTTP; Tue, 15 Apr 2014 19:15:58 -0700 (PDT) In-Reply-To: References: Date: Tue, 15 Apr 2014 23:15:58 -0300 Message-ID: Subject: Re: uaddr and friends From: carlos antonio neira bustos To: Mark Johnston Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-dtrace@freebsd.org" X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.17 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: Wed, 16 Apr 2014 02:15:59 -0000 Hi Mark, I was looking at this document https://wikis.oracle.com/display/DTrace/Actions+and+Subroutines#ActionsandSubroutines-%7B%7Busym%7D%7D currently looking at the code uaddr is the same as usym, but according to this document usym will print the symbol for a specified address. This is analogous to how uaddr works, but without the hexadecimal offsets. uaddr: date`clock_val+0x1 usym: date`clock_val here are my outputs from usym and uaddr : root@bsd:/home/cneira # dtrace -n 'pid$target::main:{usym(uregs[R_PC])}' -c ./test dtrace: description 'pid$target::main:' matched 2 probes abCPU ID FUNCTION:NAME 0 56282 main:entry test`main 0 56281 main:return test`main dtrace: pid 10588 has exited root@bsd:/home/cneira # dtrace -n 'pid$target::main:{uaddr(uregs[R_PC])}' -c ./test dtrace: description 'pid$target::main:' matched 2 probes abCPU ID FUNCTION:NAME 0 56282 main:entry test`main+0x1 0 56281 main:return test`main+0x23 dtrace: pid 10591 has exited As current is only using dt_print_usym for uaddr the output should not have the hexadecimal offset specified in that documentation. So I'm somewhat lost about which is the correct behavior , Do you have a uaddr and usym output example in current to check this?, all my changes were done in 10 prod release. Bests On Tue, Apr 15, 2014 at 10:09 PM, Mark Johnston wrote: > On Tue, Apr 15, 2014 at 8:35 PM, carlos antonio neira bustos > wrote: > > Hi All, > > > > I was looking at Dtrace todo list from > https://wiki.freebsd.org/DTraceTODO > > and started to work on : Get uaddr(), ufunc(), umod(), and usym() action > > funtions working. > > I have the data recording action (uaddr) working now, here is an > > example: > > Hi! > > Hm, these should have been (at least mostly) working since r258902: > http://svnweb.freebsd.org/base?view=revision&revision=258902 > > > > > root@bsd:/home/cneira # dtrace -n > 'pid$target::main:{uaddr(uregs[R_PC])}' > > -c ./test > > dtrace: description 'pid$target::main:' matched 2 probes > > abCPU ID FUNCTION:NAME > > 0 56282 main:entry > > test`main+0x1 > > > > 0 56281 main:return > > test`main+0x23 > > > > dtrace: pid 9687 has exited > > > > Here is the output of nm from the test binary I have used to check this > > change. > > > > U _init_tls@@FBSD_1.0 > > 08048380 T _start > > 080483a0 t _start1 > > 0804814c r abitag > > U atexit@@FBSD_1.0 > > 08048164 r crt_noinit_tag > > 080485c0 T dosomething > > 08049764 B environ > > U exit@@FBSD_1.0 > > 080484f0 t finalizer > > 08048560 t frame_dummy > > 08048590 T main > > U putchar@@FBSD_1.0 > > > > > > root@bsd:/home/cneira # dtrace -c ./test -n 'pid$target::main:entry{ > > uaddr(0x080485c0); }' > > dtrace: description 'pid$target::main:entry' matched 1 probe > > abCPU ID FUNCTION:NAME > > 0 56281 main:entry > > test`dosomething > > > > dtrace: pid 9736 has exited > > > > I'll continue working on the rest, how do I submit a patch with these > > changes ? > > Pasting it inline is generally fine if it's not too large. It's also > ok to put it in a public directory somewhere and post a link to it. > > -Mark > From owner-freebsd-dtrace@FreeBSD.ORG Wed Apr 16 02:36:10 2014 Return-Path: Delivered-To: freebsd-dtrace@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B22F74C1; Wed, 16 Apr 2014 02:36:10 +0000 (UTC) Received: from mail-ie0-x22f.google.com (mail-ie0-x22f.google.com [IPv6:2607:f8b0:4001:c03::22f]) (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 75C001C78; Wed, 16 Apr 2014 02:36:10 +0000 (UTC) Received: by mail-ie0-f175.google.com with SMTP id to1so9971656ieb.34 for ; Tue, 15 Apr 2014 19:36:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=eYjp1U+DC+peniCukKCI+KL/YUDlBTVmgudLpVtiFi0=; b=SIO+1SQSonbC8b/TkGLCWotRfmUn2a894XwNF37Fk9BpdpB1asXhvIJXCrmVGIst6f ejTosVPUPs36LgDzOHOZPp2hXU2QCZuYaWm+wnJj21zeFldmK4HQNBUEzIxjhM70N/e0 TjL2AnDHmwZ//rkqqH/wxlyj7FJCqfMMvWRdX6dd1OZ1maAk9WKl8unCvPnEnHS1rKkM F71oQKV5luPTZTNVZO8HaEQQ899VZ0hG8E4C0ncHrPgH2gqrN9YgtK0q58Gp6K9Feic4 D5kH7j+giLxWJfLiRhE4Fr6+PakF6JtnSdPLiNxyAvqUcNMmC/lELzraMFMpgVWIymgt +y0w== MIME-Version: 1.0 X-Received: by 10.50.30.170 with SMTP id t10mr1840254igh.7.1397615769825; Tue, 15 Apr 2014 19:36:09 -0700 (PDT) Sender: markjdb@gmail.com Received: by 10.64.19.241 with HTTP; Tue, 15 Apr 2014 19:36:09 -0700 (PDT) In-Reply-To: References: Date: Tue, 15 Apr 2014 22:36:09 -0400 X-Google-Sender-Auth: 3P0MVpeTjBxSn03kQPwUQoeGoiY Message-ID: Subject: Re: uaddr and friends From: Mark Johnston To: carlos antonio neira bustos Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-dtrace@freebsd.org" X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.17 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: Wed, 16 Apr 2014 02:36:10 -0000 On Tue, Apr 15, 2014 at 10:15 PM, carlos antonio neira bustos wrote: > Hi Mark, > > I was looking at this document > https://wikis.oracle.com/display/DTrace/Actions+and+Subroutines#ActionsandSubroutines-%7B%7Busym%7D%7D > currently looking at the code uaddr is the same as usym, but according to > this document > > usym will print the symbol for a specified address. This is analogous to how > uaddr works, but without the hexadecimal offsets. > > uaddr: date`clock_val+0x1 > usym: date`clock_val > > > here are my outputs from usym and uaddr : > > root@bsd:/home/cneira # dtrace -n 'pid$target::main:{usym(uregs[R_PC])}' -c > ./test > dtrace: description 'pid$target::main:' matched 2 probes > abCPU ID FUNCTION:NAME > 0 56282 main:entry test`main > 0 56281 main:return test`main > dtrace: pid 10588 has exited > > root@bsd:/home/cneira # dtrace -n 'pid$target::main:{uaddr(uregs[R_PC])}' -c > ./test > dtrace: description 'pid$target::main:' matched 2 probes > abCPU ID FUNCTION:NAME > 0 56282 main:entry > test`main+0x1 > > 0 56281 main:return > test`main+0x23 > > dtrace: pid 10591 has exited > > As current is only using dt_print_usym for uaddr the output should not have > the hexadecimal offset specified in that documentation. > So I'm somewhat lost about which is the correct behavior , Do you have a > uaddr and usym output example in current to check this?, all my changes > were done in 10 prod release. You're right, dt_print_usym handles both usym and uaddr. In the usym case, there's some special handling which looks up the symbol name corresponding to the given pc, and then sets the pc variable to the address of the symbol. Then dtrace_uaddr2str only prints the offset from the symbol if that offset is non-zero, so in the uaddr case you get "+0x1" and "+0x23" above. > > Bests > > > > > > > > On Tue, Apr 15, 2014 at 10:09 PM, Mark Johnston wrote: >> >> On Tue, Apr 15, 2014 at 8:35 PM, carlos antonio neira bustos >> wrote: >> > Hi All, >> > >> > I was looking at Dtrace todo list from >> > https://wiki.freebsd.org/DTraceTODO >> > and started to work on : Get uaddr(), ufunc(), umod(), and usym() action >> > funtions working. >> > I have the data recording action (uaddr) working now, here is an >> > example: >> >> Hi! >> >> Hm, these should have been (at least mostly) working since r258902: >> http://svnweb.freebsd.org/base?view=revision&revision=258902 >> >> > >> > root@bsd:/home/cneira # dtrace -n >> > 'pid$target::main:{uaddr(uregs[R_PC])}' >> > -c ./test >> > dtrace: description 'pid$target::main:' matched 2 probes >> > abCPU ID FUNCTION:NAME >> > 0 56282 main:entry >> > test`main+0x1 >> > >> > 0 56281 main:return >> > test`main+0x23 >> > >> > dtrace: pid 9687 has exited >> > >> > Here is the output of nm from the test binary I have used to check this >> > change. >> > >> > U _init_tls@@FBSD_1.0 >> > 08048380 T _start >> > 080483a0 t _start1 >> > 0804814c r abitag >> > U atexit@@FBSD_1.0 >> > 08048164 r crt_noinit_tag >> > 080485c0 T dosomething >> > 08049764 B environ >> > U exit@@FBSD_1.0 >> > 080484f0 t finalizer >> > 08048560 t frame_dummy >> > 08048590 T main >> > U putchar@@FBSD_1.0 >> > >> > >> > root@bsd:/home/cneira # dtrace -c ./test -n 'pid$target::main:entry{ >> > uaddr(0x080485c0); }' >> > dtrace: description 'pid$target::main:entry' matched 1 probe >> > abCPU ID FUNCTION:NAME >> > 0 56281 main:entry >> > test`dosomething >> > >> > dtrace: pid 9736 has exited >> > >> > I'll continue working on the rest, how do I submit a patch with these >> > changes ? >> >> Pasting it inline is generally fine if it's not too large. It's also >> ok to put it in a public directory somewhere and post a link to it. >> >> -Mark > > From owner-freebsd-dtrace@FreeBSD.ORG Wed Apr 16 02:54:21 2014 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 ESMTPS id D1F67728; Wed, 16 Apr 2014 02:54:21 +0000 (UTC) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) (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 8B0C31DF1; Wed, 16 Apr 2014 02:54:21 +0000 (UTC) Received: by mail-ob0-f176.google.com with SMTP id wp4so157064obc.7 for ; Tue, 15 Apr 2014 19:54:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=AGKbT7E/qpRQN0C8N4ZRZZv8LMBMoe/RfAgWrO9ZRAk=; b=xD7ojLsmWgw2A2onG1hzHakteOZcB5b9S8RGdoivr/4uA1T9njgTXUNBOiiYqH/N9p ptIEmfrayq/xJG6JFkBtDfLlaQzhhhd2h4gW39GhmydS21ukZWx/nRl8XWw0QWephztp B5nYJpib+e8teMUAiEGerQPPj9ESjsVph+DqjK4nZF+sQ1OjuyRaBBEiP2SGlRrffmv0 Dulr7NOp5225Cfk0UOFAnJlLGH0YOmAYH7tC4xucmxrTrgJvMR42+3kmRlf8gSG+T1w7 LiadoOZcAmpM0d4fBAIqoLbrDQ7o47YtWZ8Hd0AWoKz34itZ2KbaT7p4UsDO5az3W4L/ ipxA== MIME-Version: 1.0 X-Received: by 10.60.65.1 with SMTP id t1mr4449372oes.7.1397616860770; Tue, 15 Apr 2014 19:54:20 -0700 (PDT) Received: by 10.182.172.105 with HTTP; Tue, 15 Apr 2014 19:54:20 -0700 (PDT) In-Reply-To: References: Date: Tue, 15 Apr 2014 23:54:20 -0300 Message-ID: Subject: Re: uaddr and friends From: carlos antonio neira bustos To: Mark Johnston Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 Cc: "freebsd-dtrace@freebsd.org" X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.17 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: Wed, 16 Apr 2014 02:54:21 -0000 Thanks Mark. You are right, I did not look at dt_subr.c, uaddr is a short version of ustack, I'll update to current now and try to pick on something else from the list. Bests On Tue, Apr 15, 2014 at 11:36 PM, Mark Johnston wrote: > On Tue, Apr 15, 2014 at 10:15 PM, carlos antonio neira bustos > wrote: > > Hi Mark, > > > > I was looking at this document > > > https://wikis.oracle.com/display/DTrace/Actions+and+Subroutines#ActionsandSubroutines-%7B%7Busym%7D%7D > > currently looking at the code uaddr is the same as usym, but according to > > this document > > > > usym will print the symbol for a specified address. This is analogous to > how > > uaddr works, but without the hexadecimal offsets. > > > > uaddr: date`clock_val+0x1 > > usym: date`clock_val > > > > > > here are my outputs from usym and uaddr : > > > > root@bsd:/home/cneira # dtrace -n > 'pid$target::main:{usym(uregs[R_PC])}' -c > > ./test > > dtrace: description 'pid$target::main:' matched 2 probes > > abCPU ID FUNCTION:NAME > > 0 56282 main:entry test`main > > 0 56281 main:return test`main > > dtrace: pid 10588 has exited > > > > root@bsd:/home/cneira # dtrace -n > 'pid$target::main:{uaddr(uregs[R_PC])}' -c > > ./test > > dtrace: description 'pid$target::main:' matched 2 probes > > abCPU ID FUNCTION:NAME > > 0 56282 main:entry > > test`main+0x1 > > > > 0 56281 main:return > > test`main+0x23 > > > > dtrace: pid 10591 has exited > > > > As current is only using dt_print_usym for uaddr the output should not > have > > the hexadecimal offset specified in that documentation. > > So I'm somewhat lost about which is the correct behavior , Do you have a > > uaddr and usym output example in current to check this?, all my changes > > were done in 10 prod release. > > You're right, dt_print_usym handles both usym and uaddr. In the usym > case, there's some special handling which looks up the symbol name > corresponding to the given pc, and then sets the pc variable to the > address of the symbol. Then dtrace_uaddr2str only prints the offset > from the symbol if that offset is non-zero, so in the uaddr case you > get "+0x1" and "+0x23" above. > > > > > Bests > > > > > > > > > > > > > > > > On Tue, Apr 15, 2014 at 10:09 PM, Mark Johnston > wrote: > >> > >> On Tue, Apr 15, 2014 at 8:35 PM, carlos antonio neira bustos > >> wrote: > >> > Hi All, > >> > > >> > I was looking at Dtrace todo list from > >> > https://wiki.freebsd.org/DTraceTODO > >> > and started to work on : Get uaddr(), ufunc(), umod(), and usym() > action > >> > funtions working. > >> > I have the data recording action (uaddr) working now, here is an > >> > example: > >> > >> Hi! > >> > >> Hm, these should have been (at least mostly) working since r258902: > >> http://svnweb.freebsd.org/base?view=revision&revision=258902 > >> > >> > > >> > root@bsd:/home/cneira # dtrace -n > >> > 'pid$target::main:{uaddr(uregs[R_PC])}' > >> > -c ./test > >> > dtrace: description 'pid$target::main:' matched 2 probes > >> > abCPU ID FUNCTION:NAME > >> > 0 56282 main:entry > >> > test`main+0x1 > >> > > >> > 0 56281 main:return > >> > test`main+0x23 > >> > > >> > dtrace: pid 9687 has exited > >> > > >> > Here is the output of nm from the test binary I have used to check > this > >> > change. > >> > > >> > U _init_tls@@FBSD_1.0 > >> > 08048380 T _start > >> > 080483a0 t _start1 > >> > 0804814c r abitag > >> > U atexit@@FBSD_1.0 > >> > 08048164 r crt_noinit_tag > >> > 080485c0 T dosomething > >> > 08049764 B environ > >> > U exit@@FBSD_1.0 > >> > 080484f0 t finalizer > >> > 08048560 t frame_dummy > >> > 08048590 T main > >> > U putchar@@FBSD_1.0 > >> > > >> > > >> > root@bsd:/home/cneira # dtrace -c ./test -n 'pid$target::main:entry{ > >> > uaddr(0x080485c0); }' > >> > dtrace: description 'pid$target::main:entry' matched 1 probe > >> > abCPU ID FUNCTION:NAME > >> > 0 56281 main:entry > >> > test`dosomething > >> > > >> > dtrace: pid 9736 has exited > >> > > >> > I'll continue working on the rest, how do I submit a patch with these > >> > changes ? > >> > >> Pasting it inline is generally fine if it's not too large. It's also > >> ok to put it in a public directory somewhere and post a link to it. > >> > >> -Mark > > > > > From owner-freebsd-dtrace@FreeBSD.ORG Wed Apr 16 03:16:10 2014 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 ESMTPS id C73E2D9E; Wed, 16 Apr 2014 03:16:10 +0000 (UTC) Received: from mail-ie0-x231.google.com (mail-ie0-x231.google.com [IPv6:2607:f8b0:4001:c03::231]) (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 8927411E0; Wed, 16 Apr 2014 03:16:10 +0000 (UTC) Received: by mail-ie0-f177.google.com with SMTP id rl12so9953326iec.22 for ; Tue, 15 Apr 2014 20:16:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=t0AyfEantD8uzD8xuD/ARi34YrhxxvE3EtJ+AWR8ueQ=; b=Qj4TuXuoXsSHYRdGtojVvPYY2/pwzpBqiizsjQusBQqwN6KJmf95ehwykLceWaHIK/ 7BroT4vmAySNFYAiIcetH+o+LDnENBcqZi/pd1m5GfawN6EztQicbr08mSzMjnjLnnZn NSxYSvUFz/ttAqxXNxW+6nhTOlfbk+xD23XZileH8P1HOStfNV4ijDTqEaAYMFbnv8V5 lSkPa/XHMAIYXlYU9f144nH+vLZDyfvaxMWx+cU2lyVeutcnhvcsPranFy4bpPMOmcPB E7nbpoAbeIEDD4AUVgCvwnlAHjTGcD47vTd+ERMBNHYHB7xIKwZgrQIH80OAYN2ro46c X8eg== MIME-Version: 1.0 X-Received: by 10.42.247.132 with SMTP id mc4mr1690730icb.44.1397618169446; Tue, 15 Apr 2014 20:16:09 -0700 (PDT) Sender: markjdb@gmail.com Received: by 10.64.19.241 with HTTP; Tue, 15 Apr 2014 20:16:09 -0700 (PDT) In-Reply-To: References: Date: Tue, 15 Apr 2014 23:16:09 -0400 X-Google-Sender-Auth: uW1q5G7_gBGO2LQdRouik0qE9Q4 Message-ID: Subject: Re: uaddr and friends From: Mark Johnston To: carlos antonio neira bustos Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-dtrace@freebsd.org" X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.17 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: Wed, 16 Apr 2014 03:16:10 -0000 On Tue, Apr 15, 2014 at 10:54 PM, carlos antonio neira bustos wrote: > Thanks Mark. > > You are right, I did not look at dt_subr.c, uaddr is a short version of > ustack, I'll update to current now and try to pick on something else from > the list. Thanks! I've updated the TODOs a bit. I find that a good way to find things to do is to just try random DTrace scripts until something fails reproducibly. Large processes like firefox and Xorg have been a fertile source of bugs. :) And yes, please update to CURRENT; there have been quite a few bugs fixed since 10.0. FreeBSD 10.1 will have much better userland DTrace support. -Mark > > Bests > > > On Tue, Apr 15, 2014 at 11:36 PM, Mark Johnston wrote: >> >> On Tue, Apr 15, 2014 at 10:15 PM, carlos antonio neira bustos >> wrote: >> > Hi Mark, >> > >> > I was looking at this document >> > >> > https://wikis.oracle.com/display/DTrace/Actions+and+Subroutines#ActionsandSubroutines-%7B%7Busym%7D%7D >> > currently looking at the code uaddr is the same as usym, but according >> > to >> > this document >> > >> > usym will print the symbol for a specified address. This is analogous to >> > how >> > uaddr works, but without the hexadecimal offsets. >> > >> > uaddr: date`clock_val+0x1 >> > usym: date`clock_val >> > >> > >> > here are my outputs from usym and uaddr : >> > >> > root@bsd:/home/cneira # dtrace -n 'pid$target::main:{usym(uregs[R_PC])}' >> > -c >> > ./test >> > dtrace: description 'pid$target::main:' matched 2 probes >> > abCPU ID FUNCTION:NAME >> > 0 56282 main:entry test`main >> > 0 56281 main:return test`main >> > dtrace: pid 10588 has exited >> > >> > root@bsd:/home/cneira # dtrace -n >> > 'pid$target::main:{uaddr(uregs[R_PC])}' -c >> > ./test >> > dtrace: description 'pid$target::main:' matched 2 probes >> > abCPU ID FUNCTION:NAME >> > 0 56282 main:entry >> > test`main+0x1 >> > >> > 0 56281 main:return >> > test`main+0x23 >> > >> > dtrace: pid 10591 has exited >> > >> > As current is only using dt_print_usym for uaddr the output should not >> > have >> > the hexadecimal offset specified in that documentation. >> > So I'm somewhat lost about which is the correct behavior , Do you have a >> > uaddr and usym output example in current to check this?, all my >> > changes >> > were done in 10 prod release. >> >> You're right, dt_print_usym handles both usym and uaddr. In the usym >> case, there's some special handling which looks up the symbol name >> corresponding to the given pc, and then sets the pc variable to the >> address of the symbol. Then dtrace_uaddr2str only prints the offset >> from the symbol if that offset is non-zero, so in the uaddr case you >> get "+0x1" and "+0x23" above. >> >> > >> > Bests >> > >> > >> > >> > >> > >> > >> > >> > On Tue, Apr 15, 2014 at 10:09 PM, Mark Johnston >> > wrote: >> >> >> >> On Tue, Apr 15, 2014 at 8:35 PM, carlos antonio neira bustos >> >> wrote: >> >> > Hi All, >> >> > >> >> > I was looking at Dtrace todo list from >> >> > https://wiki.freebsd.org/DTraceTODO >> >> > and started to work on : Get uaddr(), ufunc(), umod(), and usym() >> >> > action >> >> > funtions working. >> >> > I have the data recording action (uaddr) working now, here is an >> >> > example: >> >> >> >> Hi! >> >> >> >> Hm, these should have been (at least mostly) working since r258902: >> >> http://svnweb.freebsd.org/base?view=revision&revision=258902 >> >> >> >> > >> >> > root@bsd:/home/cneira # dtrace -n >> >> > 'pid$target::main:{uaddr(uregs[R_PC])}' >> >> > -c ./test >> >> > dtrace: description 'pid$target::main:' matched 2 probes >> >> > abCPU ID FUNCTION:NAME >> >> > 0 56282 main:entry >> >> > test`main+0x1 >> >> > >> >> > 0 56281 main:return >> >> > test`main+0x23 >> >> > >> >> > dtrace: pid 9687 has exited >> >> > >> >> > Here is the output of nm from the test binary I have used to check >> >> > this >> >> > change. >> >> > >> >> > U _init_tls@@FBSD_1.0 >> >> > 08048380 T _start >> >> > 080483a0 t _start1 >> >> > 0804814c r abitag >> >> > U atexit@@FBSD_1.0 >> >> > 08048164 r crt_noinit_tag >> >> > 080485c0 T dosomething >> >> > 08049764 B environ >> >> > U exit@@FBSD_1.0 >> >> > 080484f0 t finalizer >> >> > 08048560 t frame_dummy >> >> > 08048590 T main >> >> > U putchar@@FBSD_1.0 >> >> > >> >> > >> >> > root@bsd:/home/cneira # dtrace -c ./test -n 'pid$target::main:entry{ >> >> > uaddr(0x080485c0); }' >> >> > dtrace: description 'pid$target::main:entry' matched 1 probe >> >> > abCPU ID FUNCTION:NAME >> >> > 0 56281 main:entry >> >> > test`dosomething >> >> > >> >> > dtrace: pid 9736 has exited >> >> > >> >> > I'll continue working on the rest, how do I submit a patch with >> >> > these >> >> > changes ? >> >> >> >> Pasting it inline is generally fine if it's not too large. It's also >> >> ok to put it in a public directory somewhere and post a link to it. >> >> >> >> -Mark >> > >> > > > From owner-freebsd-dtrace@FreeBSD.ORG Fri Apr 18 03:03:43 2014 Return-Path: Delivered-To: freebsd-dtrace@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 00D709B4 for ; Fri, 18 Apr 2014 03:03:42 +0000 (UTC) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) (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 C144613DF for ; Fri, 18 Apr 2014 03:03:42 +0000 (UTC) Received: by mail-ob0-f176.google.com with SMTP id wp4so1312433obc.21 for ; Thu, 17 Apr 2014 20:03:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=G/aQVklpchPwzeeBhMPg+41ItvN5tRiCWcyE4CsGgtk=; b=KsDSOq2x+3XsMFbmSoaxlSXhEWkIfKFFfdBvOOUpqAezRTCfnfDOI4wYM7aLPSHKJc ciViLiDaHth73n77kfbIYbuemwK/hdEHacrjLgql8PEKkfb8tnUopm8861yiyDUu7AC6 5YjBq4iZKrloIVhwwph3FdpR05ygxNUEPNkwo8yHZg7qn3UMhxnlwXl8U3Ei62kc3lzN M7Fh4Gy5pFj7OZvYCdsQ+l3eo4h+2rHBW1DvQQ/MVlHOgh3PvIwFdbQCMUH6hdUyefAf Aem0IW4rjjki/U1ZZ6NAQqkSdYX1ZcvDWHqOwMrjdY22w/8awq8RZMJOir6RFuugVvE8 Lt0Q== MIME-Version: 1.0 X-Received: by 10.60.142.229 with SMTP id rz5mr14865672oeb.1.1397790221946; Thu, 17 Apr 2014 20:03:41 -0700 (PDT) Received: by 10.182.172.105 with HTTP; Thu, 17 Apr 2014 20:03:41 -0700 (PDT) Date: Fri, 18 Apr 2014 00:03:41 -0300 Message-ID: Subject: vminfo provider From: carlos antonio neira bustos To: "freebsd-dtrace@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.17 X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.17 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, 18 Apr 2014 03:03:43 -0000 Hi All, If the vminfo provider is not available, could I get the same functionality from the vm_* probes? I mean, for example this one liner in Solaris: dtrace -n pgin'{@[execname] = count()}' Is the same as doing this in FreeBSD ? dtrace -n vm_page_insert:entry'{ @[execname] = count();}' Bests From owner-freebsd-dtrace@FreeBSD.ORG Mon Apr 21 16:18:49 2014 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 ESMTPS id D3DB8122 for ; Mon, 21 Apr 2014 16:18:49 +0000 (UTC) Received: from mail-ve0-x234.google.com (mail-ve0-x234.google.com [IPv6:2607:f8b0:400c:c01::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 9381C1857 for ; Mon, 21 Apr 2014 16:18:49 +0000 (UTC) Received: by mail-ve0-f180.google.com with SMTP id jz11so7853498veb.25 for ; Mon, 21 Apr 2014 09:18:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=3UEX8JaoamnZ8tD+VFYLnwTFFmkdJ8iDGCjPLqETNRk=; b=PWXXDsKSs29FVrYNPY0b8lr7S7gB/b/ro2xX2IN9APdGDTQT7PMRE4OZVAHsKDrM8+ UC7KWX4NoTA+eW0FExXWVghEUFCUNnB9rwc0jAF3d6QEg+6Zz+kOKm+QWIo6k9+uKxiO VfUsdvkVV+w3F8aK2Rop8fOsKH5aaidAEVQ+v7F1tNXYvUyS88bzTOjzZCBRkliOWZ5C WAShD/fq2Ed/nR/+b6O6uHvzYf4NBb4q7UNED2mEuqcW6iz6DLn64nfqtY0/AAHygGnr jK2gPr63JtX6i8n6osTBrhQPUMYwyU1AiMQc7CdS4RunCB5ghTphFuCXsi61sL7xgSQK 2iSA== MIME-Version: 1.0 X-Received: by 10.58.46.207 with SMTP id x15mr32214039vem.17.1398097128721; Mon, 21 Apr 2014 09:18:48 -0700 (PDT) Sender: markjdb@gmail.com Received: by 10.220.162.68 with HTTP; Mon, 21 Apr 2014 09:18:48 -0700 (PDT) In-Reply-To: References: Date: Mon, 21 Apr 2014 12:18:48 -0400 X-Google-Sender-Auth: o8_LojxtqC5aAvNzUVWEhlQVujY Message-ID: Subject: Re: vminfo provider From: Mark Johnston To: carlos antonio neira bustos Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-dtrace@freebsd.org" X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.17 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: Mon, 21 Apr 2014 16:18:49 -0000 On Thu, Apr 17, 2014 at 11:03 PM, carlos antonio neira bustos wrote: > Hi All, > > If the vminfo provider is not available, could I get the same > functionality from the vm_* probes? > > I mean, for example this one liner in Solaris: > > dtrace -n pgin'{@[execname] = count()}' > > > Is the same as doing this in FreeBSD ? > > > dtrace -n vm_page_insert:entry'{ @[execname] = count();}' > No, vm_page_insert doesn't correspond to a pagein. vm_page_insert is just used to add a page to a vm object, which is a higher-level operation. The vm object will determine what happens when an access of one of its pages causes a fault. It could result in a pagein from swap or a backing file, or it could just result in the allocation of a zero-filled page. > > > > Bests > _______________________________________________ > freebsd-dtrace@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-dtrace > To unsubscribe, send any mail to "freebsd-dtrace-unsubscribe@freebsd.org" From owner-freebsd-dtrace@FreeBSD.ORG Wed May 7 02:59:51 2014 Return-Path: Delivered-To: freebsd-dtrace@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1E028147 for ; Wed, 7 May 2014 02:59:51 +0000 (UTC) Received: from alto.onthenet.com.au (alto.OntheNet.com.au [203.13.68.12]) by mx1.freebsd.org (Postfix) with ESMTP id D7B2F308 for ; Wed, 7 May 2014 02:59:50 +0000 (UTC) Received: from dommail.onthenet.com.au (dommail.OntheNet.com.au [203.13.70.57]) by alto.onthenet.com.au (Postfix) with ESMTPS id 8BD5812533 for ; Wed, 7 May 2014 12:59:42 +1000 (EST) Received: from Peter-Grehans-MacBook-Pro-2.local ([64.245.0.210]) by dommail.onthenet.com.au (MOS 4.2.4-GA) with ESMTP id BUA13446 (AUTH peterg@ptree32.com.au); Wed, 7 May 2014 12:59:41 +1000 Message-ID: <5369A19B.9080505@freebsd.org> Date: Tue, 06 May 2014 19:59:39 -0700 From: Peter Grehan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-dtrace@freebsd.org Subject: Importing the latest dis_tables.c Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.18 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: Wed, 07 May 2014 02:59:51 -0000 Hi, I'd like to pull in the latest version of dis_tables.c from illumos-gate to pick up the recent work done there. This is mainly for using dtrace on the bhyve kernel module since it can decode VT-x/SVM instructions, but is probably generally useful. http://src.illumos.org/source/history/illumos-gate/usr/src/common/dis/i386/dis_tables.c What's the process for this ? Should I pull this into vendor/illumos-sys, or just drop it directly into FreeBSD (which is what the previous commits seemed to do) ? Any tips ? later, Peter. From owner-freebsd-dtrace@FreeBSD.ORG Wed May 7 04:00:53 2014 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 ESMTPS id 5E28ED20; Wed, 7 May 2014 04:00:53 +0000 (UTC) Received: from mail-ve0-x22c.google.com (mail-ve0-x22c.google.com [IPv6:2607:f8b0:400c:c01::22c]) (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 0E805C38; Wed, 7 May 2014 04:00:52 +0000 (UTC) Received: by mail-ve0-f172.google.com with SMTP id oz11so523157veb.31 for ; Tue, 06 May 2014 21:00:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=oGs4a0ryCwNhwh4GotSWxq0Ucf9ez1j9Z6FeCwZra+8=; b=0Ed+oorwDAIGh7ZimQGm9E+N6B8WiO2qOSlOOtRKInArfz9Jzrab1WEP+Vt97vkqfr ocaY0ky2NtbpQa2MoXiS4UQg/BQvhFvIMEI0csaOMHPZCOhsJ/wZzbqQC5L8qx2OagKs S7+ia/ZZP05cZb/7g77wbEPA21qGeF8ug3/hhRGseAiSAlEDcsKph9UsRwZeef7OkonO jScyy44FhJdwvCAdjyjffNtCkU8Wmh9BlTNcFEcgTmSVQ7NDxTATgMj1MUtUxcNFe7Sp Y++WQ3tgm1yP47Nj9EXohH8jE82+QUlv3QNUNYgYRf9mMoT0m4gCJ1UrN7JrAvwUOwJ3 4WRA== MIME-Version: 1.0 X-Received: by 10.52.120.39 with SMTP id kz7mr3412794vdb.41.1399435252152; Tue, 06 May 2014 21:00:52 -0700 (PDT) Sender: markjdb@gmail.com Received: by 10.220.162.68 with HTTP; Tue, 6 May 2014 21:00:52 -0700 (PDT) In-Reply-To: <5369A19B.9080505@freebsd.org> References: <5369A19B.9080505@freebsd.org> Date: Wed, 7 May 2014 00:00:52 -0400 X-Google-Sender-Auth: sdT4kNJ5JP00AECC0vD3Bv6cpaQ Message-ID: Subject: Re: Importing the latest dis_tables.c From: Mark Johnston To: Peter Grehan Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-dtrace@freebsd.org" X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.18 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: Wed, 07 May 2014 04:00:53 -0000 On Tue, May 6, 2014 at 10:59 PM, Peter Grehan wrote: > Hi, > > I'd like to pull in the latest version of dis_tables.c from illumos-gate to > pick up the recent work done there. This is mainly for using dtrace on the > bhyve kernel module since it can decode VT-x/SVM instructions, but is > probably generally useful. > > > http://src.illumos.org/source/history/illumos-gate/usr/src/common/dis/i386/dis_tables.c > > What's the process for this ? Should I pull this into vendor/illumos-sys, > or just drop it directly into FreeBSD (which is what the previous commits > seemed to do) ? Any tips ? FWIW, vendor-sys/illumos is merged to sys/cddl/opensolaris, but in FreeBSD, dis_tables.c lives at sys/cddl/dev/dtrace/x86/dis_tables.c for some reason. That is, it's not under the merge target, so merging from vendor-sys/illumos might not be possible without first moving dis_tables.{c,h} to sys/cddl/opensolaris/common/dis. I think that's at least part of the reason dis_tables.c has been updated directly in the past, so I don't think it would be problematic to keep doing it that way until dis_tables.{c,h} are moved (assuming that that's sufficient to start merging them from vendor-sys). I'm not 100% sure of this though. -Mark From owner-freebsd-dtrace@FreeBSD.ORG Wed May 7 04:47:24 2014 Return-Path: Delivered-To: freebsd-dtrace@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 44ECA46F for ; Wed, 7 May 2014 04:47:24 +0000 (UTC) Received: from nm3-vm0.bullet.mail.bf1.yahoo.com (nm3-vm0.bullet.mail.bf1.yahoo.com [98.139.212.154]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E5C6FF6A for ; Wed, 7 May 2014 04:47:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1399437634; bh=baoabwdMqgL/UD5pNO0Onq/2YgmsX9+1byFHE1qevMg=; h=Received:Received:Received:X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer; b=jhs3c32PtFAo8TdaildmG7rDIEDvgoN8ZxHs5aLYxLwuXcDd25HC6zKt28s6le0G++30VXuS7nrdlYUutDYuJAyxUZ3NXElf9fFT9dUP8VAajB4hk2mCg73yg8FsTrgStHEvuoY6W/JhloijFT/u1CL8vxq/k9ySi7zoPNWIf5DvlspyaRyTvREMshRiywtiHYDWcY/0wVIThTd0o3186UtZ2pnVn5wpB0aspUZStFBVh3zSiaeLrPhMj5uW5qmhVWkCLWQ+VcPK0gtxlt2MYVs4Z5G4Ax+oNY4CQvHszZaR5ljIR8OW8HRjxSVFpF3soOCVC5uvygFaNhZZ0GVFRg== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=GFNOQMhrSUbnRhDU4xftmkmSkRW+myYkwnALN+4oWEgsv8+vmBjfk645wNqno4HGEeAS3XdSI5wjVU1dBEAcRvshHT9zFQwE+Axn78fWFi07kldmOV1DlfrDZNXRpydDImAYO2avuXyIitQ9eFbXMVyuXXWW7XcGPNYtvyRzKDzIZiya8+3Jk6JItvKIHpUoIE/sYrIn5CGoRfORW1BqMzVEkSbbwxlGuQEfX5S7mPDBan2j+R99QcAGUFDFcK+OnG/DOCOde8OSdpvcODVeZkIOXTX96re1ycsk3aF/zqBGCbONjILXcQ09kyYdwcTdCw2UTyzJclaZXPnNKut1uQ==; Received: from [66.196.81.172] by nm3.bullet.mail.bf1.yahoo.com with NNFMP; 07 May 2014 04:40:34 -0000 Received: from [98.139.213.12] by tm18.bullet.mail.bf1.yahoo.com with NNFMP; 07 May 2014 04:40:34 -0000 Received: from [127.0.0.1] by smtp112.mail.bf1.yahoo.com with NNFMP; 07 May 2014 04:40:34 -0000 X-Yahoo-Newman-Id: 394760.96618.bm@smtp112.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: zcTZSccVM1kZ._GT4eLFBM4t_tP0Y6QEAjWwtwTqNTrmYo0 AwnhOzqYdST2krURsHglfdbdANCb5T4V4HlLIp7Vw3RIxocl4.t1lVU9IM_w 7toLam3lfLZ_x8ro6PCtG5qh_l5I86Fzvqce69PRWhQh1zvfKXVcKVHGZ5O4 JF10zCbfSge528nm2BrGm40TjQ3pd4hNBSAYHGJiB_ugIUeIehTJVYXp7_i5 YLz1ZPU.qFj_lYlMs7QQ.KqeCzHfFr_KH5khskxPDx225Jt4zveWFre7.tvL MUng_bWcMfB.XVOjACMuThSjEbm3NG91.bqVf12Ilknk3mtx0G_W3hXhDmiw 9l5Nu9LoQcJB_K4gd33k3M5YNgWBrhzeaYf5khTGoI40HwFIuuiy.aE3hojy rLE6qEK6uFn5RAmVTDNd9CgmFPpSagpum5x5rxVw0xVycHPFvDECZS4CI8YA 1lV.SopMrN926WjK4oSXaVmJjmFW6ivW33k2nQK6KvDfx33L0i83dFPHCVb_ KQL6Gz9JYWtP95SQH8yIz.YjwlF0zPWJzCly4oO5g29XkDjIw0UZLT12CMyD oX_IauqnKhiHlsQlc_N9HP0J1dfPQ5nMDbv7ALVKlZgU5KdCR0i7ZE2jzOt0 r7iRabvHUc13g0C1jjRSCc1H6xLLmpoocRvTriXGh4Z5w.e2CB_KKsbyuyQ- - X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf X-Rocket-Received: from [192.168.0.101] (pfg@190.157.126.109 with plain [98.138.105.21]) by smtp112.mail.bf1.yahoo.com with SMTP; 06 May 2014 21:40:34 -0700 PDT Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Subject: Re: Importing the latest dis_tables.c From: Pedro Giffuni In-Reply-To: Date: Tue, 6 May 2014 23:40:30 -0500 Message-Id: <86D6EFA1-6636-462C-891F-CCEDC252B86F@freebsd.org> References: <5369A19B.9080505@freebsd.org> To: Peter Grehan X-Mailer: Apple Mail (2.1874) Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "freebsd-dtrace@freebsd.org" X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.18 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: Wed, 07 May 2014 04:47:24 -0000 Il giorno 06/mag/2014, alle ore 23:00, Mark Johnston = ha scritto: > On Tue, May 6, 2014 at 10:59 PM, Peter Grehan = wrote: >> Hi, >>=20 >> I'd like to pull in the latest version of dis_tables.c from = illumos-gate to >> pick up the recent work done there. This is mainly for using dtrace = on the >> bhyve kernel module since it can decode VT-x/SVM instructions, but is >> probably generally useful. >>=20 >>=20 >> = http://src.illumos.org/source/history/illumos-gate/usr/src/common/dis/i386= /dis_tables.c >>=20 >> What's the process for this ? Should I pull this into = vendor/illumos-sys, >> or just drop it directly into FreeBSD (which is what the previous = commits >> seemed to do) ? Any tips ? >=20 > FWIW, vendor-sys/illumos is merged to sys/cddl/opensolaris, but in > FreeBSD, dis_tables.c lives at sys/cddl/dev/dtrace/x86/dis_tables.c > for some reason. That is, it's not under the merge target, so merging > from vendor-sys/illumos might not be possible without first moving > dis_tables.{c,h} to sys/cddl/opensolaris/common/dis. >=20 > I think that's at least part of the reason dis_tables.c has been > updated directly in the past, so I don't think it would be problematic > to keep doing it that way until dis_tables.{c,h} are moved (assuming > that that's sufficient to start merging them from vendor-sys). I'm not > 100% sure of this though. >=20 Hmm =85 we have indeed been sloppy when merging DTrace stuff into the = tree: I can=92t seem to find that file in the vendor-sys area. It looks = like that file was just added, instead of copied from the vendor area. Looking at our history (before the file was moved) and comparing to the = illumos history: = http://src.illumos.org/source/history/illumos-gate/usr/src/common/dis/i386= /dis_tables.c It appears the last merge to that file that we brought is the AVX = support from Aug 2010 (this was still OpenSolaris): ab47273fedff893c8ae22ec39ffc666d4fa6fc8b (I so much hate git for using = checksums instead of revisions!) So you would have to bring at least 3 more illumos revisions up to the = one in Sept 2011. One of them brings their Dtrace support for KVM which = is interesting but you may not want it at this time. Perhaps these are the changes you need: = http://src.illumos.org/source/diff/illumos-gate/usr/src/common/dis/i386/di= s_tables.c?r1=3D/illumos-gate/usr/src/common/dis/i386/dis_tables.c@7aa76ff= c594f84c1c092911a84f85a79ddb44c73&r2=3D/illumos-gate/usr/src/common/dis/i3= 86/dis_tables.c@70dc7639cedb77623859b80d3b9e9b266e89c15f&format=3Du&full=3D= 0 Although not elegant, just bringing the patch would seem easier that = going through the vendor branch :( Pedro.= From owner-freebsd-dtrace@FreeBSD.ORG Fri May 30 15:25:54 2014 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 ESMTPS id 9CF6AB17 for ; Fri, 30 May 2014 15:25:54 +0000 (UTC) Received: from nexus.ut.mephi.ru (nexus.ut.mephi.ru [85.143.112.92]) by mx1.freebsd.org (Postfix) with ESMTP id 596D1211F for ; Fri, 30 May 2014 15:25:53 +0000 (UTC) Received: from [85.143.112.127] (unknown [85.143.112.127]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: dyokunev@ut.mephi.ru) by nexus.ut.mephi.ru (Postfix) with ESMTPSA id 6E49922E07A1 for ; Fri, 30 May 2014 19:22:04 +0400 (MSK) Message-ID: <5388A227.7050805@ut.mephi.ru> Date: Fri, 30 May 2014 19:22:15 +0400 From: Dmitry Yu Okunev Organization: NRNU MEPhI User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.4.0 MIME-Version: 1.0 To: freebsd-dtrace@freebsd.org Subject: failed to resolve cwd: Unknown variable name X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WdKWsxsqsVCARrjrJ62n0GQWOPiuDPn1U" X-LastMilter: passed X-LastMilter-Score: 0 X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.18 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 May 2014 15:25:54 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WdKWsxsqsVCARrjrJ62n0GQWOPiuDPn1U Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello. I cannot use dtrace in FreeBSD for my need due to next bug. It's said that there's a build-in variable "cwd" contains "the name of the current working directory of the process associated with the current thread" [1] [1] http://docs.oracle.com/cd/E18752_01/html/819-5488/gcfpz.html But when I try to use the variable I get a failure: > dtrace: invalid probe specifier syscall:::entry { printf("%s", cwd); }: in action list: failed to resolve cwd: Unknown variable name You can get the same error by running a dtrace-script from official FreeBSD distribution: > /usr/share/dtrace/toolkit/opensnoop -c --=20 Best regards, Dmitry, head of UNIX-tech department NRNU MEPhI, tel. 8 (495) 788-56-99, add. 8255 --WdKWsxsqsVCARrjrJ62n0GQWOPiuDPn1U Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBAgAGBQJTiKIvAAoJEK2K5AyOMGec5NIQALeBg/HROWFknIyjbippK3HP Ll+iJJuK6G6YzSHLvo2brZO+rIH02nawVCRfZ4fn/iM1QYt/HZLGf9o/tdRCCGwP FXPd7Z8fm+cPZD1VbBw9YTN9z+9p0wkDJyaBEEqlmwSTKof/MCHw0oyk4mrqhemh 21BTLIzL49GvkZ5fSi/SjHK/puUAVFFoo7fmtVoYfxp0i3KPxNazNkcYQ4xCJuQx pF23aWsh6s7WemTwc3OWDE4jhXKjA5WJhYtY4Amx4yUHhMvMUrVgDONSxuDJe7BF HcBxcUd+OhR2LxQ2IgXLw+sPRk0bNMwKj+8XQ0B/CuKRWPjVhZiz7ctTTYyGVsNL N0c9ZZ1vXX+s1/VO/C1nm8fBX0NqiN/HuaQTuoJsiOj3gAm0RHDC90imjABwby33 ROisa+8FI947GeoDf7aSXjwiWPPKx22FvHz/VqnmOasdGAsJkpQLqILJ58WGjovu B65lTVwRYmJlh8MvVBcZxqMeGW2w/RmP+ttGhe7rZ7dLc7KjcxmJr9sUJ143JOJK tJyP1fwDfynPBTfpDe6VvVrhNbhEHi8EvveWB8yLTA4e2inZ2vpf8H3UYhoV9zLo /kOWim/8YyjToh9fNPoIvEs6wT+ISWnXFzLmDzdNJRLuouVr2kwFBLtFLZzm8GWZ rgYkOuR1AhhDAoMILw85 =N8Nf -----END PGP SIGNATURE----- --WdKWsxsqsVCARrjrJ62n0GQWOPiuDPn1U-- From owner-freebsd-dtrace@FreeBSD.ORG Sun Jun 1 17:00:40 2014 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 ESMTPS id 78B71C35; Sun, 1 Jun 2014 17:00:40 +0000 (UTC) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) (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 3B61A2D97; Sun, 1 Jun 2014 17:00:40 +0000 (UTC) Received: by mail-ob0-f176.google.com with SMTP id wo20so3649887obc.35 for ; Sun, 01 Jun 2014 10:00:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=1u6LJ5I7gUS33QNhxE4V+WeKRE0olmUd0vmlZuR4Fns=; b=hc3VOF1HsLZ8JbYAQ7R9ol3nnDkW3Z10qEQruSYSfiJU7BLiVmI0Xc6QmGsYN6Ggx7 cRntFzZYH3KKSowBKsc/UbbAgB/ytpGn7KC4cRXmU46fQOldf/a5DI+V36QO8qpYRDLN Dhwl8ugWqy5GG4FkCU3qLjMUNHr1Jx05TzmcxJjwSxOVQq9E4cd8kweVmjoeCt/M6/xY bjce6oHGekv/oCg+JixOetrg9gSxU8bTYaeDEgl3Pu6HqBOO9sbPpvoGkkcEOC/dRHzv HF6gYxZgGwZY/HzsjpEGw4DdCxq7197cUOWFn9W0mrvKiesfouCPKzBI6WacuBWvuR06 YFXw== MIME-Version: 1.0 X-Received: by 10.182.65.167 with SMTP id y7mr33154619obs.29.1401642039418; Sun, 01 Jun 2014 10:00:39 -0700 (PDT) Received: by 10.76.18.45 with HTTP; Sun, 1 Jun 2014 10:00:39 -0700 (PDT) Date: Sun, 1 Jun 2014 18:00:39 +0100 Message-ID: Subject: Postgresql provider no longer working From: "Sevan / Venture37" To: freebsd-dtrace@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.18 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: Sun, 01 Jun 2014 17:00:40 -0000 Hi, It appears that the Postgresql provider stopped working at some point, I'm running r266890 of 11.0-CURRENT with Postgresql 9.3.4 installed and the probes are not showing up. I've rebuild postgresql with debug defined for both client & server, but not a sausage. Starting postgreql spits out: LOG: ending log output to stderr HINT: Future log output will go to log destination "syslog". & that's it. Sevan From owner-freebsd-dtrace@FreeBSD.ORG Tue Jun 3 14:21:36 2014 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 ESMTPS id 00B1F141 for ; Tue, 3 Jun 2014 14:21:35 +0000 (UTC) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) (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 C4CB820AB for ; Tue, 3 Jun 2014 14:21:35 +0000 (UTC) Received: by mail-ob0-f172.google.com with SMTP id wp18so6140942obc.3 for ; Tue, 03 Jun 2014 07:21:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=deDVvik1x3PXJgr1NnlJyAfjrNqGRg535MDW9CGVwek=; b=UCnws2IF2xe/r6I8B9m9I0sLdvXAj/vC1KS47a2rjWq5Z4CNQGL24mH0BmCYj5I2ZQ sHjlVSdin2N0/cNNEGbz/I5+Z5Yrpsj4GNljZFO93of98rFeVbBxK4agc4ELOqP6jg4p SvrBTYkrK+aRmWsHrBXhttlJPeLE34P/ARn2g1ux9Aj/cbSj6+5cadv24wAQwzGZs6QK ePLFtifGWFKiTp7p+CqDZG+Qss+G4pm2HA5yl+RzvefhNXvaXjsyf0aQ3XaKDuSOd9LM zzywOw+WGJMY5agN5Qm8uiROcMaD1EznsYXHN792+cH87DB9BszAsuDQS5K7PHQ47Nxb Mo+w== MIME-Version: 1.0 X-Received: by 10.182.43.132 with SMTP id w4mr47531540obl.41.1401805295033; Tue, 03 Jun 2014 07:21:35 -0700 (PDT) Received: by 10.76.18.45 with HTTP; Tue, 3 Jun 2014 07:21:34 -0700 (PDT) Date: Tue, 3 Jun 2014 15:21:34 +0100 Message-ID: Subject: DTrace probes for python 2.7.7 From: "Sevan / Venture37" To: freebsd-dtrace@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.18 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: Tue, 03 Jun 2014 14:21:36 -0000 Posted up on https://www.jcea.es/artic/python_dtrace.htm Anyone tried this or previous revisions on FreeBSD?? Sevan / Venture37 From owner-freebsd-dtrace@FreeBSD.ORG Tue Jun 3 15:05:23 2014 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 ESMTPS id E97E5370 for ; Tue, 3 Jun 2014 15:05:22 +0000 (UTC) Received: from nm36-vm8.bullet.mail.bf1.yahoo.com (nm36-vm8.bullet.mail.bf1.yahoo.com [72.30.239.70]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 71F0A24CE for ; Tue, 3 Jun 2014 15:05:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1401807742; bh=PXK3IPljguoWnUbgvT31frDHw8IEbs5ohfYuP4MX2B4=; h=Received:Received:Received:X-Yahoo-Newman-Id:X-Yahoo-Newman-Property:X-YMail-OSG:X-Yahoo-SMTP:X-Rocket-Received:Message-ID:Date:From:Organization:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=qwCP8LL9YnrIf0P93zxTDKjpnQ3LwebMSSf7DjY3rpwj4D+pCgV1pPB6e9ejvQnJm9PZl1GL2PPXEnne5wj6hG576Cxs3+JYdS4Xd4VuBjgmAKQV3z7e1Tl8kYZXFEThnTYyWbLnnNhZ5obVahIYge0RzqJpShm+ipVjkZdo8v42IwOSVES3o/mIq+zISHq7+2/9YbLVwV0TdW8O1AKkk8MrsgsH4DUruOIcyl9an+kxuSXWpQhCz7VBp8bHuieNWI6RIhTGWFpMjlFZlh/Om/PuHi01pgrs3gl5iv8kvttrT2BB8kPKhg9qgAYL1K3kEsFoj9iiJ4YS+q5Fq5xghg== DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s2048; d=yahoo.com; b=OK/5hpK2eJ1twOCy6ipMqPeVji0kSl+3mqQPvxO2mQgbisB0vOI/+qD5xV8Z8HPoLkD/snQ+QxeeTefIHuP8bZ/PLYSxRVzGM9+xZVGR57bSdCbQrXA/k1ff0ETldaDZ9XmspWI1mqHOIpxk4AZfcJEye91ObEsjGtaulNLX52D6KxGyPfQLhMmerodxGO55n4AMy91XwahznhymvM+bTE9gZF6VmUfaVn3OXJ5KNO6OQgqS5jMfesh7oSGDf5/Z0JidV0RR52Ue2HBrbCMxy8oDVVLwX6aO++s77kJU7vqoRYuvTOlThUHDl78qotixG+pPoKYI3ga1z35LqzMClQ==; Received: from [98.139.215.141] by nm36.bullet.mail.bf1.yahoo.com with NNFMP; 03 Jun 2014 15:02:22 -0000 Received: from [68.142.230.71] by tm12.bullet.mail.bf1.yahoo.com with NNFMP; 03 Jun 2014 15:02:22 -0000 Received: from [127.0.0.1] by smtp228.mail.bf1.yahoo.com with NNFMP; 03 Jun 2014 15:02:22 -0000 X-Yahoo-Newman-Id: 406141.73402.bm@smtp228.mail.bf1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: O4jG3E8VM1n4ajJHWL9JxBxfl4Rfb84J.ekvsYR4fnZQDcf C2mjCrgNxXDZcbvnYzRprGCcXR9L4saLHcWchdffKD9Jt6.lhl_mU1XQtskn SroxQqFpTNYSjELEDmzm1f5hKMTA8YL8FSDjzA5yNKj9Rm1e9NVg6EwI5xqp UTncU3ULIYYbSzFyiiAK5UHR.Ph1lv3h2NxSRbYB.akaaz2R.Rg.U1xXSGjp uH4Wpxvim8afTHxb0Boafzkv0ETBBi0FzOzOadCGdky4Ipaxk4coYvL44zHR izr6s1Puy51f6teY8KuzduX0bDFJ25rSY0lVlQIWFFCzWZJVBUrWFeuFZjWx KcPOKwm7u9DMzg0OD6JJ6QOFM9x7YrIzRnZRhZcGhbrouBSIlA1pOAW4poXq t.C1_njEDv83CPDWIZR.Dr2zjTzpbPMqX67jv2nyIafLv8x6GGd0WhxLKv8v j3MJmfFhWDRSay4MNkOBCrPycblTFFoSM8zhQOpOVk4wN6KqYsCy7d0TDncH rfXy.A.QiSXdL6chiJmaeICXNxif1RY.7lgiKZfcJ8L308tHMuAkn2e5UhBp 0YPcJTZcX3B5I.ooINqVvaCXwUGV182jyZFosliRBgRr.mAgNuQQbSg-- X-Yahoo-SMTP: xcjD0guswBAZaPPIbxpWwLcp9Unf X-Rocket-Received: from [192.168.0.102] (pfg@190.157.126.109 with plain [63.250.193.228]) by smtp228.mail.bf1.yahoo.com with SMTP; 03 Jun 2014 15:02:22 +0000 UTC Message-ID: <538DE38A.20205@FreeBSD.org> Date: Tue, 03 Jun 2014 10:02:34 -0500 From: Pedro Giffuni Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: freebsd-dtrace@freebsd.org Subject: Re: DTrace probes for python 2.7.7 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.18 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: Tue, 03 Jun 2014 15:05:23 -0000 El 6/3/2014 9:21 AM, Sevan / Venture37 escribió: > Posted up on > https://www.jcea.es/artic/python_dtrace.htm > That's nice ! > Anyone tried this or previous revisions on FreeBSD?? > Unfortunately upstream python has not been very receptive with DTrace (hopefully that will be fixed). I do think we should try those in our ports but I think it's more important to turn on the Java probes which, of course, are supported by Oracle. More work configuring/testing those would be welcome. Pedro. > Sevan / Venture37 > _______________________________________________ > freebsd-dtrace@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-dtrace > To unsubscribe, send any mail to "freebsd-dtrace-unsubscribe@freebsd.org" > From owner-freebsd-dtrace@FreeBSD.ORG Tue Jun 3 19:47:22 2014 Return-Path: Delivered-To: freebsd-dtrace@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DA8EBAF7 for ; Tue, 3 Jun 2014 19:47:22 +0000 (UTC) Received: from mail-oa0-x230.google.com (mail-oa0-x230.google.com [IPv6:2607:f8b0:4003:c02::230]) (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 A5B7522EB for ; Tue, 3 Jun 2014 19:47:22 +0000 (UTC) Received: by mail-oa0-f48.google.com with SMTP id g18so6731405oah.35 for ; Tue, 03 Jun 2014 12:47:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Kwd6ak9Rgm0579efEJ9XUgtonMDl9fq8nw0H2W5kwXU=; b=OIoQ/t3TLMLmsa9gnUiRnLtl5lb05OxqSkZKBaSEG2mqDqgtz8Xt38ey3Xu7xboEmN ZGx/i2ZvRXcJCsmaerR82IFPjpbZg2bl/9v3OL+/IOrjUWIc4aHjfMeSv3sxVgbxPa29 5Wc/mmxr7GPi6Ra5FZOy2bBYAIKg696tcVXMMRZtiCdN8JmGkxjpYmUd5BzcCGOsqSqc m8i2U5X4Os7tvleO2xEIPmFSb6YN+knxUrAh4ESBsjG4Jylv3TZYHFGbOoh8VFzMoshg GwhHFmHaugBaK7p6Rfu2Qal73NWVD0z+kyVEUZDr8TkGmsXjWjF7JBJ2rodbtbIZaxi1 aqvw== MIME-Version: 1.0 X-Received: by 10.60.65.136 with SMTP id x8mr50439998oes.30.1401824841932; Tue, 03 Jun 2014 12:47:21 -0700 (PDT) Received: by 10.76.18.45 with HTTP; Tue, 3 Jun 2014 12:47:21 -0700 (PDT) In-Reply-To: References: Date: Tue, 3 Jun 2014 20:47:21 +0100 Message-ID: Subject: Re: Postgresql provider no longer working From: "Sevan / Venture37" To: freebsd-dtrace@freebsd.org Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.18 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: Tue, 03 Jun 2014 19:47:22 -0000 Same behaviour on 9.3-BETA1 r266864, 10-STABLE r266807, 11-CURRENT r266972. From owner-freebsd-dtrace@FreeBSD.ORG Wed Jun 4 01:45:58 2014 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 ESMTPS id 5738F35E for ; Wed, 4 Jun 2014 01:45:58 +0000 (UTC) Received: from mail-ve0-x22a.google.com (mail-ve0-x22a.google.com [IPv6:2607:f8b0:400c:c01::22a]) (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 1721721AE for ; Wed, 4 Jun 2014 01:45:58 +0000 (UTC) Received: by mail-ve0-f170.google.com with SMTP id db11so7926645veb.15 for ; Tue, 03 Jun 2014 18:45:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=GnyjYxCYkG7/hl/ZnKSs8UsuHELCioRnDYVGb/KsuhE=; b=CCg7nTcFgfQW+ujUbe6NSCInmBLsR3Z7rY70qsHzaGt5t9xJGRAif4pwGzS0qa8Ddj fZZIwkQPOoCMr64Kt5xIPfs9KyexHvdnN1iZKpjteNjhF8DrQoqe0SBEoApkd87yDC8a YkuRECadXNmB69kZHKJU383X5/iEBUb4U9D8q3bXKIkgB27VT8BABnUC5rhLX1YaVodE OB6RNOBpDAa4bkVjJYXWK4K9U3HZOhjK7pQBGstZdjiWCmuwmstSEGS9UXcmKtUXhCo6 J9j0wNhXDruAH0oiizirnf4349aDIzqd7yCcy3XlaMlGJx6jE4tzgBlDet8IUaPmOxzE Zk5Q== MIME-Version: 1.0 X-Received: by 10.58.135.136 with SMTP id ps8mr40471848veb.18.1401846356971; Tue, 03 Jun 2014 18:45:56 -0700 (PDT) Sender: markjdb@gmail.com Received: by 10.220.162.68 with HTTP; Tue, 3 Jun 2014 18:45:56 -0700 (PDT) In-Reply-To: References: Date: Tue, 3 Jun 2014 21:45:56 -0400 X-Google-Sender-Auth: fJuMEDaTUdJ6iAjjM0bb6l74bWI Message-ID: Subject: Re: Postgresql provider no longer working From: Mark Johnston To: "Sevan / Venture37" Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-dtrace@freebsd.org" X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.18 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: Wed, 04 Jun 2014 01:45:58 -0000 On Sun, Jun 1, 2014 at 1:00 PM, Sevan / Venture37 wrote: > Hi, > It appears that the Postgresql provider stopped working at some point, > I'm running r266890 of 11.0-CURRENT with Postgresql 9.3.4 installed > and the probes are not showing up. > > I've rebuild postgresql with debug defined for both client & server, > but not a sausage. > Starting postgreql spits out: > LOG: ending log output to stderr > HINT: Future log output will go to log destination "syslog". > > & that's it. Hi, I can't reproduce this using postgres 9.3.4 on r267033 (current). As usual, it was necessary to first kldload dtraceall and make sure postgres could access /dev/dtrace/helper (in my case I've added the pgsql user to the wheel group). It's also necessary to build with dtraceall loaded (otherwise dtrace -G will fail I think). With that, the probes show up as expected. Do other ports create probes successfully? lang/php5 has a DTrace option and manages to create probes when I run it. If it doesn't in your environment, could you try running it with the DTRACE_DOF_INIT_DEBUG environment variable set to "1" and pass along the output? Thanks, -Mark From owner-freebsd-dtrace@FreeBSD.ORG Wed Jun 4 02:28:17 2014 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 ESMTPS id AAEFDF5A for ; Wed, 4 Jun 2014 02:28:17 +0000 (UTC) Received: from mail-vc0-x233.google.com (mail-vc0-x233.google.com [IPv6:2607:f8b0:400c:c03::233]) (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 6B2162505 for ; Wed, 4 Jun 2014 02:28:17 +0000 (UTC) Received: by mail-vc0-f179.google.com with SMTP id ij19so3397681vcb.10 for ; Tue, 03 Jun 2014 19:28:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=u4Xu82pVbqZZLrpGOqkgOz7N97bLN8wYmbQ7xoNl9WM=; b=K3y0DvZCLmk0q4C8bKmg8JFrK7Oryu7ik3DpwOdX01I2x9mQlYO2iqAFEPBRQ7M9bV 0PdiuVU+ew5oU31KH7de7xxpMs6tRfDTZZxGuvFehkkRgdu/asr+xeqPd2+X3R4GnU1c 7LWi+6TMmJWGq25n6mZQUsmG3O0pRxlc9bqSOoW8hGKLHeM9yPbSVTy8VdtvGJ8ET92f vIuOEQ0I38cUFHjFlnfO3VGcH6HviwsjAR+k0BCK8kaC7RsF7JjjajZjoAVDHC9kUvvy VEiyA1mnX4vxCxKunREMzS7hPU3h+9ZJM8MkoD24rjbWiwS0g9oH04/E9vd6u89a05xE VrfQ== MIME-Version: 1.0 X-Received: by 10.52.96.8 with SMTP id do8mr34172312vdb.4.1401848896189; Tue, 03 Jun 2014 19:28:16 -0700 (PDT) Sender: markjdb@gmail.com Received: by 10.220.162.68 with HTTP; Tue, 3 Jun 2014 19:28:16 -0700 (PDT) In-Reply-To: <5388A227.7050805@ut.mephi.ru> References: <5388A227.7050805@ut.mephi.ru> Date: Tue, 3 Jun 2014 22:28:16 -0400 X-Google-Sender-Auth: JnZUkYb30k_Te04Ixs2IbG76OB0 Message-ID: Subject: Re: failed to resolve cwd: Unknown variable name From: Mark Johnston To: Dmitry Yu Okunev Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-dtrace@freebsd.org" X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.18 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: Wed, 04 Jun 2014 02:28:17 -0000 On Fri, May 30, 2014 at 11:22 AM, Dmitry Yu Okunev wrote: > Hello. > > I cannot use dtrace in FreeBSD for my need due to next bug. > > It's said that there's a build-in variable "cwd" contains "the name of > the current working directory of the process associated with the current > thread" [1] > > [1] http://docs.oracle.com/cd/E18752_01/html/819-5488/gcfpz.html > > But when I try to use the variable I get a failure: >> dtrace: invalid probe specifier syscall:::entry { printf("%s", cwd); > }: in action list: failed to resolve cwd: Unknown variable name > > You can get the same error by running a dtrace-script from official > FreeBSD distribution: >> /usr/share/dtrace/toolkit/opensnoop -c Unfortunately, it looks like implementing this variable in FreeBSD would be somewhat non-trivial. illumos (and presumably Solaris) caches a full path to the file backing a given vnode, whereas FreeBSD only caches file names and builds up a full path dynamically in vn_fullpath1(). So one can get a bit of the way there with something ugly like inline string cwd = stringof(curthread->td_proc->p_fd->fd_cdir->v_cache_dst.tqh_first->nc_name); to get the last component of a process' cwd (it needs a check for a missing cache entry), but I don't see any easy way to get at the full cwd. Calling vn_fullpath() in probe context would be a pretty bad idea since it may invoke VFS operations, so adding support for the cwd variable would probably involve adding cache-only lookup code to vfs_cache.c. That said, I'm not super familiar with this stuff, so I could be missing something; this is just based on my previously stymied efforts trying to get a full path for a vnode in a DTrace probe, for example when trying to figure out which files are getting fsync'ed. -Mark From owner-freebsd-dtrace@FreeBSD.ORG Wed Jun 4 05:16:21 2014 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 ESMTPS id E52B52CC; Wed, 4 Jun 2014 05:16:20 +0000 (UTC) Received: from nexus.ut.mephi.ru (nexus.ut.mephi.ru [85.143.112.92]) by mx1.freebsd.org (Postfix) with ESMTP id 68EAE2325; Wed, 4 Jun 2014 05:16:19 +0000 (UTC) Received: from [192.168.91.222] (sloan2.ut.mephi.ru [85.143.112.35]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: dyokunev@ut.mephi.ru) by nexus.ut.mephi.ru (Postfix) with ESMTPSA id 7FC3522E07A1; Wed, 4 Jun 2014 09:16:11 +0400 (MSK) Message-ID: <538EAAF1.1030005@ut.mephi.ru> Date: Wed, 04 Jun 2014 09:13:21 +0400 From: Dmitry Yu Okunev Organization: NRNU MEPhI User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130623 Thunderbird/17.0.7 MIME-Version: 1.0 To: Mark Johnston Subject: Re: failed to resolve cwd: Unknown variable name References: <5388A227.7050805@ut.mephi.ru> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="WTcSU6j9kJi6KEoNeqsd4LqsOTug7NN08" X-LastMilter: passed X-LastMilter-Score: 0 Cc: "freebsd-dtrace@freebsd.org" X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.18 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: Wed, 04 Jun 2014 05:16:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WTcSU6j9kJi6KEoNeqsd4LqsOTug7NN08 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello. On 06/04/2014 06:28 AM, Mark Johnston wrote: > On Fri, May 30, 2014 at 11:22 AM, Dmitry Yu Okunev wrote: >> Hello. >> >> I cannot use dtrace in FreeBSD for my need due to next bug. >> >> It's said that there's a build-in variable "cwd" contains "the name of= >> the current working directory of the process associated with the curre= nt >> thread" [1] >> >> [1] http://docs.oracle.com/cd/E18752_01/html/819-5488/gcfpz.html >> >> But when I try to use the variable I get a failure: >>> dtrace: invalid probe specifier syscall:::entry { printf("%s", cwd); >> }: in action list: failed to resolve cwd: Unknown variable name >> >> You can get the same error by running a dtrace-script from official >> FreeBSD distribution: >>> /usr/share/dtrace/toolkit/opensnoop -c >=20 > Unfortunately, it looks like implementing this variable in FreeBSD > would be somewhat non-trivial. illumos (and presumably Solaris) caches > a full path to the file backing a given vnode, whereas FreeBSD only > caches file names and builds up a full path dynamically in > vn_fullpath1(). That's strange problem because audit already returns full paths in FreeBSD. It just uses "vn_fullpath*()"? > So one can get a bit of the way there with something ugly like >=20 > inline string cwd =3D > stringof(curthread->td_proc->p_fd->fd_cdir->v_cache_dst.tqh_first->nc_n= ame); >=20 > to get the last component of a process' cwd (it needs a check for a > missing cache entry), but I don't see any easy way to get at the full > cwd. Calling vn_fullpath() in probe context would be a pretty bad idea > since it may invoke VFS operations Hm. If it's performance problem only, then personally I can endure that. Can I use vn_fullpath*() in dtrace probes on current FreeBSD? >, so adding support for the cwd > variable would probably involve adding cache-only lookup code to > vfs_cache.c. That said, I'm not super familiar with this stuff, so I > could be missing something; this is just based on my previously > stymied efforts trying to get a full path for a vnode in a DTrace > probe, for example when trying to figure out which files are getting > fsync'ed. Ok. It's became much more clear. Thanks :) --=20 Best regards, Dmitry. --WTcSU6j9kJi6KEoNeqsd4LqsOTug7NN08 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTjqr7AAoJEK2K5AyOMGeciQgP/0fdpNJ6OMvLFQvMKmTTL8U5 6UtL+RP3yciWdguzM1cgTGviMR3qIM7FGasmsG8hX0JzHjWjAtmrRvdpZoinRFqu sEJKq0Qm96AEqNrFTI++NobmXjQrod33WbFVmtiB/U34o4nRgjJqHLeSEUGiwIyo 8hK3Vrr8EmkEGmE2Q08J95I2qTqvJqSpyUZNRpX1FqqUSe6KYSc/NjccG+KwOe7g STSZ2REUhjVCzaaotnQmDYV5pHSeMSwARB+EgCTlyiv1pUfIuVMkvoRTMbpMpzOM kk+7LXl5h8Yz+l1Rxhr44mqRkikVCsWW7n6lSuLRElCzKCqeB+TuZRZta9S7PSFM fe+cxB01SAJId3LtIa2rYBj83KXe1oHp9bCcjCVHuR7Xz7y6qKrwrsoQYCaSsKAA r3mUbeeB47QzC75I8acYJ66qmn1yft+V0Lmgj7rRjKDn+Ij8uO8YLiRwU6920rBx 2eKIcQrN2RjH1Z4aPSDQk5ndbVnZsLuJkdfOEjM4DYYKfmbxU/5PTOxEeYn2xCIq J/xmz4ZKnlnIUZp2zev2ta8TJUWmZA3fVaLBpacUiLjDT+vBKpYXRPRi8B/Wk4s9 xMpUHyMmD2UDkp5RQnYNSag9UolUBq1WJj+iGu1ZG02OIR+DGWdQ7zMF7IjEhW/l x+gamePoQjtG1mD+htQm =F/W2 -----END PGP SIGNATURE----- --WTcSU6j9kJi6KEoNeqsd4LqsOTug7NN08-- From owner-freebsd-dtrace@FreeBSD.ORG Wed Jun 4 10:35:16 2014 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 ESMTPS id 10060302; Wed, 4 Jun 2014 10:35:16 +0000 (UTC) Received: from mail-ob0-x22a.google.com (mail-ob0-x22a.google.com [IPv6:2607:f8b0:4003:c01::22a]) (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 68F7520A6; Wed, 4 Jun 2014 10:35:15 +0000 (UTC) Received: by mail-ob0-f170.google.com with SMTP id uy5so7407713obc.15 for ; Wed, 04 Jun 2014 03:35:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2tT2Pn8M2+u7Z+5B7vnxbj+h9MeaFwhu1Px2a//J64A=; b=qk8XJyGaG5KhFAOdbQRHHwUvbx/I+tnTioZ2ftdxoHxuBR1nJOCWg6Hc8TnWsOYJbr ezFazKvxfQUZbDTCXleGr326UJge4iSELGASUI+TzUm+a5vLmOJ6vgYnqlI0hAOAhnTM L8f1Kq8w6p/rV1jhBAt7mS78+sSGIoLz30lSmPAKEeI7L0+RXwmbb+rkMQ/so3NH/q3+ tjWxngUCI9pLR6QXKXLC8x0kSy07CnnnpBs1tOjzX6Q1bwjjrjwtSoqhJQkhGFZpVSex 640Nau2vZXtq6LqkuI5ATnhLoW401x+poGqjp95a7elNtmUla5YUTUZbBeA0Prks16KE 2nIw== MIME-Version: 1.0 X-Received: by 10.182.34.167 with SMTP id a7mr4256938obj.3.1401878114496; Wed, 04 Jun 2014 03:35:14 -0700 (PDT) Received: by 10.76.18.45 with HTTP; Wed, 4 Jun 2014 03:35:14 -0700 (PDT) In-Reply-To: References: Date: Wed, 4 Jun 2014 11:35:14 +0100 Message-ID: Subject: Re: Postgresql provider no longer working From: "Sevan / Venture37" 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 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: Wed, 04 Jun 2014 10:35:16 -0000 On 4 June 2014 02:45, Mark Johnston wrote: > Hi, > > I can't reproduce this using postgres 9.3.4 on r267033 (current). As > usual, it was necessary to first kldload dtraceall and make sure > postgres could access /dev/dtrace/helper (in my case I've added the > pgsql user to the wheel group). It's also necessary to build with > dtraceall loaded (otherwise dtrace -G will fail I think). With that, > the probes show up as expected. > > Do other ports create probes successfully? lang/php5 has a DTrace > option and manages to create probes when I run it. If it doesn't in > your environment, could you try running it with the > DTRACE_DOF_INIT_DEBUG environment variable set to "1" and pass along > the output? > > Thanks, > -Mark Hi Mark, As previous, adjusting the permissions on /dev/dtrace/helper resolved the issue. What threw me was that I did try PHP & netatalk before posting & the probes for those two did appear. Revisiting those again now I see that they have a master process which runs as root hence not being locked out of access to /dev/dtrace/helper. Moving forward, what's your opinion on the adition of a new system group called dtrace, & the devfs rules own dtrace/helper root:dtrace perm dtrace/helper 0660 Postgresql can be made a member of this group if it's installed with dtrace support & things work from the start. Happy to raise the patch, just running it past you as I'm unsure what ideas there are for delegating access in the future. Sorry about the false alarm. Sevan / Venture37 From owner-freebsd-dtrace@FreeBSD.ORG Wed Jun 4 10:43:52 2014 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 ESMTPS id 6C2C29B9 for ; Wed, 4 Jun 2014 10:43:52 +0000 (UTC) Received: from mail-pb0-x233.google.com (mail-pb0-x233.google.com [IPv6:2607:f8b0:400e:c01::233]) (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 3781121B7 for ; Wed, 4 Jun 2014 10:43:52 +0000 (UTC) Received: by mail-pb0-f51.google.com with SMTP id ma3so6809648pbc.24 for ; Wed, 04 Jun 2014 03:43:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=gH2qaKxajb1oVftxTNZ/ZztLMGAlRpkkRk8DSAd0WD0=; b=g2HWwu0CoNJY5mqK+MvQCk2Duso4gi9N+hhmp7G4oBkroCuUr4LWrZG6ZoIIx5q2bb X9cHxWHDIEGsvXh0rk5bwVF4osvBhPtgxm8QA3ExMpSTF8rkyh2wCOnjUgtRGWF5at9B Uj2pqo1XaCkGQAhMAvuZd1Rv5RpcQWxp53XdvsY9GrmlFeErdBfFBgNx7x4mvjMTa8Y7 faYzxlvZHIXLGw2nJKpJz9zRgyEZICCYsEdq9taKRESOM1ufyDDOaGLqg1ETD/Za/DMC AwGhzOmLQ3VU9LysZ9A6Zmlit4lnkczrW5D+FAom/Dj1arxPvu2u59OfOQEg4D4fALi2 f7WQ== X-Received: by 10.69.19.225 with SMTP id gx1mr62055519pbd.34.1401878631516; Wed, 04 Jun 2014 03:43:51 -0700 (PDT) Received: from [192.168.1.7] (ppp59-167-128-11.static.internode.on.net. [59.167.128.11]) by mx.google.com with ESMTPSA id pz10sm8473533pbb.33.2014.06.04.03.43.48 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Jun 2014 03:43:50 -0700 (PDT) Sender: Kubilay Kocak Message-ID: <538EF858.9000305@FreeBSD.org> Date: Wed, 04 Jun 2014 20:43:36 +1000 From: Kubilay Kocak Reply-To: koobs@FreeBSD.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Thunderbird/30.0 MIME-Version: 1.0 To: Sevan / Venture37 , freebsd-dtrace@freebsd.org Subject: Re: DTrace probes for python 2.7.7 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.18 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: Wed, 04 Jun 2014 10:43:52 -0000 On 4/06/2014 12:21 AM, Sevan / Venture37 wrote: > Posted up on > https://www.jcea.es/artic/python_dtrace.htm > > Anyone tried this or previous revisions on FreeBSD?? > > Sevan / Venture37 > _______________________________________________ > freebsd-dtrace@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-dtrace > To unsubscribe, send any mail to "freebsd-dtrace-unsubscribe@freebsd.org" > Both of my official FreeBSD Python buildbots support dtrace, and I've been doing my best to support jcea@ over the past year or so: http://buildbot.python.org/all/buildslaves/koobs-freebsd9 http://buildbot.python.org/all/buildslaves/koobs-freebsd10 I'd like to see us be one of the first to support it (in ports), so let me know if there's anything I can do :) -- koobs From owner-freebsd-dtrace@FreeBSD.ORG Wed Jun 4 12:37:58 2014 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 ESMTPS id D83B4223; Wed, 4 Jun 2014 12:37:58 +0000 (UTC) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) (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 97C902D42; Wed, 4 Jun 2014 12:37:58 +0000 (UTC) Received: by mail-ob0-f176.google.com with SMTP id wo20so7562223obc.21 for ; Wed, 04 Jun 2014 05:37:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=heBRfRGH6t3el39In8FGrHLn5z+l7gp1XLFqu1nrZpg=; b=e4eVglleoWu4hKAM426yJRDBsavGk991suDR0Byu56xbKKcvjLFoT7dlVhtHTC1JEk vSMrrTEa1zX9tMapEgVRBjsg+mZMNo650edF88SwJa0oKjeHlJS1UJ+yU3U2GZhMNgIT 05w0SzmvAguBHIJF9qRPEgdhlZSUMQTnRDVH1j0ZSMwbfoV2jMk5CLy8z9QmzZ+CnFSK aeOLFIP00iuEtMjE34T13S44zE3kHjkNf6VCNKP8cncIisNmpZxfez/7AtgIeexZBFqW mtuPuLuZPAFzjv0r3HHmgyugACEaokcpbAUW+Sf0LxJCclk9RAQ7VFR84942w61p4YPE yjEg== MIME-Version: 1.0 X-Received: by 10.182.43.132 with SMTP id w4mr56976552obl.41.1401885477850; Wed, 04 Jun 2014 05:37:57 -0700 (PDT) Received: by 10.76.18.45 with HTTP; Wed, 4 Jun 2014 05:37:57 -0700 (PDT) In-Reply-To: <538EF858.9000305@FreeBSD.org> References: <538EF858.9000305@FreeBSD.org> Date: Wed, 4 Jun 2014 13:37:57 +0100 Message-ID: Subject: Re: DTrace probes for python 2.7.7 From: "Sevan / Venture37" To: koobs@freebsd.org Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-dtrace@freebsd.org" X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.18 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: Wed, 04 Jun 2014 12:37:58 -0000 On 4 June 2014 11:43, Kubilay Kocak wrote: > Both of my official FreeBSD Python buildbots support dtrace, and I've > been doing my best to support jcea@ over the past year or so: > > http://buildbot.python.org/all/buildslaves/koobs-freebsd9 > http://buildbot.python.org/all/buildslaves/koobs-freebsd10 > > I'd like to see us be one of the first to support it (in ports), so let > me know if there's anything I can do :) Hi Koobs, I'd check the output of your builds it doesn't appear to be building with dtrace enabled configure: WARNING: unrecognized options: --with-dtrace You need to rerun autoconf after patching The 2.7.6 patches merged with lang/python27 as expected, but the build fails due to issues with the paths added in as part of the patch which I'm currently looking into now. Sevan From owner-freebsd-dtrace@FreeBSD.ORG Wed Jun 4 12:38:41 2014 Return-Path: Delivered-To: freebsd-dtrace@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6B66924C; Wed, 4 Jun 2014 12:38:41 +0000 (UTC) Received: from mail-ob0-x235.google.com (mail-ob0-x235.google.com [IPv6:2607:f8b0:4003:c01::235]) (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 2A68E2D4B; Wed, 4 Jun 2014 12:38:41 +0000 (UTC) Received: by mail-ob0-f181.google.com with SMTP id wm4so7377598obc.26 for ; Wed, 04 Jun 2014 05:38:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=ryWAIeI0gIGcZQO8kjp6dc0KOqospEfgHNvJk1SB7xI=; b=iRzrDq9TMCZ4+h2LAXQk4NbSLwe3QEKfL7sW5P9hq4VrxFW7ULm4OH3UVoq423klgn Fwpj/CcGGk4BpjF9kZe6J3S+pjCYdbazOQMG+Bwr7LEwXVLrt5kfyqqwwzSCR317W7Rq 5rBESscVWAm8igHIOJP4hgbRp0AN4ZcefaSmdHz5MgYggLnPw/KOD4UfE57vJCs2O3Cv RbwN52nA0eT6IAgczdaKVYEtFeYm1aK3ma+DD9lDbM9fQfk+49t8fg5GtWUZ/v8HXmRZ VYqstm6Xnc9pWp7I7dZCNkEKIH7bQtsfBszfcYICrDyZkDJCXLCvTPv1rm0szoHbRbFQ jb/g== MIME-Version: 1.0 X-Received: by 10.60.52.207 with SMTP id v15mr56872888oeo.19.1401885520492; Wed, 04 Jun 2014 05:38:40 -0700 (PDT) Received: by 10.76.18.45 with HTTP; Wed, 4 Jun 2014 05:38:40 -0700 (PDT) In-Reply-To: References: <538EF858.9000305@FreeBSD.org> Date: Wed, 4 Jun 2014 13:38:40 +0100 Message-ID: Subject: Re: DTrace probes for python 2.7.7 From: "Sevan / Venture37" To: koobs@freebsd.org Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-dtrace@freebsd.org" X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.18 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: Wed, 04 Jun 2014 12:38:41 -0000 On 4 June 2014 13:37, Sevan / Venture37 wrote: > Hi Koobs, > I'd check the output of your builds it doesn't appear to be building > with dtrace enabled > configure: WARNING: unrecognized options: --with-dtrace > You need to rerun autoconf after patching http://buildbot.python.org/all/builders/AMD64%20FreeBSD%209.x%202.7/builds/410/steps/configure/logs/stdio From owner-freebsd-dtrace@FreeBSD.ORG Wed Jun 4 13:25:13 2014 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 ESMTPS id 36055194; Wed, 4 Jun 2014 13:25:13 +0000 (UTC) Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c: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 D640D2276; Wed, 4 Jun 2014 13:25:12 +0000 (UTC) Received: by mail-vc0-f171.google.com with SMTP id ij19so4045434vcb.16 for ; Wed, 04 Jun 2014 06:25:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=U/+pKcE2TDbDuMf9pO/J0J5c/Dye7jvuYCgJ9tDtVa0=; b=Lr1YsOvhtWCEJRprfXKP6thQtBs5po3fNrr1QmqQZwhSptVN6uaxXK6q+NgCGjpqqi g2+Fk2ChBk5nMRYNiYVwpcUxjgDGXAiD7ZVVNaKulQ+/l7NKgVGOxM0JyoTpxnWIkFt3 tPi5o32FTVxjTjL+oLu9B5Ct5bImh96UNc4Z39iHHfrZv3ipb0wGRHaBw1+kCcwqEJVc D6EiGe1Gtonjd7UAYe7oCxhmuT6QUk+r+dIidgjCZsmhxLBm33vlZcEjzzXY01BqLTfP 65hkZHb4tA/33AgHIFO5kUJYIISqiUkbf5ym6mKO0bfB/qH/qDye6Q6wHuvWLu3zAdUf 8rDA== MIME-Version: 1.0 X-Received: by 10.52.138.232 with SMTP id qt8mr12674265vdb.44.1401888311728; Wed, 04 Jun 2014 06:25:11 -0700 (PDT) Sender: markjdb@gmail.com Received: by 10.220.162.68 with HTTP; Wed, 4 Jun 2014 06:25:11 -0700 (PDT) In-Reply-To: <538EAAF1.1030005@ut.mephi.ru> References: <5388A227.7050805@ut.mephi.ru> <538EAAF1.1030005@ut.mephi.ru> Date: Wed, 4 Jun 2014 09:25:11 -0400 X-Google-Sender-Auth: sx-OqOYvCCD-deJWjPTb1QU4gic Message-ID: Subject: Re: failed to resolve cwd: Unknown variable name From: Mark Johnston To: Dmitry Yu Okunev Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-dtrace@freebsd.org" X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.18 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: Wed, 04 Jun 2014 13:25:13 -0000 On Wed, Jun 4, 2014 at 1:13 AM, Dmitry Yu Okunev wrote: > Hello. > > On 06/04/2014 06:28 AM, Mark Johnston wrote: >> On Fri, May 30, 2014 at 11:22 AM, Dmitry Yu Okunev wrote: >>> Hello. >>> >>> I cannot use dtrace in FreeBSD for my need due to next bug. >>> >>> It's said that there's a build-in variable "cwd" contains "the name of >>> the current working directory of the process associated with the current >>> thread" [1] >>> >>> [1] http://docs.oracle.com/cd/E18752_01/html/819-5488/gcfpz.html >>> >>> But when I try to use the variable I get a failure: >>>> dtrace: invalid probe specifier syscall:::entry { printf("%s", cwd); >>> }: in action list: failed to resolve cwd: Unknown variable name >>> >>> You can get the same error by running a dtrace-script from official >>> FreeBSD distribution: >>>> /usr/share/dtrace/toolkit/opensnoop -c >> >> Unfortunately, it looks like implementing this variable in FreeBSD >> would be somewhat non-trivial. illumos (and presumably Solaris) caches >> a full path to the file backing a given vnode, whereas FreeBSD only >> caches file names and builds up a full path dynamically in >> vn_fullpath1(). > > That's strange problem because audit already returns full paths in > FreeBSD. It just uses "vn_fullpath*()"? > >> So one can get a bit of the way there with something ugly like >> >> inline string cwd = >> stringof(curthread->td_proc->p_fd->fd_cdir->v_cache_dst.tqh_first->nc_name); >> >> to get the last component of a process' cwd (it needs a check for a >> missing cache entry), but I don't see any easy way to get at the full >> cwd. Calling vn_fullpath() in probe context would be a pretty bad idea >> since it may invoke VFS operations > > Hm. If it's performance problem only, then personally I can endure that. > > Can I use vn_fullpath*() in dtrace probes on current FreeBSD? It's a safety thing. DTrace probes execute with interrupts disabled, so they're fairly limited in what they're allowed to do. Name resolution potentially requires the underlying filesystem code to read from disk or invoke an RPC, which cannot be done in probe context. Hence my suggestion of a cache-only lookup function that could be callable from within a probe. -Mark > >>, so adding support for the cwd >> variable would probably involve adding cache-only lookup code to >> vfs_cache.c. That said, I'm not super familiar with this stuff, so I >> could be missing something; this is just based on my previously >> stymied efforts trying to get a full path for a vnode in a DTrace >> probe, for example when trying to figure out which files are getting >> fsync'ed. > > Ok. It's became much more clear. Thanks :) From owner-freebsd-dtrace@FreeBSD.ORG Wed Jun 4 13:47:10 2014 Return-Path: Delivered-To: freebsd-dtrace@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 49827C1C for ; Wed, 4 Jun 2014 13:47:10 +0000 (UTC) Received: from mail-ve0-x22c.google.com (mail-ve0-x22c.google.com [IPv6:2607:f8b0:400c:c01::22c]) (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 06D362490 for ; Wed, 4 Jun 2014 13:47:09 +0000 (UTC) Received: by mail-ve0-f172.google.com with SMTP id oz11so8823211veb.31 for ; Wed, 04 Jun 2014 06:47:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=FwCwlKN1Y0nHj2zMkZtzPbvnwnD3zv9+4M7Nnaef0Qk=; b=hm8FkYhaUBqOsf1rSbD2Ji4pfNUTB90VvYfTQZPd7JyE9ZqUwNQ/CDPD3Ht2yJGinH iPlKGeC2LVg0u46ijNBlzoRclM1Tz6kYT5n5vjtpIKipHr51b3nIrSgk91vwlOh2qyTl r/Ta7MnKz88KO+q6ZJCNwM7RPjCOszMMzC6iRXaTxcX7h7XJ8i5lyvFTOwh0B7oZNDsy 8+T3yn9Snkx0Z4Pg1yqb6SwubWUIm28JY3SmMaGxaLsqLNRnames/gsmOEhrDfR6rXWw 7E/FVPNg2KZR1r2WF5yqw/3TYQJDnkkzhzx+fDhUvaex2erlSPHK489dEE4Ip36pjt19 wJTg== MIME-Version: 1.0 X-Received: by 10.52.22.13 with SMTP id z13mr37309282vde.10.1401889629097; Wed, 04 Jun 2014 06:47:09 -0700 (PDT) Sender: markjdb@gmail.com Received: by 10.220.162.68 with HTTP; Wed, 4 Jun 2014 06:47:09 -0700 (PDT) In-Reply-To: References: Date: Wed, 4 Jun 2014 09:47:09 -0400 X-Google-Sender-Auth: InY36xugsDlxB0raYBIWoluUKwE Message-ID: Subject: Re: Postgresql provider no longer working From: Mark Johnston To: "Sevan / Venture37" Content-Type: text/plain; charset=UTF-8 Cc: "freebsd-dtrace@freebsd.org" X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.18 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: Wed, 04 Jun 2014 13:47:10 -0000 On Wed, Jun 4, 2014 at 6:35 AM, Sevan / Venture37 wrote: > On 4 June 2014 02:45, Mark Johnston wrote: >> Hi, >> >> I can't reproduce this using postgres 9.3.4 on r267033 (current). As >> usual, it was necessary to first kldload dtraceall and make sure >> postgres could access /dev/dtrace/helper (in my case I've added the >> pgsql user to the wheel group). It's also necessary to build with >> dtraceall loaded (otherwise dtrace -G will fail I think). With that, >> the probes show up as expected. >> >> Do other ports create probes successfully? lang/php5 has a DTrace >> option and manages to create probes when I run it. If it doesn't in >> your environment, could you try running it with the >> DTRACE_DOF_INIT_DEBUG environment variable set to "1" and pass along >> the output? >> >> Thanks, >> -Mark > > Hi Mark, > As previous, adjusting the permissions on /dev/dtrace/helper resolved the issue. > What threw me was that I did try PHP & netatalk before posting & the > probes for those two did appear. > Revisiting those again now I see that they have a master process which > runs as root hence not being locked out of access to > /dev/dtrace/helper. > > Moving forward, what's your opinion on the adition of a new system > group called dtrace, & the devfs rules > > own dtrace/helper root:dtrace > perm dtrace/helper 0660 > > Postgresql can be made a member of this group if it's installed with > dtrace support & things work from the start. > Happy to raise the patch, just running it past you as I'm unsure what > ideas there are for delegating access in the future. I think it would be simpler to just allow any process to register probes through /dev/dtrace/helper, with some limits on the number of probes that can be registered by a given process. I believe this is what illumos does. If for some reason this can't be done, then having a dtrace group would be a good alternative, but it's probably preferable to avoid implementing both solutions. However, before changing the default permissions I'd like the code (probe and DOF registration handlers specifically) to be audited by someone on the security team. -Mark From owner-freebsd-dtrace@FreeBSD.ORG Wed Jun 4 13:49:29 2014 Return-Path: Delivered-To: freebsd-dtrace@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5511AC8E for ; Wed, 4 Jun 2014 13:49:29 +0000 (UTC) Received: from mail-pb0-x22d.google.com (mail-pb0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) (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 1E46C24B3 for ; Wed, 4 Jun 2014 13:49:29 +0000 (UTC) Received: by mail-pb0-f45.google.com with SMTP id um1so7031876pbc.32 for ; Wed, 04 Jun 2014 06:49:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:reply-to:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=2r43YegUpbcjUHOt5EsbRu5Yb78f3bi9Yb/PooWACk0=; b=0H2E2XR6K9A4nE2DBruQFVJCaR0IS/S48ooV4OrxnlRoVP1FA+7N80snITPzTuDnRQ 4iCW2hWeIAaKdmEaOKpArqVELFs15ZpPuaF1STiLnv28nyRf32XnyQbXNbd7A4fL1oNu MYps9+d5SHsWj8Qn4Gnc6Un6BpREJ+sFFm5AsV+FrZx0cWNzwsIdBQ+zxKkQFwNLmtya tgjNjNK3oqAPcm4Lv3pth9SvlfKR3Twmjc0BuR/P8JA2kYBaikhoXLSqwSEbSU3+28qI 65L8xsbWJeMX6QrxcboQJLT+roXO3rJwZnaMl4lkmTAfOE/Z1dVBqNznTcWdcjO4rR5B hiKw== X-Received: by 10.69.26.103 with SMTP id ix7mr62715246pbd.41.1401889768491; Wed, 04 Jun 2014 06:49:28 -0700 (PDT) Received: from [192.168.1.7] (ppp59-167-128-11.static.internode.on.net. [59.167.128.11]) by mx.google.com with ESMTPSA id gg3sm10353127pbc.34.2014.06.04.06.49.26 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Jun 2014 06:49:27 -0700 (PDT) Sender: Kubilay Kocak Message-ID: <538F23DB.2040003@FreeBSD.org> Date: Wed, 04 Jun 2014 23:49:15 +1000 From: Kubilay Kocak Reply-To: koobs@FreeBSD.org User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:30.0) Gecko/20100101 Thunderbird/30.0 MIME-Version: 1.0 To: Sevan / Venture37 Subject: Re: DTrace probes for python 2.7.7 References: <538EF858.9000305@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Cc: "freebsd-dtrace@freebsd.org" X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.18 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: Wed, 04 Jun 2014 13:49:29 -0000 On 4/06/2014 10:37 PM, Sevan / Venture37 wrote: > On 4 June 2014 11:43, Kubilay Kocak wrote: >> Both of my official FreeBSD Python buildbots support dtrace, and I've >> been doing my best to support jcea@ over the past year or so: >> >> http://buildbot.python.org/all/buildslaves/koobs-freebsd9 >> http://buildbot.python.org/all/buildslaves/koobs-freebsd10 >> >> I'd like to see us be one of the first to support it (in ports), so let >> me know if there's anything I can do :) > > Hi Koobs, > I'd check the output of your builds it doesn't appear to be building > with dtrace enabled > configure: WARNING: unrecognized options: --with-dtrace > You need to rerun autoconf after patching > > The 2.7.6 patches merged with lang/python27 as expected, but the build > fails due to issues with the paths added in as part of the patch which > I'm currently looking into now. > > > > Sevan > The buildmaster sets the configure argument for all builds unconditionally (for when dtrace support does land in tip) but jcea has only tested using the custom builder so far Have you been in touch with Jesús yet? This is the relevant issue ID: http://bugs.python.org/issue13405 From owner-freebsd-dtrace@FreeBSD.ORG Wed Jun 4 19:15:02 2014 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 ESMTPS id D5F5FE60 for ; Wed, 4 Jun 2014 19:15:02 +0000 (UTC) Received: from mail-oa0-x22e.google.com (mail-oa0-x22e.google.com [IPv6:2607:f8b0:4003:c02::22e]) (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 A253C25D9 for ; Wed, 4 Jun 2014 19:15:02 +0000 (UTC) Received: by mail-oa0-f46.google.com with SMTP id g18so8346939oah.19 for ; Wed, 04 Jun 2014 12:15:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=FNolzZIhx+pyRR9zrzcK+vkzyLPF/m4BCIQH3xbQ/Hc=; b=Oq8A3o+lNkaHyvhGKdH2SFVOsUdYxXSp3RvLnPZaPB1mDiLsvq8k74hUDuQeo06khD 7ocMDplHx+FWpA31YGWL7hdkS1FrIYuFsozDVNfyRsPEd1YQgwkHMVdygquPWB2RWMyv klwiaF0DYvszL6HRuEldXXm6lAaMcJIHXfC1Q5xlt2nZxYlMnNtIQ1FwnGz4uv9VuFvz H8sbBP0YRK+s4/XyAjm5I3rnngUbnen+2evCGp1MQ/ZpitDhfZGHRRx9HWqdlfTEvfaU kaXNwtGIQh4e/7DWOg7+5Q3KdN4xJG3xf+CKVrqE3geCFnFaGnMOTWaP6HfU1CAo0PAQ mYyQ== MIME-Version: 1.0 X-Received: by 10.182.231.197 with SMTP id ti5mr2347372obc.41.1401909301844; Wed, 04 Jun 2014 12:15:01 -0700 (PDT) Received: by 10.76.18.45 with HTTP; Wed, 4 Jun 2014 12:15:01 -0700 (PDT) In-Reply-To: References: Date: Wed, 4 Jun 2014 20:15:01 +0100 Message-ID: Subject: Re: DTrace probes for python 2.7.7 From: "Sevan / Venture37" To: "freebsd-dtrace@freebsd.org" Content-Type: text/plain; charset=UTF-8 X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.18 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: Wed, 04 Jun 2014 19:15:02 -0000 I've merged the patch with lang/python27 port & now dealing with build issues with a little help from vg@ You can keep up on: https://bitbucket.org/sevan/python27-dtrace cc -DNDEBUG -L/usr/local/lib -pthread -o Include/pydtrace_offsets Include/pydtrace_offsets.c Include/pydtrace_offsets.sh OTHER Python/ceval.o Include/pydtrace_offsets > Include/pydtrace_offsets.h if test "/usr/sbin/dtrace" != "" ; then touch -r Python/ceval.o Python/ceval.o.ts_dtrace ; touch -r Modules/gcmodule.o Modules/gcmodule.o.ts_dtrace ; touch -r Objects/classobject.o Objects/classobject.o.ts_dtrace ; touch -r Objects/typeobject.o Objects/typeobject.o.ts_dtrace ; /usr/sbin/dtrace -o Python/pydtrace.o -DPYDTRACE_STACK_HELPER -I. -IInclude -I./../Include -I/usr/local/include -C -G -s Include/pydtrace.d Python/ceval.o Modules/gcmodule.o Objects/classobject.o Objects/typeobject.o ; touch -r Python/ceval.o.ts_dtrace Python/ceval.o ; touch -r Modules/gcmodule.o.ts_dtrace Modules/gcmodule.o ; touch -r Objects/classobject.o.ts_dtrace Objects/classobject.o ; touch -r Objects/typeobject.o.ts_dtrace Objects/typeobject.o ; rm Python/ceval.o.ts_dtrace ; rm Modules/gcmodule.o.ts_dtrace ; rm Objects/classobject.o.ts_dtrace ; rm Objects/typeobject.o.ts_dtrace ; else touch Python/pydtrace.o ; fi; dtrace: failed to compile script Include/pydtrace.d: line 26: typedef redeclared: __uint8_t Sevan / Venture37 From owner-freebsd-dtrace@FreeBSD.ORG Fri Jun 6 11:40:16 2014 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 ESMTPS id 9AD647C1; Fri, 6 Jun 2014 11:40:16 +0000 (UTC) Received: from nexus.ut.mephi.ru (nexus.ut.mephi.ru [85.143.112.92]) by mx1.freebsd.org (Postfix) with ESMTP id 19CBE25C1; Fri, 6 Jun 2014 11:40:15 +0000 (UTC) Received: from [85.143.112.127] (unknown [85.143.112.127]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: dyokunev@ut.mephi.ru) by nexus.ut.mephi.ru (Postfix) with ESMTPSA id 42E1322E1A62; Fri, 6 Jun 2014 15:40:07 +0400 (MSK) Message-ID: <5391A8B4.4030906@ut.mephi.ru> Date: Fri, 06 Jun 2014 15:40:36 +0400 From: Dmitry Yu Okunev Organization: NRNU MEPhI User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.4.0 MIME-Version: 1.0 To: Mark Johnston Subject: Re: failed to resolve cwd: Unknown variable name References: <5388A227.7050805@ut.mephi.ru> <538EAAF1.1030005@ut.mephi.ru> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="fTouAIcmO3bwgWq656h71xuXKm6vmEQr6" X-LastMilter: passed X-LastMilter-Score: 0 Cc: freebsd-dtrace@freebsd.org X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.18 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, 06 Jun 2014 11:40:16 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fTouAIcmO3bwgWq656h71xuXKm6vmEQr6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 06/04/2014 05:25 PM, Mark Johnston wrote: > On Wed, Jun 4, 2014 at 1:13 AM, Dmitry Yu Okunev = wrote: >> On 06/04/2014 06:28 AM, Mark Johnston wrote: >>> On Fri, May 30, 2014 at 11:22 AM, Dmitry Yu Okunev wrote: >>>> But when I try to use the variable I get a failure: >>>>> dtrace: invalid probe specifier syscall:::entry { printf("%s", cwd)= ; >>>> }: in action list: failed to resolve cwd: Unknown variable name >>>> >>>> You can get the same error by running a dtrace-script from official >>>> FreeBSD distribution: >>>>> /usr/share/dtrace/toolkit/opensnoop -c >>> So one can get a bit of the way there with something ugly like >>> >>> inline string cwd =3D >>> stringof(curthread->td_proc->p_fd->fd_cdir->v_cache_dst.tqh_first->nc= _name); >>> >>> to get the last component of a process' cwd (it needs a check for a >>> missing cache entry), but I don't see any easy way to get at the full= >>> cwd. Calling vn_fullpath() in probe context would be a pretty bad ide= a >>> since it may invoke VFS operations >> >> Hm. If it's performance problem only, then personally I can endure tha= t. >> >> Can I use vn_fullpath*() in dtrace probes on current FreeBSD? >=20 > It's a safety thing. DTrace probes execute with interrupts disabled, > so they're fairly limited in what they're allowed to do. Name > resolution potentially requires the underlying filesystem code to read > from disk or invoke an RPC, which cannot be done in probe context. > Hence my suggestion of a cache-only lookup function that could be > callable from within a probe. Well. Here're two problems: 1. The solution returns only the last component of cwd. How to get the rest? I can handle it myself (if it's possible), but if somebody already have working solution that would be great :) 2. Is this solution steady to FreeBSD version updates? I think that this headers can be changed with every major version. --=20 Best regards, Dmitry, head of UNIX-tech department NRNU MEPhI, tel. 8 (495) 788-56-99, ext. 8255 --fTouAIcmO3bwgWq656h71xuXKm6vmEQr6 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBAgAGBQJTkai1AAoJEK2K5AyOMGec2X8QALJIHX2zuZ+2JtqFZ1ONoE1f 2GHzB29EkpNgdsVh2pdlGjUN+PaTQlh3aUJknqrfxpXidvfYnkwy5FRUEuBRSHcT Ne/FXsERE8lbfgP8Av/EF/lbFOM0lfbIKFT6IEldv+/6Zb2SSBBE9lKzyQWmOTbp gbFFsc2KbXPxG30/ARXI9ElbLsG/7n3WVN6It2WMt9uaxyOAVFdMvfpBA2SmlwLj age9BQNwyBt8p8mrf+zAjH/Ex2Q4VG3XFRNDHGD2p0YjWuZDxuV5qT0xu7us9R+A rpG6H04fhLHfldlsY7Lqbu2VykVsz2odoECiVLkSU3vkoj8vRuh7xXFx4s0uG08V H6WTYe3FNrBMzO/o26Pg6kbpTksWDiCa7NVboysJxQeGVdiHWyeku1zwRiEwFxCa c/GdRkGRzqYj3yUo9qnYeXg8RGDZQ7kRD+J0gjQas7Mj4mPB+8aYfZ+RopykYiDF IvOlBTd8KCyRnhZWdsERWz7OOeiUQjtWv88/bYhB9E+VMl6p9HO2KfkDlL4WUcuP kMtyH73kboMl5QfQyieJmN1tP3ompTa/uCYiBUnFrW3kJxrgHBoycs6b3zBYJXYh nv3FClp1qsf1tZeZxmeIxlaNymHWGwRf+7bLjmI3J9tP6XL+zCz8ZbzenPJ3Vz/A IEJfmSuHaykN/pY64jV3 =LDuB -----END PGP SIGNATURE----- --fTouAIcmO3bwgWq656h71xuXKm6vmEQr6-- From owner-freebsd-dtrace@FreeBSD.ORG Mon Jun 9 18:16:39 2014 Return-Path: Delivered-To: freebsd-dtrace@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 116B3F0 for ; Mon, 9 Jun 2014 18:16:39 +0000 (UTC) Received: from mail-ob0-x229.google.com (mail-ob0-x229.google.com [IPv6:2607:f8b0:4003:c01::229]) (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 D01472282 for ; Mon, 9 Jun 2014 18:16:38 +0000 (UTC) Received: by mail-ob0-f169.google.com with SMTP id wp18so3723883obc.14 for ; Mon, 09 Jun 2014 11:16:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=DlVb7Ca9YPBCadhTt8TOFS8xL6FSu8i+gLK1xWleSsI=; b=KityOBSfHFgIaXDI5EhMlM13thpzhoSuJbqydwzx5XaLqp0lXP7LVU7HbAIPaFzHxn /P1ozpcYbIVQnsgLUPTMu8UmC5uqDTDZUvY0HQtUWGtBbxJlnh9aZkt3/KchDKQpAbQD LpQ1CmOMXbHPoqi/hz5kgWwAcwYQCGQjTRklyST+lW8mcCTJLxi6ANou8EXfYMWfk6dR DmvktQxSKorvxeWjFcIs5hg5aq++2LYbf0kwM5vh4E5ZZNfQFzf7D1432h3J2H9kDnBG Wr8QPzQ0aWMmBe7j973lAQEH27msBRZThDhTwCmxTvNTgKh7+e0LeIVkzQQIsuNQP0f6 5daQ== MIME-Version: 1.0 X-Received: by 10.182.65.167 with SMTP id y7mr26338410obs.29.1402337798030; Mon, 09 Jun 2014 11:16:38 -0700 (PDT) Received: by 10.76.18.114 with HTTP; Mon, 9 Jun 2014 11:16:37 -0700 (PDT) In-Reply-To: References: Date: Mon, 9 Jun 2014 19:16:37 +0100 Message-ID: Subject: Re: DTrace probes for python 2.7.7 From: "Sevan / Venture37" To: "freebsd-dtrace@freebsd.org" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.18 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: Mon, 09 Jun 2014 18:16:39 -0000 On 4 June 2014 20:15, Sevan / Venture37 wrote: > dtrace: failed to compile script Include/pydtrace.d: line 26: typedef > redeclared: __uint8_t On i386 the build fails differently with r266655 snapshot from 20140525 =E2=80=9Cfailed to compile script Include/pydtrace.d: =E2=80=9C/usr/lib/dtr= ace/ip.d=E2=80=9D line 2: type redeclared: struct devinfo" There is of course an inconsistent. The original error regarding the redeclaration of __uint8_t was from a AMD64 host running r266972. Installing the AMD64 r266655 snapshot & retrying the build results in, failed to compile script Include/pydtrace.d: =E2=80=9C/usr/lib/dtrace/unistd.d=E2=80=9D, line 135: syntax error near =E2= =80=9Ccsinfo_t=E2=80=9D Can anyone shed some light on what's going on. Sevan From owner-freebsd-dtrace@FreeBSD.ORG Mon Jun 9 18:28:34 2014 Return-Path: Delivered-To: freebsd-dtrace@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 09E81524 for ; Mon, 9 Jun 2014 18:28:34 +0000 (UTC) Received: from mail-ve0-x235.google.com (mail-ve0-x235.google.com [IPv6:2607:f8b0:400c:c01::235]) (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 BB1A223AC for ; Mon, 9 Jun 2014 18:28:33 +0000 (UTC) Received: by mail-ve0-f181.google.com with SMTP id db11so1494634veb.26 for ; Mon, 09 Jun 2014 11:28:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=PU7VJML5CsaycuiwZa4xFuA1wqBY9PUijGTEpHrk3y4=; b=L4qxRS1ad4U4ILAhZ9U3EraThgZ5kv+tz2MOS9eK+fW1JsbcCX3Cam9OLr1HDVP425 b3XGf/7VfLbZVQxLnD1zfZgC9fHncvRgC2aWGyOoGfzjNcCiRCASeJp60x/1VTMxzXg6 yU1lCNuZ5ZB4OX9ilC/Z41oHl4GQfrcHab83RWgztXguxrf7WkAEk1355NGMKqGDdX+o mMRHYyCMBEguAM9NY0aZ7PK7nQ66FaCa19oQm2Je21riCgvnQ4YMw7SJskdQE5AF8nw7 BViokEylb3aa3PZMYBC41hV9SUFI1UqvzOMZD+mu5UZfwNFtJhavsr49x6hCyu1dx/aG QLCw== MIME-Version: 1.0 X-Received: by 10.52.33.241 with SMTP id u17mr1774641vdi.82.1402338512751; Mon, 09 Jun 2014 11:28:32 -0700 (PDT) Sender: markjdb@gmail.com Received: by 10.220.162.68 with HTTP; Mon, 9 Jun 2014 11:28:32 -0700 (PDT) In-Reply-To: References: Date: Mon, 9 Jun 2014 14:28:32 -0400 X-Google-Sender-Auth: gpCkdrklACIVzx_GStSXKLii-qg Message-ID: Subject: Re: DTrace probes for python 2.7.7 From: Mark Johnston To: "Sevan / Venture37" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "freebsd-dtrace@freebsd.org" X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.18 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: Mon, 09 Jun 2014 18:28:34 -0000 On Mon, Jun 9, 2014 at 2:16 PM, Sevan / Venture37 wro= te: > On 4 June 2014 20:15, Sevan / Venture37 wrote: >> dtrace: failed to compile script Include/pydtrace.d: line 26: typedef >> redeclared: __uint8_t > > On i386 the build fails differently with r266655 snapshot from 20140525 > > =E2=80=9Cfailed to compile script Include/pydtrace.d: =E2=80=9C/usr/lib/d= trace/ip.d=E2=80=9D > line 2: type redeclared: struct devinfo" > > There is of course an inconsistent. > > The original error regarding the redeclaration of __uint8_t was from a > AMD64 host running r266972. > > Installing the AMD64 r266655 snapshot & retrying the build results in, > > failed to compile script Include/pydtrace.d: > =E2=80=9C/usr/lib/dtrace/unistd.d=E2=80=9D, line 135: syntax error near = =E2=80=9Ccsinfo_t=E2=80=9D > > Can anyone shed some light on what's going on. This is probably because the build is running dtrace -G without the dtrace kernel modules loaded. This shouldn't be a problem, but currently is because dtrace(1) parses the scripts in /usr/lib/dtrace and errors out if dtrace isn't available in the kernel. Things like "#pragma depends_on" don't work, and there seem to be bugs in the error reporting of libdtrace; one ends up with the error messages above. I'd like to fix this by changing dtrace -G to not process scripts in the libdir, but I'm not yet sure what the implications of this are. I will ask on the dtrace-discuss list soon. In the meantime, a somewhat unsatisfactory workaround would be to just kldload dtraceall before starting the build. -Mark From owner-freebsd-dtrace@FreeBSD.ORG Mon Jun 9 18:40:09 2014 Return-Path: Delivered-To: freebsd-dtrace@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2CC186CD; Mon, 9 Jun 2014 18:40:09 +0000 (UTC) Received: from mail-oa0-x236.google.com (mail-oa0-x236.google.com [IPv6:2607:f8b0:4003:c02::236]) (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 DE8312498; Mon, 9 Jun 2014 18:40:08 +0000 (UTC) Received: by mail-oa0-f54.google.com with SMTP id eb12so3825753oac.27 for ; Mon, 09 Jun 2014 11:40:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9k6ON37fFv0MSGPnCHLrO5SKyVHne4C2sSWGjZd+jfU=; b=kMCv5lxxuccoXfrZ/dlvM7cjV9kKCMeT9z55UzgE9XmnxAzWSLli8tAhapYBEI3agP NRQkfvO46ehtJfrE7rMNeA8bsAtIy9o+U0dqwdB7Y4wnLq5/ctZNEsptKgzKw7Yk8Aj5 D8u8UWJ4742JhSMZ0OFE9qP7bfiu2e0eaeT3vrHR4DlZ+/Du7D6KNZ8RllzMCMoQ6uWS oCM0BGRzH39wWoVTgSGBpfWUS0L7RQR26z1c1Kg3FubibDQd67WnqOtp0Q9vgfchKixI sRfJoAiLVIjnin7SxOpoLjlz1kZCgpNMtD8HelLQsvJ9Mk5ijpc0UhEF8WfZSqfGEGv5 G+Dg== MIME-Version: 1.0 X-Received: by 10.60.52.207 with SMTP id v15mr28023588oeo.19.1402339208034; Mon, 09 Jun 2014 11:40:08 -0700 (PDT) Received: by 10.76.18.114 with HTTP; Mon, 9 Jun 2014 11:40:07 -0700 (PDT) In-Reply-To: References: Date: Mon, 9 Jun 2014 19:40:07 +0100 Message-ID: Subject: Re: DTrace probes for python 2.7.7 From: "Sevan / Venture37" 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 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: Mon, 09 Jun 2014 18:40:09 -0000 On 9 June 2014 19:28, Mark Johnston wrote: > This is probably because the build is running dtrace -G without the > dtrace kernel modules loaded. This shouldn't be a problem, but > currently is because dtrace(1) parses the scripts in /usr/lib/dtrace > and errors out if dtrace isn't available in the kernel. Things like > "#pragma depends_on" don't work, and there seem to be bugs in the > error reporting of libdtrace; one ends up with the error messages > above. > > I'd like to fix this by changing dtrace -G to not process scripts in > the libdir, but I'm not yet sure what the implications of this are. I > will ask on the dtrace-discuss list soon. > > In the meantime, a somewhat unsatisfactory workaround would be to just > kldload dtraceall before starting the build. > > -Mark Indeed, that was it, with dtraceall module loaded on r266655 VM's, everything fails with the same error now. "dtrace: failed to compile script Include/pydtrace.d: line 26: typedef redeclared: __uint8_t" Sevan From owner-freebsd-dtrace@FreeBSD.ORG Wed Jul 16 04:14:49 2014 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 ESMTPS id 035E4540 for ; Wed, 16 Jul 2014 04:14:49 +0000 (UTC) Received: from mail-ie0-x235.google.com (mail-ie0-x235.google.com [IPv6:2607:f8b0:4001:c03::235]) (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 C0AD828A7 for ; Wed, 16 Jul 2014 04:14:48 +0000 (UTC) Received: by mail-ie0-f181.google.com with SMTP id rp18so300411iec.26 for ; Tue, 15 Jul 2014 21:14:48 -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=3GyFIu4cUjZIPBs6a+u4e6botOuJXlhszNZY1IAX8bc=; b=m/jIO5882MI+a1r2UsXRb+hiRhuC705HyZzO4WlBQ74pEUUK1WzRxS1PgErInYXjQD L7P1Zbw+3rz9ETOhvnx636koO1FynvTYGKsVGhhG0YA9zoIt2TflJF2IuSTSMY9x4sTf G7aK0Uj5yRdwHXedVzrHYUqojogjL9l1+6iYlaalUxXeGnw8Qwlib0bUVuGeTtWKJeN8 V2j79Zrf4DP9e72NsacbtJEkBwTWE8ZzY7ypRMKpU8EZEWne4m+P65GNaGEdhvwp1jWL efcAdjR8PPTGv2HSWJ+GMbd0Awgi/cKNN0xwIMuqcqJb6JbS1F0mOgq3skR1lUUo6dwh iLEg== X-Received: by 10.42.214.207 with SMTP id hb15mr34780423icb.30.1405484088223; Tue, 15 Jul 2014 21:14:48 -0700 (PDT) Received: from raichu (24-212-142-131.cable.teksavvy.com. [24.212.142.131]) by mx.google.com with ESMTPSA id l5sm3338436ige.6.2014.07.15.21.14.47 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 15 Jul 2014 21:14:47 -0700 (PDT) Sender: Mark Johnston Date: Wed, 16 Jul 2014 00:14:45 -0400 From: Mark Johnston To: Sevan / Venture37 Subject: Re: DTrace probes for python 2.7.7 Message-ID: <20140716041445.GB20065@raichu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Cc: "freebsd-dtrace@freebsd.org" X-BeenThere: freebsd-dtrace@freebsd.org X-Mailman-Version: 2.1.18 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: Wed, 16 Jul 2014 04:14:49 -0000 On Mon, Jun 09, 2014 at 07:40:07PM +0100, Sevan / Venture37 wrote: > On 9 June 2014 19:28, Mark Johnston wrote: > > This is probably because the build is running dtrace -G without the > > dtrace kernel modules loaded. This shouldn't be a problem, but > > currently is because dtrace(1) parses the scripts in /usr/lib/dtrace > > and errors out if dtrace isn't available in the kernel. Things like > > "#pragma depends_on" don't work, and there seem to be bugs in the > > error reporting of libdtrace; one ends up with the error messages > > above. > > > > I'd like to fix this by changing dtrace -G to not process scripts in > > the libdir, but I'm not yet sure what the implications of this are. I > > will ask on the dtrace-discuss list soon. > > > > In the meantime, a somewhat unsatisfactory workaround would be to just > > kldload dtraceall before starting the build. > > > > -Mark > > Indeed, that was it, with dtraceall module loaded on r266655 VM's, > everything fails with the same error now. > > "dtrace: failed to compile script Include/pydtrace.d: line 26: typedef > redeclared: __uint8_t" I've since discovered that the correct way to solve this problem is by adding "-xnolibs" to the dtrace -G flags.