The latest arm-none-eabi-gdb version 12.3.Rel1 has a delay of about 10 seconds with J-Link GDB server

[avi-77]

Hi,

I have recently updated the arm toolchain from version 10-q4 to 12.3.rel1. The arm-none-eabi-gdb included with version 12.3.rel1 has introduced a delay of about 10-15 seconds after 'SWO enabled successfully.' statement is printed on the console. Is this a known issue? Can the user update some settings in the GDB Segger J-Link Debugging window to avoid this delay?

Received monitor command: SWO EnableTarget 0 0 0x1 0
SWO enabled successfully.
It waits for about 10-15 seconds at the SWO enabled statement before printing the below statement
Downloading 10944 bytes @ address 0x00100000 - Verified OK

[ilg-ul]

Could you try to manually start the GDB server in a terminal and the arm-none-eabi-gdb in a separate terminal to see if the delay is stil present?

Then run the same test, with an older arm-none-eabi-gdb, and try to compare the two runs.

[avi-77]

Manually starting the gdb server and arm-none-eabi-gdb didn't help. Although, I tried replacing the arm-none-eabi-gdb with the one from https://github.com/xpack-dev-tools/arm-none-eabi-gcc-xpack/releases/tag/v12.2.1-1.2 and it works fine without any delay.

The major difference that I see between 12.3.rel1 and 12.2.1-1.2 is the size of the arm-none-eabi-gdb (i.e. 256 MB for 12.3.rel1 and 6.89 MB for 12.2.1-1.2). Also, the arm-none-eabi-gdb from xpack depends on some DLLs such as libgcc_s_seh-1.dll, libgmp-10.dll, libiconv-2.dll, libmpc-3.dll, libmpfr-4.dll, libstdc++-6.dll, libwinpthread-1.dll and libzstd.dll.

Since you maintain the xpack version, you might have a better understanding of what might be causing this delay if arm-none-eabi-gdb from 12.3.rel1 and 12.2.rel1 release is used.

Is there anything that can be done on the plugin side to make this work with arm-none-eabi-gdb that is part of 12.3.rel1? Also, if I were to replace the arm-none-eabi-gdb with the one from xpack, what are the drawback or side effects? In addition, are all the DLLs mentioned above required for using the xpack version of arm-none-eabi-gdb?

[ilg-ul]

Manually starting the gdb server and arm-none-eabi-gdb didn't help

What does this mean? Is the delay still present?

you might have a better understanding of what might be causing this delay if arm-none-eabi-gdb from 12.3.rel1 and 12.2.rel1 release is used

Well, not really, I'm just compiling the same sources as Arm, using the same configurations, without any customisations; I have little insight on how they work.

I'll make a new xPack release soon, based on the latest Arm release, and let you know when I have a pre-release, to test it.

Is there anything that can be done on the plugin side

If starting manually does not work, what do you expect the plug-ins to do extra to make it work?

if I were to replace the arm-none-eabi-gdb with the one from xpack, what are the drawback or side effects?

You have to replicate the distribution structure, with the DLLs and everything, otherwise it will probably not start.

Probably a better suggestion is to stick to the previous Arm release.

are all the DLLs mentioned above required for using the xpack version of arm-none-eabi-gdb?

Yes. I guess the Arm distributions builds the binaries statically, and generates large executables. The xPack distribution is able to keep track of the dependencies, and keep a single copy of the library for use by multiple executables.

[avi-77]

What does this mean? Is the delay still present?
Yes, the delay is still present.

If starting manually does not work, what do you expect the plug-ins to do extra to make it work?
I was just wondering if you knew of any command that could be added to the GDB client setup in the Debugger window to resolve this delay issue.

I'll make a new xPack release soon, based on the latest Arm release, and let you know when I have a pre-release, to test it.
Thank you. I will wait for the release. Can I assume it will be released by the end of August?

[ilg-ul]

I was just wondering if you knew of any command that could be added to the GDB client setup in the Debugger window to resolve this delay issue.

I don't know of such commands, but if you find anything, please post your findings here.

Can I assume it will be released by the end of August?

I hope so, it depends on how many changes are compared to the previous release.

[ilg-ul]

The new release is available.

[silabs-daperez]

@avi-77
When you build your application, which toolchain debug level are you using? -g? -g3? If you're using -g3, does building your application using debug level -g remove the delay? Just an idea.

[TommyMurphyTM1234]

@avi-77 When you build your application, which toolchain debug level are you using? -g? -g3? If you're using -g3, does building your application using debug level -g remove the delay? Just an idea.

As far as I can see you have to explicitly select an xPack XBB debug build for -g -O0 to be used:

• https://github.com/xpack-dev-tools/xbb-helper-xpack/blob/918109e955b484dcab3e3e21ff9d30067b17ee42/scripts/xbb.sh#L975

otherwise -O2 (and no debug info) is selected:

• https://github.com/xpack-dev-tools/xbb-helper-xpack/blob/918109e955b484dcab3e3e21ff9d30067b17ee42/scripts/xbb.sh#L980

[avi-77]

Hi @silabs-daperez,

This issue only occurs with the Arm gdb downloaded from https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads. The arm gdb version compiled by @ilg-ul works fine https://github.com/xpack-dev-tools/arm-none-eabi-gcc-xpack/releases/tag/v12.3.1-1.1.

The issue with the 12.3.Rel1 is that it takes 20+ seconds to read the debug symbols. The debug level -g, -g3 doesn't help. There is no delay if I set the debug level to None.

537,434 &"monitor SWO EnableTarget 0 0 0x1 0\n"
537,480 @"SWO enabled successfully.\r\n"
537,480 38^done
537,480 (gdb)
537,480 41-list-thread-groups i1
537,480 &"symbol-file C:\\Users\\abc\\workspace12\\blinky\\Debug\\blinky.elf\n
"
*537,481 ~"Reading symbols from C:\Users\abc\workspace12\blinky\Debug\blinky.elf...\n*
"
559,766 39^done
559,766 (gdb)
559,766 &"load C:\\Users\\abc\\workspace12\\blinky\\Debug\\blinky.elf\n"
559,767 ~"Loading section .text, size 0xc88 lma 0x100000\n"
559,768 40+download,{section=".text",section-size="3208",total-size="757449"}
559,768 40+download,{section=".text",section-sent="3208",section-size="3208",total-sent="3208",total
-size="757449"}