So until then the GCC folks' answer is: If your code uses compile time options that change the ABI of your compiler, you need to compile a compiler (well, libgcc) with those options, too.
No, that is not the party line.
Huh? If you use ABI changing options then you need libraries that match. This includes libgcc. In rare cases it may be possible to get limited iteroperation, but this is the exception rather than the rule.
Sure, but in that case GCC itself should select a matching multilib, or do whatever else is necessary to make -mregparm useful at all.
See also comment #4 on PR41055.
You can't assume that an object/library (in particular libgcc) compiled for one target environment will work on a different target, even if they nominally use the same ABI.
Sure.
For example in a linux userspace environment the correct way to indicate division by zero may be a raise/kill syscall. Obviously this is completely bogus in a bare metal environment.
Well, in the case at hand, dividing by zero is wrong /per se/, so we should figure out why that happened.
If you want to use the wrong toolchain (e.g. a linux targeted compiler for bare metal applications such as bootloaders or kernels) then you should expect to have to jump though hoops. The hacks required vary by both architecture and compiler version, and range from making sure you never write particular code sequences to providing your own implementation of all the libgcc routines. This is an internal compiler ABI, so the requirements may change without warning.
Building with a powerpc-eabi toolchain should work though, and it doesn't either if I understand correctly.
Segher