libunwind-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Dave Watson
Subject: Re: [Libunwind-devel] libunwind-1.2 released, patch roundup for 1.3-rc
Date: Thu, 19 Jan 2017 10:51:00 -0800
User-agent: Mutt/1.6.0 (2016-04-01)

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? 

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]