This should fix PR22384
Diff Detail
Event Timeline
Just checked with -mfpu=vfp3-d16... seems the integrated assembler is still throwing a hissy fit: https://gist.github.com/jroelofs/cecb20b150f5050e6efc Need to fix that too before this patch will work.
Unwind/CMakeLists.txt | ||
---|---|---|
25 ↗ | (On Diff #19047) | It would be nice to split these on architecture boundary and keep the variants in a single file. Something like: UnwindRegistersRestore-${ARCH}.S UnwindRegistersSave-${ARCH}.S Might be nice to do that for the current save/restore file as a setup change. |
46 ↗ | (On Diff #19047) | I think you didn't mean for this to be part of the change. |
Unwind/UnwindRegistersRestore_restoreCoreAndJumpTo.S | ||
14 ↗ | (On Diff #19047) | Since we effectively never assembly this file in the __APPLE__ case anyways, why not change the build system to only assembly this file if APPLE (and similar through out which won't be needed if we do the single file per arch). |
16 ↗ | (On Diff #19047) | Why not make this more explicit: #if defined(__ARM_ARCH_ISA_THUMB) .thumb #elif defined(__ARM_ARCH_ISA_ARM) .arm #else #error unsupported ARM ISA #endif And similar through out which won't be needed if we do the single file per arch. |
Unwind/CMakeLists.txt | ||
---|---|---|
25 ↗ | (On Diff #19047) | I split them per-function so that there was no possible way a .fpu directive accidentally applied to something it shouldn't. If we could push & pop fpu states, I'd be less worried about it. |
46 ↗ | (On Diff #19047) | oops, yeah, I didn't. |
Unwind/UnwindRegistersRestore_restoreCoreAndJumpTo.S | ||
14 ↗ | (On Diff #19047) | The "right" fix is to use the defines which say whether unwind is sjlj on apple or not. Spewing that assumption around in the form of __APPLE__ probably isn't right, agreed. |
16 ↗ | (On Diff #19047) | sounds reasonable to me. |
Unwind/CMakeLists.txt | ||
---|---|---|
25 ↗ | (On Diff #19047) | In my local patch, I separated by arch, too and left the newer fpus for the last. Push/pop support may come in this year, but that will mean we'll need ifdefs for gcc compiling it... I see what you're worrying about, but these functions will never matter, because the .fpu is only to let the assembler compile that, not to make it run on a hardware that doesn't have vfp. I personally think one same per arch would be best... |
I ditched the idea of separating these all by funcion... that leads to a lot of churn. Instead, now I've added all the right .fpu directives to each function.
I didn't do anything different with the iwwmx functions yet because the integrated assembler refuses to build them on -march=armv6-m (even with .march armv5t ; .arm). It should however take care of PR22384.
I've tested this on my baremetal setup with clang as the compiler, and it seems to be fine. I don't have a convenient way of testing it with gcc/binutils, so it'd be useful if one of you could double check me on that.
From my side, yes. I guess it can't be much more broken that already is, so go for it.
cheers,
--renato