[cfe-dev] compiler-rt non-neon builds are still broken

[Renato Golin]

On 14 December 2014 at 22:21, Jonathan Roelofs
<jonathan at codesourcery.com> wrote:
> That's an interesting point. Really we should split this function in two, so
> the demand-saving logic saves the high regs only when an EHT entry requests
> it. That way you can build an unwinder that will work on both VFPv3-D16
> processors, and ones with D16~D31.

The function is already split in two, one for 0~15 and another for
16~31, but the latter still needs to be compiled successfully on all
arches.

One solution, with macros, is to not even compile for non-NEON
binaries, but people want to compile to VFPv2 and still link the
library on NEON code and work.

I particularly find that kind of programming very lazy, and coping
with the demands of lazy people is impossible when different people
are lazy for different things.


> It'd be nice if we could eliminate those preprocessor checks so you could
> link a -march=armv5t unwinder against an -mfpu=neon binary and have it work.

Would it? I can't see the purpose in this...


> I added the original ones so I could build -march=armv4t, -march=thumbv4t,
> -march=thumbv6-m unwinders, because I couldn't figure out how to get the
> assembler shut up about unsupported coprocessor instructions. Is there a way
> to tell the assembler "yes, I really really know what I'm doing"? If so,
> that would be a much better solution than what we've got now.

There is, by using the .fpu directive, but that's biding for the rest
of the file, so you could end up writing NEON code out of the space
where the .fpu directive was meant for and the compiler will never
find the bug. You'd get a run time bug when running on a machine that
has no NEON.

The alternative, using push/pop like MIPS or PPC, we could make the
FPU change local to that function, but there isn't support for that in
ARM yet. I'm planning to add it in addition to the horribly broken
.fpu directive in the next few months. This will be required for IFUNC
implementations.

The other alternative is to split those functions on a separate file,
that has .fpu NEON, so that we're sure that only when these functions
are called that we actually unwind VFP/NEON registers. Since we
already guarantee that in the library (by only marking the registers
tainted when we *use* them), this should do ok for the time being.

It'd also be a way to compile libc++abi with GCC, as I doubt they will
implement push/pop too soon for ARM...

cheers,
--renato