Getting GDB version slow after toolchain update

Sysprogs forums Forums VisualGDB Getting GDB version slow after toolchain update

This topic contains 8 replies, has 2 voices, and was last updated by  davidoz 1 month ago.

Viewing 9 posts - 1 through 9 (of 9 total)
  • Author
    Posts
  • #34599

    davidoz
    Participant

    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

    Version 12.2.1

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

    Cheers
    David

    • This topic was modified 1 month, 1 week ago by  support. Reason: formatting
    #34601

    support
    Keymaster

    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.

    #34602

    davidoz
    Participant

    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?

    #34603

    support
    Keymaster

    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

    #34604

    davidoz
    Participant

    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

     

    #34641

    support
    Keymaster

    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

    #34643

    davidoz
    Participant

    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

     

    #34646

    support
    Keymaster

    Hi,

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

    No idea why the binaries shipped by ARM work differently.

    #34647

    davidoz
    Participant

    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

Viewing 9 posts - 1 through 9 (of 9 total)

You must be logged in to reply to this topic.