FROM : Bob Ippolito
DATE : Fri Dec 24 01:54:01 2004
On Dec 23, 2004, at 2:47 PM, Steven Kramer wrote:
>
> Op 23-dec-04 om 17:36 heeft Herr Witten het volgende geschreven:
>
>>> Don't. Pass an extra parameter (id sender?) instead.
>>
>> I did not want to do this, but it seems to be the easiest route. I
>> will probably go with this, since manually traversing the call stack
>> does not seem to be a normal thing. I don't even know how to do it.
>>
>>> ..but it's a little easier than that sounds, because the good folks
>>> of
>>> cocoadev have already written the code.
>>
>> Unfortunately, I cannot spend the time launching a subprocess. I had
>> hoped for a more direct solution. Nevertheless, thank you very much.
>>
>>> you can always write a couple of tracing macro something like
>>> #define TRACE_FUNC(x) NSLog(@"0x%x->%s", self, x);
>>> then
>>> void myfunc(int a ....) {
>>> TRACE_FUNC("myfunc")
>>> .....
>>> }
>>
>
> You can probably get the source for atos from Apple's Darwin
> distributions. It may be a worthwhile download. Please let me know if
> you ever get this going...
You can also raise and catch an NSException, which you should be able
to get a stack trace from (as addresses). If you're tracing specific
IMPs or functions, it should be easy enough to get their addresses
without resorting to looking at the symbol table directly. If not, you
could look at the symbol tables directly in-process with the dyld APIs,
see /usr/include/mach-o/*.h .. all of this stuff is pretty crazy
though, it sounds like the wrong solution to a problem that you might
not even have :)
-bob
DATE : Fri Dec 24 01:54:01 2004
On Dec 23, 2004, at 2:47 PM, Steven Kramer wrote:
>
> Op 23-dec-04 om 17:36 heeft Herr Witten het volgende geschreven:
>
>>> Don't. Pass an extra parameter (id sender?) instead.
>>
>> I did not want to do this, but it seems to be the easiest route. I
>> will probably go with this, since manually traversing the call stack
>> does not seem to be a normal thing. I don't even know how to do it.
>>
>>> ..but it's a little easier than that sounds, because the good folks
>>> of
>>> cocoadev have already written the code.
>>
>> Unfortunately, I cannot spend the time launching a subprocess. I had
>> hoped for a more direct solution. Nevertheless, thank you very much.
>>
>>> you can always write a couple of tracing macro something like
>>> #define TRACE_FUNC(x) NSLog(@"0x%x->%s", self, x);
>>> then
>>> void myfunc(int a ....) {
>>> TRACE_FUNC("myfunc")
>>> .....
>>> }
>>
>
> You can probably get the source for atos from Apple's Darwin
> distributions. It may be a worthwhile download. Please let me know if
> you ever get this going...
You can also raise and catch an NSException, which you should be able
to get a stack trace from (as addresses). If you're tracing specific
IMPs or functions, it should be easy enough to get their addresses
without resorting to looking at the symbol table directly. If not, you
could look at the symbol tables directly in-process with the dyld APIs,
see /usr/include/mach-o/*.h .. all of this stuff is pretty crazy
though, it sounds like the wrong solution to a problem that you might
not even have :)
-bob
| Related mails | Author | Date |
|---|---|---|
| lingwitt | Dec 22, 07:39 | |
| Andrew Farmer | Dec 22, 08:16 | |
| Jérémie Banier | Dec 22, 08:40 | |
| Ken Ferry | Dec 22, 08:42 | |
| Herr Witten | Dec 23, 17:36 | |
| Steven Kramer | Dec 23, 20:47 | |
| Bob Ippolito | Dec 24, 01:54 |






Cocoa mail archive

