Re: OmniObjectMeter and PB/gdb
Re: OmniObjectMeter and PB/gdb
- Subject: Re: OmniObjectMeter and PB/gdb
- From: Paul Williamson <email@hidden>
- Date: Wed, 07 Aug 2002 01:20:02 -0700
At 09:44 PM 8/6/2002 -0700, Timothy J. Wood wrote:
1)
- Start the vict^H^H^H^H target using OOM
- Start a debugger session (I use gdb in Terminal, but PB should work)
- Do NOT start the process in gdb, but instead figure out the pid of
the target and do:
attach pid
I could've sworn that didn't work yesterday, but today it does. Thanks!
Probably I was confused by a couple of things:
First, I didn't realize that the target program automatically breaks when
you attach to it with gdb. Nothing runs again until you tell it to. I guess
that makes sense.
Second, I didn't realize that OOM can't run, not even its UI, when the
target program isn't running. This makes OOM+gdb a much less appealing
combination that I had hoped. I wanted to paw around in the OOM displays
while my program sat at a breakpoint, so I could carefully step through the
consequences of each part of the program.
I guess that OOM is trying to minimize its data collection, so it only
retrieves the information it needs to update the display. And that implies
that OOM can't update the display in any useful way when it can't collect
new data. And it must be gathering data by communicating with routines in
the running target process. Oh, well.
I can't figure out how to get a gdb running in PB without also running the
target program.
2) (This is what I was doing...)
- Link the OmniObjectMeterFramework as per the instructions in the
OOM manual
- Launch the process in gdb
- Launch OOM and it should automatically connect
I was hoping to avoid this, but I just tried it and ...
First, there's an error in the help file. It says to include
<OmniObjectMeterFramework/OOMPublic>, but that doesn't exist. It's actually
<OmniObjectMeterFramework/OOMPublic.h>.
Second, the procedure given for creating what the help file calls a "link"
but is actually an alias does not work. It runs afoul of permissions.
Bypassing the permissions problem allows the alias to be created.
Third, the alias doesn't work. The build fails, complaining that it can't
open the framework. Getting rid of the alias and creating an actual link
(from Terminal with "ln -s") allows the program to find the framework and
run. (Disclaimer: maybe I'm confused about the alias and the link, too. I'm
a refugee from embedded systems and this is the first Mac OS alias I've
ever created.)
Finally, OOM successfully connects with the target and gets data, hurrah.
But it works the same way as with the first procedure: the OOM UI freezes
when the target program is paused. Too bad. However, this procedure does
have the advantage that you can do it from within Project Builder.
Thanks for your help!
-Paul
email@hidden
_______________________________________________
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.