I have a question when doing the binary analysis. For a given ELF file (hello.elf) that has already been identified for the ARM architecture, how can I quickly know if this ELF is for Cortex-A or Cortex-M? More specifically, I'm trying to identify the whole bare-metal images (or RTOS images like FreeRTOS) for the Cortex-M.
From the result of "file hello.elf":
% file hello.elf
hello.elf: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, with debug_info, not stripped
We can only see that this ELF is for ARM.
And from the result of "readelf -h ./hello.elf":
% readelf -h ./hello.elf
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Entry point address: 0xcb5
Start of program headers: 52 (bytes into file)
Start of section headers: 150896 (bytes into file)
Flags: 0x5000200, Version5 EABI, soft-float ABI
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 5
Size of section headers: 40 (bytes)
Number of section headers: 19
Section header string table index: 17
It's also only showing this file is for the ARM architecture.
So are there any other approaches that can quickly identify the target architecture of an ELF file?
Thank you for your time!
Maybe check out the section addresses? Cortex-M has (flash) code usually in 0-1fffffff, with RAM at 2000000-3fffffff or (external) 60000000-9fffffff, while don't most Cortex-A chips typically have all-ram architectures without the explicit "banks" of memory. (OTOH, Cortex-A will also have an MMU can I guess they could put their section starts whereever they want, including at Cortex-M-compatible locations?)
Not sure if this is what you are looking for:
$ readelf -A test.elf
Attribute Section: aeabi
Tag_ABI_FP_number_model: IEEE 754
Tag_ABI_HardFP_use: SP only
Tag_ABI_VFP_args: VFP registers
Thank you for your reply! Yes, that's exactly what I'm looking for. However, this -A argument only works for those bare-mental applications. For the multi-world projects that are compiled into two executables (e.g, FreeRTOSDemo_s.axf, and FreeRTOSDemo_ns.axf), this argument does not give any output.
So do you have any suggestions to identify those executables mentioned above? Thank you for your time!
Interesting. The ELF I showed you was actually generated from an AzureRTOS project. So it is not bare-metal and -A still works.
For your multi-world project which seems to be MDK-based FreeRTOS one, I currently do not have similar setup to play with so am not able to provide further suggestion you need. Will try to look into this later.