RE: -finstrument-functions and program startup
RE: -finstrument-functions and program startup
- Subject: RE: -finstrument-functions and program startup
- From: "Karan, Cem (Civ, ARL/CISD)" <email@hidden>
- Date: Thu, 29 Jan 2009 09:09:59 -0500
- 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!
http://en.wikipedia.org/wiki/Heisenbug#Heisenbug
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)
Thanks,
Cem Karan
_______________________________________________
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