Re: Making sense of ktrace(1) output

2007-06-20 Thread Peter Jeremy
On 2007-Jun-18 12:34:21 -0700, [EMAIL PROTECTED] wrote: > Why not create a flag though instead of check to see if an environment > variables been set? The patch is to a library. There's no easy way to pass a flags to it and using environment variables is already used to control the behaviour of (

Re: Making sense of ktrace(1) output

2007-06-18 Thread youshi10
On Tue, 19 Jun 2007, Peter Jeremy wrote: On 2007-Jun-18 15:37:11 +0200, Roman Divacky <[EMAIL PROTECTED]> wrote: well.. instead of using ktrace I'd suggest building profiled pkg_add and see that way where the time is spent. ktrace is great if you dont have the source code... but you do :) If

Re: Making sense of ktrace(1) output

2007-06-18 Thread youshi10
On Mon, 18 Jun 2007, Roman Divacky wrote: Unfortunately I have to profile all of the source up the tree to create profiled symbols, and I'm running into some issues profiling liblegacy. Does anyone have any hints for getting around that, or just profiling all of the relevant libs? I thin

Re: Making sense of ktrace(1) output

2007-06-18 Thread Peter Jeremy
On 2007-Jun-18 15:37:11 +0200, Roman Divacky <[EMAIL PROTECTED]> wrote: >well.. instead of using ktrace I'd suggest building profiled pkg_add >and see that way where the time is spent. ktrace is great if you dont >have the source code... but you do :) If you decide to go this route, you might like

Re: Making sense of ktrace(1) output

2007-06-18 Thread Roman Divacky
>Unfortunately I have to profile all of the source up the tree to > create profiled symbols, and I'm running into some issues profiling > liblegacy. >Does anyone have any hints for getting around that, or just > profiling all of the relevant libs? I think you can build fbsd with profili

Re: Making sense of ktrace(1) output

2007-06-18 Thread Garrett Cooper
Roman Divacky wrote: On Mon, Jun 18, 2007 at 01:55:01AM -0700, Garrett Cooper wrote: Peter Jeremy wrote: On 2007-Jun-18 00:39:44 -0700, Garrett Cooper <[EMAIL PROTECTED]> wrote: However, I was able to get ktrace output. The only problem is that ktrace(1) apparently outputs onl

Re: Making sense of ktrace(1) output

2007-06-18 Thread Roman Divacky
On Mon, Jun 18, 2007 at 01:55:01AM -0700, Garrett Cooper wrote: > Peter Jeremy wrote: > >On 2007-Jun-18 00:39:44 -0700, Garrett Cooper <[EMAIL PROTECTED]> > >wrote: > > > >>However, I was able to get ktrace output. The only problem is that > >>ktrace(1) apparently outputs only in binary, instea

Re: Making sense of ktrace(1) output

2007-06-18 Thread banshee
kdump(1) -- Best regards, banshee, vault13.org... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Making sense of ktrace(1) output

2007-06-18 Thread Garrett Cooper
Peter Jeremy wrote: On 2007-Jun-18 00:39:44 -0700, Garrett Cooper <[EMAIL PROTECTED]> wrote: However, I was able to get ktrace output. The only problem is that ktrace(1) apparently outputs only in binary, instead of plaintext output. Can I convert it to plaintext somehow and process it?

Re: Making sense of ktrace(1) output

2007-06-18 Thread Simias
Garrett Cooper <[EMAIL PROTECTED]> writes: > Ok, so in my effort to find out the choke point for pkg_add, and in > the process I've tried both struss and strace, which have failed > because they weren't tracking the right PID and weren't following > forks (seemed like procfs is all mucked up even

Re: Making sense of ktrace(1) output

2007-06-18 Thread Peter Jeremy
On 2007-Jun-18 00:39:44 -0700, Garrett Cooper <[EMAIL PROTECTED]> wrote: > However, I was able to get ktrace output. The only problem is that ktrace(1) > apparently outputs only in binary, instead of plaintext output. Can I > convert it to plaintext somehow and process it? kdump(1) -- Peter Je

Making sense of ktrace(1) output

2007-06-18 Thread Garrett Cooper
Ok, so in my effort to find out the choke point for pkg_add, and in the process I've tried both struss and strace, which have failed because they weren't tracking the right PID and weren't following forks (seemed like procfs is all mucked up even though it's mounted and appears to be working to