> 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>
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 traction and even get done quicker than trying to debug here a problem in an external library. Even though you want your CoreCLR to work on Android, I assume this will be mainly developed from a Windows IDE, so IDE folks that know a thing or two about unwinding in this list might have a better chance at getting interested and fixing it than command line folks like me.> 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?Hum, no, that was with shared libraries. I'll try with static.> 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.The bug I reported was on the shared version of it, so that might be related to your problem.> 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.What's the GCC version you're using? cheers, --renato
> There are a lot of Windows folks in LLVM, and certainly good support > for it, including on ARM, so maybe that would get more traction and > even get done quicker than trying to debug here a problem in an > external library. Even though you want your CoreCLR to work on > Android, I assume this will be mainly developed from a Windows IDE, so > IDE folks that know a thing or two about unwinding in this list might > have a better chance at getting interested and fixing it than command > line folks like me.My initial focus certainly isn't Android, it's probably the biggest application of an ARM port sure, but currently plain ARMv7 Linux is what I'm targeting. Windows uses it's own unwinder from the OS and so libunwind is cross-plat specific thing. Perhaps it'd be worth trying to get it implemented, I did look and it looked not too difficult, but that was me glancing over the code in a few minutes.> What's the GCC version you're using?4.8.4, again packaged from Ubuntu 14.04 LTS, not sure if they include any patches that'd change this behaviour. Ben. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150729/b80cecc2/attachment.html>