From owner-freebsd-current@FreeBSD.ORG Thu Mar 1 22:05:46 2012 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F0512106564A for ; Thu, 1 Mar 2012 22:05:45 +0000 (UTC) (envelope-from gonzo@hq.bluezbox.com) Received: from hq.bluezbox.com (hq.bluezbox.com [70.38.37.145]) by mx1.freebsd.org (Postfix) with ESMTP id BB9918FC1B for ; Thu, 1 Mar 2012 22:05:45 +0000 (UTC) Received: from localhost ([127.0.0.1]) by hq.bluezbox.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.73 (FreeBSD)) (envelope-from ) id 1S3Dsd-000C5m-R4; Thu, 01 Mar 2012 13:49:44 -0800 Message-ID: <4F4FEEFC.5060902@freebsd.org> Date: Thu, 01 Mar 2012 13:49:48 -0800 From: Oleksandr Tymoshenko User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "freebsd-mips@freebsd.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: gonzo@hq.bluezbox.com X-Spam-Level: ---- X-Spam-Report: Spam detection software, running on the system "hq.bluezbox.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see The administrator of that system for details. Content preview: Hello, Last few weeks I've been working on DTrace port for MIPS architecture. I believe that project reached the stage when it's ready for public review/testing before going into the tree. Patch and some information could be found here: http://people.freebsd.org/~gonzo/mips/dtrace/ [...] Content analysis details: (-4.4 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 0.0 AWL AWL: From: address is in the auto white-list Cc: freebsd-current@freebsd.org Subject: DTrace/MIPS port X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Mar 2012 22:05:46 -0000 Hello, Last few weeks I've been working on DTrace port for MIPS architecture. I believe that project reached the stage when it's ready for public review/testing before going into the tree. Patch and some information could be found here: http://people.freebsd.org/~gonzo/mips/dtrace/ I'd appreciate review/testing from interested parties and if there are no major roadblocks the plan is to commit this patch sometime next week. DTrace/MIPS passes substantial part of DTrace suite on my Octeon-based board. ==== TEST RESULTS ==== mode: /usr/sbin/dtrace passed: 853 failed: 74 total: 927 There are some caveats/limitations though: - fbt, pid, lockstat, profile providers are not implemented - MIPS passes function arguments in registers and unless they're saved on stack the value of some might be unavailable in backtrace. So values of argN variables might be bogus sometimes. - dtrace uses kldstat(2) to get path to kernel binary and for "embedded" systems (e.g. without loader(8)) it's just "kernel" So kernel binary should be in current directory so dtrace could get CTF data from it. We need either command-line switch or env variable to let dtrace know where to look for binary. I haven't yet decided which way to go. - Not really dtrace issue, but somewhat related. FreeBSD/MIPS default kernel stacks size seems to be insufficient to load kernel modules with dependency chain longer then three modules (dtrace_test -> dtrace_all -> dtrace -> cyclic -> opensolaris) Sometimes I get kernel stack exhaustion as a combination of FS-related calls that goes down to NFS functions + WITNESS code. No proper solution for it yet. Workaround - load module one by one. - Tested only on mips64be platform. mips32be, mips32le, mips64le were not tested. Patches: dtrace-all.diff - is a cumulative patch that contains diff between HEAD branch and project branch in p4. In order to make code review easier I split it into several sub-patches based on functionality area. dtrace-ctf.diff Current version of ctfmerge assumes that target byte order is the same as host one. This patch checks byte order of ELF files being used to decide whether byte order in CTF structures' fields should be reversed. dtrace-toolchain.diff - Disable SGI compatibility for generated DWARF data. It confuses ctfconvert. - Set as(1) default ABI and target size the same as target platform dtrace-sys.diff - Kernel part of DTrace code - More intelligent kernel stack overflow handler dtrace-userland.diff - Userland part of DTrace code - Build DTrace tols as a part of toolchain build if we're cross-compiling - Various libraries' plugs for MIPS