Getting GDB version slow after toolchain update

[davidoz]

Hi Forum,

After updating the ARM Toolchain from 10.3.1 to 12.2.1 (and OpenOCD) getting the GDB version command is taking 42 seconds to complete.

Verion 10.3.1

C:\sysgcc\arm-eabi\10.3.1\bin\arm-none-eabi-gdb.exe --interpreter mi "C:/Users/dxo/Projects/XYZRobotProject/Prototypes/XYZNucleoF429ZI/XYZNucleoF429ZI/Debug/XYZNucleoF429ZI_instrumented.elf"
[ 0 ms] -gdb-version
[ 87 ms] C:\sysgcc\arm-eabi\10.3.1\bin\arm-none-eabi-gdb.exe: warning: Couldn't determine a path for the index cache directory.
[ 100 ms] =thread-group-added,id="i1"
[ 100 ms] ~"GNU gdb (GDB) 10.2.90.20210621-git\n"
[ 100 ms] ~"Copyright (C) 2021 Free Software Foundation, Inc.\n"
[ 100 ms] ~"License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>\nThis is free software: you are free to change and redistribute it.\nThere is NO WARRANTY, to the extent permitted by law."
[ 101 ms] ~"\nType \"show copying\" and \"show warranty\" for details.\n"
[ 101 ms] ~"This GDB was configured as \"--host=i686-w64-mingw32 --target=arm-none-eabi\".\n"
[ 101 ms] ~"Type \"show configuration\" for configuration details.\n"
[ 101 ms] ~"For bug reporting instructions, please see:\n"
[ 101 ms] ~"<https://www.gnu.org/software/gdb/bugs/>.\n"
[ 101 ms] ~"Find the GDB manual and other documentation resources online at:\n <http://www.gnu.org/software/gdb/documentation/>."
[ 101 ms] ~"\n\n"
[ 101 ms] ~"For help, type \"help\".\n"
[ 101 ms] ~"Type \"apropos word\" to search for commands related to \"word\"...\n"
[ 107 ms] ~"Reading symbols from C:/Users/dxo/Projects/XYZRobotProject/Prototypes/XYZNucleoF429ZI/XYZNucleoF429ZI/Debug/XYZNucleoF429ZI_instrumented.elf...\n"
[ 147 ms] ~"GNU gdb (GDB) 10.2.90.20210621-git\n"
[ 147 ms] ~"Copyright (C) 2021 Free Software Foundation, Inc.\n"

Version 12.2.1

              C:\sysgcc\arm-eabi\12.2.1\bin\arm-none-eabi-gdb.exe --interpreter mi "C:/Users/dxo/Projects/XYZRobotProject/Prototypes/XYZNucleoF429ZI/XYZNucleoF429ZI/Debug/XYZNucleoF429ZI_instrumented.elf"
[       0 ms] -gdb-version
[      85 ms] =thread-group-added,id="i1"
[      85 ms] ~"GNU gdb (Arm GNU Toolchain 12.2.MPACBTI-Rel1 (Build arm-12-mpacbti.34)) 13.1.90.20230307-git\n"
[      85 ms] ~"Copyright (C) 2023 Free Software Foundation, Inc.\n"
[      85 ms] ~"License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>\nThis is free software: you are free to change and redistribute it.\nThere is NO WARRANTY, to the extent permitted by law."
[      85 ms] ~"\nType \"show copying\" and \"show warranty\" for details.\n"
[      85 ms] ~"This GDB was configured as \"--host=i686-w64-mingw32 --target=arm-none-eabi\".\n"
[      85 ms] ~"Type \"show configuration\" for configuration details.\n"
[      85 ms] ~"For bug reporting instructions, please see:\n"
[      85 ms] ~"<https://bugs.linaro.org/>.\n"
[      85 ms] ~"Find the GDB manual and other documentation resources online at:\n    <"
[      85 ms] ~"http://www.gnu.org/software/gdb/documentation/>.\n\n"
[      85 ms] ~"For help, type \"help\".\n"
[      85 ms] ~"Type \"apropos word\" to search for commands related to \"word\"...\n"
[      89 ms] ~"Reading symbols from C:/Users/dxo/Projects/XYZRobotProject/Prototypes/XYZNucleoF429ZI/XYZNucleoF429ZI/Debug/XYZNucleoF429ZI_instrumented.elf...\n"
[   42467 ms] ~"GNU gdb (Arm GNU Toolchain 12.2.MPACBTI-Rel1 (Build arm-12-mpacbti.34)) 13.1.90.20230307-git\n"
[   42467 ms] ~"Copyright (C) 2023 Free Software Foundation, Inc.\n"

Is there any reason why getting the GDB version should take that long?

Cheers
David

• This topic was modified 1 year, 4 months ago by support. Reason: formatting

[support]

Hi,

It could be a bug in the new GDB. We have checked it and it looks like ARM released another minor update.

