Re: Strange Instruction Pointers
Re: Strange Instruction Pointers
- Subject: Re: Strange Instruction Pointers
- From: Jim Ingham <email@hidden>
- Date: Wed, 9 Jun 2004 19:04:14 -0700
What's going on is that the way gcc emits constructors for C++ objects
is slightly complicated. Sometimes, there are different constructors
depending on whether the object is "in-charge of constructing its
members" or "not in charge of constructing its members". This is
required if a class can be a virtual base class of a diamond diagram,
since then only one of the two "paths" should construct the members,
but the C++ Standard requires that both paths get called. However,
these constructors don't get called directly, there is a generic
constructor which just decides which of these to call.
So stepping into a new () involves stepping through this generic
constructor first, and the generic constructor has whacky line number
information because of the way the debug info gets laid out. Note that
gcc doesn't always make the whole variety of constructors, so that's
probably why you sometimes see one thing, and sometimes another...
What really needs to happen is that gdb needs to be changed to
recognize the "generic" constructor as a trampoline - much like
objc_msgSend is for ObjC. We have a bug about this, but I haven't
gotten to it yet. It turns out to be a bit tricky to implement.
In the meantime, if you just keep on stepping you should end up in the
real constructor.
Jim
On Jun 9, 2004, at 2:57 PM, Ricky Sharp wrote:
I have a native carbon app project in Xcode 1.2 running on 10.3.4.
Recently, when stepping into the constructors of my objects, the
debugger displays this for thread-1 just after I step into a line such
as CObject* anObject = new CObject()
# Thread-1
0 operator new(unsigned long)
1 main
The highlight is on the operator new line and the debugger brings up a
completely unreleated file and places the current instruction pointer
on that line.
For example, it just stopped on the following line:
CFStringRef IIShellStrings_PreferencesFileName = CFSTR ("Preferences
File Name");
In other situations, stepping into constructors will stop on inline
functions of some unrelated object.
If I step out, then back in, my stack trace them becomes:
# Thread-1
0 CObject::CObject
1 main
I tried duplicating this issue with the stock Carbon app template. I
then modified it to declare this class:
class CObject
{
private:
int mX;
public:
CObject (int x) { mX = x; }
};
and in main, I did:
CObject* anObject = new CObject (0);
Stepping in on that line in main jumps to the correct constructor line.
Back to the problematic app...it's a debug build and all optimizations
are turned off. I also have ZeroLink disabled. Is this a bug in the
debugger? Or is this a sign of some sort of memory corruption in my
app? The app has been running beautifully though; no crashes or
signals raised.
___________________________________________________________
Ricky A. Sharp mailto:email@hidden
Instant Interactive(tm) http://www.instantinteractive.com
_______________________________________________
xcode-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/xcode-users
Do not post admin requests to the list. They will be ignored.
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Jim Ingham
email@hidden
Developer Tools - gdb
_______________________________________________
xcode-users mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/xcode-users
Do not post admin requests to the list. They will be ignored.