This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Examining STL maps?


I've seen this question posted a few times on USENET, but never any answers.  Is there any way, short of creating my own debugging routines, to examine an STL container from gdb?  I like to keep a good deal of my program data in maps, vectors, and whatnot, but that means that when I'm debugging, I need to be able to peek inside and see the number of elements, or examine individual elements. 

I am able to examine elements of vectors, but I can't figure out how to deal with maps; gdb doesn't seem to like the .operator[] definition.  And I can't call member functions of either vectors or maps; gdb complains about the function being inlined, despite my having disabled inlines in gcc several different ways.

Details:

Here's a simple test program.

#include <iostream>
#include <string>
#include <map>

using namespace std;

int main()
{
 map<string, string> stringmap;
 map<int, string> intmap;
 
 stringmap["key"]="value";
 intmap[1234]="value2";
 cout << stringmap["key"] << endl << intmap[1234] << endl;
}

When I try to debug it:

(gdb) p stringmap["key"]
One of the arguments you tried to pass to operator[] could not be converted to what the function wants.
(gdb) p stringmap.size()
Cannot evaluate function -- may be inlined
(gdb) p intmap[1234]
Attempt to take address of value not located in memory.

I am compiling using gcc 2.95.3, with all optimizations off, full debugging info:

g++ -c -O0 -ggdb3 -fno-inline -fkeep-inline-functions -Wall test.cpp 

I have tried with and without the two inline flags.  The docs are unclear on exactly how they interact, but they don't seem to affect this example anyway.  I am debugging with the 5/3 snapshot of gdb on Solaris 7.

Ideas for workarounds?  Or is gdb just not that advanced yet with templates, even with the post-5.0 patches?  Is there a long-term solution?

Jay Levitt


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]