We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
Hello,since a few releases of the ARM GCC toolchain, GDB is extremely slow to load the symbols on Windows (at least since the GCC 11 release).It usually takes 5-10s to load them the first time on a specific ELF file.After that, it may be instant, there is probably some caching made by GDB. It gets slow again a few minutes later on the same file.I usually have to use GDB from the 7-2018-q2 release to get it working with a fast symbols loading.Unfortunately the ELF generated by the latest GCCs tend to crash this old GDB, making this solution unreliable now.
This seems to be a Windows specific problem (I didn't tested the Linux version, but it is probably not happening otherwise this bug would be fixed already).To reproduce: - use arm-gnu-toolchain-14.2.rel1-mingw-w64-i686-arm-none-eabi.zip from the ARM website (on Windows 10 / 11) - download any embedded .elf, for example https://github.com/jonvolk/stm32-slcan/blob/master/stm32-slcan.elf - on the shell (any, the Windows cmd.exe will do), type: arm-none-eabi-gdb.exe stm32-slcan.elf - see how much time it takes to load the symbols before gdb is readyThanks,Florent
Hi, I had same issue on my win10 PC and believe found the root cause. On my side gdb needed 10-30 seconds to load elf symbol table.
When I added "debug-file-directory /debug" in my gdbinit the loading took only 1-2 seconds. Before applying the change default vale for debug-file-directory was "//lib/debug". I believe that gdb tried to search network for debug symbols on windows and witting for timeout resulting long symbol table delays.
The proposed solution is just workaround, "/debug" should be set as default for debug-file-directory in next gdb build.