Hi all,
The arm-none-eabi-gdb binary in the windows 12.3.rel1 release is built with a debug configuration. The binary file is 263MB (contains symbols) whereas previous versions were around 6MB. I'm hoping ARM will see this and fix it for the next release :)
Cheers
David
Hi,
Our arm-none-eabi toolchain releases of GCC 11 and later come from a different infrastructure, where the binaries were not stripped, and we have kept it that way with the view that the symbols will provide useful debug information if there are errors.
It is not clear to us yet how many users would prefer leaving the symbols in there Vs how many users would prefer removing the symbols. Is the larger file size causing issues in your case?
We would listen to more feedback and information from our users, to help us decide whether we should remove the symbols from the binaries.
Kind regards
Vasee
Hi Vasee,
Thank you for your reply.
If it was just a case of symbols in the binaries, I would not have raised it. This is clearly a defect in your build/deployment process. It only effects arm-none-eabi-gdb.exe. All other binaries have been built correctly i.e. using a 'release' configuration (no symbols and compiler optimizations enabled).
The main problem isn't the symbols in the gdb binary, it is the speed. Since it was built with a debug configuration, it was not compiled with compiler optimizations enabled. It runs considerably slower than the previous versions (gcc 10). E.g when reading a large ELF file, it was normally instantaneous, but now it is taking over 20 seconds. This has been raised before - see
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
You can easily test it yourself. Compare the time arm-none-eabi-gdb.exe v10 and v12.3 take to read a large ELF file. The later one takes magnitudes longer. It is not because the functionality has changed, but because it wasn't built with compiler optimizations.
Kind Regards
Hi vvinayag,
Do you have any updates on this issue?
Regards,
Avi
Apologies for the delay in responding.
The arm-none-eabi-gdb binary in the 12.3.Rel1 release contains debug symbols, which explains the large file size. We will address this in the next release.
With regards to the optimizations, I think that the binaries are built with -O2. If the GDB binary is slow, then this requires further investigation.
I wasn't able to reproduce the issue yet. If possible, are you able to confirm whether the slowness in reading a large ELF file is only in the Windows binary, or is it also slower on the Linux hosted arm-none-eabi-gdb ?
Kind regards,
The issue is Windows-specific. Do you have information on the next planned release?
Hello, Please expect the a release (13.3) with this issue fixed in the next few days.
Hi Nikita Venkatesh , Having tried out version 13.3.Rel1 of the ARM GNU Toolchain from developer.arm.com/.../arm-gnu-toolchain-13.3.rel1-mingw-w64-i686-arm-none-eabi.zip, I still encounter the issue where GDB takes an extremely long time to read debug symbols (community.arm.com/.../the-latest-arm-none-eabi-gdb-version-12-3-rel1-takes-20-seconds-reading-symbols-from-elf-file). In this forum post (sysprogs.com/.../, someone mentioned that building the source themselves resolves the issue. However, I’m unsure why the official built version from ARM exhibits this problem. Please let me know if additional details are required, and when a fix might be available?
I am sorry that GDB is still taking a long time to read debug symbols. In the latest release we have ensured that GDB is not a debug build, and the binary size of arm-none-eabi-gdb.exe has reduced to 11MB.
We will investigate why reading symbols could take a long time. Are you able to provide a reference ELF file, or provide the steps to generate the ELF file you have?
Kind Regards,
Hi vvinayag , Due to company policies, I am unable to share the ELF file directly on the community forum. Is there a way I can share the file with you privately?
Hello,
Are you able to open a Support Case online and upload the file to that support case?
Any files shared via that support case are only visible to you and to Arm.
Open a Support Case