DTrace/MIPS port
Hi Gonzo, I got your patch of port mips (http://lists.freebsd.org/pipermail/freebsd-current/2012-March/032182.html), in which you noted that fbt, pid are not implemented. Would you pls. explain the reason why fbt and pid aren't implemented? If I want to use fbt and pid, what should I do ? Best Regards, Yafang ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: DTrace/MIPS port
On 01/03/2012 1:49 PM, Oleksandr Tymoshenko wrote: 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. These changes are now committed into the FreeBSD HEAD branch ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: DTrace/MIPS port
On 26 March 2012 15:01, Oleksandr Tymoshenko go...@freebsd.org wrote: These changes are now committed into the FreeBSD HEAD branch Great work! Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: DTrace/MIPS port
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-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
DTrace/MIPS port
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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
