FreeRTOS Symbols Not Loaded when "loadFiles" and "symbolFiles" are Used
#1007
Comments
|
+1 |
|
I think I understand what is going on. OpenOCD (any gdb-server) gets one chance to query gdb for symbol info and that is at the very start of the session. We are not involved in providing this info. In OpenOCD, there are no re-tries if the symbols change, because it doesn't even know that such a thing occurred. But, if we are loading the elf files very late during the debug cycle and can do something about it, then we will. We may have a chicken and egg situation. I also see this as a common problem and I am sure there are solutions out there. Hope we get lucky and stumble across the solution. Most of this is not documented well btw. |
|
@haneefdm: nice |
|
Good to know. If/When this gets fixed, I will need help testing it. I will report back here. This will be a large enough (dangerous) change that it may require a pre-release so it will not destroy development environments for half a million users. |
|
This is actually an issue with A fix is being tested and RTOS detection should work so long as you don't use other fancy options. I will be providing a patched build for testing tomorrow. |
|
A fix is available here https://github.com/Marus/cortex-debug/releases 1.13.0-pre3 I will be closing this, but if you are still having issues, we can reopen it. |
|
Hi, Thanks a lot for your solution. By doing this, I was previously able to add a breakpoint on both applications, but the Freertos thread-aware was KO. With your update, I can only debug the application file (I can't add breakpoint on my bootloader). Do you think this is normal, do you know a way to debug both applications, with the Freertos thread-aware? Thanks in advance, Sam |
Looks like one thing was fixed by breaking another. |
|
Thank you for your quick reply. As I understand, I therefore used : This help, and I can now add breakoint on both code. But I didn't mentionned that both bootloader & application are using Freertos, freertos stack-aware seems to not be reloaded when I jump in application code (Only freertos task from bootloader seems to be loaded, and is still display on call stack windows when the final application is running. Moreover, if no breakpoint is set on bootlader, task aren't displayed on call stack windows). |
|
@sgouraud Yes, you can only get thread info for one item. This is because FreeRTOS can query symbol info just once at the beginning when gdb connects to the gdb server. I don't the FreeRTOS will ever requery gdb. It would not know when to do it either. In most instances, while you can load as many images as you want, you can only get thread info for one executable. Bootloader is just FW like your main application. It is nothing special. |
|
@whosht is right. symbol-file is erasing any previous symbols. But add-symbol-file is not reading symbols at all and there are no threads (original problem) as far as gdb-server (openocd, JLink, etc.) are concerned. Back to experimentation and re-opening this issue. Not sure what the solution is yet. |
First off - thanks for your work on this extension. We use it at ADI for our MSDK, and it's been a much better experience than Microsoft's cpptools.
Describe the bug
For a FreeRTOS project, if a launch profile explicitly specifies the executable and symbol files with
"loadFiles"/"symbolFiles"it will fail to find FreeRTOS debug symbols and fail to show a thread-aware call stack. Ex:When only
"executable"is used, then the FreeRTOS symbols are loaded correctly and the call stack becomes thread-aware as expected. Ex:Expected behavior
FreeRTOS symbols should be loaded correctly if
"loadFiles"/"symbolFiles"are used. We have dual-core microcontrollers with a secondary RISC-V core and we build binaries for each core separately so that the debug symbols can be loaded correctly.Manually using
exec-file/symbol-fileon the GDB command-line works (see extra context at bottom), and so does a cpptools debug profile in a similar setup.Environment (please complete the following information):
Please include
launch.jsonNote: We load values from
settings.json(see VSCode-Maxim project.For this project,
${config:program_file}and${config:symbol_file}point to the same file. See here for the full project.Failed profile:
Successful profile:
The XRTOS view works fine in either case, and inspecting the logs this seems to be a bug with how cortex-debug drives GDB when the split options are used.
Attach text from
Debug ConsoleOutput for failed profile.
Note the "warning: No executable has been specified and target does not support\ndetermining executable automatically. Try using the "file" command." immediately after loading the symbol file between cmd 10/11. Not sure how or why the file info is getting dropped there.
Output for the successful profile
Additional context
We use an OpenOCD debug server with
configure -rtos autoadded to our target's .cfg files. The symbols are there in the binary and can be loaded successfully on the command-line usingexec-file/symbol-file:The text was updated successfully, but these errors were encountered: