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.
So the simplest way is just not assuming any ABI details if possible and not using CFLAGS that change the default ABI.
Sure, but then you have to build a compiler that defaults to the ABI you want. Note that this anyway doesn't solve the regparm model, and also not the Sparc -mcmodel problem AFAICS.
The "simplest way" to fix it would be first to figure out exactly what is actually wrong, and go from there.
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. 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.
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.
Paul