I have a std::map< std::string, std::string> cont;
I want to see cont[ "some_key" ] in gdb. When I'm trying
p cont[ "some_ket" ]
I'm getting this message: One of the arguments you tried to pass to operator[] could not be converted to what the function wants.
I'm using GNU gdb Red Hat Linux (6.3.0.0-1.162.el4rh). Thanks
The latest gdb has python support baked in so one could easily write a function to print out the contents of any stl structure. However you'd have to learn the API and write the script. Luckily gcc 4.5 will ship with the needed python scripts to get gdb to intelligently handle stl data structures.
EDIT: you don't have to wait for GCC 4.5 (which by the way has already been released), you can just grab the code from SVN.
You can write your own dump functions and call them:
(gdb) call dump(m)
see this thread:
http://www.mail-archive.com/help-gplusplus#gnu.org/msg02109.html
I'm curious about the GDB helper macros.
Gdb doesn't understand C++ operator overloading.
Related
Consider a c++ program that produces some segmentation fault and aborted.
In regular debugging using gdb, I can do the following and see results
(gdb) r
(gdb) p str_var.size()
where str_var is defined as std::string in the file.
However, I encountered some problem when debugging with a core dump. After I load the core dump in gdb by
gdb EXECUTABLE core.pid
and run the following command in gdb terminal
(gdb) p str_var.size()
gdb says "You can't do that without a process to debug."
I am only able to do things like bt (view stack trace) or directly print std::string variable, but just couldn't find an easy way to check some information like printing the size of a std::string. Is it always the case that debugging capabilities are limited when debugging a core dump? Particularly for the problem here, is there a way to know the size of a std::string in core dump debugging?
No, to be able to call a function, you need a context that is not present when reading core files. The only way to get you info is to explore the class(es) in order to find where it is stored, but can be painful as the stl can have some quite hard to follow implementations.
Moreover, depending on you program and compilation options, some values may be inlined (not stored anyway) or stored in registers, which can make the task quite painful.
Nevertheless, as said n.m, there are some pretty printers that ease the task if you use some standard stl (For example do not work on stlport AFAIK)
If you compile with gcc, std::string struct:
You should read _Rep before _M_dataplus._M_p.
p ((std::string::_Rep*)image_data)[-1]
And then print this.
{<std::basic_string<char, std::char_traits<char>, std::allocator<char> >::_Rep_base> = {_M_length = 30752, _M_capacity = 32711, _M_refcount = -1}, static _S_max_size = 4611686018427387897, static _S_terminal = 0 '\000', static _S_empty_rep_storage = <optimized out>}
std::unique_ptr are nice, but I find them less comfortable when debugging in DDD or gdb.
I'm using the gdb pretty printers that are part of gcc (e.g., /usr/share/gcc-4.8.2/python/libstdcxx/v6/printers.py). That is a big win for readability, for example:
$ print pTest
std::unique_ptr<MyType> containing 0x2cef0a0
However, dereferencing the pointer does not work:
$ print *pTest
Could not find operator*.
When I need to access the value, I have to manually copy the pointer and cast it to the correct type, for example:
print *((MyType*) 0x2cef0a0)
If the process is still running, this version works (still ugly but better):
print *pTest.get() // will not work if analyzing a core dump
The straightforward approach to Display *pTest in DDD does not work either. It only results in the following error:
<error: Could not find operator*.>
Is there a way to debug C++11 code with unique_ptr in DDD (without breaking the workflow like I do with my cumbersome workarounds)?
I'm not afraid to use gdb commands, but DDD integration would be a plus. For example, following pointers in data structures by just double-clicking on them is often faster than typing.
I already tried to drop the pretty printer, but it is also not optimal. The best that I could come up with is the following:
print pTest._M_t->_M_head_impl
This problem is actually not related to C++11, unique_ptr or pretty printing. The problem is that gcc does not emit code for std::unique_ptr::operator* that could be called by gdb to dereference the unique_ptr. If you for instance add *pTest; to your code then gdb does perform the dereferencing.
A similar problem is described in the SO post How to `print`/evaluate c++ template functions in gdb. Almost the same problem is described for an auto_ptr at https://sourceware.org/ml/archer/2012-q1/msg00003.html. If I understand the thread correctly one workaround would be to patch the pretty printer and also print out the dereferenced pointer when printing the unique_ptr. A gdb bug report can be found at http://sourceware.org/bugzilla/show_bug.cgi?id=12937.
The gdb wiki at https://sourceware.org/gdb/wiki/STLSupport describes more pretty printing solutions, which could have other workarounds.
Edit: A more elegant solution forcing the compiler to emit code for all member templates including operator* is to explicitly instantiate the class:
template class std::unique_ptr<MyType>;
GDB has a feature called xmethods which allows you to reimplement C++ methods in Python. This makes get() and the operator* available in GDB even if the compiler did not explicitly emit code for them.
Make sure that you are loading not only the pretty printers but also the xmethods in your .gdbinit:
python
import sys
sys.path.insert(0, '/usr/share/gcc-8.2.1/python/')
# This would only enable the printers but not the xmethods:
# from libstdcxx.v6.printers import register_libstdcxx_printers
from libstdcxx.v6 import register_libstdcxx_printers
register_libstdcxx_printers (None)
end
How do I explore the content of a variable of complex type, say, a multimap where key and value are also of some complex type, like some classes.
Debug can only show the value of the pointer, but not the content of the instance of multimap. I know in gdb, if you have a variable var, and it has a method, say, getAddress(), then you can do something like: p var->getAddress() to see the value retured by that function, Can I do something similar in Eclipse Debug?
Hope this helps:
Here is a way to use standard gdb commands from within Eclipse (a console where you can type them in):
Use gdb console in Eclipse
Here are the scripts Joachim mentioned (multimap is supported): http://sourceware.org/gdb/wiki/STLSupport
I want to dump a backtrace from a C++ program in Linux in a similar format as it is done in gdb. I tried to use the backtrace() and backtrace_symbols() functions for this purpose. These returned function names and offsets. I can use the __cxa_demangle() function to get a readable function name.
Is there any way to get the file/line positions too, as it is done by gdb?
How it's better to invoke gdb from program to print its stacktrace?`
Methode #4, shows a way to get filename and line. But uses a extern program..
I have some C++ code like this that I'm stepping through with GDB:
void foo(int num) { ... }
void main() {
Baz baz;
foo (baz.get());
}
When I'm in main(), I want to step into foo(), but I want to step over baz.get().
The GDB docs say that "the step command only enters a function if there is line number information for the function", so I'd be happy if I could remove the line number information for baz.get() from my executable. But ideally, I'd be able to tell GDB "never step into any function in the Baz class".
Does anyone know how to do this?
Starting with GDB 7.4, skip can be used.
Run info skip, or check out the manual for details: https://sourceware.org/gdb/onlinedocs/gdb/Skipping-Over-Functions-and-Files.html
Instead of choosing to "step", you can use the "until" command to usually behave in the way that you desire:
(gdb) until foo
I don't know of any way to permanently configure gdb to skip certain symbols (aside from eliding their debugging information).
Edit: actually, the GDB documentation states that you can't use until to jump to locations that aren't in the same frame. I don't think this is true, but in the event that it is, you can use advance for the same purpose:
(gdb) advance foo
Page 85 of the GDB manual defines what can be used as "location" arguments for commands that take them. Just putting "foo" will make it look for a function named foo, so as long as it can find it, you should be fine. Alternatively you're stuck typing things like the filename:linenum for foo, in which case you might just be better off setting a breakpoint on foo and using continue to advance to it.
(I think this might be better suited as a comment rather than an answer, but I don't have enough reputation to add a comment yet.)
So I've also been wanting to ignore STL, Boost, et al (collectively '3rd Party') files when debugging for a while. Yesterday I finally decided to look for a solution and it seems the nearest capability is the 'skip' command in GDB.
I found the 'skip' ability in GDB to be helpful, but it's still a nuisance for me because my program uses a lot of STL and other "3rd Party" template code. In this case I have to mark a bunch of files as skip. After the 2nd time doing so I realized it would be more helpful to be able to skip an entire directory--and most helpful to skip a directory and all subdirectories. That way I can skip, for example, /usr since none of my code lives there and I typically have no interest in debugging through 3rd party code. So I extended the 'skip' command in gdb to support a new type 'dir'. I can now do this in gdb:
skip dir /usr
and then I'm never stopped in any of my 3rd party headers.
Here's a webpage w/ this info + the patch if it helps anyone: info & patch to skip directories in GDB
It appears that this isn't possible in GDB. I've filed a bug.
Meanwhile, gdb has the skip function command. Just execute it when you are inside the uninteresting function and it will not bother you again.
skip file is also very useful to get rid of the STL internals.
As Justin has said, it has been added in gdb 7.4. For more details, take a look at the documentation.