http://www.yolinux.com/TUTORIALS/src/dbinit_stl_views-1.03.t...
Here they have some functions that inspect vector by means of _M_impl and friends, why can't gdb do this?
As for std::vector, GDB can and does do this now, through python based pretty printers.
That gdb script is completely unnecessary for this now. Most distros ship with gdb + appropriate pretty printers pre-installed, but they are also available in the libstdc++ repo.
See https://sourceware.org/gdb/wiki/STLSupport
If you use this, print on a vector just works, no extra commands or anything needed.
Code:
#include <vector>
using namespace std;
int main()
{
vector<int> beans;
beans.resize(5);
beans[3] = 4;
beans [4] = 66;
}
g++ -g 156.cpp
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
SKIPPED OUT WARRANT INFO HERE
Reading symbols from /badcode/a.out...done.
(gdb) break 156.cpp:10
Breakpoint 1 at 0x4008e6: file 156.cpp, line 10.
(gdb) run
Starting program: /badcode/a.out
Breakpoint 1, main () at 156.cpp:10
10 beans [4] = 66;
(gdb) print beans[3]
$2 = (int &) @0x60401c: 4
(gdb) print beans[4]
$3 = (int &) @0x604020: 0It's possible the parent meant "why can't GDB make v[0] do an inspection directly on the structure". The simple answer is: "It can't possibly know what the function call does". So you'd have to teach it, specifically, that std::vector is special, or provide a mechanism to override the native calls with python scripting (IE be able to say "here is a replacement for T &operator[int] on std::vector that is in python, and works without a live process").
GDB actually does real overload resolution (it has to, otherwise in some 'simple' cases, it'd have to ask you 100 questions about what functions you are trying to call), making that strategy more complicated.
If your only mechanism for reproduction is a core dump, yes this is a pain in the ass. But this shouldn't be true, even remotely, since you always have things like gdbserver/etc.
Years ago, I used to be the C++ maintainer for GDB. By the time I left, things like doing this on a live process worked about 90% of the time (up from 0%). It turns out what he's trying to do is harder than one would think, but it should actually work.
Part of the reason it doesn't really work all that often on coredumps is because you often need access to vtables, thunk functions (which you could theoretically execute without a live process in most ABI's, but it doesn't know this). Depending on the class, there may also be runonce constructors (for static data and associated guard variables), etc.