I downloaded the latest stable toolchain published for Linux x86_64, aarch64: arm-gnu-toolchain-11.3.rel1-x86_64-aarch64-none-linux-gnu.tar.xz
The libraries from this toolchain do not have a build-id which messes with some of our workflows, E.g., we can't do a proper backtrace analysis with tools like Sentry.
To illustrate:
$ file ./arm-gnu-toolchain-11.3.rel1-x86_64-aarch64-none-linux-gnu/aarch64-none-linux-gnu/libc/lib64/libc.so.6./arm-gnu-toolchain-11.3.rel1-x86_64-aarch64-none-linux-gnu/aarch64-none-linux-gnu/libc/lib64/libc.so.6: ELF 64-bit LSB shared object, ARM aarch64, version 1 (GNU/Linux), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, with debug_info, not stripped
Notice how there is no build-id listed there. For contrast, here is the output of the file command for another toolchain which does include build-ids:
$ file ./arm-none-linux-gnueabihf/libc/lib/libc-2.28.so ./arm-none-linux-gnueabihf/libc/lib/libc-2.28.so: ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, BuildID[sha1]=d6f3fa913c453c25d2c115730ea34f4a04855dd7, for GNU/Linux 4.18.20, with debug_info, not stripped
I'm wondering if it would be possible to publish a new version of gcc 11.3 but with build ids.
Thanks,
Eric.
It looks like adding `--enable-linker-build-id` to both `gcc_stage1_flags` and `gcc_stage2_flags` is enough to enable the build-id on all the libraries. This has been taken from the GCC 10.2 manifest for arm 32 hosted on Linux x86_64.
armkeil.blob.core.windows.net/.../gcc-arm-arm-none-linux-gnueabihf-abe-manifest.txt