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

[Vitaly_Kuzmichev]

From: Vitaly Kuzmichev <address@hidden>

Hi Yichao Yu,

As expected, your patchset regressed libunwind to the state when unw_step()
fails to unwind a function that has [cantunwind] entry in ARM EXTBL and
good DWARF info. Generally, this is because of your modification in
unw_step() (src/arm/Gstep.c) that made arm_exidx_step() to be done first
before dwarf_step().


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

No matter whether Ken Werner was right or not, he was the first who declared
it, his patch was applied to libunwind and did not cause any problems to other
people. When you contradict with any changes done before your work, it is very
important for you to provide any proof that someone (e.g. Ken Werner) was not
completely correct.
That is what I mean.


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

It sounds like there is a bug in DWARF v4 parsing, but instead of
debugging and fixing it, you just added "smart" version of
UNW_ARM_UNWIND_METHOD environment variable.

May be you can not use UNW_ARM_UNWIND_METHOD for some reason, ok.
Neither me can. Some of the functions in our example do not have DWARF info,
but present in ARM EXTBL.


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

You would not, but arm_exidx_step() actually does.


Regards,
Vitaly.