Re: Runtime messages
Re: Runtime messages
- Subject: Re: Runtime messages
- From: OS X AIBO <email@hidden>
- Date: Sat, 26 Oct 2002 10:57:37 -0700 (PDT)
--- Alan Nilsson <email@hidden> wrote:
>
Is there any way to make the run time system dump every message to
>
the console for an application?
No, not out of the box, but you may be able to create one.
This idea was considered a while back as a poor-man's way to compute
method coverage, without recompiling for instrumentation, to bolster
the value of defect metrics. (This was ~7 yrs ago --- I could be wrong
on any number of details, so hopefully I'm not just spewing.)
As Ondra Cada pointed out, the information you seek might be obtained
through the objc_msgSend* functions. These functions certain have the
info, but getting and using that information is another matter.
One route to exposing the parameters of obj_msgSend* functions, as
suggested by OC, is to use gdb, set a breakpoint and print out the
relevant information.
Here's an example of using gdb to dig through the stack:
For every Obj-C method, there are two hidden parameters inserted by the
compiler: the object (aka self) and the selector, an integer
representing the signature of the method.
What's the convention for passing parameters on the stack? Check out
http://developer.apple.com/techpubs/macosx/DeveloperTools/MachORuntime/2rt_powerpc_abi/index.html
If I read this correctly, there is no frame pointer, just a stack
pointer, with a relative offset of 24 to where the parameter section
begins.
For example, say you have a class MyClass which implements one method
"someMethod" which takes no args and returns void. By setting a
breakpoint on this method in gdb, you can wring the information you
seek with:
(gdb)po *(unsigned int *)(*$r1 + 24)
<MyClass: 0x1d36c80>
(gdb) po NSStringFromSelector(*(unsigned int *)(*$r1 + 28))
someMethod
(This example is contrived because having symbols makes all of this
unnecessary.)
But when you apply this same technique to obj_msgSend(), this doesn't
work in general because of the obfuscated way these functions can pass
their parameters. (You shouldn't think of this obfuscation as
necessarily bad--it makes these functions efficient which we all really
really want!) Put simply, fixed integer offsets don't always point to
the desired parameters for all functions/methods.
There was another approach we considered which could succeed where the
gdb approach fails. (Also, it is unproven, and is considerably more
work).
Starting with Darwin's objc runtime project, write your own version of
objc runtime which harvests the info you seek, and load this dylib
before the default ObjC runtime by specifying its path at the front of
your DYLD_LIBRARY_PATH.
Hope that helps,
--Dan
--- Alan Nilsson <email@hidden> wrote:
>
Is there any way to make the run time system dump every message to
>
the
>
console for an application? Or is there a tool that can monitor
>
this?
>
>
I realize this would be a very large amount of info, but in certain
>
instances it could be very educational and useful to see exactly what
>
messages are sent to what objects when a certain event occurs.
>
>
Alan
>
_______________________________________________
>
cocoa-dev mailing list | email@hidden
>
Help/Unsubscribe/Archives:
>
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
>
Do not post admin requests to the list. They will be ignored.
Y! Web Hosting - Let the expert host your web site
http://webhosting.yahoo.com/
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.