Re: [Libunwind-devel] [PATCH] arm: ptrace: Fix order of probing unwind tables

[Yichao Yu]

> 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
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/libunwind-devel