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

[Jonathan Roelofs]

On 12/15/14 12:54 PM, Renato Golin wrote:
> 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...
Think about it from the perspective of a toolchain provider that wants to ship a 
multilib that will work on chips with and without neon registers. The particular 
example I gave may be bogus, but I think the principle stands.
>
>
>> 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.
That sounds like the right solution.
>
> 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
>

-- 
Jon Roelofs
jonathan at codesourcery.com
CodeSourcery / Mentor Embedded