On 08/02/2017 12:47 PM, Jakub Jelinek wrote: > On Wed, Aug 02, 2017 at 12:38:13PM -0600, Jeff Law wrote: >> On 07/17/2017 01:23 AM, Yuri Gribov wrote: >>> I've rebased the previous patch to trunk per Andrew's suggestion. >>> Original patch description/motivation/questions are in >>> https://gcc.gnu.org/ml/gcc-patches/2017-06/msg01869.html >> Is his stuff used for exception handling? If so, doesn't that make the >> performance a significant concern (ie that msync call?) > > For the performance issue, I wonder if it wouldn't be better to just > compile the unwinder twice, basically include everything needed for the > verification backtrace in a single *.c file with special defines, and > not export anything from that *.o file except the single entrypoint. > That would also handle the ABI problems. Yea.
Given that the vast majority of the time the addresses are valid, I wonder if we could take advantage of that property to keep the overhead lower in the most common cases. Something like setup a signal handler when we first start unwinding that flags the error and tear it down when we're done unwinding? Obviously we can't do setup/tear down each time for each address. Anyway, just thinking outloud here... > > For the concurrent calls of other threads unmapping stacks of running > threads (that is where most of the verification goes against), I'm afraid > that is simply non-solveable, even if you don't cache anything, it will > still be racy. Absolutely -- I think solving this stuff 100% reliably without races isn't possible. I think the question is can we make this significantly better. Jeff
