[LLVMdev] ARM unwinding bug (original) (raw)

Renato Golin renato.golin at linaro.org
Wed Jul 29 13:58:09 PDT 2015

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! :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. 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

More information about the llvm-dev mailing list