trying to understand otool's inner workings
trying to understand otool's inner workings
- Subject: trying to understand otool's inner workings
- From: Sam Hocevar <email@hidden>
- Date: Mon, 8 Jan 2007 13:04:17 +0100
- Mail-copies-to: never
I am trying to understand how otool reads binaries. I traced it with
ktrace, but the information is pretty meager:
% ktrace -d -t cnisuw otool -d /usr/lib/libz.dylib
/usr/lib/libz.dylib:
[...]
% kdump
[...]
3137 otool CALL open(0xbffffc65,0,0x8c)
3137 otool NAMI "/usr/lib/libz.dylib"
3137 otool RET open 4
3137 otool CALL fstat(0x4,0xbffff920)
3137 otool RET fstat 0
3137 otool CALL close(0x4)
3137 otool RET close 0
3137 otool CALL open(0xbffffc65,0,0x8c)
3137 otool NAMI "/usr/lib/libz.dylib"
3137 otool RET open 4
3137 otool CALL fstat(0x4,0xbffff920)
3137 otool RET fstat 0
3137 otool CALL close(0x4)
3137 otool RET close 0
3137 otool CALL fstat(0x1,0xbfffef80)
3137 otool RET fstat 0
3137 otool CALL ioctl(0x1,FIODTYPE,0xbfffef4c)
3137 otool RET ioctl 0
3137 otool CALL write(0x1,0x99000,0x15)
3137 otool GIO fd 1 wrote 21 bytes
"/usr/lib/libz.dylib:
"
[...]
So, according to the kdump, otool only does an fstat() between the
open() and close() calls. Surely this is not sufficient to read the
__DATA section, is it? Or does fstat() also cause the kernel to load the
file in memory? Any idea how I could know what otool does to read the
file that ktrace is not aware of? Is there another tool that I can use
instead of ktrace that will give me more information?
Regards,
--
Sam.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden