search for: unw_get_save_loc

> 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 is...

On 29 July 2015 at 22:46, Ben Pye <ben at curlybracket.co.uk> wrote: > 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. Or, you could try to persuade people to implement that in LLVM? There are a lot of Windows folks in LLVM, and certainly good support for it, including on ARM, so maybe that would get more tract...

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

> 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 >