Suppose you have a cross-compilation tool-chain that produces binaries for the ARM architecture.
Your tool-chain is like this (running on a X86_64 machine with Linux):
- arm-linux-gnueabi-gcc.exe : for cross-compilation for Linux, running on ARM.
- arm-gcc.exe : for bare-metal cross-compilation targeting ARM.
... and the plethora of other tools for cross-compilation on ARM.
Points that I'm interested in are:
- (E)ABI differences between binaries (if any)
- limitations in case of bare-metal (like dynamic memory allocations, usage of static constructors in case of C++, threading models, etc)
- binary-level differences between the 2 cases in terms of information specific to each of them (like debug info support, etc);
- ABI differences is up to how you invoke the compiler, for example GCC has
-mabi
and that can be one of ‘apcs-gnu’, ‘atpcs’, ‘aapcs’, ‘aapcs-linux’ and ‘iwmmxt’.
- On bare-metal limitations for various runtime features exists because someone hasn't provided them. Be them initializing zero allocated areas or providing C++ features. If you can supply them, they will work.
- Binary level differences is also up to how you invoke compiler.
You can check GCC ARM options online.