On Wed, Aug 2, 2017 at 1:39 PM, Yury Gribov <tetra2005.patc...@gmail.com> wrote: > On 02.08.2017 20:02, Jeff Law wrote: >> >> 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. >> >>> 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. > > > All, > > First of all, thanks for the feedback. This is indeed not a 100% robust > solution, just something to allow tools like Asan to produce more sane > backtraces on crash (currently when stack is corrupted they would crash in > the unwinder without printing at least partial backtrace). >
FWIW, glibc 2.26 is changed to abort as soon as possible when stack is corrupted: https://sourceware.org/bugzilla/show_bug.cgi?id=21752 https://sourceware.org/bugzilla/show_bug.cgi?id=12189 There is very little point to unwind stack when stack is corrupted. -- H.J.
