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,