[all-commits] [llvm/llvm-project] d3c744: Correctly update isSignalFrame when unwinding the ...

[Sterling-Augustine via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: d3c744313c3cca0c076f031ec71e66ca74b12f2a
      https://github.com/llvm/llvm-project/commit/d3c744313c3cca0c076f031ec71e66ca74b12f2a
  Author: Sterling Augustine <saugustine at google.com>
  Date:   2019-11-07 (Thu, 07 Nov 2019)

  Changed paths:
    M libunwind/src/DwarfInstructions.hpp
    M libunwind/src/UnwindCursor.hpp
    M libunwind/src/UnwindLevel1-gcc-ext.c
    A libunwind/test/signal_frame.pass.cpp

  Log Message:
  -----------
  Correctly update isSignalFrame when unwinding the stack via dwarf.

A "signal frame" is a function or block of code where execution arrives via a signal or interrupt, rather than via a normal call instruction. In fact, a particular instruction is interrupted by the signal and needs to be restarted. Therefore, when the signal handler is complete, execution needs to return to the interrupted instruction, rather than the instruction immediately following the call instruction, as in a normal call.

Stack unwinders need to know this to correctly unwind signal frames. Dwarf handily provides an "S" in the CIE augmentation string to describe this case, and the libunwind API provides various functions to for unwinders to determine it,.

The llvm libunwind implementation correctly sets it's internal variable "isSignalFrame" when initializing an unwind context. However, upon stepping up the stack, the current implementation correctly reads the augmentation string and sets it in the CIE info (which it then discards), libunwind doesn't update it's internal unwind context data structure.

This change fixes that, and provides compatibility with both the canonical libunwind and the libgcc implementation.

Reviewers: jfb

Subscribers: christof, libcxx-commits

Tags: #libc

Differential Revision: https://reviews.llvm.org/D69677