On 08/03/2017 11:03 AM, Florian Weimer wrote: > * Jeff Law: > >>> If speed is not a concern, but reliability is, call fork (the system >>> call, not glibc's wrapper which calls fork handlers) and do the work >>> in a single-threaded copy of the process. There, you can set up >>> signal handlers as you see fit, and the VM layout won't change >>> unexpectedly. > >> Speed is one of the concerns. > > I thought this was debugging-only, optional unwinder behavior. My understanding was this was in the EH path as well. If it's outside the EH path, then I don't care about the cost of msync and the like :-)
> >> Essentially we're pondering an efficient >> mechanism to know if a given code address is valid so that we know if we >> should even try to unwind through a particular stack frame. > > Efficient code address validation is possible using data structures > maintained by ld.so. If those data structures are mostly read-only, > they cannot be corrupted, so pointers and offsets in them don't have > to be validated before derefencing them. Understood. > > But the main problem is the frame pointer chain, and the current lack > of registration for stacks. The program can just malloc some area, > switch the SP, and start running from there. Some libraries do > exactly that. And without knowledge of the bottom address of the > stack, it is impossible to verify that the frame pointer chain goes > somewhere off the stack. Yea. > >> One could probably claim that in the EH path a call to msync shouldn't >> be a concern. I'm skeptical these days, but could be convinced that >> it's tolerable. > > Quite a few applications are sensitive to EH performance. The current > freshness check for the cache is very inefficient, which is a > significant problem for some users. If we can push out the flag check > the top level (essentially compiling the unwinder twice, with and > without checking), I don't think this would cause significant > additional performance issues. Yea. I went back and reviewed the internal BZ. It's actually just the print-a-backtrace thing rather than EH unwinding. SO yea, if the print-a-backtrace path and EH path both use bits, we could just compile them twice, once with checking once without respectively. Jeff