Re: How to work around this bug?
Re: How to work around this bug?
- Subject: Re: How to work around this bug?
- From: Alastair Houghton <email@hidden>
- Date: Thu, 26 May 2005 13:38:27 +0100
On 24 May 2005, at 00:28, Theodore H. Smith wrote:
On 23 May 2005, at 23:40, j o a r wrote:
On 23 maj 2005, at 21.45, Theodore H. Smith wrote:
Unable to set breakpoint MacMFCShims.h:853. Make sure to build
the file MacMFCShims.h with debugging symbols.
Note: breakpoint 17 also set at pc 0x230dc.
Note: breakpoints 17 and 18 also set at pc 0x230dc.
Why are you trying to set a breakpoint in a header file?
Because it's a C++ class.
class MyClass {
void MyFunction() {
Code();
}
};
In which case the MyFunction() routine will be inlined, which makes
debugging difficult at best. If you want to debug your code, change
the header file to say
class MyClass {
...
void MyFunction();
...
};
then create a separate .cc file for the implementation.
If you're using templates, then you're out of luck, because this
trick won't work. In that case, you'll have to set breakpoints on
addresses in the code, rather than line numbers. Either that, or
write specialised implementations and use them to actually implement
your template.
The reason for the confusion is that the line numbers in the debug
information are duplicated---that is, the code has been generated
more than once for the same line number---so GDB has no idea which
piece of code you mean when you say e.g. break MacMFCShims.h:853.
This isn't a bug, it's just a limitation caused by inlining of C++
member functions defined in class definitions (see 9.3.2 in the C++
Standard). I suppose you could file an enhancement request for GDB,
asking for it to query for the right place when it finds more than
one address associated with a line number, although it'll be tricky
to disambiguate because it's possible that GDB would have to go
several steps back up the call stack to find an unambiguous location
(and don't forget, we're talking about a theoretical call stack which
could even include virtual functions or calls through pointers to
functions/member functions). Basically, it's a difficult problem.
Kind regards,
Alastair.
--
http://www.alastairs-place.net
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden