Can’t we fix this whole problem by having getcontext subtract from the pc to start with, so that nobody ever has to decrement the pc on the first call to unw_step?
Doug > On Mar 29, 2017, at 3:48 PM, Doug Moore <do...@rice.edu> wrote: > > For linux, it’s not using the ip directly to determine is_signal_frame, but > it’s using information from processing dwarf data, which it can only find if > it has the right ip in the first place. > > It seems like the init_cursor caller should be passing an argument to declare > whether this is a signal handler frame or not. I’d expect her to know that. > It’s a lot more reliable that having libunwind try to figure it out. > > Doug > > >> On Mar 29, 2017, at 3:33 PM, Doug Moore <do...@rice.edu> wrote: >> >>> But I think we need to know the IP to detect signal frames? >> >> >> We need to know an IP, yes. It’s not clear that we need the >> decremented-by-1 IP, though. Especially since we’re deciding whether to >> decrement it based on whether it’s in a signal frame or not. >> >> I looked at the x86_64 implementations of unw_is_signal_frame for freebsd >> and linux. >> >> For freebsd, unw_is_signal_frame uses the (unmodified) ip in the cursor >> argument to determine whether this is a signal frame. So, for freebsd, we >> could call unw_is_signal_frame early, passing the cursor we had already, and >> use that to determine whether or not to use ip or ip-1 for searching >> dwarf/eh_frame structures. >> >> For linux, unw_is_signal_frame does not look at the ip; it returns a value >> under the assumption that another function, either tdep_fetch_frame or >> tdep_cache_frame, has already set that value. And tdep_fetch_frame does not >> look at the ip field of the cursor passed to it either. Really, I’m not >> sure yet where the ip gets examined in the linux version of >> unw_is_signal_frame. >> >> Doug >> >> >>> On Mar 29, 2017, at 10:12 AM, Dave Watson <davejwat...@fb.com> wrote: >>> >>> On 03/27/17 05:36 PM, Doug Moore wrote: >>>> It looks like the call to tdep_fetch_frame in fetch_proc_info would >>>> determine whether or not this was a signal frame, and thus whether or not >>>> we needed to use the previous instruction for the lookup. >>>> >>>> Of course, we call tdep_fetch_frame only after we’ve already tried that >>>> lookup. But perhaps some of the work done to identify signal frames could >>>> be moved up a bit, so that a better decision could be made about whether >>>> or not to use the previous instruction. >>>> >>>> Does that make any sense? >>> >>> But I think we need to know the IP to detect signal frames? >>> >>> My thought was that if IP-1 lookup failed, we could try IP lookup, and >>> if it was a signal frame, use that instead (probably with verify=1) >>> >>> !DSPAM:10223,58dbcee539347198113515! >>> >>> >> > _______________________________________________ Libunwind-devel mailing list Libunwind-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/libunwind-devel
