similar to: [LLVMdev] ARM unwinding bug

> 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

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,

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

> 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

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

On 29 July 2015 at 23:11, Ben Pye <ben at curlybracket.co.uk> wrote: > 4.8.4, again packaged from Ubuntu 14.04 LTS, not sure if they include any > patches that'd change this behaviour. This should be similar to 4.8.2 that I have, so no worries there. cheers, --renato

Hi Ben, I am aware of the bug. I have downloaded the test case and look around few days ago. However, I am still trying to figure out the situation. Thus, I have no further comments at the moment. BTW, as an amateur LLVM developer, I am fixing the issues with my spare time, thus I have to prioritize the tasks (3.7 release gets much higher priority currently) and sorry for not being

On 29 July 2015 at 22:23, Mason Wheeler <masonwheeler at yahoo.com> wrote: > That would be Ben. :) We'll get there, eventually... :) > Meh. It's more of a "if you build it, they will come" thing. We haven't > finished building it yet, but when we do, they *will* come! :D Thought so. Ben will have to learn a lot about unwinding, then... :D > Genuine

Hi all, I'm working on the CoreCLR project, coordinating a community effort to produce an Android port of Microsoft's open-source version of the CLR.  A major part of that is getting everything to run on the ARM32 architecture, which is by far the most common CPU for Android devices. A couple weeks ago, Ben Pye, a developer working on the ARM32 stuff, found and reported a bug related to

On 29 July 2015 at 16:53, Mason Wheeler <masonwheeler at yahoo.com> wrote: > A couple weeks ago, Ben Pye, a developer working on the ARM32 stuff, found > and reported a bug related to incorrect generation of stack unwinding info. > ( https://llvm.org/bugs/show_bug.cgi?id=24146 ) Apparently it only occurs > under a highly specific set of circumstances, which might look like a

> From: Renato Golin <renato.golin at linaro.org> > > On 29 July 2015 at 20:14, Mason Wheeler <masonwheeler at yahoo.com> wrote: > > Well, yes, an unwinding expert *was* who I was really hoping to hear from. But > > if I understand correctly, you're saying that rather than seeing the values Ben > > reported, the sample code crashes on you on both

> From: Renato Golin <renato.golin at linaro.org> > > > On 29 July 2015 at 16:53, Mason Wheeler <masonwheeler at yahoo.com> wrote: > > A couple weeks ago, Ben Pye, a developer working on the ARM32 stuff, found > > and reported a bug related to incorrect generation of stack unwinding info. > > ( https://llvm.org/bugs/show_bug.cgi?id=24146 ) Apparently it

> On 18 Nov 2019, at 19:55, Peter Smith <peter.smith at linaro.org> wrote: > > On Mon, 18 Nov 2019 at 15:23, Sergej Jaskiewicz <jaskiewiczs at icloud.com <mailto:jaskiewiczs at icloud.com>> wrote: >> >> Hi Peter, >> >> Thanks for your response. >> >> On 18 Nov 2019, at 17:44, Peter Smith <peter.smith at linaro.org> wrote:

Hi Peter, Thanks for your response. > On 18 Nov 2019, at 17:44, Peter Smith <peter.smith at linaro.org> wrote: > > On Mon, 18 Nov 2019 at 12:32, Sergej Jaskiewicz via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> There’s this bug: https://bugs.llvm.org/show_bug.cgi?id=38468

> On 18 Nov 2019, at 22:11, Peter Smith <peter.smith at linaro.org> wrote: > > On Mon, 18 Nov 2019 at 17:06, Sergej Jaskiewicz <jaskiewiczs at icloud.com <mailto:jaskiewiczs at icloud.com>> wrote: >> >> >> >> On 18 Nov 2019, at 19:55, Peter Smith <peter.smith at linaro.org> wrote: >> >> On Mon, 18 Nov 2019 at 15:23, Sergej

On 29 July 2015 at 20:14, Mason Wheeler <masonwheeler at yahoo.com> wrote: > Well, yes, an unwinding expert *was* who I was really hoping to hear from. But > if I understand correctly, you're saying that rather than seeing the values Ben > reported, the sample code crashes on you on both compilers? I do notice that > you're using different versions of both compilers

Although this has been discussed in the past, I think that given a few conversations, it seems that it unfortunately needs to be brought up again. There seems to be some disagreement over the ideal location of the unwinder (libunwind). Currently, libunwind resides in a subdirectory of libc++abi. There seems to be some desire from multiple parties that it be moved into compiler-rt or a separate

On 1/31/15 5:36 AM, Renato Golin wrote: > On 31 Jan 2015, at 03:02, Dan Albert <danalbert at google.com> wrote: >> Talked it over with Saleem on IRC, and I've come around to thinking libunwind is a better default for --rtlib=compiler-rt. Reason being that --rtlib=compiler-rt means libgcc probably isn't even available. > > It's not just that, it's about making

On 31 Jan 2015, at 03:02, Dan Albert <danalbert at google.com> wrote: > Talked it over with Saleem on IRC, and I've come around to thinking libunwind is a better default for --rtlib=compiler-rt. Reason being that --rtlib=compiler-rt means libgcc probably isn't even available. It's not just that, it's about making it self-contained. In a system with both gcc and llvm

Hi all, I'm debugging a crash in the guts of libunwind that started occuring when I changed the ASan runtime to use _Unwind_Backtrace() on OSX to report errors. The crash happens for every test case that has an ASan report in it, so I'm suspecting something's wrong with the unwind info generated by the Xcode Clang, which I'm using to build my Clang and the ASan runtime library