On Jun 30, 2008, at 1:06 PM, Joan Lluch (casa) wrote:
So well, the problem was that some time ago I had set several of my
source files to "Objective C++" (by changing their extension to .mm)
in order to use the new/delete operators. By renaming back the files
to .m and using malloc/sizeof/free instead all the problems went
away. In fact, the calls the debugger refused to trace, were
precisely the ones where a language change occurred. This included
calls from my code to the frameworks, and I suppose that "step over"
was also failing because of this.
It sounds like the debugger isn't detecting that you are in an ObjC++
file, but it could be something else too. Enable the GDB log in Xcode-
>Preferences 'Debugging' with a path of '/tmp/XCGDLog'. Reproduce the
problem and attach the log to your bug report.
Now, after having learned a lot in the process, a remaining question
arises: The developer-tools documentation carelessly states that you
can use Objective-C and Objective-C++ as you want with no
restrictions, with no mention of the dramatic consequences that
doing so will have on your ability to debug your code. Unless I am
missing something, of course.
It is expected to work and the documentation is telling you this. My
Objective-C++ code steps fine so it's not like it is completely
busted, but my code it's not representative of all possible code that
could be written. Please file a bug report with clear steps to
reproduce the problem. If you attach a sample project that shows the
issue it can be much easier to track down the issue if you happen to
be experiencing an edge case instead of an easily reproducible bug.
So my question is: Is it possible to compile a project as Objective-C
++, and being able to tell somehow the compiler/debugger that it
should use the appropriate workarounds (or measures) so that the
debugger could actually be used? After all, activity monitor is able
to show a complete stack call trace even in that mixed-C-dialect
context. So why not the debugger?
Sample and Activity Monitor blindly follow the stack pointer to
generate a backtrace. This is not always the correct thing to do and
GDB attempts to do the right thing. Here is a GDB macro that will
follow the stack pointer so you don't have to fire up another program:
define x86-bt
set $frameno = 1
set $cur_ebp = $ebp
printf "frame 0 EBP: 0x%08x EIP: 0x%08x\n", $ebp, $eip
x/1i $eip
set $prev_ebp = *((int *) $cur_ebp)
set $prev_eip = *((int *) ($cur_ebp + 4))
while $prev_ebp != 0
printf "frame %d EBP: 0x%08x EIP: 0x%08x\n", $frameno, $prev_ebp,
$prev_eip
x/1i $prev_eip
set $cur_ebp = $prev_ebp
set $prev_ebp = *((int *) $cur_ebp)
set $prev_eip = *((int *) ($cur_ebp + 4))
set $frameno = $frameno + 1
end
end
Cheers,
Christopher Friesen
Apple
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/xcode-users/email@hidden
