Debugging c++ template classes
I'm working on a huge (1,000,000 lines of code + 12 3rd party libraries) project and I'm trying to use gdb to debug some template classes. More specifically, I've got a template within a template. I want to be able to get a breakpoint. Note that my GDB script has a number of dir commands so it can find all the sources and header files. In this case, there is a static class variable I want to set a watchpoint on. But, even when stepping thorough I generally cannot even view the lines of code (templates are generally inlined). In this particular case I am using the Intel C++ compiler on an Itanium processor. What is really strange is that the Intel version of the code fails to obtain some data, but executes and exits cleanly. The g++ code executes cleanly and segfaults on exit. There are other debugging techniques I am using, but the ability to step into or set a breakpoint in a template class function would save me some time. -- Jerry Feldman <gaf@blu.org> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
On Thursday 01 December 2005 09:46, Jerry Feldman wrote:
I'm working on a huge (1,000,000 lines of code + 12 3rd party libraries) project and I'm trying to use gdb to debug some template classes. More specifically, I've got a template within a template. I want to be able to get a breakpoint. Note that my GDB script has a number of dir commands so it can find all the sources and header files. In this case, there is a static class variable I want to set a watchpoint on. But, even when stepping thorough I generally cannot even view the lines of code (templates are generally inlined). In this particular case I am using the Intel C++ compiler on an Itanium processor.
What is really strange is that the Intel version of the code fails to obtain some data, but executes and exits cleanly. The g++ code executes cleanly and segfaults on exit.
There are other debugging techniques I am using, but the ability to step into or set a breakpoint in a template class function would save me some time.
I don't believe you will be able to do that. The problem is that templates are actually converted into "regular source code" and then compiled. The only thing I can think of which might shed some light on things is running `objdump -C ' on the object code. Depending on your situation, that may, or may not be useful. The difference in behavior between the two compilers is probably a result of the "unspecified behavior" related to program termination. My guess is, the g++ generated version is trying to execute some cleanup code that is accessing an invalid memory address. Examine your destructors carfully. Steven
I don't believe you will be able to do that. The problem is that templates are actually converted into "regular source code" and then compiled. The only thing I can think of which might shed some light on things is running `objdump -C ' on the object code. Depending on your situation, that may, or may not be useful. Just a stab in the dark. Templates are "inlined" which is the correct terminology. The problem is that like preprocessor macros you can't really get to them per se. What I am trying to track down is that there are about 1000 instances of
The difference in behavior between the two compilers is probably a result of the "unspecified behavior" related to program termination. My guess is, the g++ generated version is trying to execute some cleanup code that is accessing an invalid memory address. Examine your destructors carfully. At the moment, I don't really care about the g++ segfault. We only built with g++ because we were having other problems with the Intel compiler (that was not a problem with the compiler, but with 3rd party libraries). The problem I'm focusing on is much earlier. What we are doing is a 64-bit proof of concept type of situation. In this case, the Intel compiler should generate code that runs about 40% faster
On Thursday 01 December 2005 2:44 pm, Steven T. Hatton wrote: this function, and I'm trying to find out why a number of them are not showing up in an array in the Intel compiler version, but do show up in the G++ version. (I also didn't mention that there are also a lot of dynamic shared libraries in the mix which makes it even more challenging). than the g++ code. -- Jerry Feldman <gaf@blu.org> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
On Thursday 01 December 2005 15:32, Jerry Feldman wrote:
On Thursday 01 December 2005 2:44 pm, Steven T. Hatton wrote:
I don't believe you will be able to do that. The problem is that templates are actually converted into "regular source code" and then compiled. The only thing I can think of which might shed some light on things is running `objdump -C ' on the object code. Depending on your situation, that may, or may not be useful.
Just a stab in the dark. Templates are "inlined" which is the correct terminology.
Not all template code is inlined. The term used for the act of converting a template to a regular class or function by replacing template parameters with the types or values given as arguments is "instantiation". The definition resulting from template instantiation is called a "specialization". That use of the term "instantiation" is distinct from the instantiation of a class which means to convert the class definition into an object code representation. That will happen with both regular classes and class definitions in the form of template specializations. Template inlining is governed by the same rules that govern regular function inlining.
The problem is that like preprocessor macros you can't really get to them per se. What I am trying to track down is that there are about 1000 instances of this function, and I'm trying to find out why a number of them are not showing up in an array in the Intel compiler version, but do show up in the G++ version. (I also didn't mention that there are also a lot of dynamic shared libraries in the mix which makes it even more challenging).
How is the array allocated? I can't really comment on that situation without more information.
The difference in behavior between the two compilers is probably a result of the "unspecified behavior" related to program termination. My guess is, the g++ generated version is trying to execute some cleanup code that is accessing an invalid memory address. Examine your destructors carfully.
At the moment, I don't really care about the g++ segfault. We only built with g++ because we were having other problems with the Intel compiler (that was not a problem with the compiler, but with 3rd party libraries). The problem I'm focusing on is much earlier. What we are doing is a 64-bit proof of concept type of situation. In this case, the Intel compiler should generate code that runs about 40% faster than the g++ code.
The g++ segfaults probably indicate a flaw in the program. By determining the cause, you may be able to solve your other problem. Steven
On Thursday 01 December 2005 6:33 pm, Steven T. Hatton wrote:
How is the array allocated? I can't really comment on that situation without more information. I've tracked the problem deeper. It has nothing to do with that particular class. The system loads a large number of dynamic libraries.
At the moment, I don't really care about the g++ segfault. We only built with g++ because we were having other problems with the Intel compiler (that was not a problem with the compiler, but with 3rd party libraries). The problem I'm focusing on is much earlier. What we are doing is a 64-bit proof of concept type of situation. In this case, the Intel compiler should generate code that runs about 40% faster than the g++ code.
The g++ segfaults probably indicate a flaw in the program. By determining the cause, you may be able to solve your other problem. I'm sure there are many flaws in this program (and any large program). I'm actually not the person working with the G++ version. I currently know of a couple of 64-bit to 32-bit issues in the code that could possibly be related to that. It comes down to a matter of resources.
-- Jerry Feldman <gaf@blu.org> Boston Linux and Unix user group http://www.blu.org PGP key id:C5061EA9 PGP Key fingerprint:053C 73EC 3AC1 5C44 3E14 9245 FB00 3ED5 C506 1EA9
participants (2)
-
Jerry Feldman -
Steven T. Hatton