Following the information here: Renode GDB doc, I tried setting up debugging between the emulation and Eclipse-based STM32CubeIDE.
For that, I added to my .resc script, which creates the STM32L072-based machine and loads my firmware .elf file(s), a line at the end:
machine StartGdbServer 3333 true
That was my first attempt, with the "true" for auto-starting the emulation once GDB connects. With that, my debug config in CubeIDE is as follows:
create "GDB Hardware Debugging" template to start off (the STM32-specific template offered by CubeIDE cannot be used as it presumes the presence of an ST-Link or similar HW debugger)
"Main" tab: set "Project", and "C/C++ Application" binary, disable auto-build - to not have the IDE change the binary that's already loaded by the .resc script
"Debugger": "JTAG Device" to "Generic TCP/IP", "localhost:3333"
"Startup": no loading of image or symbols, as .resc script already loads .elf files, "Run commands" box is empty
If I then start Renode, in the monitor, load my .resc file with "include" (i.e. not starting the emulation, just preparing the device & starting gdbserver), and then start to debug with that above configuration, CubeIDE's threads view shows like there was a breakpoint, but at address 0x0,and no source code file is opened. Starting and pausing the program with the > and || buttons does not improve anything.
The monitor output also does not show a lot of action, seems the pogram does indeed not really run:
[INFO] my_app: GDB server with all CPUs started on port :3333
[INFO] cpu0: Guessing VectorTableOffset value to be 0x8000000.
[INFO] cpu0: Setting initial values: PC = 0x8001F49, SP = 0x20005000.
No more output. (logging function names is enabled)
So I tried the alternative of not setting "start once gdb connects" to true:
machine StartGdbServer 3333
and, for debug config step 4., the "Run commands" box now contains:
monitor start
continue
If I then start Renode again, load the .resc file, and then start debugging from CubeIDE,
I see, in the Renode monitor, the program running through until the point where it runs into an assertion, while the CubeIDE debug session looks basically ending immediately after starting. So, at least the "monitor start" has arrived, as the program ran, although unimpeded by the connected(?) GDB.
What's missing from these configurations for debugging to work?
Related
I'm trying to debug a Raspberry Pi Pico project using openOCD + Picoprobe. I go through the steps that appear to be correct to do all this from my Linux PC (the Get started with Pico and C++ guide is for the Raspberry Pi, but there are tutorials online for PC), but when trying to set breakpoints in gdb, it appears to be looking at a different file.
My steps are the following:
In a console, navigate to the openOCD folder and run:
sudo src/openocd -s tcl/ -f tcl/interface/picoprobe.cfg -f tcl/target/rp2040.cfg
I get only info messages, no errors, until it waits for the gdb to connect
Info : starting gdb server for rp2040.core0 on 3333
Info : Listening on port 3333 for gdb connections
Then, in a different console, I navigate to what I want to debug, in this case the blink.c example. I stand inside the build folder with my .elf file and run
sudo gdb-multiarch blink.elf
(gdb) target extended-remote localhost:3333
(gdb) monitor reset init
(gdb) break 15
where 15 is a relevant debuggable line. But the thing is, the breakpoints are said to be set in a different file:
Breakpoint 1 at 0x20000178: file ../../../../../../libgcc/config/arm/lib1funcs.S, line 1461
and then on, all breakpoints are also set there. Here's an example trying to set 3 different breakpoints:
(gdb) b 15
Breakpoint 1 at 0x20000178: file ../../../../../../libgcc/config/arm/lib1funcs.S, line 1461.
(gdb) b 16
Note: breakpoint 1 also set at pc 0x20000178.
Breakpoint 2 at 0x20000178: file ../../../../../../libgcc/config/arm/lib1funcs.S, line 1461.
(gdb) b 17
Note: breakpoints 1 and 2 also set at pc 0x20000178.
Breakpoint 3 at 0x20000178: file ../../../../../../libgcc/config/arm/lib1funcs.S, line 1461.
So that. I am totally lost on what's happening here. Could anyone point me to why this is happening, or what that file does?
I see it's been a few months but I just ran into the same problem, here's what I've learned.
When you compile the C/C++ program that you're trying to debug, you need to compile it in debug mode, which tells the compiler to include debug symbols in the program. If compiling directly with gcc, you can use the -g flag. However, I'm assuming you're using CMake, in which case you can just add set(CMAKE_BUILD_TYPE Debug) to your CMakeLists.txt (found a few other options here as well)
Probably goes without saying, but after recompiling this way, you'll need to re-load your new program onto your target Pico by holding the bootsel button and plugging it into your machine directly (ie. not via your debugger Pico).
I also found that after doing this, setting breakpoints just to specific lines still didn't behave as expected, and I had to actually specify the name of the file as well, ex: break main.c:15
I'm trying out STM32CubeIDE, and I've been trying to get it to work with the GDB QEMU debugging plugin that's part of the Eclipse CDT package. I've been able to create the project and debug configuration for my STM32F4-Discovery board, and the debugger partially launches, however, just as the simulator starts up, the GUI window it creates suddenly crashes and I get this error:
Error in final launch sequence
Failed to execute MI command:
-target-select remote localhost:1234
Error message from debugger back end:
Truncated register 18 in remote 'g' packet
Failed to execute MI command:
-target-select remote localhost:1234
Error message from debugger back end:
Truncated register 18 in remote 'g' packet
Truncated register 18 in remote 'g' packet
I think this is caused by some mismatch between the CDT plugin I installed and the GCC toolchain that shipped with my installation of Ubuntu 20.04. However, I'm not sure how to fix this.
Is there anything I try to fix this?
So it looks like there were a couple factors as to why this wasn't working. First off, the error messages that I was getting immediately after the GUI debugger terminated were due to an incorrect installation of the arm-none-eabi-gdb package. In order to fix this, I downloaded the package from the ARM site and followed the instructions detailed here. After installing the arm-none-eabi-gdb package again, I went into the project debug configuration settings, navigated to the "debugger" tab in this window, and then changed the GDB executable path from the variables the IDE had set for me to the actual GDB executable path (in this case /usr/bin/arm-none-eabi-gdb).
After that was done, the debugger would no longer immediately terminate, but I was still getting some errors in console shortly after it started (see below). In addition, the debugger GUI would produce no meaningful output, and Ubuntu would warn that the process had frozen.
NVIC: Bad read offset 0xd88
qemu-system-gnuarmeclipse: Attempt to set CP10/11 in SCB->CPACR, but FP is not supported yet.
To solve this, I right clicked the project in the project explorer panel of the IDE, then went to C/C++ build section, then to the Settings section under that, and then finally to the "Tool settings" section of this menu. Under "MCU settings", there are two options for "Floating point unit" and "Floating point ABI", which I changed to "None" and "Software implementation" respectively. After saving these configuration changes, I went to the system_stm32f4xx.c file under the src/ directory of the project, and commented out these lines:
/* FPU settings ------------------------------------------------------------*/
#if (__FPU_PRESENT == 1) && (__FPU_USED == 1)
SCB->CPACR |= ((3UL << 10*2)|(3UL << 11*2)); /* set CP10 and CP11 Full Access */
#endif
After that, I cleaned the project, rebuilt it, and relaunched the debugger. It then functioned normally.
I am having trouble getting a reliable debugging setup.
I have seen other threads in some forums across the net with a similar title, but the circumstances seem different.
Setup:
Linux (Xubuntu) 64bit
Eclipse CDT, Neon 4.6.0
"GDB Hardware Debugging" plugin from eclipse "install new software", configured to reset & delay 3sec, halt; load symbols (all checkboxes, no custom commands)
arm-none-eabi-gcc 4.8.3 tool chain
OpenOCD, recently downloaded, running in an own console, configured for my exact MCU with script provided by them & the st-link
STM32L476RG MCU with hard float, which is used.
ST-Link V2 debugger (stand-alone)
Now, there is a sequence with which I am, after some struggle every time, able to connect with the debugger, but stepping and reading variables doesn't work so clearly reliable that I'd trust what I see for a second.
But to even get to that point where the call stack would not be full of obvious nonsense entries and only very few of them, is tiring.
Example:
Flash the device with the firmware. This usually works without trouble.
Start openocd.
Start debugging in Eclipse.
OpenOcd shows connection, then says: "undefined debug reason 7 - target needs reset"
I regardless press the "resume" button in Eclipse to make the program run past the bogus top stack frame it shows.
Press "suspend" (still bogus in callstack), then "terminate".
Ctrl+C out of OpenOcd.
Manually (hardware) reset the stm32 MCU.
Restart OpenOcd.
Start debugging in Eclipse again.
OpenOCD output:
GNU ARM Eclipse 64-bits Open On-Chip Debugger 0.10.0-dev-00287-g85cec24-dirty (2016-01-10-10:31)
Licensed under GNU GPL v2
For bug reports, read
http://openocd.org/doc/doxygen/bugs.html
Info : auto-selecting first available session transport "hla_swd". To override use 'transport select '.
Info : The selected transport took over low-level target control. The results might differ compared to plain JTAG/SWD
adapter speed: 500 kHz
adapter_nsrst_delay: 100
none separate
none separate
Info : Unable to match requested speed 500 kHz, using 480 kHz
Info : Unable to match requested speed 500 kHz, using 480 kHz
Info : clock speed 480 kHz
Info : STLINK v2 JTAG v24 API v2 SWIM v4 VID 0x0483 PID 0x3748
Info : using stlink api v2
Info : Target voltage: 3.192646
Info : stm32l4x.cpu: hardware has 6 breakpoints, 4 watchpoints
Info : accepting 'gdb' connection on tcp/3333
Info : device id = 0x10076415
Info : flash size = 1024kbytes
undefined debug reason 7 - target needs reset
Now with some luck, I finally have a somewhat working debugger connection, for a while.
But this may as well need some repetitions.
Why the "press resume" in between when it's clear the connection is bad? Not sure, this seemed to increase the likelihood that in the next iteration I'll have the connection, a lot.
A maybe relevant note:
The MCU has an LCD connected to it and from that I can see when it resets.
For some reason, starting debugging in Eclipse will apparently not reset the device, although the reset checkbox is checked in the debug config.
If I open a telnet connection to OpenOCD in a terminal, and do "reset" there, the device does reset.
What could be causes for the odd behavior of my setup?
What OpenOCD client you're using? I made a mistake using the host gdb and I got this error. And after I modified my debugger path to the location of my arm-none-eabi-gdb in "Debug Configuration" of your eclipse the problem disappeared.
From your post you only mentioned you used arm-none-eabi-gcc toolchain, so don't know if you set your gdb to arm-none-eabi-gdb in "Debug Configurations", which is separate from project toolchain settings.
Another version of OpenOCD helped me. Met a similar issue with OpenOCD 0.10.0 from http://gnuarmeclipse.github.io. Initially it worked then the issue appeared. Removed it and installed the build from http://www.freddiechopin.info.
I'd like to debug to debug a remote application with GDB.
My target system is a FreeBSD 8.3 box with gdbserver running. The application has been compiled successfully on that box. My Eclipse CDT 4.2 runs on Windows 7 with recent MinGW installed.
This is an external program I'd like to debug. It is neither written by me nor I do have it as a library. I do not intend to write my own program. In this case it is Subversion 1.8.0-dev which I want to debug.
I have created a simple C project, attached the source of Subversion. Created a remote debug config and attached the sources to the running thread in gdbserver.
Now, eclipse enters the main function of Subversion but when I set a breakpoint in another attached source file, Eclipse says: No source file named ra_loader.c or it simply says "No source available".
Then It simply exists the application.
What am I missing here?
Try the suggestion made on this thread
Quote :
1) run a debug session and open the gdb console inside Eclipse
('Console' tab -> 'Display Selected Console' button -> choose the one
ending with 'gdb')
2) use command 'pwd' in the console to print
gdb's current working dir
3) use command 'info line main' to get
the source file where gdb expect to find of my "int main(...)"
function
4) concatenate the result of step 2 with result of step
3 (which should be a relative path) to see if it matches the
correct source file I want
5) use the 'cd' command in gdb (to
change the current working dir) till I get the correct match in
step 4
Knowing the initial working directory (2) and the correct working directory (5) for gdb , I had 2 options: 1) Use gdb's 'cd'
command every time I launch a debug session (I could setup a
.gdbinit file in the gdb initial working directory to do this
automatically) or 2) Setup the 'Source' tab, in 'Debug
Configurations', to make Eclipse use paths that match with gdb's
initial working dir ('Project - Path Relative to Source Folders'
worked for me)
A while ago I changed my personal operating system to linux and my development enviroment to KDevelop.
However debugging c++ projects is still not working as it should.
My KDevelop version is 4.2.2 (I installed it through package management)
Every time I hit the "debug button" the application is starting with the console message
warning: GDB: Failed to set controlling terminal: Operation not permitted and debugging functionality is not available.
Any ideas welcome.
(If you need additional information don't hesitate to ask)
I also had this problem, but I use gdb in KDevelop sparsely enough that hadn't bothered me yet. Here's my log of trying to fix it:
Grepping through the GDB 7.3.1 source code reveals that this message is printed when GDB tries to set its master TTY to a newly-created pseudo-tty (see gdb/inflow.c, lines 683-740). In particular, a call to ioctl with request TIOCSCTTY fails with a permissions error.
With this in mind, I took a look at the Linux kernel source code to see what could cause a failure. A bit of searching shows that it will eventually degenerate into a call to tiocsctty(). The comment from tiocsctty that is important here:
/*
* The process must be a session leader and
* not have a controlling tty already.
*/
Since the only other reason it can fail with EPERM is if the tty that GDB creates is actually a controlling tty for another process (which seems highly unlikely), I thought it reasonable to assume that GDB is not a session leader. Fair enough, it's launched by KDevelop after all!
So: I tried not launching the GDB session in an external terminal, and it works. Problem narrowed down.
Originally, the external terminal line was set to konsole --noclose --workdir %workdir -e %exe. Changing this to terminator -e %exe made a slight difference: KDevelop warned me that
GDB cannot use the tty* or pty* devices.
Check the settings on /dev/tty* and /dev/pty*
As root you may need to "chmod ug+rw" tty* and pty* devices and/or add the user to the tty group using "usermod -G tty username".
I checked my permissions; my user was part of the tty group and all relevant files were readable and writable.
Grepping through the KDevelop source code reveals how KDevelop actually sets up the terminal. It runs the shell script
tty > FIFO_PATH ; trap "" INT QUIT TSTP ; exec<&-; exec>&-; while :; do sleep 3600;done
and then sets up GDB to use the terminal device it reads from FIFO_PATH. (My name, by the way, not the one that KDevelop uses.) The problem (as best I can tell) is that gdb is not launched as a child of the shell script, and thus cannot use it as its main tty.
I'm not feeling up to patching KDevelop to make this work properly as of yet (or finding what actually caused this to stop working in the first place . . .), so the best I can suggest at the moment is to simply not use an external terminal for debugging purposes.
Good luck! I'll update if I find anything useful.
As Arthur Zennig said, for more information, you need to do something
Firstly, you need to create the Terminal profile
Secondly, open Launch Configurations, fill info such as the image below
Good luck!
In case you got the error:
"Can't receive konsole tty/pty. Check that konsole is actually a
terminal and that it accepts these arguments"
RUN > CONFIGURE LAUCHERS > (See picture below. My project name was "loops")
What worked for me was to uncheck checkbox "Use External Terminal". Found the in the "Compiled Binaries" Tab.