On Thu, Jan 19, 2017 at 1:51 PM, Dave Watson <[email protected]> wrote: > On 01/18/17 06:54 PM, Yichao Yu wrote: >> On Wed, Jan 18, 2017 at 1:13 PM, Dave Watson <[email protected]> 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. _______________________________________________ Libunwind-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/libunwind-devel
