Thread-topic: -finstrument-functions and program startup
Greg Parker wrote on Wednesday, January 28, 2009 4:22 PM
> On Jan 28, 2009, at 10:33 AM, Karan, Cem (Civ, ARL/CISD) wrote:
> > First off, I know this question is going to the wrong list,
> but I have
> > NO idea which list would be best. If anyone wants to jump
> in and tell
> > me a better list, I'll gladly move there.
> > Background:
> > I have an application that is working very, very hard to drive me
> > insane. It is multithreaded, lazy, and has my broken attempt at
> > trampoline code. Now, it crashes once in a while, but I'm not sure
> > what the trail of broken bits are that causes the crash. If only I
> > had a way of instrumenting every single entry and exit of each
> > function, I could log it all… which is exactly what -finstrument-
> > functions does.
> You'll likely get better results from dtrace than
> -finstrument- functions. DTrace can be programmed to act on
> function entry or exit for all functions in a specified file.
> (DTrace experts: this is your cue to chime in.)
I thought DTrace was primarily statistical in nature, right? Won't -finstrument-function work better in my case because it is guaranteed to be called each time?
Meh, I have no idea; I've never used it before, just Instruments, and not much at that.
> Be warned that any instrumentation tool is likely to perturb
> your bug away, if it is in fact a problem with multithreading
> or code generation.
I KNEW I'd seen a great name for this somewhere!
Yes, I'm familiar with them, and that is part of the reason for running the traces. I'm hoping that with enough traces I'll figure out why I'm having problems. I figure that by running diffs on all the traces, I'll start finding commonalities between them, which will give me a clue as to what to look for.
> > For those of you that don't know about it, when you
> compile your code
> > using -finstrument-functions, just after the entry point of each
> > instrumented function the function
> __cyg_profile_func_enter() will be
> > called, and __cyg_profile_func_exit() will be called just before
> > function exit. You define those functions as you wish.
> > The tricky part is that there are certain functions that
> must not be
> > instrumented like that, so you need to set the attribute
> > no_instrument_function on those functions. In my case, I
> want to run
> > some startup code before either of those methods ever get
> called. I
> > put my code into main(), but, IIRC, there is some function
> that gets
> > called before main() does. If that is a library function, I'm OK
> > since __cyg*() won't get compiled into anything I don't have the
> > source for, but if gcc is generating some code that calls __cyg*()
> > before I get the chance to do the setup, I'm going to
> > have another crash. So, is there anything called before main()?
> > What about just before main() returns?
> +load methods and static C++ constructors are obvious examples of code
> run before main().
I hadn't thought of those. That would explain a great deal though.
> For testing purposes, you could add a flag that's set after
> your prep work is complete, and check it in
> __cyg_profile_func_enter. You could even do the prep work
> inside __cyg_profile_func_enter if the flag isn't set yet.
Yeah, I just tested that, and it works well. I'd like to find a way of registering a callback that is guaranteed to be the last function called in the program, but there doesn't seem to be a way (registering with atexit() doesn't work; there are a lot of functions called afterwards, and, although not actually necessary for what I'm doing, I'd like to see what they are)
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden