6
votes

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);
2
That sounds like "difference between my small program and my operating system"...deviantfan
@deviantfan: Sound more like "Can I use all the "normal" features of C/C++ that I'm used to for firmware (bare-metal) development?" After reading this article here: state-machine.com/arm/Building_bare-metal_ARM_with_GNU.pdf I noticed some limitations of bare-metal C/C++. Are there any more (and differences also)? :)Liviu Gheorghisan
For real bare metal, you need to write a portability layer for newlib. On Gnu Linux, either eglibc or glibc is used. Basically, your question is what is the difference. There are 1000s. Do you want to use mmap()? Etc. The binary/compiler differences don't matter (mostly). It is the 'C' libraries that are completely different. File I/O?artless noise

2 Answers

3
votes
  • 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.

1
votes

I recently started a little project to use a Linux standard C library in a bare-metal environment. I've been describing it on my blog: http://ellcc.org/blog/?page_id=289 Basically what I've done is set up a way to handle Linux system calls so that by implementing simplified versions of certain system calls I can use functions from the standard library. For example, the current state for the ARM implements simplified versions of read(), readv(), write(), writev() and brk(). This allows me to use printf(), fgets(), and malloc() unchanged.

I'm my case, I use the same compiler for targeting Linux and bare-metal. Since it is clang/LLVM based, I can also use the same compiler to target other processors. I'm working on a bare-metal example for the Mips right now.

So I guess the answer is that there doesn't have to be any difference.