Question: I have a product which bootloader and application are compiled using a compiler (gnuarm GCC 4.1.1) that generates "arm-elf".

The bootloader and application are segregated in different FLASH memory areas in the linker script.

The application has a feature that enables it to call the bootloader (as a simple c-function with 2 parameters).

I need to be able to upgrade existing products around the world, and I can safely do this using always the same compiler.

Now I'd like to be able to compile this product application using a new GCC version that outputs arm-eabi.

Everything will be fine for new products, where both application and bootloader are compiled using the same toolchain, but what happens with existing products?
If I flash a new application, compiled with GCC 4.6.x and arm-none-eabi, will my application still be able to call the bootloader function from the old arm-elf bootloader?

---

Furthermore, not directly related to the above question, can I mix object files compiled with arm-elf into a binary compiled with arm-eabi?

---

EDIT:

I think is good to make clear I am building for a bare metal ARM7, if it makes any difference...

Answer: 
No. An ABI is the magic that makes binaries compatible. The Application Binary Interface determines various conventions on how to communicate with other libraries/applications. For example, an ABI will define calling convention, which makes implicit assumptions about things like which registers are used for passing arguments to C functions, and how to deal with excess arguments.

I don't know the exact differences between EABI and ABI, but you can find some of them by reading up on EABI. [Debian's page](http://wiki.debian.org/ArmEabiPort) mentions the syscall convention is different, along with some alignment changes.

Given the above, of course, you cannot mix arm-elf and arm-eabi objects.

The above answer is given on the assumption that you talk to the bootloader code in your main application. Given that the interface may be very simple (just a function call with two parameters), it's possible that it might work. It'd be an interesting experiment to try. However, it is not \*\* guaranteed\*\* to work.

Please keep in mind you do not have to use EABI. You can generate an arm-elf toolchain with gcc 4.6 just as well as with older versions. Since you're using a binary toolchain on windows, you may have more of a challenge. I'd suggest investigating [crosstool-ng](http://crosstool-ng.org/), which works quite well on Linux, and may work okay on cygwin to build the appropriate toolchain.
I *Think* that this will be OK. I did a migration something like this myself, from what I remember I only ran into a problem to do with handling division.

[This is the best info I can find about the differences](http://wiki.debian.org/ArmEabiPort), it suggests that if you don't have struct alignment issues, you may be OK.