configuring CL for GDB on gcc 4.8

[petah]

Hi Eran,

I installed gcc/g++ 4.8 on Debian stable (gcc borrowed from unstable) and created a new entry in build_settings.xml, first duplicating the g++ entry, then replacing gcc and g++ fields with full paths to their 4.8 equivalents. It builds and runs fine but gdb retrieves the wrong symbols.

Code: Select all

DEBUG>>*running,thread-id="all"
*running,thread-id="all"
DEBUG>>=library-loaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",symbols-loaded="0",thread-group="i1"
=library-loaded,id="/lib64/ld-linux-x86-64.so.2",target-name="/lib64/ld-linux-x86-64.so.2",host-name="/lib64/ld-linux-x86-64.so.2",symbols-loaded="0",thread-group="i1"
DEBUG>>=library-loaded,id="linux-vdso.so.1",target-name="linux-vdso.so.1",host-name="linux-vdso.so.1",symbols-loaded="0",thread-group="i1"
=library-loaded,id="linux-vdso.so.1",target-name="linux-vdso.so.1",host-name="linux-vdso.so.1",symbols-loaded="0",thread-group="i1"
DEBUG>>&"warning: Could not load shared library symbols for linux-vdso.so.1.\nDo you need \"set solib-search-path\" or \"set sysroot\"?"
DEBUG>>&"\n"

and fails to create a "this" watch:

Code: Select all

DEBUG>>00000028^done,BreakpointTable={nr_rows="1",nr_cols="6",hdr=[{width="7",alignment="-1",col_name="number",colhdr="Num"},{width="14",alignment="-1",col_name="type",colhdr="Type"},{width="4",alignment="-1",col_name="disp",colhdr="Disp"},{width="3",alignment="-1",col_name="enabled",colhdr="Enb"},{width="18",alignment="-1",col_name="addr",colhdr="Address"},{width="40",alignment="2",col_name="what",colhdr="What"}],body=[bkpt={number="1",type="breakpoint",disp="keep",enabled="y",addr="0x00000000004217ce",file="/home/plaufenb/development/inhance_depot/DDT3/Client/src/LuaDDTmain.cpp",fullname="/home/plaufenb/development/inhance_depot/DDT3/Client/src/LuaDDTmain.cpp",line="148",times="1",original-location="/home/plaufenb/development/inhance_depot/DDT3/Client/src/LuaDDTmain.cpp:148"}]}
DEBUG>>00000030-data-disassemble -s "$pc -100" -e "$pc + 100" -- 0
DEBUG>>00000031-data-disassemble -s "$pc" -e "$pc + 1" -- 0
DEBUG>>00000029^error,msg="-var-create: unable to create variable object"
-var-create: unable to create variable object

One online posts mention a new dward format but there's no clear answer, is there a CL field I missed? Is this a lost cause?

thx a lot!

-- p

[petah]

Btw manually adding -gstabs/-ggdb/-gstabs+, etc. to the build line changes some stuff but debugged vars are still off. I noticed that Debian testing has a new GDB version 7.6.1 with gcc 4.8 but I already screwed up one system playing incremental tip-toe updgrades

cheers

[DavidGH]

Hi,

I'm using a self-built gdb 7.6.1 on wheezy without problems (though not with gcc 4.8). My build howto:

(The build requires ncurses-devel, otherwise you'll get 'missing termcap' configure errors)

mkdir builddir
cd builddir
../configure --prefix=$(pwd)
make -j4 && make install
i.e. you don't do things inside the gbd/ dir. It would work OK without the --prefix= and without make installing, but then gdb complains it can't find its datadir (for loading python modules for pretty-printing etc) under /usr/local/share/
The binary is builddir/gdb/gdb

Then put /path/to/gdb-7.6.1/builddir/gdb/gdb in the top field of CL's Debugger Settings.

Regards,

David

[petah]

yeah mine works fine with gcc 4.7.2 so it'd only be to get gcc 4.8's new C++11 regex iterators and hopefully less noisy build error reports. If you don't my me asking, is there a particular reason you decided to upgrade GDB, i.e. performance, features or bug fixes?

thx for your help,

-- p

[DavidGH]

is there a particular reason you decided to upgrade GDB, i.e. performance, features or bug fixes?

Mostly to make sure it works OK with CL .

[petah]

I updated gdb and gdbserver to 7.6.1 and can now debug gcc 4.8-built code but had this error (or warning?) in the gdb log:

Code: Select all

DEBUG>>&"Traceback (most recent call last):\n"
DEBUG>>&"  File \"<string>\", line 4, in <module>\n"
DEBUG>>&"  File \"/home/plaufenb/.codelite/gdb_printers/libstdcxx/v6/printers.py\", line 911, in register_libstdcxx_printers\n"
DEBUG>>&"    gdb.printing.register_pretty_printer(obj, libstdcxx_printer)\n"
DEBUG>>&"  File \"/usr/share/gdb/python/gdb/printing.py\", line 146, in register_pretty_printer\n"
DEBUG>>&"    printer.name)\n"
DEBUG>>&"RuntimeError: pretty-printer already registered: libstdc++-v6\n"
DEBUG>>&"Error while executing Python code.\n"
DEBUG>>^error,msg="Error while executing Python code."
^error,msg="Error while executing Python code."

so I commented-out the two lines in CL's GDB startup commands that registered libstdcxx printers.

I have never been able to pretty-print STL containers though (even before fiddling with gcc versions) and gdb's log now shows headers for both gcc 4.7 and 4.8. I don't think gdb gets that information from my binary because I confirmed it doesn't use any 4.7 headers -- how can I ensure the correct headers are passed to gdb?

thx again,

-- p

[eranif]

and gdb's log now shows headers for both gcc 4.7 and 4.8.

The only thing that comes to mind is the debugger paths in the project settings -> Debugger
Other than that, codelite has no control of the search paths

Eran

[petah]

The only thing that comes to mind is the debugger paths in the project settings -> Debugger

Woohoo that works! I added

Code: Select all

/usr/include/c++/4.8

to the project settings' debugger paths and gdb's log showed only the right headers. The log also adds:

Code: Select all

DEBUG>>00000005-environment-directory /usr/include/c++/4.8
(...)
DEBUG>>00000005^done,source-path="/usr/include/c++/4.8:$cdir:$cwd"

I then had to re-enable the python lines that registered the libstdcxx printers in CL, which even though dump an error in gdb's log are apparently necessary to see pretty-printed STL containers.

I realized that inspecting member variables through "this" doesn't trigger pretty-printing on STL containers (at least not the correct one) which is why I didn't see them until now. Containers display fine as local C++ variables and in CL's watch view when the watch is the full " this->my_stl_container_member" name; but a "this" watch alone doesn't work, nor does an expanded "this" in locals.

The class I tested this on had no extra namespaces, and this occurs with both:

Code: Select all

typedef std::unordered_map<what, ever> my_map;

and

Code: Select all

using my_map = std::unordered_map<what, ever>;

Does anybody else see that limitation or is it my setup? my CL version is ~2 months old.

thx!

-- p

[petah]

FYI I found this post from Vadim Z http://wxwidgets.blogspot.com.es/2009/0 ... n-gdb.html , apparently gdb's failure to use pretty-printers depending on context is well-known:

Unlike the custom gdb commands, the custom pretty-printers apply to all occurrences of the objects, including as fields in the other data structures and even in the backtraces printed by gdb itself so they are much more useful.

I'll just wait for the llvm debugger, gdb's too thick for me to want to invest more time in it

cheers,