Could you try using this gdb version [arm-none-eabi-gdb.exe​]? Is it also slow?

Also if you could share the ELF file via our support form, we can try a few workarounds and see if the slowdown could be easily avoided.

[davidoz]

Hi Support,

The new gdb didn’t help.  It is still slow.  I have sent you the ELF in the support ticket as requested.  I did try an old ELF with the new toolchain but that also was slow.  I don’t think the issue is with reading the ELF, but I’ll let you have a look.

Btw, the new toolchain is expecting _fstat, _getpid and _kill to be implemented.  Will dummy functions of these be added to the profiler code?

c:/sysgcc/arm-eabi/12.2.1/bin/../lib/gcc/arm-none-eabi/12.2.1/../../../../arm-none-eabi/bin/ld.exe: c:/sysgcc/arm-eabi/12.2.1/bin/../lib/gcc/arm-none-eabi/12.2.1/thumb/v7e-m+fp/hard\libc_nano.a(libc_a-fstatr.o): in function `_fstat_r':
fstatr.c:(.text._fstat_r+0xe): warning: _fstat is not implemented and will always fail
c:/sysgcc/arm-eabi/12.2.1/bin/../lib/gcc/arm-none-eabi/12.2.1/../../../../arm-none-eabi/bin/ld.exe: c:/sysgcc/arm-eabi/12.2.1/bin/../lib/gcc/arm-none-eabi/12.2.1/thumb/v7e-m+fp/hard\libc_nano.a(libc_a-signalr.o): in function `_getpid_r':
signalr.c:(.text._getpid_r+0x0): warning: _getpid is not implemented and will always fail
c:/sysgcc/arm-eabi/12.2.1/bin/../lib/gcc/arm-none-eabi/12.2.1/../../../../arm-none-eabi/bin/ld.exe: c:/sysgcc/arm-eabi/12.2.1/bin/../lib/gcc/arm-none-eabi/12.2.1/thumb/v7e-m+fp/hard\libc_nano.a(libc_a-signalr.o): in function `_kill_r':
signalr.c:(.text._kill_r+0xe): warning: _kill is not implemented and will always fail

[support]

Hi,

Thanks, we have reproduced the issue on our side, although it only took 5 seconds with the latest GDB 12 vs. instant with GDB 10.

Based on a quick look, gdb keeps looking for the .dwp file (separate file with debug symbols) and it appears to trigger some strange bug on the Windows side. The issue also appears intermittent – about 1/3 of runs the symbols load instantly.

You can try disabling Windows Defender – it could be related to the bug. If it doesn’t help, you can replace the gdb binary in the new toolchain with the one from the old toolchain. It will not affect the code produced by the compiler.

We will run some more tests on it next week and will see if there is a better workaround.

As for the not implemented and will always fail error, please see this page: https://visualgdb.com/documentation/semihosting/#notimpl

[davidoz]

Hi Support,

Thanks for letting me know.  We don’t use windows defender (it’s disabled), but we do use other virus software that isn’t visible to me (I can’t disable it).  I haven’t found my situation to be intermittent, it is consistently 42 seconds.  I did find typing the commands directly into the gdb shell was a bit faster, but still a lot slower than instantaneous.

I noticed the 12.2.1 version of arm-none-eabi-gdb.exe is 260KB while the 10.3.1 is 6KB.  It looks like they released the debug version by mistake.  I don’t think that is the issue since the patched version 12.3.1 is 8KB and is still slow.

Another dev has reported the same problem on the ARM Forum, but no answers yet:

https://community.arm.com/support-forums/f/compilers-and-libraries-forum/54939/the-latest-arm-none-eabi-gdb-version-12-3-rel1-takes-20-seconds-reading-symbols-from-elf-file

 

I’ve replaced the new gdb with the old gdb as suggested and that is working.  Thanks for letting explaining the “not implemented” issue.

 

Cheers

David

 

[support]

Hi,

We have run some additional tests and it looks like the problem only happens with the gdb binaries shipped with the original ARM toolchain. We built the latest gdb 13.2 from sources, and it manages to load the symbols instantly, just like the older gdb versions.

We have published an updated ARM toolchain that replaces the GDB binary with the one we built. You can install it via VisualGDB Package Manager or directly from here: arm-eabi-gcc12.3.1.exe

[davidoz]

Hi Support,

I can also confirm the new build is working correctly.  Thanks for the update.

Is the source code you used to produce the build an official release from ARM?  i.e. not a beta?

 

Cheers

David

 

[support]

Hi,

We used the source from here and the default configuration line:

../gdb-13.2/configure --target=arm-none-eabi --host=i686-w64-mingw32

No idea why the binaries shipped by ARM work differently.

[davidoz]

Hi Support,

I understand.  The gcc 12.3.1 came from the released source, and gdb 13.2.1 came from the pre-release.

The GDB binary that ARM released is definitely a debug build, so it must be an issue with their deployment process.

 

Thanks

David

[Author]

Posts