Debugging problems with MacPorts GCC on OS X - c++

I can't seem to get readable debugging output for programs compiled with GCC 4.7 MacPorts build.
I've tried with both GDB 6.3 and GDB 7.3 and each have their own problems.
Try with GDB 7.3 (MacPorts)
With GDB 7.3 I get the following output on startup:
$ ggdb ./test
GNU gdb (GDB) 7.3
Copyright (C) 2011 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-apple-darwin11.4.0".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
BFD: unable to read unknown load command 0x24
BFD: unable to read unknown load command 0x26
BFD: unable to read unknown load command 0x24
BFD: unable to read unknown load command 0x26
Reading symbols from /Users/StackedCrooked/programming/projects/stacked-crooked/Playground/LockOrderChecker/test...Reading symbols from /Users/StackedCrooked/programming/projects/stacked-crooked/Playground/LockOrderChecker/test.dSYM/Contents/Resources/DWARF/test...done.
done.
Running and triggering an assertion results in an unreadable stack trace:
(gdb) r
Starting program: /Users/StackedCrooked/programming/projects/stacked-crooked/Playground/LockOrderChecker/test
BFD: unable to read unknown load command 0x24
BFD: unable to read unknown load command 0x26
main
Assertion failed: (false), function lock, file main.cpp, line 168.
Program received signal SIGABRT, Aborted.
0x00007fff8ede282a in ?? ()
(gdb) bt
#0 0x00007fff8ede282a in ?? ()
#1 0x00007fff9a273a9c in ?? ()
#2 0x00007fff6af00690 in ?? ()
#3 0x0000003000000030 in ?? ()
#4 0x00007fffffffffdf in ?? ()
#5 0x000000010b305840 in ?? ()
#6 0x00007fff6af006d0 in ?? ()
#7 0x00007fff9a2a65de in ?? ()
#8 0x0000000000000000 in ?? ()
Try with GDB 6.3 (built-in)
According to this answer I should use GDB 6.3. However that leads to a different set of problems. During startup I get a bunch of errors:
GNU gdb 6.3.50-20050815 (Apple version gdb-1708) (Thu Nov 3 21:59:02 UTC 2011)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared libraries .
warning: Could not find object file "/Volumes/work/macports/var/macports/build/_Volumes_work_mports_dports_lang_gcc47/gcc47/work/build/x86_64-apple-darwin11/libstdc++-v3/src/.libs/compatibility.o" - no debug information available for "../../../../gcc-4.7.1/libstdc++-v3/src/c++98/compatibility.cc".
warning: Could not find object file "/Volumes/work/macports/var/macports/build/_Volumes_work_mports_dports_lang_gcc47/gcc47/work/build/x86_64-apple-darwin11/libstdc++-v3/src/.libs/compatibility-debug_list.o" - no debug information available for "../../../../gcc-4.7.1/libstdc++-v3/src/c++98/compatibility-debug_list.cc".
warning: Could not find object file "/Volumes/work/macports/var/macports/build/_Volumes_work_mports_dports_lang_gcc47/gcc47/work/build/x86_64-apple-darwin11/libstdc++-v3/src/.libs/compatibility-debug_list-2.o" - no debug information available for "../../../../gcc-4.7.1/libstdc++-v3/src/c++98/compatibility-debug_list-2.cc".
This is what I see if an assertion is triggered and I try to get a backtrace:
Assertion failed: (false), function lock, file main.cpp, line 168.
Program received signal SIGABRT, Aborted.
0x00007fff8ede282a in __kill ()
(gdb) bt
#0 0x00007fff8ede282a in __kill ()
#1 0x00007fff9a273a9c in abort ()
#2 0x00007fff9a2a65de in __assert_rtn ()
Die: DW_TAG_unspecified_type (abbrev = 19, offset = 423)
has children: FALSE
attributes:
DW_AT_name (DW_FORM_strp) string: "decltype(nullptr)"
Die: DW_TAG_unspecified_type (abbrev = 19, offset = 423)
has children: FALSE
attributes:
DW_AT_name (DW_FORM_strp) string: "decltype(nullptr)"
Dwarf Error: Cannot find type of die [in module /Users/StackedCrooked/programming/projects/stacked-crooked/Playground/LockOrderChecker/test.dSYM/Contents/Resources/DWARF/test]
According to this answer (which quotes the GCC 4.5 manual) I should use the -gdwarf-2 -gstrict-dwarf options.
I followed this advice. My build command looks like this:
g++ -o run-test -std=c++0x -Wall -Wextra -Werror -gdwarf-2 -gstrict-dwarf -g2 -O0 -I/opt/local/include main.cpp
However, it doesn't fix any of the aforementioned problems.
For the record: I'm on OS X Lion.
Does anyone know how to fix this?

