I'm trying to use GDB to debug Qemu running on m68k architecture. I am attempting to make some changes to Qemu source to add some functionality to m68k support, and I am trying to use GDB to test changes I have currently made. Important to note is that I am using Qemu v5.2.0-rc1, as that is the version of Qemu currently utilized in a larger system that I am concurrently working with. Currently, I am using qemu-system-m68k to run buildroot (uClinux kernel) on that architecture, using the "-s -S" options for gdb. In a separate terminal, I am trying to run GDB on that remote target using (gdb) target remote localhost:1234, but I am getting the following error message:
warning: Architecture rejected target-supplied description
The connection to the uClinux Qemu kernel seems to go okay, but I cannot connect to the remote host.
I have tried finding any possible solutions to this problem, including setting the GDB architecture (currently says i386, not sure if this is right), which does not work. I have no idea how to get GDB running on this m68k Qemu emulated Linux kernel, and any help would be great. Thanks!
The error message means that QEMU's gdb stub sent gdb a description of what the CPU is (mostly a list of registers), and gdb didn't understand it. One common cause of this is trying to debug with a gdb for the wrong architecture.
You need to use a gdb which is aware of the the target architecture. On Ubuntu there is a 'gdb-multiarch' package which has a gdb-multiarch binary that knows about more than just x86. Otherwise you might need to build gdb from source. You can check if your gdb knows about m68k by running it with no arguments and typing the command set arch m68k. If it replies The target architecture is assumed to be m68k then it's OK (and your issue is something more complicated); if it gives you an error (eg Undefined item: "m68k") then you need to use a different gdb.
Related
I want to setup the following environment: I've got a STM32H753I-EVAL2 eval board, connected on a Windows PC. Until now I was developping and debugging locally on this PC with STM32CubeIDE. For several reasons my code source is on a Linux server (Samba mounting) so it takes forever to build a project. Hence I want to develop on the linux server from my Windows machine.
Compiling is working fine (and is way faster) but the issue is about debugging. I know it is possible to debug remotely, the Debug Configuration window from Eclipse (I'm using OpenOcd) allows to connect to a remote GDB server. What I don't know is how to start a GDB server on the Windows machine that will connect to the STM32 board ?
Sorry for the "answer to myself" but I think it might be useful for others (and even to me when I have forgotten in a few weeks ;) ).
Here is how to do.
on host side (on the machine where the eval board is physically plugged in) you have to manually launch the GDB server application that comes with STM32CubeIDE installation. See STMicro application note UM2576 for details. The default command line is:
ST-LINK_gdbserver.exe -d -v -cp "C:\ST\STM32CubeIDE_1.0.0.19w12patch\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_1.0.0.201903011553\tools\bin"
Now you've done the hardest. On server/remote side you have to setup the Debug Configuration to use OpenOcd with option "Connect to remote GDB server" and simply enter IP address and port number (which is not 3333 by default but 61234, but it can be modified).
This setup is working fine, even if I encoutered some instabilities during debugging once in a while.
I see two (maybe three) options
Use an alternate GDB server (see below)
Run the GDB server from STMCubeIDE in isolation (see OP's answer for Windows, this answer for Linux)
GDB Serial (not really an option right now but I'll share my experience so far)
I have used the second option to succesfully debug my target using arbitary GDBs such as gdb-multiarch command line and in the (non STMCube-ified) Eclipse CDT
Alternative GDB Servers
You could try STLink open source. I did. The problem is, your device might not be supported properly. I built 1.6.1 from Github to enable support for STM32G03x device. While moving to this version enabled it to detect the device, and I can use st-flash to program the device, the debugger is unusable (try and alter a register, it alters the wrong one, try and single step a program, it crashes immediately).
Do try it though .. it's easy and quick to install (or build), so it's worth checking if your device will work correctly with it.
Openocd is another option, but seems not to support SWD connection. I tried a build that allegedly had a patch for this but no luck.
If you can get one of these open source alternatives to work, they have another advantage, you may be able run them on something like a Raspberry PI, which means you don't have to get a PC physically close to your target.
Run the GDB server from STMCubeIDE in isolation
For Windows, see the OP's answer. For Linux, I do this alter the pathnames to suit your installation
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/user/apps/st/stm32cubeide_1.5.1/plugins/com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.linux64_1.5.0.202011040924/tools/bin/native/linux_x64/ /home/user/apps/st/stm32cubeide_1.5.1/plugins/com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.linux64_1.5.0.202011040924/tools/bin/ST-LINK_gdbserver -p 61234 -l 1 -d -s -cp /home/user/apps/st/stm32cubeide_1.5.1/plugins/com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.linux64_1.5.0.202011040924/tools/bin -m 0 -k
How did I get to this? Firstly launched a debugging session from STMCubeIDE, then ran
ps aux | grep gdbserver
Then we can see how Eclipse (STMCube) is launching the gdbserver and work from there.
If you find it complains about a .so file, locate that file from the STMCube installation and ensure the path to the directory containing it is in LD_LIBRARY_PATH (as per my example)
You can also launch the program with --help to show more options.
If add -e (persistent) you can disconnect and reconnect a GDB client without resetting the target (it will reset on initial invocation of the gdb server though, even without -k).
GDB Serial
This is where the target implements the GDB server end of the protocol. The GDB stub usually runs in an exception handler. This would usually be your breakpoint handler but you can also make it the default handler for unhandled exceptions, or, for example, the ctrl-c interrupt.
I have done a lot of Googling about this recently and basically when people ask about it on forums they usually get responses along the lines of "Here be dragons" or "Why don't you use JTAG?"
So the drivers for this, you might like to know, are in the GDB sources git://sourceware.org/git/binutils-gdb.git under gdb/stubs. The documentation is here. There isn't a stub implementation there for arm. Which is sad really, I used to use GDB remote serial regularly where I worked, and some of those targets were indeed ARM. The operating system was ecos.
So could ecos GDB stubs be ported to bare metal? Having giving it a good coat of looking at, I believe yes they could. The stubs are based on the ones from the GDB sources but they are heavily polluted with Ecos and Redboot build macros and copyright (the ogiringals were written by HP and released without copyright). We don't know what bugs the Ecos stubs may contain (I fixed at least one back in the day and I don't recall whether I submitted a patch). We don't know if they really support the latests architectures properly. And, we don't know if, after that, they simply use up too much memory - my STM32 has 8K of SRAM and I already see buffers that have a default size of 2K (not saying that's necessary but you see how work needs to be done here..)
So this third option, I will revisit this one day but for now, for me, it's a nope.
I have been tasked with setting up a development environment for an embedded platform. So far, I have set up a remote build host in NetBeans, which copies all of the source files to the target device, compiles them natively with the GNU toolchain on the device (g++, ld, etc.), and then runs the compiled binary and forwards stdout to the development machine that NetBeans is running on.
What I don't understand is: How does the binary on the build machine know where and when to start/stop if the breakpoints exist only in NetBeans? The build host only required ssh access and a compiling/linking toolchain, but somehow seems to communicate with NetBeans for debugging. A colleague of mine suggested it uses gdbserver, but I have not found any documentation on the NetBeans website about this package, and it is not installed on the build host (at least not from apt). How is NetBeans doing this?
GUI IDE's which use (or can be configured to use) a distinct command-line toolchain for compilation and debug typically do this by running each required toolchain program as a subprocess and interacting with it through standard streams. Essentially, the IDE would use gcc or gdb with the same textual interface used when running it in a terminal window. The IDE uses its knowledge of lines in the source file to configure breakpoints in gdb much as you would while running it by hand.
In your case, the IDE is configured to use a "remote host" for all of this, so instead of being invoked locally, the toolchain is controlled through as ssh session to the remote machine where both building and running occur.
Because the gdb debugger and the target program are running on the same computer, no gdbserver is required.
In the cases where gdb is too large for the target system, gdbserver is a small program which often gets cross-compiled for the target and loaded onto it. This serves as a compact little delegate which talks to the main gdb program running on a build machine via a serial or network connection and performs the raw interaction with processor, memory, and running program on behalf of gdb.
Another possibility is that the gdbserver role is held by a helper program running on the same machine as gdb which instead commands something like a JTAG debug adapter to interact with the target hardware at a lower level. In this case however, the helper program implementing the gdbserver protocol is not usually called "gdbserver" but instead has an implementation specific name, for example openocd.
gdb runs on the target machine. Only communication with gdb (commands etc) goes via net to your local machine. Read gdb documentation if need to know more/
You can do exactly the same - just open the remote terminal , run gdbserver, start gdb and you are done :)
Can someone give instructions on how to run/debug an OpenMPI (C/C++/Fortran) program in Eclipse PTP using the actual parallel run/debug modes on a local machine?
I've set a local connection in the 'Remote Environments' section. If I specify the actual program executable as the executable then eclipse gets stuck with 'submit interactive' and 'Launching... Submitting the job...' in the progress window, and I'm left with the specified number of processes of the program running at full CPU indefinitely. If I specify another program, like mpirun or mpiexec, and provide the necessary arguments to get to the program executable then the only difference is that I have the same number of mpirun's running at 0 CPU.
I should add that if I actually select "Local" under "Connection Type" then I get an error:
Failed to execute command: ompi_info -a --parseable
Reason: Cannot run program "ompi_info": Unknown reason
even though that command works fine from the command line and runs successfully when connecting to local host as setup in the 'remote environments'
I've seen the guides on the Eclipse website, but they're no help. I've checked [1] and [2], but I still get this working right.
I can get a program running successfully in parallel by treating it like a normal program and setting the executable to mpiexec and providing the necessary arguments, but I want to do actual parallel debugging, so this doesn't suffice.
EDIT:
I should be more specific. I know there are other methods of debugging, but Eclipse PTP (parallel tools platform) should be able to handle this perfectly, so I'm looking for an explanation from someone who has setup Eclipse PTP on their local machine such that they can use a parallel run configuration and the parallel debugging tools.
Please ask your question on the ptp-user mailing list.
https://dev.eclipse.org/mailman/listinfo/ptp-user
Sounds like openmpi isn't in the path available within eclipse
In fact, this is in the PTP FAQ on https://wiki.eclipse.org/Parallel_Tools_Platform_FAQ#Q:_I_get_the_error_.22Failed_to_execute_command:_ompi_info_-a_--parseable.22_when_I_use_the_Open_MPI_target_configuration_on_my_Mac
I've never actually used the Eclipse IDE, but I debug my MPI code using xterm and gdb:
mpirun -np 2 xterm -e gdb -ex run ./tool
Not exactly what you where after, but perhaps it helps...
Not sure which OS you're using, but I had this issue on MacOS. It's because Eclipse doesn't run .bash_profile or .bashrc, so its environment (namely PATH) won't have everything it needs. You could try to edit the PATH variable to include it by some other means (which I found to be overly complicated on Mac), OR you can just run the eclipse executable from a shell so that it inherits your typical environment. For me this was located at:
~/eclipse/parallel-neon/Eclipse.app/Contents/MacOS/eclipse
Then eclipse was able to detect OpenMPI just fine (PATH contained /usr/local/bin).
I managed to set up a gdbserver for a Qt application and ran it on a 64-bit Ubuntu computer using:
gdbserver <ip>:20000 ./sampleQtApp
And I tried to connect it to using a remote computer of the same network using GDB as follows:
set architecture i386:x86-64:intel
target remote <ip>:20000
It gives me the following output, and I can not figure out why.
(gdb) target remote 10.9.5.79:20000
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.
Remote debugging using 10.9.5.79:20000
Remote register badly formatted: T0506:0000000000000000;07:a080c7ceff7f0000;10:f0fae7b0107f0000;thread:7c0;core:0;
here: 00000000;07:a080c7ceff7f0000;10:f0fae7b0107f0000;thread:7c0;core:0;
(gdb)
What am I doing wrong here?
What is your gdb/gdbserver version? Try a more recent one. Look also this question.
I've just spent a whole day trying to find a way to enable GDB debugging from Qt Creator or Eclipse. I learned that there are basically two approaches to launch the target application:
Using ssh (ssh host gdb)
Using gdbserver
I was able to use both approaches to launch gdb remotely and start the application. However, GDB never responds to any breakpoints set in the IDE. Also I can't pause the application to inspect the program state. In Qt Creator I just get an obscure stack trace (I might have been looking at the traces of ssh or gdb actually...).
Can anyone help me to get started?
Progress!
I found that with Qt Creator 2.0 there is an feature called "Attach and debug remote application." It's based on gdbserver. The good thing is that it stops on the IDE's breakpoints. However, there are two issues:
When it hits a breakpoint it only shows assembly code, not the source code.
GDB often quits because of 'signal received'
I should probably mention that the remote executable is compiled with an older version of GCC than the one installed on my local PC. Perhaps some of the problems are related to this.
Update
I should mention that I switched to running cgdb on the remote machine via SSH.
The remote Qt Creator-based solution wasn't stable. GDB tends to quit because of mysterious 'signal received' messages.
So that GDB on your host (the machine you develop and compile on, so where you have Qt Creator) you have to give it access to the "symbol file".
I usually don't use Qt Creator, but GDB and gdbserver directly for cross-compiled programs remote-debugging. You could maybe give this a try to be sure that this works for you and maybe then find the missing option in Qt Creator (or maybe this will help you find what is missing).
On the target machine run:
gdbserver :5000 yourprogram
On the host machine, run gdb and then load the symbol file:
(gdb) symbol-file yourprogram
On GDB on the host machine, you then have to connect to connect GDB to the remote gdbserver:
(gdb) target remote target_ip_address:5000
From then you can use GDB on the host controlling the program on the target.
I hope this helps!
Due to peculiarities in our makefile build system the file references contained in the debugging symbols look like this:
../src/main.cpp
../../src/utils/logger.cpp
This is no problem for GDB, but Qt Creator was unable to map these paths to the actual files. I was able to fix this by adding 'dir' statements in the GDB init file:
dir src
dir src/utils
...
Now it works.