I have Ubuntu 22.04 (64bit) running as Guest OS in VirtualBox in my Host Win10 (also 64bit).
In Ubuntu (guest) I have the following command running:
gdbserver localhost:9999 ./application
And then in Win10 (host) I try to connect using gdb, from Mingw64:
(gdb) target remote 192.168.0.24:9999
But I encounter the following error:
warning: Architecture rejected target-supplied description
Reading <ubuntu path to folder>/application 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 <ubuntu path to folder>/application from remote target...
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.
Reading symbols from target: <ubuntu path to folder>/application...
Remote register badly formatted: T0506:0000000000000000;07:80e4ffffff7f0000;10:b032fef7ff7f0000;thread:p35e0.35e0;core:0;
here: 00000000;07:80e4ffffff7f0000;10:b032fef7ff7f0000;thread:p35e0.35e0;core:0;
Both are the same architecture, so I don't understand what is going on.
The important line in the output is:
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.
This is telling you that the version of GDB you are running on the Windows host was built without support for debugging GNU/Linux targets.
This is probably why you also get this warning:
warning: Architecture rejected target-supplied description
which is GDB saying it doesn't understand the target description that the remote sent through.
As a result of rejecting the target description, GDB doesn't know the correct size for the architecture registers, which, I suspect is why you run into the error:
Remote register badly formatted: T0506:0000000000000000;07:80e4ffffff7f0000;10:b032fef7ff7f0000;thread:p35e0.35e0;core:0;
here: 00000000;07:80e4ffffff7f0000;10:b032fef7ff7f0000;thread:p35e0.35e0;core:0;
Notice the here: line starts with 00000000;07... this is halfway through the first register in the T packet, i.e. the remote sent 8-bytes, but GDB was expecting only 4-bytes for that register.
I suspect the solution to all your problems is to try and either install, or build yourself, a version of GDB that supports all targets, this should then include GNU/Linux support, and everything should work.
Related
When I started "qemu-system-x86_64 -S -s" and used gdb attach to that vm, everything is worked as I expected, but when I issued the command "set architecture i8086", it told me,
warning: Selected architecture i8086 is not compatible with reported target architecture i386:x86-64
warning: A handler for the OS ABI "GNU/Linux" is not built into this configuration
of GDB. Attempting to continue with the default i8086 settings.
Architecture `i8086' not recognized.
The target architecture is set automatically (currently i386:x86-64)
I found the following blog that's worked for my problem, but you need to use qemu-system-i386 32bit version of qemu.
https://astralvx.com/debugging-16-bit-in-qemu-with-gdb-on-windows/
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?
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.
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.
Can I debug a program running on a remote target to which I have ssh access, using local source files?
Say I've got a program called hello.c, in directory /home/jla/hello on my home machine.
And on the remote machine I put this same file in a directory /hello, and compile it with
$ gcc -g -o hello hello.c, and then delete the remote hello.c, but leave the executable.
Can I then run gdb locally, get it to ssh in to the remote machine to run the executable, but use the local sources as reference?
Notes:
Annoyingly, the remote machine is very stripped down and can't be altered. It has gdb, but it doesn't have gdbserver
Note that the local and the remote machine have different architectures. In this particular case 64bit and 32bit intel
What I really want to do is run it under emacs/gud. But this would be a great start.
The architectures of remote and local machines matter very little. What matters is how hello, gdb and gdbserver are built.
It sounds from your description that hello is built (on remote machine) for x86_64-linux-gnu
That means you need x86_64-linux-gnu gdbserver, and also a 32-bit GDB that is capable of debugging x86_64 binaries. You should be able to build both, copy gdbserver to the remote machine, and debug "normally".