According to the g++ man pages you should use -ggdb to generate debug symbols for gdb. BTW, just using -g always generated good symbols for gdb in my experience (on linux, windows (mingw) and mac).

The warnings from your MacPorts gdb 7.3 session are for load commands 0x24 (LC_VERSION_MIN_MACOSX) and 0x26 (LC_FUNCTION_STARTS). These are new load commands but are not essential for debugging - the warnings are harmless. The fact that your session lacks any symbolic information is maybe because of ASLR? It's been years since that was introduced into the system for user land debugging but that's what the debugger output can look like if it doesn't know that everything slid around in memory at runtime.
Have you tried using lldb? The version provided in Xcode 4.5 is really quite nice. It is the debugger that Apple is currently supporting and developing actively, and it should work with the DWARF output by more recent compilers correctly. The command syntax is a little different than gdb (although there are many command shortcuts provided that make it familiar to gdb users), there's a table of gdb/lldb command equivalences provided over at http://lldb.llvm.org/lldb-gdb.html. Give it a try, you might like it.

Related

AVX-512 - Debugging application with Intel SDE not working

I am trying to debug AVX-512 instructions on an emulated CPU using Intel® Software Development Emulator but it doesn't work as desired after setting a breakpoint. I followed this blog post: Debugging Emulated Code on Linux*
In window #1:
~$ g++ -g -O0 -mavx512f main.cpp -o main # compile main.cpp file
~$ sde -debug -- ./main # enable debugging
Application stopped until continued from debugger.
Start GDB, then issue this command at the (gdb) prompt:
target remote :54105
In window #2
# run debugger
~$ gdb ./main
GNU gdb (Ubuntu 9.2-0ubuntu1~20.04) 9.2
Copyright (C) 2020 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-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./main...
# set target "target remote :portnumber"
(gdb) target remote :54105
Remote debugging using :54105
warning: remote target does not support file transfer, attempting to access files from local filesystem.
Reading symbols from /lib64/ld-linux-x86-64.so.2...
(No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
0x00007fa7bbbcc100 in ?? () from /lib64/ld-linux-x86-64.so.2
# suspend program at main function
(gdb) break main
Breakpoint 1 at 0x2c9c: file /home/borrow/source/repos/se-test/main.cpp, line 165.
# start program execution from the beginning of the program
(gdb) run
The "remote" target does not support "run". Try "help target" or
"continue".
# step to next line of code
(gdb) step
Cannot find bounds of current function
# continue executing until next break point
(gdb) c
Continuing.
warning: Probes-based dynamic linker interface failed.
Reverting to original interface.
[Inferior 1 (Remote target) exited normally]
In window #2: as you can see
gdb run should run a program but it doesn't work. gdb c should also run until the next breakpoint but executes the program and terminates. This command gives me the following warning message:
warning: Probes-based dynamic linker interface failed.
In window #1: The program runs and ends (without stopping).
Program code looks like this:
// main.cpp
#include <immintrin.h>
const int N=64;
int64_t srcA[N] = {0};
int64_t srcB[N] = {0};
int64_t dst[N] = {0};
void foo()
{
__m512i result,B,C;
for ( int i=0; i<N; i+=8 ){
B = _mm512_loadu_si512(&srcA[i]);
C = _mm512_loadu_si512(&srcB[i]);
result = _mm512_add_epi64(B,C);
_mm512_storeu_si512(&dst[i], result);
}
}
int main() {
...
foo();
...
}
I tried running AVX2 code without SDE emulator using gdb and it worked. First I start it on an emulated CPU with SDE, it fails. How can I solve this problem?
It seems to be broken for PIE executables
(confirmed on Arch GNU/Linux with GCC 10.2, GDB 10.1, SDE 8.33.)
Build with g++ -O2 -fno-pie -no-pie -g -march=skylake-avx512 and everything works. (I had to run gdb ./a.out instead of bare GDB; without that it couldn't find the right file even after connecting to the remote.)
$ g++ -O2 -march=skylake-avx512 -no-pie -fno-pie -g avx512.cpp
$ /opt/sde-external-8.33.0-2019-02-07-lin/sde64 -debug -- ./a.out
Application stopped until continued from debugger.
Start GDB, then issue this command at the (gdb) prompt:
target remote :59783
Then in another terminal tab
$ gdb ./a.out
...
(gdb) target remote :59783
warning: remote target does not support file transfer, attempting to access files from local filesystem.
Reading symbols from /lib64/ld-linux-x86-64.so.2...
(No debugging symbols found in /lib64/ld-linux-x86-64.so.2)
0x00007f4f7033b090 in _start () from /lib64/ld-linux-x86-64.so.2
(gdb) b main
Breakpoint 1 at 0x401050: file avx512.cpp, line 29.
(gdb) b foo
Breakpoint 2 at 0x401190: file avx512.cpp, line 14.
(gdb) c
Continuing.
Breakpoint 1, main () at avx512.cpp:23
(gdb) layout asm
(copy-paste of some of the disassembly window)
│B+ 0x401120 <_Z3foov> xor eax,eax
│ 0x401122 <_Z3foov+2> nop WORD PTR [rax+rax*1+0x0]
│ >0x401128 <_Z3foov+8> vmovdqu64 zmm1,ZMMWORD PTR [rax+0x404260]
│ 0x401132 <_Z3foov+18> add rax,0x40
│ 0x401136 <_Z3foov+22> vpaddq zmm0,zmm1,ZMMWORD PTR [rax+0x404420]
│ 0x401140 <_Z3foov+32> vmovdqu64 ZMMWORD PTR [rax+0x404020],zmm0
│ 0x40114a <_Z3foov+42> cmp rax,0x200
│ 0x401150 <_Z3foov+48> jne 0x401128 <_Z3foov+8>
│ 0x401152 <_Z3foov+50> vzeroupper
│ 0x401155 <_Z3foov+53> ret
(gdb) layout src
asm-level and source-level debugging both work fine, stepping into intrinsic "functions" in avx512fintrin.h and so on when using stepi (aka si).
Without specifying the filename separately from connecting to the remote:
$ gdb
(gdb) target remote :46879
Remote debugging using :46879 warning: No executable has been specified and target does not support determining executable automatically. Try using the "file" command.
0x00007f0f85830090 in ?? ()
(gdb)
(IDK if it matters that my .gdbinit includes layout reg, the full-screen terminal TUI mode. Nice when it works but somewhat buggy.)
Or as a super hacky workaround with PIE executables, I was also able to put a delay loop at the top of main, giving you a chance to attach and then control-C before SDE finishes executing your program.
Then I could set breakpoints and start single-stepping. (Presumably a sleep or read system call would work). Source-level debugging still seemed broken, but I was able to debug the asm with layout reg. I used set $rip = ... with a copy-pasted address to get out of the _mm_pause() loop after attaching and hitting control-C.

Pid 4845 in trap loop, signal 11 Memory fault(coredump)

We are facing an error when running proccess
Pid 4845 in trap loop, signal 11
Memory fault(coredump)
Here the output of the command gdb bch core
bscs2app:/apps/bscsadm/bscs/SK_20200202 ] gdb bch core
HP gdb 6.3 for HP Itanium (32 or 64 bit) and target HP-UX 11iv2 and 11iv3.
Copyright 1986 - 2011 Free Software Foundation, Inc.
Hewlett-Packard Wildebeest 6.3 (based on GDB) is covered by the
GNU General Public License. Type "show copying" to see the conditions to
change it and/or distribute copies. Type "show warranty" for warranty/support.
..
warning: Load module /apps/bscsadm/bscs/bin/hpux11_31.x/bch has been stripped.
Debugging information is not available.
(no debugging symbols found)...
Core was generated by `bch'.
Program terminated with signal 11, Segmentation fault.
SEGV_MAPERR - Address not mapped to object
(no debugging symbols found)..."/apps/bscsadm/bscs/SK_20200202/./": can't read symbols: File format not recognized.
warning: Error in reading symbols from ... skipping
warning: Load module /oracle/ora111/lib/libnnz11.so has been stripped.
Debugging information is not available.
#0 0xc0000000000d2120:0 in BV_overlap+0x2e0 ()
from /usr/lib/hpux64/dld.so
(gdb)
If installing the latest HP-UX Linker, Libraries and Tools patch does not solve your problem, you should report it to HPE.

Opening core dump file with different executable but the same sources

I have a coredump file from a colleague's machine.
We both have the same sources for the program and the same third party *.so files (like libmysqlclient18 and several in-house ones).
The problem is that we both compile the software (from the same sources) independently and I want to use his core dump files for inspection with GDB on my machine.
When I try to load the core file and my executable into gdb I get:
user#ubuntu:/mnt/hgfs/share/dir$ gdb prog core
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
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 "i686-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from /mnt/hgfs/share/dir/prog...done.
warning: exec file is newer than core file.
[New LWP 4465]
[New LWP 4462]
[New LWP 4464]
warning: Can't read pathname for load map: Input/output error.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
Core was generated by `./prog'.
Program terminated with signal 11, Segmentation fault.
#0 0x002d3706 in ?? () from /lib/i386-linux-gnu/libc.so.6
(gdb) bt full
#0 0x002d3706 in ?? () from /lib/i386-linux-gnu/libc.so.6
No symbol table info available.
#1 0x00000000 in ?? ()
No symbol table info available.
(gdb)
Is this possible for this scenario to work? (I compile the software with debugging symbols enabled, of course)
If not, what are the technical details I'm missing?
I know for sure that it wouldn't be possible if he or I would make modifications to the source, since then the executable would be different, but this is not the case, the third party *.so files and the sources, they all match.
UPDATE:
After installing libc6-dbg as user mkfs suggested in the comments, I get this in gdb:
user#ubuntu:/mnt/hgfs/share/dir$ gdb prog core
GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04
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 "i686-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from /mnt/hgfs/share/dir/prog...done.
warning: exec file is newer than core file.
[New LWP 4465]
[New LWP 4462]
[New LWP 4464]
warning: Can't read pathname for load map: Input/output error.
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1".
Core was generated by `./prog'.
Program terminated with signal 11, Segmentation fault.
#0 0x002d3706 in _IO_helper_overflow (s=0x0, c=0) at vfprintf.c:2188
2188 vfprintf.c: No such file or directory.
(gdb) bt
#0 0x002d3706 in _IO_helper_overflow (s=0x0, c=0) at vfprintf.c:2188
#1 0x00000000 in ?? ()
(gdb) bt full
#0 0x002d3706 in _IO_helper_overflow (s=0x0, c=0) at vfprintf.c:2188
written = 47
target = <optimized out>
used = -1226838776
#1 0x00000000 in ?? ()
No symbol table info available.
(gdb)
Is this possible for this scenario to work?
Yes, but you need to ensure that the symbol layout of the binary you build on both machines is identical (or at least close enough). This isn't necessarily trivial: things like local username, pathname for sources or installation directory, and hostname sometimes leak into the built object files, and may cause symbol mismatch.
To check whether the binaries are close, run diff <(nm a.out) <(nm b.out) -- there should only be few differences. If you see a lot of differences, your binaries aren't close enough.
I compile the software with debugging symbols enabled, of course
This may be your first mistake: if your coworker builds with -O2, and you build with -g (and implied -O0), the binary is guaranteed to not match.
You need to build with exactly the flags your coworker builds with (but you may add debugging symbols; e.g. if your coworker builds with -O2, you should build with -O2 -g together).
P.S. Note that you also need identical versions of system libraries on the two machines.

Compiling a Qt application in order to get better debuginfos (Linux)

I downloaded FabariaGest source code then to compile it you have to run:
on qt 4 systems:
cmake -DMAKE_INSTALL_PREFIX=directory -DWANT_QT4=ON -DWANT_QWT=ON
on qt5 systems:
cmake -DMAKE_INSTALL_PREFIX=directory -DWANT_QT5=ON -DWANT_QWTQT5=ON
When it finishes, you run
# make install
Since I get a segmentation fault when I start the software, I tried to run
cd /opt/fabaria_gest
gdb fabaria_gest
run
backtrace
but I only get
[user#localhost fabaria_gest]$ gdb fabaria_gest
GNU gdb (GDB) Fedora 7.9.1-19.fc22
Copyright (C) 2015 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-redhat-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from fabaria_gest...(no debugging symbols found)...done.
(gdb) run
Starting program: /opt/fabaria_gest/fabaria_gest
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Detaching after fork from child process 7246.
[New Thread 0x7fffe0798700 (LWP 7244)]
Program received signal SIGSEGV, Segmentation fault.
0x00000000004f568c in QBasicAtomicInteger<int>::load() const ()
(gdb) backtrace
#0 0x00000000004f568c in QBasicAtomicInteger<int>::load() const ()
#1 0x0000000000502a92 in QtPrivate::RefCount::ref() ()
#2 0x0000000000502e37 in QString::QString(QString const&) ()
#3 0x00000000006b9709 in _ZL13getSystemInfov ()
#4 0x00000000006bc29f in main ()
(gdb)
#0 0x00
What can I do to recompile the software in order to get better debuginfos? Setting set follow-fork-mode in GDB did not help
Using
cmake -DCMAKE_BUILD_TYPE=Debug ...
will instruct cmake to generate debug information, which should make the backtrace easier to read.

GDB 7.3.1 on OSX Lion

I'm trying to use GDB (v 7.3.1) from macports to debug an executable compiled with
g++ 4.7 (also from macports). However, I start the debugger, I get the following output:
GNU gdb (GDB) 7.3.1 Copyright (C) 2011 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-apple-darwin11.2.0". For
bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/... BFD: unable to read unknown
load command 0x24 BFD: unable to read unknown load command 0x26 BFD:
unable to read unknown load command 0x24 BFD: unable to read unknown
load command 0x26
Then, whenever I attempt to backtrace, the debugger is unable to provide any
information about the stack; I get output like:
> #0 0x00000001085106d5 in ?? ()
> #1 0x000000010833d9b6 in ?? ()
> #2 0x0000000107e23000 in ?? ()
> #3 0x00007f828341f630 in ?? ()
> #4 0x00007f828341bc10 in ?? ()
> #5 0x00007f8283421950 in ?? ()
> #6 0x00007f8283427020 in ?? ()
> #7 0x00007f8283425510 in ?? ()
> #8 0x00007f82834195e0 in ?? ()
> #9 0x0000000100000001 in ?? ()
> #10 0x0000000100000000 in ?? ()
I've built with debug symbols, and I'm able to debug the executable fine on
linux. Does anyone know what's going on here or how I might fix it. It's
really difficult to fix certain problems without a debugger!
I don't know much about OSX or usage of gdb on it, but this appears to have been fixed shorly
after the release of gdb 7.3.1, I seem to recall something about the release of OSX and the release of gdb or binutils being around the same time, with the developer not having any early access to OS X. You could try a later version of gdb.
I'm guessing that the following patch committed shortly after 7.3.1 fixes it:
http://permalink.gmane.org/gmane.comp.gnu.binutils/54607
GDB 7.4.1 had fixed this issue, you could get and build it.
http://sourceware.org/gdb/wiki/BuildingOnDarwin