C++ template debugging

[mpatrick]

I'm using TotalView 8.3.0-0 to debug c++ template. As I read in totalView user's guide, it is possible to break inside the template code. However when I compile and link the following code (using gcc 4.1.2: g++ -o power -g3 -O0 power.cpp), I cannot put the break point inside the template at all. If I break inside the main function and step-in, it simply goes to the end without stepping into the template. Could someone give me some suggestion? Can totalview debug C++ template?

Regards,

Marco

---------------------------------

template<long long X, long long Y>
struct ctime_pow {
static const long long result =
X * ctime_pow<X, Y-1>::result;
};

template<long long X>
struct ctime_pow<X,0> {
static const long long result = 1;
};

int main() {
cout << "The result of 7^3 is: " << ctime_pow<7, 3>::result << endl << endl;
}

[PeterT-RogueWave]

Marco,

I actually tried this back when you originally posted it and had meant to reply, but things got in the way.

TotalView is certainly capable of debugging templates. However, this requires that we receive adequate debug information from the compiler when the program is built. This is bound to vary from compiler to compiler as well. Using g++ I could not get the compiler to generate any line number info for the templates, no matter what options I tried. However, using the same compiler I was able to get info generated and therefore break inside my templates for the following:

// program to check templated function
#include <stdarg.h>
#include <vector>

class A {};

class B {};

class C {};

template <class T>
class D {
int dummy_member;
public:
D(int i=0) {dummy_member=i;}
template <class U>
void f(U*, int,
const std::vector<C> &,
const std::vector<C> &,
const std::vector<int> &,
const std::vector<int> &) const {
/* STOP: */
int dummy_=1;
dummy_++;
return;
}
};

int main(int argc, char *argv[]) {
const D<A> da;
B b;
B * pb = &b;
int i = 1;
const std::vector<C> vC;
const std::vector<int> vi;

da.f(pb,i,vC,vC,vi,vi);
i++;
}


Not that this does anything useful, but then it's just a test program designed to illustrate functionality. I'm not sure why the compiler gave no information for the test case you had, but it may just be a degree of complexity in the template section. Perhaps this works better in your real code, rather than this test program.

Regards

[odoucet]

Hi Peter,

I'm experiencing the same problem as Marco with TotalView 8.6.2-2 and gcc 4.1.2 on a Linux RedHat5 / x86-64 platform.

> [size 2]this [/size][size 2]requires that we receive adequate debug information from the compiler when the program is built[/size]

Could you tell us what exact debug info is adequate for TV in order for us to tune the compiler accordingly.

I manage to debug the same template code with gdb so I suppose the debug info is there but not in the proper format...

If template debugging is currently not possible with gcc 4.1.2, please let us know: we'll save time.

Regards,
Olivier

[PeterT-RogueWave]

Hello Olivier,

> I manage to debug the same template code with gdb so I suppose the debug info is there but not in the proper format..

My standard rule of thumb is that if gdb can debug it, we should be able to. If TotalView cannot handle the same code adequately, then I would think that is a bug in TotalVIew. I just tried the above code from Marco again, and neither gdb or TotalView appear to be able to hit a breakpoit in the template code. If your case can be debugged with gdb, b ut not TotalView, it would be good to report that to

support@totalviewtech.com

with a reproducer, and I'll see what we can do.

Regards,

[shunter]

Hello,

I've also been tracking down a similar issue with inline/template heavy code. In a small test case, I was able to track it down to using -g versus -g3 with gcc. Unfortunately, I've been told that TotalView doesn't support -g3 and I haven't been able to create a test case I can give out that exhibits the behavior with -g even though the same behavior occurs in the code base I work with which only uses -g.

I was able to set breakpoints within the inline code, and it would properly stop at those breakpoints, but the GUI wouldn't have the correct file open. In cases where the wrong file being shown was too short, the yellow 'you are here' arrow would appear at the very bottom of the file. In other cases, it would appear on the correct line (Though still in the wrong file) but would not scroll to that location.

What is most interesting is that if you then go to Tools -> Command Line and type 'dlist' in the CLI, it shows the correct file and line. It seems to be specific to the GUI. GDB also knows what file it is actually in.

-- Sean

[PeterT-RogueWave]

Hi,

Is this Val? I saw the response to your question about -g3, and I'd like to add a bit of clarification. In general we don't test with -g3 and have found the most 'digestible' debug information to be generated with -g. However, if the behavior of the debugger is demonstrably incorrect, I still think of it as a bug that needs to be fixed. I'll see what I can do about that.

If, in your larger code, you are only using -g and are still seeing this behavior that you ascribe to -g3 in the smaller example, that is almost certainly a bug. At this point, it's hard to say if it is the same problem you are seeing with the small case, as we don't have enough information on it. It is certainly possible, even with -g, to pick up the wrong file. This usually happens with files that have the same name, and which lie in your search path before the current directory. In the test case that I saw, assuming again that it was you that submitted it, I had a problem at first finding the right source, as the executable was called 'main' and I already had a main in my search path. You can see if this might be a problem by specifying

totalview ./program

so that you are assured of picking up the right executable.

As for the problem I gather you are seeing with the incorrect source file, the above may explain it (the Search Paths) , or it mayb we are not handling the debug information correctly. If you are unable to take a look at the program you are seeing this with, maybe you could run the executable through readelf

readelf -w ./foo >& foo.w

and then send that along to us. If you cxan point out a few places where the code seems to be mis-behaving, that would help narrow things down. If you really want to motivate us, just mention that gdb has no problem with this.

Regards,

[shunter]

Hi,

No, but I do work with Val. Posted to this thread because I noticed the author had a similar case where they were using -g3.


In the larger code base, the behavior does act the same as the small test case, and I did a check of looking for .debug_macinfo (something -g3 seems to add) in all our .so's and .o's that could possibly be linked against during a debug session but didn't see it anywhere. I also made sure to check using 'dlist -e' from the TotalView command line inside the GUI (from the tools menu) as described above and it did show the correct file and line.

I did make sure I was debugging the correct executable. I'm also pretty sure the source paths is the problem. I was able to cause the problem or fix the problem by removing the MyOtherClass.h include from the executable's source (main). Unfortunately, this is only a reasonable fix in the small test case. Interestingly, I also did this: Compiled the .so, removed all code from MyOtherClass.h, and then compiled only main (This requires doing the commands by hand as the makefile in that test case will try to rebuild the .so too and fail) with that empty include file. This still caused the same problem. I also took a look at the debug sections differences between -g and -g3 using readelf. There are a fair number of differences in general, and a new section, but I think what might be the problem is that the file table in debug_info was in a different order with -g3 than with -g.

I can't give out a useful readelf or other information from the larger code base that shows the problem. It's a combination of many very large .so's and an executable. The debug-dump (-w) readelf of the .so in question is 1.1gb by itself.


And yes, gdb handles our code (and -g3) fine. But so does the TotalView CLI. Just not the TotalView GUI.

-- Sean