5 ms·

std::vector does not have any virtual functions, so how comes it needs the vtable for this? http://www.yolinux.com/TUTORIALS/src/dbinit_stl_views-1.03.txt http

std::vector does not have any virtual functions, so how comes it needs the vtable for this? http://www.yolinux.com/TUTORIALS/src/dbinit_stl_views-1.03.txt 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?

DannyBee 13y ago
I was explaining the general problem. 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 https://sourceware.org/gdb/wiki/STLSupport If you use this, print on a vector just works, no extra commands or anything needed.
- makomk 13y ago
  The pretty printers let you print the entire vector, but do they let you access individual elements within the (potentially very large) vector? That's what this blog post is complaining about not being able to do.
  - EliRivers 13y ago
    Works absolutely fine on my very standard, almost vanilla installation. Code: #include <vector> using namespace std; int main() { vector<int> beans; beans.resize(5); beans[3] = 4; beans [4] = 66; } Build command: g++ -g 156.cpp gdb debugging session: 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: 0
  - DannyBee 13y ago
    So, I thought the post above me asked a different question, related to printing out vectors in general :) Possibly they didn't mean to, but asking gdb to "p v[0]" is a function call execution of operator[]. As mentioned in the grandparent, this should work fine on a live process, but is harder on a not live one. It'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.

DannyBee 13y ago

I was explaining the general problem. 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 https://sourceware.org/gdb/wiki/STLSupport If you use this, print on a vector just works, no extra commands or anything needed.

makomk 13y ago
The pretty printers let you print the entire vector, but do they let you access individual elements within the (potentially very large) vector? That's what this blog post is complaining about not being able to do.
- EliRivers 13y ago
  Works absolutely fine on my very standard, almost vanilla installation. Code: #include <vector> using namespace std; int main() { vector<int> beans; beans.resize(5); beans[3] = 4; beans [4] = 66; } Build command: g++ -g 156.cpp gdb debugging session: 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: 0
- DannyBee 13y ago
  So, I thought the post above me asked a different question, related to printing out vectors in general :) Possibly they didn't mean to, but asking gdb to "p v[0]" is a function call execution of operator[]. As mentioned in the grandparent, this should work fine on a live process, but is harder on a not live one. It'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.