Hello,
We noticed that build of TF-M for CM33 platform generates ELF file for which architecture is armv3m. Step to reproduce:
1. Build TF-M secure image for CM33 platform with armclang (used 6.19). 2. Use arm-none-eabi-objdump provided with arm-gnu-toolchain-11.3.rel1-mingw-w64-i686-arm-none-eabi to print headers: * arm-none-eabi-objdump -x tfm_s.axf
You will see following output: tfm_s.axf architecture: armv3m, flags 0x00000012: EXEC_P, HAS_SYMS
While fromelf (from armclang) prints following: ========================================================================
** ELF Header Information
File Name: tfm_s.axf
Machine class: ELFCLASS32 (32-bit) Data encoding: ELFDATA2LSB (Little endian) Header version: EV_CURRENT (Current version) Operating System ABI: none ABI Version: 0 File Type: ET_EXEC (Executable) (2) Machine: EM_ARM (ARM)
Image Entry point: 0x16004319 Flags: EF_ARM_HASENTRY + EF_ARM_ABI_FLOAT_HARD (0x05000402)
ARM ELF revision: 5 (ABI version 2)
Is't expected? Because we have problems with debugging images generated by armclang in eclipse with gdb.
Regards, Roman.
Hi,
I think the GNU objdump prints out the build attributes, in a GNU elf file this section looks like this:
readelf -A tests_reg/spe/build2/bin/tfm_s.elf Attribute Section: aeabi File Attributes Tag_CPU_name: "cortex-m85" Tag_CPU_arch: v8.1-M.mainline Tag_CPU_arch_profile: Microcontroller Tag_THUMB_ISA_use: Yes Tag_ABI_PCS_wchar_t: 4 Tag_ABI_FP_denormal: Needed Tag_ABI_FP_exceptions: Needed Tag_ABI_FP_number_model: IEEE 754 Tag_ABI_align_needed: 8-byte Tag_ABI_enum_size: small Tag_CPU_unaligned_access: v6 Tag_DSP_extension: Allowed Tag_PAC_extension: PAC/AUT instructions permitted in the NOP and in the non-NOP space Tag_BTI_extension: BTI instructions permitted in the NOP and in the non-NOP space
If we build with armclang, these attributes are not included in the elf file (no aeabi attributes section, this is an optional/implementation defined section), but included in every object file, so the linker can check the compatibility between each object file (FP, abi, etc). I've checked both GNU and armclang builds, the ELF file headers are the same which contains the arm 32bit architecture information too.
Can I ask what problems are you facing?
You can try using debug build or you can give this armlink option a try: https://developer.arm.com/documentation/101754/0622/armlink-Reference/armlin...
Regards, Dávid
From: Roman.Mazurak--- via TF-M tf-m@lists.trustedfirmware.org Sent: Wednesday, August 14, 2024 12:53 PM To: tf-m@lists.trustedfirmware.org Subject: [TF-M] ARMCLANG generates ELF with armv3m architecture
Hello,
We noticed that build of TF-M for CM33 platform generates ELF file for which architecture is armv3m. Step to reproduce:
1. Build TF-M secure image for CM33 platform with armclang (used 6.19). 2. Use arm-none-eabi-objdump provided with arm-gnu-toolchain-11.3.rel1-mingw-w64-i686-arm-none-eabi to print headers: * arm-none-eabi-objdump -x tfm_s.axf
You will see following output: tfm_s.axf architecture: armv3m, flags 0x00000012: EXEC_P, HAS_SYMS
While fromelf (from armclang) prints following: ========================================================================
** ELF Header Information
File Name: tfm_s.axf
Machine class: ELFCLASS32 (32-bit) Data encoding: ELFDATA2LSB (Little endian) Header version: EV_CURRENT (Current version) Operating System ABI: none ABI Version: 0 File Type: ET_EXEC (Executable) (2) Machine: EM_ARM (ARM)
Image Entry point: 0x16004319 Flags: EF_ARM_HASENTRY + EF_ARM_ABI_FLOAT_HARD (0x05000402)
ARM ELF revision: 5 (ABI version 2)
Is't expected? Because we have problems with debugging images generated by armclang in eclipse with gdb.
Regards, Roman.
tf-m@lists.trustedfirmware.org