Is there any command or a way to start VirtualBox with GDB (VirtualBox GDB stub) such as the command with QEMU.
QEMU -s
I have found that there is a GDB stub Here, but it only works with windows.
Related
I'm trying to debug a 32-bit executable on a 64-bit Ubuntu system. It runs just fine by itself from the command line, but when I try to use gdb, it hangs in ld-linux.so.2. Also, gdb works for the 64-bit version of the executable. Does anyone have a clue as to what I should try?
I just re-imaged a machine to Ubuntu 18.04.3, and I installed the multilib versions of gcc and g++.
Thanks in advance.
gdb <executable>
GNU gdb ...
This GDB was configured as "x86_64-linux-gnu"
...
Reading symbols from <executable>...done.
(gdb) show archi
The target architecture is set automatically (currently i386)
(gdb) break main
Breakpoint 1 at ...
(gdb) run
Starting program...
warning: Breakpoint address adjusted from 0xf7fd9be0 to 0xfffffffff7fd9be0.
...
(7 of these)
[hangs...]
[In another terminal, ran 'kill -CONT <pid>']
Program received signal SIGCONT, Continued.
0xf7fd9be0 in ?? () from /lib/ld-linux.so.2
(gdb) cont
[hangs again...]
UPDATE: This problem has been fixed for Ubuntu in the gdb package version 8.1-0ubuntu3.2, so just upgrading your packages (sudo apt update && sudo apt upgrade) should help currently.
ORIGINAL ANSWER:
#EmployedRussian suggested in his edit to the question:
By downgrading from gdb=8.1-0ubuntu3.1 to gdb=8.1-0ubuntu3 the debugger started working again for me.
This also worked for me on Ubuntu 18.04.3. You should issue these commands:
sudo apt install gdb=8.1-0ubuntu3 # downgrade GDB to the working version
sudo apt-mark hold gdb # prevent upgrading (until the repository version is fixed)
I created a bug report for Ubuntu: https://bugs.launchpad.net/ubuntu/+source/gdb/+bug/1848200
You can click Does this bug affect you? if you have an Ubuntu account to get it fixed sooner.
Probably this gdb bug:
https://sourceware.org/bugzilla/show_bug.cgi?id=23210
Try upgrading to the current GDB version (8.3.1). If Ubuntu doesn't offer a package for that, you can try compiling it yourself.
This is now fixed in 8.1-0ubuntu3.2 in bionic-updates: https://launchpad.net/ubuntu/+source/gdb/8.1-0ubuntu3.2
I am using Ubuntu 16.04 on x86_64 workstation, and I'm cross-compiling a small demo program in C++, and deploying it to an embedded linux target running ARM architecture (environment-setup-cortexa9hf-neon-poky-linux-gnueabi, arm-poky-linux-gnueabi-g++).
I am able to successfully do this which gives me a debug session on commandline:
Target:
rpm -ivh gdbserver-7.10.1-r0.cortexa9hf_neon.rpm
gdbserver :9091 ${APPNAME}
Host:
sudo apt-get install gdb-multiarch
gdb-multiarch $APPNAME
target remote 192.168.0.212:9091
...
I can now use gdb-multiarch on commandline!
However from here... I really want to be able to use one of the many gdb frontend tools to provide a GUI to set breakpoints and step through the code (akin to gdbgui, or using vscode and configuring for a debugger). Are there any gdb frontend tools that specifically support gdb-multiarch?
Any tool I try, I believe no matter what it uses base gdb executable and gives this error because of mismatched architecture:
target remote 192.168.0.212:9091
Remote debugging using 192.168.0.212:9091
warning: Architecture rejected target-supplied description
Remote 'g' packet reply is too long: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000070fdff7e00000000c0fafc76100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
UPDATE 1 --
I can kinda sorta get this to work using ddd tool:
ddd --eval-command="target remote $MY_TARGET_IP:9091" --debugger gdb-multiarch
However! This is ancient and buggy, and I can't set breakpoints in loaded .so's right now with this.
I tried gdbgui with its options to specify debugger, but that's not currently working either. I filed a feature request report here:
https://github.com/cs01/gdbgui/issues/237
I found a way using gdbgui, but it required me to rebuild gdb from source code against my specific remote target architecture. Details of how I got it to work are here:
https://github.com/cs01/gdbgui/issues/237
Important bits in case the above link breaks:
TLDR Solution:
I was trying to rely on a prebuild gdb-multiarch from ubuntu apt repos, which didn't work. When I decided to download gdb and rebuild from source while configuring for arm-linux-gnuabi target arch.
Build method:
downloaded latest gdb source code
unzip it, go into folder, and build it like this:
./configure --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --target=arm-linux-gnuabi && make -j8 && sudo make install
Important to note that for my particular remote gdb server it's running on ARM so i had to say target=arm-linux-gnuabi in configure. GDB is building for my PC x86 arch, but it knows when debugging to recognize the target as ARM!
Now, arm-linux-gnuabi-gdb is installed by default to /usr/local/bin ... but you can instead provide prefix=<path> to where you want it to install in ./configure script above.
Using this, I was able to build a secondary copy of gdb called arm-linux-gnuabi-gdb which i could feed to gdbgui like this:
gdbgui -g arm-linux-gnuabi-gdb
From there, I can give gdb commands to connect to my remote gdbserver. I'm having to set breakpoints beforehand. My gdb commands are like this to set a few breakpoints:
set breakpoint pending on
break my_object.cpp:<line number for breakpoint>
b example_function_name
target remote <remote arm machine IP>:<gdbserver port>
c
Works great! This is leaps and bounds better than running gdb on commandline on my remote target.
This is a question from an absolute beginner.
I have a Ubuntu 14.04 host, gdb 7.7.1 installed on it and a project cross-compiled for qnx. I also have a qnx target, that I want to debug my app on.
The instructions on the internet tell me to use either gdb on PC + gdbserver, but I don't have gdbserver installed and I don't think I can compile gdb for qnx. I have something called pdebug. Instructions for qnx tell me that gdb has to have the target qnx command, that it clearly does not posess.
Here's what I've done:
# Assuming that 255.255.255.255 is the target ip and 1234 is the port
# On target
pdebug 1234
On host
gdb
gdb> target remote 255.255.255.255:1234
Then I got a couple of warnings and the gdb> again, as it was normal.
I managed to install a connection between my host and target, but when I hit run in gdb, it tries to run my local copy of the app, instead of running it on target.
There is no way one can debug qnx apps with Ubuntu's gdb.
You have to use qnx's gdb built for the exact this purpose, that is able to run target qnx and many other commands you will need. You have to use qnx's gdb on your host and pdebug on your target and run the same commands you ran:
# on target
pdebug 1234
# on host
ntoarm-gdb
(gdb) file MyQnxApp
(gdb) target qnx 255.255.255.255:1234
(gdb) upload MyQnxApp /mnt/myWorkingDir/MyQnxApp
(gdb) b main
(gdb) r
Then you will see the info about your connection:
Remote debugging using 255.255.255.255:1234
Remote target is <your_endianness>
See this detailed instructions.
Whenever I try to debug any program (i.e. a welcome message), I get this prompt. Any ideas how to run the debugger for C++ program?
I am using Macbook Pro OS X El Capitan (10.11.3)
For Mac OSX 10.5 and above,
Install Homebrew (if you don't have it already)
/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
Install GDB
brew install gdb
Go to https://sourceware.org/gdb/wiki/BuildingOnDarwin and follow the instructions to code sign the gdb binary.
If you're on Sierra, run the following command in your terminal
echo "set startup-with-shell off" >> ~/.gdbinit
Finally, run the following comamnd in your terminal
which gdb
Copy the output path from that command, (mine was /usr/local/bin/gdb) into the Debugger Command box in Netbeans and start debugging!
On Linux systems derived from debian, you have to install gdb
sudo apt-get install gdb
Then in debbuger command type
/usr/bin/gdb
More information of gdb can be found in GDB: The GNU Project Debugger
Make sure gdb is installed in your machine. you can do this by following
C:\cygwin64>setup-x86_64.exe -q -P gdb
after this, select gdb as a debugger in netbeans
gdb location
Use Synaptic to install gdb. This debugger is required for Netbeans.
On a Mac, I installed HomeBrew first, then followed this exactly on the Sierra OS. Worked perfectly. After Homebrew is installed, you have to create then sign your gdb certificate. Then select it in your IDE debugger section.
The instructions show how to select gdb in Eclipse, but I got it working in NetBeans by pushing the debugger button and typing in the file path in the popup (as mentioned in this document).
https://www.ics.uci.edu/~pattis/common/handouts/macmingweclipse/allexperimental/mac-gdb-install.html
I'm trying to debug target with gdb, but get rejection.
(gdb) target remote 10.0.0.2:2345
Remote debugging using 10.0.0.2:2345
warning: Architecture rejected target-supplied description
Remote 'g' packet reply is too long: 00000000ba4eefbe0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000c04defbe0000000090770940100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
The PC is 64-bit architecture, ubuntu 64-bit
$ uname -a
Linux ubuntu-VirtualBox 3.13.0-24-generic #47-Ubuntu SMP Fri May 2 23:30:00 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Trying to set different architecture doesn't help.
(gdb) set architecture i386:x86-64:intel
The target architecture is assumed to be i386:x86-64:intel
(gdb) target remote 10.0.0.2:2345
Remote debugging using 10.0.0.2:2345
warning: Architecture rejected target-supplied description
Reply contains invalid hex digit 59
Thanks for any idea,
Ran
I solved this problem using the gdb-multiarch instead of only gdb in my remote machine.
When I was using the gdb I got the following error:
(gdb) target remote 192.168.1.254:9092
Remote debugging using 192.168.1.254:9092
warning: Architecture rejected target-supplied description
Remote 'g' packet reply is too long: 000000002efeffbe34feffbe0000000000000000000000000000000000000000000000000000000000000000000000000000000020fdffbe000000006c1effb6100000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
(gdb)
My remote machine is as 32bit Intel Ubuntu V 16.04 and the target machine is an ARM 32bit Linux.
I followed these steps:
1: Keep the same binary executable in remote and target machine (compiled to the target machine and with Debug option, which in GCC is just a "-g" option);
2: Install gdbserver on target machine:
$ sudo apt install gdbserver
3: Install gdb-multiarch in the remote machine:
$ sudo apt install gdb-multiarch
4: Start gdbserver on target Machine:
$ gdbserver localhost:9092 app
where 9092 is the port I chose and app is the name of the binary executable;
5: Start gdb-multiarch on remote machine:
$ gdb-multiarch app
6: Type gbd-multiarch command:
(gdb) target remote 192.168.1.254:9092
where that IP address is the one of my target machine;
After step 6 I got the following screen (instead of the error), and the debug worked well:
(gdb) target remote 192.168.1.254:9092
Remote debugging using 192.168.1.254:9092
Reading /lib/ld-uClibc.so.0 from remote target...
warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
Reading /lib/ld-uClibc.so.0 from remote target...
Reading symbols from target:/lib/ld-uClibc.so.0...(no debugging symbols found)...done.
0xb6ff1e6c in _start () from target:/lib/ld-uClibc.so.0
(gdb)
i had a similar problem, debugging code on a ARM CortexA5 from openSUSE 13.1 i64. problem occured, when i called the gdbserver on the target and gdb on the laptop, but called gdb on laptop not pointing to the cross compiled binary, but to the one compiled for the laptop (hence i64).
after calling gdb on the laptop pointing to the same, cross compiled binary that is started with gdbserver on the target, all is OK and the error message dissapears.
This means that gdb you called on local machine and gdbserver you called on remote machine is of different architecture, this also means that the application you compiled would be cross-compiled with a compiler supported by your remote machine. So in the local machine you should call the gdb supported by the remote machine. Most probably it would be available in the same path where your cross compiler exists.
I just configured my windows and now I can remote debug from my windows machine to a linux binary.
Be sure your GDB compiled with correct options in your host machine(windows machine in my case). An example:
./gdb-7.4/configure --with-expat --target=x86_64-unknown-linux-gnu --host=i686-pc-mingw32
If you don't have expat download and install it.
You should download the gdb source code. And in same folder you should run configure.
--target option value should be same as the target's gdb banner. Go to target machine(linux in my case) and type gdb you will see something like x86_64-unknown-linux-gnu, you should input this value.
--host option should be i686-pc-mingw32 if you are on windows and using mingw.