On Wed, Oct 28, 2009 at 06:55:28PM +, Joel Reymont wrote:
I have a script where I can freely reference struct nameidata*, struct
vnode*, etc. on Snow Leopard.
How does DTrace know about these data types? I understand things like
#pragma D depends_on library darwin.d
where darwin.d
Same on Mac OS X. In Snow Leopard, the final CTF data is linked into the kernel
file. In previous versions of Mac OS X, the CTF data was in a separate
mach_kernel.ctfsys file
$ size -arch x86_64 -l /mach_kernel | grep -A 2 __CTF
Segment __CTF: 0 (vmaddr 0x0 fileoff 5320728)
Section
On Oct 28, 2009, at 8:00 PM, Shantonu Sen wrote:
Same on Mac OS X. In Snow Leopard, the final CTF data is linked into
the kernel file. In previous versions of Mac OS X, the CTF data was
in a separate mach_kernel.ctfsys file
I didn't know what CTF was but this page provided a good summary:
not enough space typically means you ran out of virtual memory
--
This message posted from opensolaris.org
___
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
That's strange -- I see lots of output. What operating system and
version are you running?
Adam
On Oct 28, 2009, at 3:58 PM, tester wrote:
how does one trace functions just in the binary (not including all
the libraries)
tracing ps gives this
# dtrace -n 'pid$target:ps::entry{}' -c ps
Adam,
# uname -a
SunOS 5.10 Generic_141414-10 sun4v sparc SUNW,SPARC-Enterprise-T5220
# more /etc/release
Solaris 10 5/09 s10s_u7wos_08 SPARC
Copyright 2009 Sun Microsystems, Inc. All Rights Reserved.
Use is subject to license terms.
I wondered if it might be because ps is linked to the magic am I a
64-bit kernel
or a 32-bit kernel program (aka /usr/lib/isaexec) that magically
execs the
correct binary (at least on S10). You should still see what that does, I
would
think.
Well, that's not it. All you get if you start the
