Re: [Libunwind-devel] libunwind-1.2 released, patch roundup for 1.3-rc

[Yichao Yu]

On Wed, Jan 18, 2017 at 1:13 PM, Dave Watson <address@hidden> wrote:
> On 01/13/17 01:22 PM, Yichao Yu wrote:
>> Fixing instruction pointer offset on ARM (hopefully non-controversial
>> since it's just mirroring x86)
>> https://github.com/JuliaLang/julia/blob/fd1495138b72df4e5e68208e032ac184d330bfca/deps/patches/libunwind-arm-pc-offset.patch
>
> looks good, doesn't apply cleanly, looks like it depends on the exidx patch,
> I'll see if I can rework

Probably since this is a bug that I fixed after the exidx one.

>
>> Accept newer DWARF version: This one is a total hack and even had a
>> typo in it... ;-p. Do you have any plan about doing this more
>> properly?
>> I was told that DWARF 4 didn't add too much new stuff. Is it possible
>> to only complain if a unsupported feature is detected so that we don't
>> need to bump this version too often?
>> https://github.com/JuliaLang/julia/blob/fd1495138b72df4e5e68208e032ac184d330bfca/deps/patches/libunwind-dwarf-ver.patch
>
> We haven't run in to this yet - it looks like the eh_frame versions
> haven't changed, only the debug_info?  Do you have an example I could
> look at where it fails?

I believe this one was causing issue for me only for debug_info
unwinding on ARM. Should be less of an issue if exidx is used first
(and works). The context is LLVM JIT and probably anything that emits
a DWARF4 debug info.

>
>> Prefer EXIDX unwinding on ARM: This one is also a little hack. In my
>> experience the unwind info is more reliable for unwinding than the
>> debug info and since it's used by c++ I think it makes sense to use
>> that method first.
>> https://github.com/JuliaLang/julia/blob/fd1495138b72df4e5e68208e032ac184d330bfca/deps/patches/libunwind-prefer-extbl.patch
>
> I'm not an arm expert, but looks reasonable to me.

The "little hack" part of this is the unwind info lookup. At least on
ARM there are two different unwind info format that we support (debug
info and exidx) and since the lookup function doesn't currently take a
format as input parameter, the lookup can return the wrong one....
This is hacked around for local address space in the patch by adding a
internal function to pass that parameter but it won't work for remote
address space. Ideally the address space callbacks should be updated
to take this into account but I'm not sure what's the best way to do
that and what's the backward compatibility/deprecation policy for
libunwind.

>
>> And yet another patch we carry that might be of general interest.
>> https://github.com/JuliaLang/julia/blob/fd1495138b72df4e5e68208e032ac184d330bfca/deps/patches/libunwind-freebsd-mapper.patch
>
> Someone else mentioned this as well. Applied as
> 09a598a3da5091f4f2cb522a0948d768c63de611, thanks.
>
> Thanks