Re: Template Problems
Re: Template Problems
- Subject: Re: Template Problems
- From: Andreas Grosam <email@hidden>
- Date: Fri, 5 Aug 2005 01:57:23 +0200
On 04.08.2005, at 23:12, Jim Ingham wrote:
The problem here is that the gdb's "break" command assumes that there
is a 1-1 correspondence between the break expression and the code
address implementing it. This is obviously not true for templates.
It's on our list of things to fix, but we haven't fixed it yet.
This not only seems the only problem.
For instance, if you have a class template and a certain instantiation
of a member function, say
int Foo<int>::foo()
then, in gdb the command
(gdb) list Foo<int>::foo()
might return a total wrong location in the source files where the
function should start ( begin of function body).
where determining the address of the member function via
(gdb) info line Foo<int>::foo()
returns:
Line xxx of "path/to/source/where/it/has/been/instantiated.cp/" starts
at address 0x1234 and ends at 0x2345
Firstly, "Line xxx" points apparently to the correct line number in the
source file where the function is defined as a template, and more
precisely, at the line for the first statement - which is the
initialization of the first argument with default values - as opposed
to the begin of the function body.
The path, on the other hand, seams to be the source file where the
template has been instantiated. That is, line number and path are
pretty unrelated!!
Secondly, the addresses seem to be correct.
When searching the source lines for a specific address:
(gdb) list *0x1234
it returns
0x1234 is in Foo<int>::foo()
(path/to/source/where/it/has/been/instantiated.cp: xxx)
which is equally wrong - the line number and the file does not match.
Only if we have "luck", the compiler correctly matches the line of the
defintion of the template and the path to the file where the template
is defined. Only then, gdb is also able to print correctly the source
when using command:
(gdb) list Foo<int>::foo()
or
(gdb) list *0x1234
Well, the problem is, there is a bug elsewhere when the compiler
generates debug infos for templates.
Not surprisingly, that XCode hardly can manage such corrupt debug
informations.
Andreas
You can work around it for breaking on functions in the gdb
command-line by using the "rbreak" command:
(gdb) rbreak Printer.*print
That will break on all the versions of the print method of the Printer
template class.
You can also do set breakpoints on the individual instantiations, for
instance:
(gdb) break Printer<int>::print
will only break on the int version... You can do this second bit by
adding "Symbolic Breakpoints" in the Xcode Breakpoint window. The one
trick I noticed is that if you use ZeroLink, we bail out too early and
don't set the breakpoint... So you need to turn off ZeroLink to get
this to work.
Jim
On Aug 4, 2005, at 12:20 PM, Mike Jackson wrote:
OK,
I can reproduce the problem very simply. Create a new C++ Tool
project. Add a new file called FindLoops.h
Put the following in the file.
#include <iostream>
template <class T> class Printer {
public:
static void print(const T&t) {
std::cout << t << std::endl;
}
};
In main.cpp put the following:
#include <iostream>
#include "FindLoops.h"
int main (int argc, char * const argv[]) {
std::cout << "Hello, World!\n";
Printer<int>::print(10);
Printer<double>::print(10.5);
std::cout << "DONE" << std::endl;
return 0;
}
Check the compile settings to have FULL debug symbols. Set a
breakpoint in the "FindLoops.h" file at the line that does the cout.
Run the debugger. Xcode flys right past the break point.
Now, if I put the template in the main.cpp file, then the debugger
will hit the breakpoint.
I am new to C++ and all this, so can some one explain what might be
happening (**cough _apple_ cough **) ;-)
Mike Jackson
On Aug 4, 2005, at 2:25 PM, Mike Jackson wrote:
I went back through all my projects and set the debug symbols to
"ALL". Still no luck stopping at a breakpoint.
Mike
On Aug 4, 2005, at 1:54 PM, Mike Jackson wrote:
I tried the following in a "test" project: In main.cpp
#include <iostream>
template <class T> class Printer {
public:
static void print(const T&t) {
std::cout << t << std::endl;
}
};
int main (int argc, char * const argv[]) {
// insert code here...
std::cout << "Hello, World!\n";
Printer<int>::print(10);
Printer<double>::print(10.5);
return 0;
}
The debugger will stop in the template just fine. In my case, the
template code is in _another_ project that is referenced by the
current project, and the template code is in a .h file. Don't know
if this makes a difference or not. I am still too new to C++/Xcode
to know. I did double check that Optimization is OFF in all the
projects, although I will double check that.
Mike Jackson
On Aug 4, 2005, at 10:28 AM, Andreas Grosam wrote:
On 04.08.2005, at 15:38, Wade Girard wrote:
First this to do is to verify that you are generating debug
symbols, the second is to verify that optimizing is OFF. Note
that setting it to none -o0 is not off.
according the doc, -O0 optimization is indeed off and is the
default. But -O isn't off, did you mean this?
My experience is, that there are (still) a lot of troubles with
the debugger especially with templates - not only regarding
synchronizing with the source.
What may confuse source synchronizing (even with -O0):
Long comments at arbitrary positions in the file
Macros, multi line
templates
static inline functions
breakpoints in member initializer lists
Although it is better than it was in XCode 1.5, this *may* happen
frquently - not always and it is not always reproducible. I have
no workaround for this problem.
If it happens, i try several other things to solve my original
problem - typically loosing a lot of time and getting
disappointed and annoyed.
When having templates, I also recommend to close the assembly
window, since there might occure more troubles: if this happens,
the debugger just refuses to work at all. Furthermore, it is a bit
faster, so one step only takes 2 seconds instead of 3.
Andreas
The only way that I know of to do this is to use a xcconfig file
and have/add the following two lines
GCC_DEBUGGING_SYMBOLS = full
GCC_OPTIMIZATION_LEVEL =
On Aug 4, 2005, at 7:47 AM, Mike Jackson wrote:
I'll try again.
The debugger is ignoring breakpoints set inside a template
function. How do I get the debugger to actually stop at those
breakpoints?
Stats: Xcode 2.1. OS X 10.4.2. PB 1.67/1.5GB RAM
Thanks for any Help
---
Mike Jackson
mike _at_ bluequartz dot net
This email sent to email@hidden
This email sent to email@hidden
---
Mike Jackson
mike _at_ bluequartz dot net
_______________________________________________
---
Mike Jackson
mike _at_ bluequartz dot net
---
Mike Jackson
mike _at_ bluequartz dot net
_______________________________________________
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
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
email@hidden
This email sent to email@hidden
_______________________________________________
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