> In your patch libunwind-prefer-extbl.patch you say that ARM EXTBL unwinding > "seems to be more reliable". This contradicts Ken Werner's commit 92327a3 > description where DWARF is called "more powerful than the ARM specific > unwind tables".
I'm only talking about unwinding, as in restoring register values here. I believe both of them should be able to do it so I'm not sure what does "more powerful" means in this context. I can't say anything about debug info unwinding but since the EXTBL is part of the ABI, I believe it must be reliable for doing unwinding if present. In another word, it is as good as it can be as the first unwind format to try because it's easy to tell if the unwinding is accurate. > Do you have any code example demonstrating advantage of using ARM EXTBL > in prior to DWARF? Or your words were rather a guess? It's not a guess, though I also don't have a minimum example to demonstrate that. This is for unwinding of functions dumped to a shared object from a LLVM JIT. We generate DWARF 4 debug info which does not make libunwind too happy and I had to disable a DWARF version check so that could be why the debug info unwinding fails sometimes. It could also be that the debug info generated by LLVM is not accurate. > Unfortunately, I can not say that EXTBL is reliable, it does not provide > function end offset (nor its size), so IP-to-function mapping can not > be precise, so not really reliable. For lookup up IP-to-function mapping, I'll definitely **NOT** use EXTBL. (Though if no debug info is present, the ip range can be used as a fallback). This is precisely the issue I mentioned about specifying the format explicitly. Different format might be better for doing different jobs and the caller usually has a better idea what the fallback order is/interested in multiple format if one format is present but not useful. > > I can try to check your patchset with our code example of unwinding remote > process doing division by zero. I will let you know of results. Would be good to check if the fallback logic works as intended. > > Regards, > Vitaly. > > _______________________________________________ > Libunwind-devel mailing list > Libunwind-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/libunwind-devel _______________________________________________ Libunwind-devel mailing list Libunwind-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/libunwind-devel
