On Thu, Aug 03, 2017 at 09:48:47AM -0600, Jeff Law wrote:
> > 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. 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.
>
> 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.
There are many projects that abuse exception handling for normal control
flow and where the EH speed is very important. While the msync calls were
not performed during normal EH or normal backtrace in the posted patch,
just in sections guarded with __builtin_expect on some variable, it still
makes worse RA because the compiler has to store and load all the state it
could have in call clobbered registers across that spot.
Jakub
