Date: Fri, 2 Mar 2012 18:51:33 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Oleksandr Tymoshenko <gonzo@freebsd.org> Cc: freebsd-current@freebsd.org, "freebsd-mips@freebsd.org" <freebsd-mips@freebsd.org> Subject: Re: DTrace/MIPS port Message-ID: <alpine.BSF.2.00.1203021850300.99200@fledge.watson.org> In-Reply-To: <4F4FEEFC.5060902@freebsd.org> References: <4F4FEEFC.5060902@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 1 Mar 2012, Oleksandr Tymoshenko wrote: > 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. This is great news -- I probably won't be in a position to test or contribute usefully for a couple more months, but will endeavour to do so once our port to CHERI MIPS is a bit further along! Robert > > ==== 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 > _______________________________________________ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.00.1203021850300.99200>