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.