Appreciate any feedback to the early access core software and we're all ears on feature requests. Let us know if you encounter any sub-optimal output and we'll fix it, hope some of you guys find this useful and live a more manageable life :-P
As the author of a crash reporting framework, this is the first time I've seen execution speed of a frame unwinder so strongly touted :-)
Without code, I can't make much of a comment otherwise, although I'm certainly interested to see your patches to libunwind once it's upstreamed.
One of the reasons we didn't use libunwind in PLCrashReporter (and instead, wrote our own DWARF unwinding code) was the relative difficulty we saw in porting libunwind to Mach-O and the Mach thread/VM APIs, as compared to the cost in porting our relatively platform-neutral code to other platforms.
The analysis side is super interesting too, and it'll be great to see more of what emerges from your work. I can't think of much that's been published on that front other than Microsoft's overview of their Windows Error Reporting heuristics:
Come on now, you're the author of the crash reporting framework for mobile :-P Big fan of PLCrashReporter and your work with it, the mobile error reporting market has much to thank for it. I've looked at some of your code and definitely appreciated the cleanliness of it.
On performance:
The execution speed being touted here is not that of a frame unwinder and we're building something that goes beyond this in scope. Our core client-side technology is a debugging library optimized for tracing. Unwinding was only a bottleneck for some specific ridiculous workloads and usually the bottleneck is elsewhere if program structure is being parsed (and this is where the general purpose debuggers end up taking up so much time).
There are applications out there that are so complex that traditional debuggers are simply infeasible (imagine 30 minute+ backtraces). However, what we're excited about are all those spare cycles we get to make use of...
On libunwind:
Yes. We'll be targeting some exotic platforms, and this is where libunwind definitely helps. It definitely lacks in file format abstractions but we support multiple unwinding backends for this reason, it will be painful but not too painful.
Thanks for the SOSP link, looks interesting. I agree, this is an area that has definitely been neglected by academia.
We're very excited for the first release of our platform and I'll keep you posted on it, your feedback would be great and we think we've come up with very useful technology.
