> 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 only occurs > > under a highly specific set of circumstances, which might look like a minor > > corner case, except that that just happens to be exactly the configuration > > needed to build CoreCLR for ARM32. > > Hi Mason, > > I did see the bug, but I have to say that, as priorities go, that's > way too low on my list to go past the initial look. > > I compiled your test on a Cortex-A15 / Linux with Clang-3.8 (trunk) > and GCC 4.8.2 and on both occasions, the program crashes on > _Unwind_VRS_Pop() while stepping. > > I, then, left it for the unwinding experts, which I'm not.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 than he was, which may or may not be relevant. What hardware was this on? Ben said he's been using a Raspberry Pi, not sure which model. I'll ask him to weigh in on here with additional details. Unfortunately he's in a different time zone and probably asleep at the moment, so it might be a while. In the meantime, can you provide details of the crash you're observing? Just saying "it crashes on FooBarBaz," which is not even mentioned anywhere in the source of the test case, doesn't provide much useful information. At the risk of trotting out one of the oldest cliches in the book, this works (or at least breaks as described) on our end! :P> > This is a blocking problem for us, and I > > was just wondering how things are coming on it? Has anyone been looking > > into this, who might be able to provide some sort of estimate as to what's > > going on and when we might expect to see a fix? > > I think you're looking at it from the wrong angle... > > I seriously doubt that anyone besides your group will care much about> CLR on Android.Just off the top of my head, everyone using Xamarin and a significant fraction of the Unity3D community will care about this. Plus a non-trivial percentage of approximately 20 million existing .NET devs, the ones who would like to produce mobile apps if the existing "solutions" weren't either horribly expensive or barely workable and low-quality. I can definitely say this is not something that no one will care about!> So, unless this bug affects other people, not much will progress without > your help.Very well. What help do you need? I'd be happy to provide any assistance necessary.> Posting a bug on bugzilla is the first step. Having a source file,> some command lines to try out and some expected results is the second. > Adding the right people (Anton, me, Logan) is the third step. > Excellent. But it doesn't stop there. > > You have to continue to investigate, step through, disassemble, check > the unwind sources, give us some ideas. The closer you get to a > recognisably obvious problem, the easier it will be to get someone > else's attention. > > We all got an email from that bug (because you CC us), and we probably > all looked at it and thought: "hum, that's weird. Let me try". Because > that's so far off our current priorities, when it failed at the very> step, you think, "I'll wait until the OP provides more info".Yeah, I wondered if it might not be something like that. We were all waiting to hear back from you, because from our perspective we've provided a complete, reproducible test case, and if anything more is needed, we'd expect someone to respond to the Bugzilla post asking about it. Good thing I checked, then! :)> This> would go a long way to motivate people to reply, even with a simple > "have you tried this?". As it stands, I don't even know what to say, > honestly.What I would say, in your position, is I'd post a response to the Bugzilla entry detailing my problems so that the original author would see it and be able to improve the bug report.> For example, I also found a bug in the unwinder: > > https://llvm.org/bugs/show_bug.cgi?id=24273 > > I did more or less what you did, put some info on how to reproduce. > But I'm not expecting anyone to look at it. That's for me to keep > there, in case I have some more time to investigate it. If either > Logan or Anton had a look, that'd be awesome! But I don't expect them > to. If I want that one to progress, I'll have to do a lot more than> what I did.Forgive my saying so, but that seems like a bizarre attitude, as you've already admitted that you don't know much about unwinding. Isn't that the entire point of specialization? Having people who have their own area that they know well and become expert in, all working together, is what lifted mankind out of the subsistence agrarian lifestyle and enabled us to build our way up to the modern age. If something went wrong with my car, I certainly wouldn't attempt to diagnose it myself and figure out the root cause so the guys at the dealership would have an easier job of it, because tracking down the problem when I lack the training, experience and tools to do so would waste a great deal of my time on something that the dealership's experts could presumably figure out far more quickly and accurately than I could. Everyone can agree that this is perfectly reasonable when talking about cars, so why, when it comes to code, does the exact opposite philosophy tend to appear? Mason
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 than he was, which may or may > not be relevant. What hardware was this on? Ben said he's been using a > Raspberry Pi, not sure which model.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. It goes back to the priorities argument... There's no support contracts in open source software. :)> I'll ask him to weigh in on here with additional details. Unfortunately he's > in a different time zone and probably asleep at the moment, so it might be a > while.That's ok. We're all in a different time zone, anyway. :)> In the meantime, can you provide details of the crash you're observing? > Just saying "it crashes on FooBarBaz," which is not even mentioned anywhere in > the source of the test case, doesn't provide much useful information. At the > risk of trotting out one of the oldest cliches in the book, this works (or at > least breaks as described) on our end! :PThat's the catch. I know that unw_step() calls _Unwind_VRS_Pop() while loading the stack frame, because you need the context of that frame, so for me that looked like a good thing to say. If you report a bug in the unwinder, I expect you to either understand a bit about it (like me), or to have someone at your disposal that do. I cannot dig the problem for you, first because I don't have your setup or your hardware, but also because my priorities are not aligned to solving issues with the unwinder on .NET. You can't expect people to have the same environment as you have, or even to share your enthusiasm with the things you're trying to build.> Just off the top of my head, everyone using Xamarin and a significant fraction > of the Unity3D community will care about this. Plus a non-trivial percentage > of approximately 20 million existing .NET devs, the ones who would like to > produce mobile apps if the existing "solutions" weren't either horribly expensive > or barely workable and low-quality. I can definitely say this is not something > that no one will care about!I don't know what Xamarin is, but if Unity3D and .NET developers are concerned, I'm sure they could lend us a hand to fix this problem. If a company is really interested in getting that to work, they could even pay a developer to fix this. If out of those 20 million developers, not a single one can help you, then maybe it's not that important for them...> Yeah, I wondered if it might not be something like that. We were all waiting > to hear back from you, because from our perspective we've provided a complete, > reproducible test case, and if anything more is needed, we'd expect > someone to respond to the Bugzilla post asking about it. Good thing I > checked, then! :)I understand, and for that, I apologise. Even though that wasn't anywhere near my priorities, I did have a look, so I should have said it failed for me, asking for more details. 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...> Forgive my saying so, but that seems like a bizarre attitude, as you've > already admitted that you don't know much about unwinding. Isn't that the > entire point of specialization?I have worked with unwinding some years ago, but the knowledge is very specific and I forgot most of it. That's why I still have a look around, but I'm no specialist, by far. Logan and Anton are the guys you're looking for. Would you rather I didn't look at it, or replied to your email, if I'm not the specialist? (this is a genuine question)> If something went wrong with my car, I certainly wouldn't attempt to diagnose > it myself and figure out the root cause so the guys at the dealership would > have an easier job of it, because tracking down the problem when I lack the > training, experience and tools to do so would waste a great deal of my time > on something that the dealership's experts could presumably figure out far > more quickly and accurately than I could. Everyone can agree that this is > perfectly reasonable when talking about cars, so why, when it comes to code, > does the exact opposite philosophy tend to appear?Simply because you're paying the dealership to fix your car. That's their job, to fix *your* car. If, on the other hand, you found a blueprint in a magazine, say "Popular Mechanics" to build a Demoiselle[1], and you procured the parts, built it on your barn, and the thing wouldn't fly, would you expect Dumont to fix it for you? For free? In open source, the only thing that works is effort. If you put the effort to learn the technology I care about, I'll put the effort to help you find the solution. I'd never find it for you, especially if you expect me to do it on my own. If you don't care about the technology and just want the bloody thing to work, then you're free to hire a developer to do it for you. That's what most companies do. Mine included. :) There is no such thing as free lunch. But if you want to share your lunch with me, and if I would like to have half of your sandwich, I'd be glad to give half of mine to you. Makes sense? cheers, --renato [1] https://en.wikipedia.org/wiki/Santos-Dumont_Demoiselle
> 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>
> 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 compilers? I do notice that > > you're using different versions of both compilers than he was, which may or may > > not be relevant. What hardware was this on? Ben said he's been using a > > Raspberry Pi, not sure which model. > > 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.I asked Ben, and he says he's using the Raspberry Pi 2 (ARM 7) model.> 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.OK, we'll try that.> > In the meantime, can you provide details of the crash you're observing? > > Just saying "it crashes on FooBarBaz," which is not even mentioned anywhere in > > the source of the test case, doesn't provide much useful information. At the > > risk of trotting out one of the oldest cliches in the book, this works (or at > > least breaks as described) on our end! :P > > That's the catch. > > I know that unw_step() calls _Unwind_VRS_Pop() while loading the stack > frame, because you need the context of that frame, so for me that > looked like a good thing to say. If you report a bug in the unwinder, > I expect you to either understand a bit about it (like me), or to have> someone at your disposal that do.That would be Ben. :)> If out of those 20 million developers, not a single one can help you,> then maybe it's not that important for them...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> > Forgive my saying so, but that seems like a bizarre attitude, as you've > > already admitted that you don't know much about unwinding. Isn't that the > > entire point of specialization? > > I have worked with unwinding some years ago, but the knowledge is very > specific and I forgot most of it. That's why I still have a look > around, but I'm no specialist, by far. Logan and Anton are the guys > you're looking for.Awesome. I hope one of them sees this then. :)> Would you rather I didn't look at it, or replied to your email, if I'm > not the specialist? (this is a genuine question)Genuine answer: If you do know something, I'd rather you reply with that and contribute what you can, even if you don't know everything. Every little contribution can be helpful.> There is no such thing as free lunch. But if you want to share your > lunch with me, and if I would like to have half of your sandwich, I'd > be glad to give half of mine to you. > > Makes sense?Makes perfect sense to me. Share with me a fix for this bug, and in return I'll happily share with you my ARM32 CLR, and the Android support, once we get them working. :D Mason