Debugging C++ - Revision history

Unhammer: /* Using gdb to debug lttoolbox/apertium */

2017-05-16T13:57:13Z

Using gdb to debug lttoolbox/apertium

2017-04-27T16:59:52Z

2013-02-04T06:34:35Z

In Emacs

2013-02-04T06:34:22Z

Valgrind

2013-02-04T06:25:23Z

Using gdb to debug lttoolbox/apertium

2013-02-03T15:44:25Z

Using gdb to debug lttoolbox/apertium

2013-02-03T15:44:05Z

Using gdb to debug lttoolbox/apertium

2013-02-03T15:43:51Z

Using gdb to debug lttoolbox/apertium

2013-02-03T15:43:37Z

Using gdb to debug lttoolbox/apertium

2013-02-03T15:43:27Z

Using gdb to debug lttoolbox/apertium

@@ Line 44: / Line 44: @@
 [[File:Gdb-emacs.png|200px|thumb|right|GDB running in Emacs]]
 Do <code>M-x gdb</code> and you'll be asked "Run gdb (like this):", change it to say <code>libtool --mode=execute gdb -i=mi lttoolbox/lt-comp</code> and press return. In the main menu, you can click <code>Gud → GDB-MI</code> and tick off <code>Display Other Windows</code> (or type <code>M-x gdb-many-windows</code> to toggle showing of the breakpoint list, local variables, stacktrace etc.
+===No line numbers in gdb?===
+See
+https://www.mail-archive.com/cygwin@cygwin.com/msg86175.html for some ways to debug the lack of debug info
 ==Valgrind==

@@ Line 52: / Line 52: @@
 $ libtool --mode=execute valgrind lttoolbox/lt-comp lr foo.dix foo.bin
 </pre>
+==Other C++ tips==
+===faster re-compilation with ccache===
+ccache is a compiler cache – it detects when the same compilation is re-run, and re-uses the old results
+On Ubuntu/Debian, first do
+<pre>
+sudo apt install ccache
+</pre>
+then in e.g. an autotools project, do
+<pre>
+./configure CC="ccache gcc" CXX="ccache g++"
+make
+</pre>
+===faster linking in autotools-projects with ld.gold===
+(e.g. in hfst) ld.gold is about 3x faster than the standard ld.bfd
+binutils on Ubuntu/Debian includes ld.gold already
+just do
+<pre>
+export CXXFLAGS='-fuse-ld=gold'
+export CFLAGS='-fuse-ld=gold'
+./configure
+make -j4
+</pre>
+===faster linking in cmake-projects with ld.lld===
+(e.g. in vislcg3) ld.lld is even faster than ld.gold
+On Ubuntu/Debian, first do
+<pre>
+sudo apt install lld-4.0
+sudo ln -s /usr/bin/ld.lld-4.0 /usr/bin/ld.lld  # Why doesn't Debian put this in /etc/alternatives by default?
+</pre>
+then in the cmake project, just
+<pre>
+./cmake.sh -DCMAKE_C_FLAGS="-fuse-ld=lld" -DCMAKE_CXX_FLAGS="-fuse-ld=lld"
+make -j4
+</pre>
 [[Category: Development]]

@@ Line 41: / Line 41: @@
 </pre>
-===In Emacs===
+===In [[Emacs]]===
 [[File:Gdb-emacs.png|200px|thumb|right|GDB running in Emacs]]
 Do <code>M-x gdb</code> and you'll be asked "Run gdb (like this):", change it to say <code>libtool --mode=execute gdb -i=mi lttoolbox/lt-comp</code> and press return. In the main menu, you can click <code>Gud → GDB-MI</code> and tick off <code>Display Other Windows</code> (or type <code>M-x gdb-many-windows</code> to toggle showing of the breakpoint list, local variables, stacktrace etc.

@@ Line 46: / Line 46: @@
 ==Valgrind==
+[http://valgrind.org/ Valgrind] is another debugging tool that lets you profile programs, check for memory leaks, and much much much more.
-is also cool
+As with gdb, use the libtool wrapper when running Valgrind:
+<pre>
+$ libtool --mode=execute valgrind lttoolbox/lt-comp lr foo.dix foo.bin
+</pre>
 [[Category: Development]]

@@ Line 16: / Line 16: @@
 <pre>
 $ libtool --mode=execute gdb lttoolbox/lt-comp
+</pre>
+And it should give you some output and the (gdb) prompt:
+<pre>
+Current directory is ~/src/apertium/trunk/lttoolbox/
+GNU gdb (GDB) 7.5.1
+Copyright (C) 2012 Free Software Foundation, Inc.
+License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
+This is free software: you are free to change and redistribute it.
+There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
+and "show warranty" for details.
+This GDB was configured as "x86_64-unknown-linux-gnu".
+For bug reporting instructions, please see:
+<http://www.gnu.org/software/gdb/bugs/>...
+Reading symbols from ~/src/apertium/trunk/lttoolbox/lttoolbox/.libs/lt-lt-comp...done.
+(gdb)
+</pre>
+Now you can pass command-line arguments, set a breakpoint and run the program:
+<pre>
+(gdb) set args lr foo.dix foo.bin
+(gdb) break lt_comp.cc:52
+(gdb) run
 </pre>

@@ Line 4: / Line 4: @@
 To start using gdb, you first have to recompile with the <code>-g</code> option sent to gcc:
-<code>
+<pre>
 $ sh autogen.sh  # ensure autotools are set up
 $ make clean     # force a full recompile
-# these options turn gdb-support on and optimisation off for C, C++ and linking:
+ # these options turn gdb-support on and optimisation off for C, C++ and linking:
 $ ./configure CFLAGS="-ggdb3 -O0" CXXFLAGS="-ggdb3 -O0" LDFLAGS="-ggdb3"
 $ make
-</code>
+</pre>
 Most gdb-tutorials will tell you to start gdb like <code>gdb path/to/binary</code>. However, since apertium/lttoolbox uses libtool, files like trunk/lttoolbox/lttoolbox/lt-comp are actually not binaries, but wrapper scripts which ensure the correct libraries are loaded. Since gdb doesn't understand these wrapper scripts, we need to wrap the gdb call with libtool. If you want to debug lt-comp, you start gdb like this (assuming you are in trunk/lttoolbox):
-<code>
+<pre>
 $ libtool --mode=execute gdb lttoolbox/lt-comp
-</code>
+</pre>
 ===In Emacs===