I have an app that I have developed using QT Creator. The project builds and references a couple shared libraries that are in the build tree. When I try to debug my project using the remote debugger, I can't step into or break on any of the library code.
I have tried fixing it by setting LD_LIBRARY_PATH, using set-solib-search-path, etc.
More detailed info:
Host machine is a VM running Ubuntu 16.04
Target machine is a BeagleBone Black running Jessie
Everything is compiled as debug (with the -g flag)
My executable is in /home/debian
My library files are in /home/debian/lib
ls $LD_LIBRARY_PATH shows all of my library files, as expected
Start up command for GDB:
set solib-search-path /home/debian/lib
running gdb /home/debian/lib/mylib.so.1 yields the following:
GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
Copyright (C) 2014 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 "arm-linux-gnueabihf".
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 lib/mylib.so.1...done.
which implies that gdb is able to read the symbols.
However, running info shared library in the debugger console in qt yields
>~"From To Syms Read Shared Object Library\n"
>~" No /home/debian/lib/mylib.so.1\n"
Running sharedlibrary /home/debian/lib/mylib.so.1 doesn't seem to do anything; it just says "done".
Running add-symbol-file /home/debian/lib/mylib.so.1 fails with
The address where /home/debian/lib/mylib.so.1 has been loaded is missing
The application output screen says "Could not load shared library symbols" when it starts, and says "Do you need "set solib-search-path" or "set sysroot"?" but show solib-search-path prints out
The search path for loading non-absolute shared library symbol files is /home/debian/lib. as expected.
How can I resolve this so that I can debug my libraries?
EDIT:
If I debug on the target device, instead of remote debugging from Qt Creator, gdb can load the symbols, step into library code, and set breakpoints just peachily. Anyone have an idea as to why I can't remote debug?
Related
This is an XY question because I still haven't found a solution for my initial question.
However, I'd like to know (at least out of curiosity) the answer. This might help to understand how gdbserver works.
Given a mingw-w64 compiled binary to run on Windows, can a GCC gdbserver (launched on WSL) debug this binary? It seems that it can: see UPDATE
Will it work with WSL's mingw-w64 gdb? (run CLion on WSL to remotelly debug Windows app)
Can I "cheat" mingw-w64 to connect to the GCC gdbserver? Obviously, it refuses to work:
(gdb) target remote 192.168.0.101:1234
Remote debugging using 192.168.0.101:1234
warning: A handler for the OS ABI "GNU/Linux" is not built into this configuration
of GDB. Attempting to continue with the default i386:x86-64 settings.
warning: Architecture rejected target-supplied description
Reading /init from remote target...
warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
warning: A handler for the OS ABI "GNU/Linux" is not built into this configuration
of GDB. Attempting to continue with the default i386:x86-64 settings.
warning: Architecture of file not recognized.
Reading /init from remote target...
Reading symbols from target:/init...(no debugging symbols found)...done.
Remote register badly formatted: T0506:0000000000000000;07:a0e5feffff7f0000;10:0060220000000000;thread:p1007.1007;core:0;
here: 00000000;07:a0e5feffff7f0000;10:0060220000000000;thread:p1007.1007;core:0;
msys64/mingw64/gdbserver.exe is a bad option:
CLion does not want to connect when CLion is the one to start the server
the server constantly crashes
And I couldn't find an alternative for gdbserver on Windows.
So far I have a configuration:
Windows with MinGW-w64 compiler to build an app (using CLion as an IDE)
Remote Virtual Windows machine to remotelly debug the app (CLion does not support MSVC's remote debugger)
WSL Ubuntu on Virtual Windows (bruh) - this is needed for a proper shell with sshd (git bash/msys64 bash/mingw64 mintty do not work as Windows OpenSSH shells. No matter how hard i tried).
UPDATE
So I launched WSL /usr/bin/gdbserver :1234 test on my Virtual Windows. Then I launched WSL /usr/bin/gdb from my local Windows machine.
And it didn't show any errors:
eld#RU-AI000174:~$ gdb
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".
(gdb) target remote 192.168.0.101:1234
Remote debugging using 192.168.0.101:1234
Reading /init from remote target...
warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
Reading /init from remote target...
Reading symbols from target:/init...
(No debugging symbols found in target:/init)
0x0000000000226000 in ?? ()
(gdb) continue
Continuing.
[Inferior 1 (process 1202) exited normally]
Is this an expected and/or reliable behavior?
Long story short - LLDB doesn't debug my program properly, so I need to use GDB on my Mac to debug a c++ project. Steps I've taken:
Install GDB 8.0.1 and 8.1 via brew/macports (ie try all options)
Codesign the binary properly.
Start the mac in restart mode and typing csrutil enable --without debug
Choose the custom GDB executable in Clion.
Write in the .gdbinit file located in the home directory set startup-with-shell off
When I go to debug in Clion, in the debugger window it reads:
GNU gdb (GDB) 8.0.1
Copyright (C) 2017 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-darwin17.2.0".
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".
[New Thread 0x2203 of process 1208]
warning: unhandled dyld version (15)
In the console window it just prints the path of the executable and then hangs there until eventually it says 'command timed out'.
Any ideas would be massively appreciated.
I am trying to debug a simple "hello world" C++ program on Ubuntu 16.04 but gdb is not able to recognize the executable file format. However, I am able to successfully run the executable on the command line.
Here is the code
#include <iostream>
using namespace std;
int main() {
cout << "!!!Hello World!!!" << endl; // prints !!!Hello World!!!
return 0;
}
I compile the program file TestProject.cpp using the command
g++ -g TestProject.cpp -o hello
Then to debug, I give the command
gdb ./hello
I get the following error message
GNU gdb (Ubuntu 7.11.1-0ubuntu1~16.5) 7.11.1
Copyright (C) 2016 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".
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"...
"/home/<home>/./hello": not in executable format: File format not recognized
Something seems to be corrupt with the Ubuntu machine. Because I am able to debug the same program on another Ubuntu 16.04 virtual machine.
It is almost certain that ks1322's comment is correct one:
You've installed a 64-bit GCC, so your ./hello is a 64-bit binary (use file ./hello to confirm).
You've installed a 32-bit only GDB, so it doesn't know how to debug x86_64 binaries.
The fix is simple: install 64-bit GDB (which is capable of debugging both 32 and 64-bit binaries), or build hello in 32-bit mode (with g++ -m32 ...).
I had the same issue on mac os.
there is a bug in gdb: https://sourceware.org/bugzilla/show_bug.cgi?id=23746
their git repository has already had the fix. Unfortunately, the bins in homebrew have not had it yet. So, I had to git clone git://sourceware.org/git/binutils-gdb.git, compiled it and installed as it is described in the readme file.
I do believe this will fix yours on ubuntu.
P.S. it works on my machine but I have to run eclipse as root:
sudo /.../MacOS/eclipse. Otherwise, I have Launching : Configuring GDB Aborting configuring GDB. Cause I do not know how to fix it (
I compiled the c++ code library at github.com/RainerKuemmerle/g2o using cmake after adding
set(CMAKE_BUILD_TYPE Debug)
so as to be able to debug the application. Then it created a build file named "g2o". But when I try debugging with gdb, this is the output I get.
user2#arm_machine:~/g2o/trunk/bin$ gdb g2o
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 "arm-linux-gnueabihf".
For bug reporting instructions, please see:
<http://bugs.launchpad.net/gdb-linaro/>...
Reading symbols from /scratch/mbaxkms7/ARM_Programs_mbaxkms7/g2o/trunk/bin/g2o...(no debugging symbols found)...done.
(gdb)
Is there any other way to generate debug information while using cmake?
Your approach with adding set(CMAKE_BUILD_TYPE Debug) works fine.
But g2o is the program which was build with Release options. Debug version of g2o is called g2o_d. Thus to debug you need launch debugger in the following way:
user2#arm_machine:~/g2o/trunk/bin$ gdb g2o_d
Note
Different names isn't common feature of CMake but only of the g2o project:
# postfix, based on type
SET(CMAKE_DEBUG_POSTFIX "_d" CACHE STRING "postfix applied to debug build of libraries")
SET(CMAKE_RELEASE_POSTFIX "" CACHE STRING "postfix applied to release build of libraries")
I'm trying to read an ARM core file on my Linux desktop, but it seems not to be able to figure out my core file. Is there any way I can instruct gdb what type my core file is?
$ file ~/daemon
./daemon: ELF 32-bit LSB executable, ARM, version 1, dynamically linked (uses shared libs), for GNU/Linux 2.0.0, not stripped
$ file ~/core
./core: ELF 32-bit LSB core file ARM, version 1 (SYSV), SVR4-style, from './daemon -v -v -v -v -e 10 -t foo'
$ gdb-multiarch ~/daemon ~/core
GNU gdb (GDB) 7.5-ubuntu
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-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from ./daemon...done.
"./core" is not a core dump: File format is ambiguous
(gdb) core-file ~/core
"./core" is not a core dump: File format is ambiguous
The generating platform is armv4, which gdb-multiarch claim to support, according to the "set architecture" list.
EDIT: To clarify, my desktop machine running gdb is "x86_64-linux-gnu", namely an 64-bit Intel Ubuntu box.
This may help:
$ gdb-multiarch
...
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
(gdb) set gnutarget elf32-littlearm
(gdb) file daemon
...
(gdb) target core core
...
(gdb)
The following is relevant only if your desktop (where you are trying to run gdb-multiarch) is x86.
Gdb is a debugger. As such it will not be able to debug a foreign architecture executable on your x86 desktop machine because you cannot run arm code on x86 processor. You can however debug it remotely using gdb-server which will run on arm machine.
Is your desktop arm or x86?