[LLVMdev] ARM unwinding bug
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