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

[Yichao Yu]

On Thu, Jan 19, 2017 at 1:51 PM, Dave Watson <address@hidden> wrote:
> On 01/18/17 06:54 PM, Yichao Yu wrote:
>> On Wed, Jan 18, 2017 at 1:13 PM, Dave Watson <address@hidden> wrote:
>> > On 01/13/17 01:22 PM, Yichao Yu wrote:
>> >> 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.
>
> Ah I see.  How about if this was a flag on the address_space object,
> which we could then check for both local and remote unwinding?

That sounds good to me. Unfortunately I'm not that familiar with the
details to come up with a better/non-breaking trick. =(

>
> I think this would break ABI compatibility though.  It is unfortunate
> that most of these APIs don't take a flags argument.