[LLVMdev] ARM unwinding bug

[Renato Golin]

On 29 July 2015 at 22:20, Ben Pye <ben at curlybracket.co.uk> wrote:
> Not sure if you got the other message, I think I managed to split the topic
> as I wasn't subscribed to receive the previous message. This error has been
> on the Raspberry Pi 2, so that's a Cortex A7 I believe, certainly ARMv7.

Excellent!


> I
> haven't yet built trunk as on the device I run out of memory and do not have
> enough disk space to allocate a large enough swap space, and it's too slow
> to wait for it to fail, so I'd have to cross compile which is not something
> I have yet attempted, unfortunately LLVM/Clang only provides AMD64 packages
> for nightly builds, despite building it for a vast matrix.

Exactly. It's just not good enough yet. Even gold has problems with
the huge debug objects... :(


> I don't believe this to be an unwinder bug, but a generation bug (of the
> unwind information). I do find the crash you experience curious, but it's
> not something I have had occur here. Unfortunately I can't say I have great
> experience with the ARM unwind information, but really got to that
> conclusion by eliminating libunwind as GCC does generate unwind information
> that results in PC being restored.

Yeah, that's where unwinding gets tough...

Unwinding the stack, either for debug or profile purposes, is composed
of two independent parts: the compiler (generating
prologues/epilogues, as well as unwind tables) and the library (doing
the actual unwinding, using the table as reference and relying on the
pushes and pops to be correct).

If you include C++ exception handling, there's a third actor in play:
user code, which needs to get throw/catch in the right places, and
more libraries to implement those builtins, and more compiler work to
produce cleanups, landing pads and other stuff.

So, it's not because libunwind (from pathscale) works with GCC that
it's not a bug in libunwind. It's entirely possible that GCC is being
lenient where it shouldn't, or that pathscale's libunwind is abusing
of some GCC bug, there doesn't exist in Clang. We have seen those by
the bucket loads in the kernel, android and other large projects.


> I think you could reproduce this on scaleway.io 's hosted service, which
> offer a free month, but I'd be happy to provide access to something if
> that's what it took. As I said though, RPi 2 should be a pretty vanilla
> Cortex A7 core.

Right, so that's the other missing piece of information. One that you
are extremely forgiven for not realising... :)

libunwind is the name of at least 3 different libraries: LLVM's,
Pathscale's and SourceForge's. It's possible that the last two are the
same, or have the same root, but LLVM's is a brand new one, and the
idea to name it "libunwind" did NOT get my vote. Alas, it is what it
is now... :)

You should also realise that using another libunwind makes matters
more complex, because now it's far less likely that the LLVM's
libunwind folks will be interested in fixing that...

cheers,
--renato