On Fri, 25 Mar 2016 07:37:25 +0100, Albert ARIBAUD albert.u.boot@aribaud.net wrote:
Hello Tom,
That way,
U-Boot gets the stable and controlled AEABI support you want;
GCC keeps its somewhat stable but uncontrolled internal "generated code / libgcc" interface;
U-Boot won't interfere with non-aeabi-related stuff in GCC+libgcc, i.e. whatever ibgcc-related but non-AEABI-related changes occur in a GCC release, we won't break them changes in non-AEABI ;
GCC+libgcc won't interfere with AEABI any more, i.e. whatever AEABI breakages happen in a given GCC toolchain will not break U-Boot.
This design works with any ARM toolchain -- which is kind of evident since it separates generic ARM EABI support from specific toolchain support.
Addition: this does not mean we should get rid of the private libgcc support: it can be useful in case of an issue with the non-aeabi part of libgcc.
Amicalement,