• State Suggested Answer
  • Locked Locked
  • Replies 11 replies
  • Answers 1 answer
  • Subscribers 22 subscribers
  • Views 7201 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

The arm-none-eabi-gdb.exe binary in version 12.3.rel1 is a debug build.

david_oz

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

Parents
  • 0 in reply to vvinayag

    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

    David

Reply
  • 0 in reply to vvinayag

    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

    David

Children