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. |
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: