> Yes, so, that's yet another missing info. Which ARM? RaspberyPi, > although popular, is a very old and somewhat deprecated architecture > (ARMv6). Most people work on ARMv7 and ARMv8 nowadays, so if you can't > reproduce the bugs on those, you'll have a hard time finding people to > help you.> Also, Clang 3.6 is not that old, but we don't really provide > maintenance to non-trunk versions of the compiler, so if you want a > bug looked into, you need to reproduce it in trunk. If you can't, than > the problem is fixed, and you either wait for the new release to come > out, or build your own from trunk.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. 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. 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.> I'll update the bug with some more info, but you need to reproduce it > in trunk and in a hardware that I have access to. RPI is just not > relevant enough for me, that I don't even have one. Perhaps I should > buy one...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. Ben. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150729/3c7c4e91/attachment.html>
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
> 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...I certainly understand the issue in using PathScale's libunwind, but the lack of unw_get_save_loc is somewhat problematic and means that it is preferable to use the other libunwind within coreclr. I do think I tried to use the LLVM libunwind however with my repro, as a static library, and got the same behaviour with both GCC and Clang (certainly with the full coreclr I tried and had the same issue), so again your crash seems strange, have you tried with LLVMs libunwind with a static library? There was some further issue that prompted me to use that instead of a shared library, but this was over a week ago so sorry for forgetting exactly what it is I tried. I do wish there was some better way to build code for the platform, but short of spending more money than I can really afford for an open source project, I am somewhat stuck for the time being, so apologies for not trying on trunk as I said. Ben. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150729/f5e31c9d/attachment.html>