[libunwind] Add configuration to disable sigreturn frame check

[smeenai]

Summary

https://reviews.llvm.org/D90898 added a check to libunwind for a
sigreturn frame on Linux aarch64. The check operates by reading from
memory, and the patch notes the possibility of segfaults occurring as a
result. We're observing such segfaults internally (possibly due to
invalid unwind info in libraries which are out of our control). Add a
configuration option to omit this sigreturn check, for users who are
willing to give up the ability to unwind through sigreturn frames in
return for avoiding potential segfaults.

The alternative would be to check memory before attempting to access it,
and that's the approach taken by nongnu libunwind [1]. There were
concerns raised on the original review about the syscalls needed for
this (e.g. pipe) not being available because of OS security
configurations, and there's also the overhead incurred by the memory
checking, so I'm inclined to go with the current approach for now.

[1] https://github.com/libunwind/libunwind/blob/e07b43c02d5cf1ea060c018fdf2e2ad34b7c7d80/src/aarch64/Ginit.c#L187

[danielkiss]

Thanks for the patch.

libunwind/CMakeLists.txt

91

Please an option here like this.

[smeenai]

Add CMake option

[smeenai]

Use suggested wording for CMake option, which I missed earlier

[MaskRay]

We're observing such segfaults internally (possibly due to invalid unwind info in libraries which are out of our control).

It would be interesting to know whether Clang does anything wrong here. @chill is improving such stuff.

(Without signal trampoline frame recognization, it could be bad for crash reporting: https://maskray.me/blog/2022-04-10-unwinding-through-signal-handler#glibc-aarch64 )

[smeenai]

In D123428#3443648, @MaskRay wrote:

We're observing such segfaults internally (possibly due to invalid unwind info in libraries which are out of our control).

It would be interesting to know whether Clang does anything wrong here. @chill is improving such stuff.

(Without signal trampoline frame recognization, it could be bad for crash reporting: https://maskray.me/blog/2022-04-10-unwinding-through-signal-handler#glibc-aarch64 )

Unfortunately, we're only observing this crash on a small subset of devices in the wild, and I haven't had any luck reproducing it locally, so I can't say whether Clang is producing invalid unwind info or there's some system libraries on those particular devices with issues.

Our crash reporting uses a different unwinding flow which won't be affected by the change here. This configuration will only affect the unwinding used for exceptions, and we're willing to try not being able to unwind through sigreturn frames for that scenario.

The "fix" (that's still subject to time-of-check-to-time-of-use issues) would be to see if memory is readable before accessing it, like nongnu libunwind does, but there were concerns raised in the original review about the system calls required not being accessible because of security configurations (https://reviews.llvm.org/D90898#2384775), plus the overhead of the checking. Do you have any ideas for that?

[rprichard]

... that's still subject to time-of-check-to-time-of-use issues

Using /proc/self/maps would be subject to TOCTOU, but I think most methods wouldn't, e.g.:

• Open /proc/self/mem and pread() the address. This seems strictly better than /proc/self/maps?
• Create a pipe using pipe(), write() the bytes into the pipe buffer and read() them back out. I believe a Linux pipe buffer is guaranteed to be big enough (>= 8 bytes).
• process_vm_readv

I wonder if security configurations are a problem. Maybe I should experiment on an Android build.

[smeenai]

In D123428#3444134, @rprichard wrote:

... that's still subject to time-of-check-to-time-of-use issues

Using /proc/self/maps would be subject to TOCTOU, but I think most methods wouldn't, e.g.:

• Open /proc/self/mem and pread() the address. This seems strictly better than /proc/self/maps?
• Create a pipe using pipe(), write() the bytes into the pipe buffer and read() them back out. I believe a Linux pipe buffer is guaranteed to be big enough (>= 8 bytes).
• process_vm_readv

I wonder if security configurations are a problem. Maybe I should experiment on an Android build.

With all those methods, there's still the chance (however unlikely) that the address is readable at the time of the check but somehow becomes unreadable by the time we perform the actual read, right? I doubt it matters much in practice though.

For the pipe, since we'll be checking for validity multiple times, I imagine we'll need to empty out the buffer at some point. libunwind seems to use mincore if available and the pipe as a fallback, but I'm not really understanding how mincore would work here, since a page could be readable even though it's not currently resident.

[rprichard]

In D123428#3444170, @smeenai wrote:

In D123428#3444134, @rprichard wrote:

Using /proc/self/maps would be subject to TOCTOU, but I think most methods wouldn't, e.g.:

• Open /proc/self/mem and pread() the address. This seems strictly better than /proc/self/maps?
• Create a pipe using pipe(), write() the bytes into the pipe buffer and read() them back out. I believe a Linux pipe buffer is guaranteed to be big enough (>= 8 bytes).
• process_vm_readv

I wonder if security configurations are a problem. Maybe I should experiment on an Android build.

With all those methods, there's still the chance (however unlikely) that the address is readable at the time of the check but somehow becomes unreadable by the time we perform the actual read, right? I doubt it matters much in practice though.

The unwinder needs to read two aligned 4-byte words at the target PC. I was thinking that it could replace the ordinary reads with system calls. e.g. For the pipe trick, write the target 8 bytes into a pipe and then read them back out. If multiple threads share a pipe fd, then they'd need the synchronize their use of the pipe.

I wonder if we'd need to close the pipe fd for dlclose. On Android, the unwinder is linked statically into app shared objects.

For the pipe, since we'll be checking for validity multiple times, I imagine we'll need to empty out the buffer at some point. libunwind seems to use mincore if available and the pipe as a fallback, but I'm not really understanding how mincore would work here, since a page could be readable even though it's not currently resident.

Yeah, mincore doesn't seem to do what's needed here.

[MaskRay]

In D123428#3444198, @rprichard wrote:

In D123428#3444170, @smeenai wrote:

In D123428#3444134, @rprichard wrote:

Using /proc/self/maps would be subject to TOCTOU, but I think most methods wouldn't, e.g.:

• Open /proc/self/mem and pread() the address. This seems strictly better than /proc/self/maps?
• Create a pipe using pipe(), write() the bytes into the pipe buffer and read() them back out. I believe a Linux pipe buffer is guaranteed to be big enough (>= 8 bytes).
• process_vm_readv

I wonder if security configurations are a problem. Maybe I should experiment on an Android build.

With all those methods, there's still the chance (however unlikely) that the address is readable at the time of the check but somehow becomes unreadable by the time we perform the actual read, right? I doubt it matters much in practice though.

The unwinder needs to read two aligned 4-byte words at the target PC. I was thinking that it could replace the ordinary reads with system calls. e.g. For the pipe trick, write the target 8 bytes into a pipe and then read them back out. If multiple threads share a pipe fd, then they'd need the synchronize their use of the pipe.

I wonder if we'd need to close the pipe fd for dlclose. On Android, the unwinder is linked statically into app shared objects.

For the pipe, since we'll be checking for validity multiple times, I imagine we'll need to empty out the buffer at some point. libunwind seems to use mincore if available and the pipe as a fallback, but I'm not really understanding how mincore would work here, since a page could be readable even though it's not currently resident.

Yeah, mincore doesn't seem to do what's needed here.

https://github.com/abseil/abseil-cpp/blob/master/absl/debugging/internal/address_is_readable.cc has gone through several iterations. We can use rt_sigprocmask.

[smeenai]

In D123428#3444212, @MaskRay wrote:

In D123428#3444198, @rprichard wrote:

In D123428#3444170, @smeenai wrote:

In D123428#3444134, @rprichard wrote:

Using /proc/self/maps would be subject to TOCTOU, but I think most methods wouldn't, e.g.:

• Open /proc/self/mem and pread() the address. This seems strictly better than /proc/self/maps?
• Create a pipe using pipe(), write() the bytes into the pipe buffer and read() them back out. I believe a Linux pipe buffer is guaranteed to be big enough (>= 8 bytes).
• process_vm_readv

I wonder if security configurations are a problem. Maybe I should experiment on an Android build.

With all those methods, there's still the chance (however unlikely) that the address is readable at the time of the check but somehow becomes unreadable by the time we perform the actual read, right? I doubt it matters much in practice though.

The unwinder needs to read two aligned 4-byte words at the target PC. I was thinking that it could replace the ordinary reads with system calls. e.g. For the pipe trick, write the target 8 bytes into a pipe and then read them back out. If multiple threads share a pipe fd, then they'd need the synchronize their use of the pipe.

I wonder if we'd need to close the pipe fd for dlclose. On Android, the unwinder is linked statically into app shared objects.

For the pipe, since we'll be checking for validity multiple times, I imagine we'll need to empty out the buffer at some point. libunwind seems to use mincore if available and the pipe as a fallback, but I'm not really understanding how mincore would work here, since a page could be readable even though it's not currently resident.

Yeah, mincore doesn't seem to do what's needed here.

https://github.com/abseil/abseil-cpp/blob/master/absl/debugging/internal/address_is_readable.cc has gone through several iterations. We can use rt_sigprocmask.

@rprichard, do you know if this would work for Android? It has the TOCTOU issue, but I imagine it's much simpler than having to manage and synchronize the pipe fd, and we could live with the TOCTOU in practice.

[rprichard]

In D123428#3475346, @smeenai wrote:

In D123428#3444212, @MaskRay wrote:

https://github.com/abseil/abseil-cpp/blob/master/absl/debugging/internal/address_is_readable.cc has gone through several iterations. We can use rt_sigprocmask.

@rprichard, do you know if this would work for Android? It has the TOCTOU issue, but I imagine it's much simpler than having to manage and synchronize the pipe fd, and we could live with the TOCTOU in practice.

I'm glad @MaskRay found this -- I think it will probably work, and it seems better than assuming the PC is readable.

I see rt_procsigmask listed in bionic/libc/SYSCALLS.TXT, and I don't see it mentioned in any of the bionic/libc/SECCOMP*.txt files. I think that means seccomp is allowing the system call. I looked at kernel/signal.c, and AFAICT it's not doing any security checks that could be a problem. Bionic itself uses rt_sigprocmask for (at least) spawning new processes, creating/exiting threads, TLS-related locking, POSIX timers, and abort(). I think any seccomp-like blocking of rt_sigprocmask would have to be very targeted, so I think the syscall is probably allowed everywhere on Android.

It is assuming that the kernel will validate the address before validating the how. The kernel has a principle of not breaking userland -- is there a more specific guarantee we can rely on? e.g. The code has this comment:

// This strategy depends on Linux implementation details,
// so we rely on the test to alert us if it stops working.

The kernel source is structured as two wrappers around sigprocmask, SYSCALL_DEFINE4(rt_sigprocmask, ...) and COMPAT_SYSCALL_DEFINE4(rt_sigprocmask, ...). The wrappers copy user memory to/from kernel memory before calling sigprocmask, so it makes sense that they would validate the address first.

[rprichard]

In D123428#3476371, @rprichard wrote:

In D123428#3475346, @smeenai wrote:

In D123428#3444212, @MaskRay wrote:

https://github.com/abseil/abseil-cpp/blob/master/absl/debugging/internal/address_is_readable.cc has gone through several iterations. We can use rt_sigprocmask.

@rprichard, do you know if this would work for Android? It has the TOCTOU issue, but I imagine it's much simpler than having to manage and synchronize the pipe fd, and we could live with the TOCTOU in practice.

I'm glad @MaskRay found this -- I think it will probably work, and it seems better than assuming the PC is readable.

I see rt_procsigmask listed in bionic/libc/SYSCALLS.TXT, and I don't see it mentioned in any of the bionic/libc/SECCOMP*.txt files. I think that means seccomp is allowing the system call. I looked at kernel/signal.c, and AFAICT it's not doing any security checks that could be a problem. Bionic itself uses rt_sigprocmask for (at least) spawning new processes, creating/exiting threads, TLS-related locking, POSIX timers, and abort(). I think any seccomp-like blocking of rt_sigprocmask would have to be very targeted, so I think the syscall is probably allowed everywhere on Android.

It is assuming that the kernel will validate the address before validating the how. The kernel has a principle of not breaking userland -- is there a more specific guarantee we can rely on? e.g. The code has this comment:

// This strategy depends on Linux implementation details,
// so we rely on the test to alert us if it stops working.

The kernel source is structured as two wrappers around sigprocmask, SYSCALL_DEFINE4(rt_sigprocmask, ...) and COMPAT_SYSCALL_DEFINE4(rt_sigprocmask, ...). The wrappers copy user memory to/from kernel memory before calling sigprocmask, so it makes sense that they would validate the address first.

I talked with cferris today (the maintainer of Android's libunwindstack), and I think LLVM's libunwind could just use process_vm_readv, which is more straightforward and would also avoid the TOCTOU issue.

process_vm_readv is used by libunwindstack, and cferris wasn't aware of any situation where process_vm_readv was blocked.

process_vm_readv is presumably slower than rt_procsigmask, but that's probably acceptable? It's only used when the unwinder can't find DWARF unwind info for a PC.

process_vm_readv requires a 3.2 kernel or newer, but this is syscall only needed for arm64, and arm64 support wasn't added until a later kernel version (3.7, it appears?).

I think the kernel special-cases process_vm_readv so it doesn't need ptrace permissions when reading the calling process's address space. When mm == current->mm, the kernel skips the ptrace_may_access call:

• https://github.com/torvalds/linux/blob/v5.17/mm/process_vm_access.c#L202
• https://github.com/torvalds/linux/blob/v5.17/kernel/fork.c#L1324

[smeenai]

In D123428#3487134, @rprichard wrote:

In D123428#3476371, @rprichard wrote:

In D123428#3475346, @smeenai wrote:

In D123428#3444212, @MaskRay wrote:

https://github.com/abseil/abseil-cpp/blob/master/absl/debugging/internal/address_is_readable.cc has gone through several iterations. We can use rt_sigprocmask.

@rprichard, do you know if this would work for Android? It has the TOCTOU issue, but I imagine it's much simpler than having to manage and synchronize the pipe fd, and we could live with the TOCTOU in practice.

I'm glad @MaskRay found this -- I think it will probably work, and it seems better than assuming the PC is readable.

I see rt_procsigmask listed in bionic/libc/SYSCALLS.TXT, and I don't see it mentioned in any of the bionic/libc/SECCOMP*.txt files. I think that means seccomp is allowing the system call. I looked at kernel/signal.c, and AFAICT it's not doing any security checks that could be a problem. Bionic itself uses rt_sigprocmask for (at least) spawning new processes, creating/exiting threads, TLS-related locking, POSIX timers, and abort(). I think any seccomp-like blocking of rt_sigprocmask would have to be very targeted, so I think the syscall is probably allowed everywhere on Android.

It is assuming that the kernel will validate the address before validating the how. The kernel has a principle of not breaking userland -- is there a more specific guarantee we can rely on? e.g. The code has this comment:

// This strategy depends on Linux implementation details,
// so we rely on the test to alert us if it stops working.

The kernel source is structured as two wrappers around sigprocmask, SYSCALL_DEFINE4(rt_sigprocmask, ...) and COMPAT_SYSCALL_DEFINE4(rt_sigprocmask, ...). The wrappers copy user memory to/from kernel memory before calling sigprocmask, so it makes sense that they would validate the address first.

I talked with cferris today (the maintainer of Android's libunwindstack), and I think LLVM's libunwind could just use process_vm_readv, which is more straightforward and would also avoid the TOCTOU issue.

process_vm_readv is used by libunwindstack, and cferris wasn't aware of any situation where process_vm_readv was blocked.

process_vm_readv is presumably slower than rt_procsigmask, but that's probably acceptable? It's only used when the unwinder can't find DWARF unwind info for a PC.

process_vm_readv requires a 3.2 kernel or newer, but this is syscall only needed for arm64, and arm64 support wasn't added until a later kernel version (3.7, it appears?).

I think the kernel special-cases process_vm_readv so it doesn't need ptrace permissions when reading the calling process's address space. When mm == current->mm, the kernel skips the ptrace_may_access call:

• https://github.com/torvalds/linux/blob/v5.17/mm/process_vm_access.c#L202
• https://github.com/torvalds/linux/blob/v5.17/kernel/fork.c#L1324

Thanks for all the research and info here! I'm abandoning this since the process_vm_readv route seems like a much better path. (I likely won't have time to take a swing at that for a couple of weeks, but I'm also happy for anyone else to try it if they have the time, of course.)

[smeenai]

D126343 implements the process_vm_readv approach

libunwind/CMakeLists.txt

 option(LIBUNWIND_WEAK_PTHREAD_LIB "Use weak references to refer to pthread functions." OFF)
 option(LIBUNWIND_USE_COMPILER_RT "Use compiler-rt instead of libgcc" OFF)
 option(LIBUNWIND_INCLUDE_DOCS "Build the libunwind documentation." ${LLVM_INCLUDE_DOCS})
 option(LIBUNWIND_INCLUDE_TESTS "Build the libunwind tests." ${LLVM_INCLUDE_TESTS})
 option(LIBUNWIND_IS_BAREMETAL "Build libunwind for baremetal targets." OFF)
 option(LIBUNWIND_USE_FRAME_HEADER_CACHE "Cache frame headers for unwinding. Requires locking dl_iterate_phdr." OFF)
 option(LIBUNWIND_REMEMBER_HEAP_ALLOC "Use heap instead of the stack for .cfi_remember_state." OFF)
 option(LIBUNWIND_INSTALL_HEADERS "Install the libunwind headers." OFF)
+option(LIBUNWIND_OMIT_LINUX_AARCH64_SIGRETURN_CHECK "Disable the sigreturn trampoline check on AArch64 Linux." OFF)
 
 set(LIBUNWIND_LIBDIR_SUFFIX "${LLVM_LIBDIR_SUFFIX}" CACHE STRING
     "Define suffix of library directory name (32/64)")
 option(LIBUNWIND_INSTALL_LIBRARY "Install the libunwind library." ON)
 cmake_dependent_option(LIBUNWIND_INSTALL_STATIC_LIBRARY
   "Install the static libunwind library." ON
   "LIBUNWIND_ENABLE_STATIC;LIBUNWIND_INSTALL_LIBRARY" OFF)
 cmake_dependent_option(LIBUNWIND_INSTALL_SHARED_LIBRARY
   "Install the shared libunwind library." ON

 if(LIBUNWIND_USE_FRAME_HEADER_CACHE)
   add_compile_definitions(_LIBUNWIND_USE_FRAME_HEADER_CACHE)
 endif()
 
 if(LIBUNWIND_REMEMBER_HEAP_ALLOC)
   add_compile_definitions(_LIBUNWIND_REMEMBER_HEAP_ALLOC)
 endif()
 
+if(LIBUNWIND_OMIT_LINUX_AARCH64_SIGRETURN_CHECK)
+  add_compile_definitions(_LIBUNWIND_OMIT_LINUX_AARCH64_SIGRETURN_CHECK)
+endif()
+
 # This is the _ONLY_ place where add_definitions is called.
 if (MSVC)
   add_definitions(-D_CRT_SECURE_NO_WARNINGS)
 endif()
 
 # Disable DLL annotations on Windows for static builds.
 if (WIN32 AND LIBUNWIND_ENABLE_STATIC AND NOT LIBUNWIND_ENABLE_SHARED)
   add_definitions(-D_LIBUNWIND_HIDE_SYMBOLS)

libunwind/src/UnwindCursor.hpp

 #ifdef _WIN32
   #include <windows.h>
   #include <ntverp.h>
 #endif
 #ifdef __APPLE__
   #include <mach-o/dyld.h>
 #endif
 
+#if defined(_LIBUNWIND_TARGET_LINUX) && defined(_LIBUNWIND_TARGET_AARCH64) &&  \
+    !defined(_LIBUNWIND_OMIT_LINUX_AARCH64_SIGRETURN_CHECK)
+#define _LIBUNWIND_CHECK_LINUX_AARCH64_SIGRETURN
+#endif
+
 #if defined(_LIBUNWIND_SUPPORT_SEH_UNWIND)
 // Provide a definition for the DISPATCHER_CONTEXT struct for old (Win7 and
 // earlier) SDKs.
 // MinGW-w64 has always provided this struct.
   #if defined(_WIN32) && defined(_LIBUNWIND_TARGET_X86_64) && \
       !defined(__MINGW32__) && VER_PRODUCTBUILD < 8000
 struct _DISPATCHER_CONTEXT {
   ULONG64 ControlPc;
const uint32_t *ehtp =
                          &off, &len);
     if (_Unwind_VRS_Interpret((_Unwind_Context *)this, ehtp, off, len) !=
             _URC_CONTINUE_UNWIND)
       return UNW_STEP_END;
     return UNW_STEP_SUCCESS;
   }
 #endif
 
-#if defined(_LIBUNWIND_TARGET_LINUX) && defined(_LIBUNWIND_TARGET_AARCH64)
+#if defined(_LIBUNWIND_CHECK_LINUX_AARCH64_SIGRETURN)
   bool setInfoForSigReturn() {
     R dummy;
     return setInfoForSigReturn(dummy);
   }
   int stepThroughSigReturn() {
     R dummy;
     return stepThroughSigReturn(dummy);
   }

 #endif // defined(_LIBUNWIND_SUPPORT_SEH_UNWIND)
 
 
   A               &_addressSpace;
   R                _registers;
   unw_proc_info_t  _info;
   bool             _unwindInfoMissing;
   bool             _isSignalFrame;
-#if defined(_LIBUNWIND_TARGET_LINUX) && defined(_LIBUNWIND_TARGET_AARCH64)
+#if defined(_LIBUNWIND_CHECK_LINUX_AARCH64_SIGRETURN)
   bool             _isSigReturn = false;
 #endif
 };
 
 
 template <typename A, typename R>
 UnwindCursor<A, R>::UnwindCursor(unw_context_t *context, A &as)
     : _addressSpace(as), _registers(context), _unwindInfoMissing(false),
#endif
   setLastPC(pc);
   return true;
 }
 #endif
 
 
 template <typename A, typename R>
 void UnwindCursor<A, R>::setInfoBasedOnIPRegister(bool isReturnAddress) {
-#if defined(_LIBUNWIND_TARGET_LINUX) && defined(_LIBUNWIND_TARGET_AARCH64)
+#if defined(_LIBUNWIND_CHECK_LINUX_AARCH64_SIGRETURN)
   _isSigReturn = false;
 #endif
 
   pint_t pc = static_cast<pint_t>(this->getReg(UNW_REG_IP));
 #if defined(_LIBUNWIND_ARM_EHABI)
   // Remove the thumb bit so the IP represents the actual instruction address.
   // This matches the behaviour of _Unwind_GetIP on arm.
   pc &= (pint_t)~0x1;
if (!CFI_Parser<A>::decodeFDE(_addressSpace, fde, &fdeInfo, &cieInfo)) {
       // Double check this FDE is for a function that includes the pc.
       if ((fdeInfo.pcStart <= pc) && (pc < fdeInfo.pcEnd))
         if (getInfoFromFdeCie(fdeInfo, cieInfo, pc, 0))
           return;
     }
   }
 #endif // #if defined(_LIBUNWIND_SUPPORT_DWARF_UNWIND)
 
-#if defined(_LIBUNWIND_TARGET_LINUX) && defined(_LIBUNWIND_TARGET_AARCH64)
+#if defined(_LIBUNWIND_CHECK_LINUX_AARCH64_SIGRETURN)
   if (setInfoForSigReturn())
     return;
 #endif
 
   // no unwind info, flag that we can't reliably unwind
   _unwindInfoMissing = true;
 }
 
-#if defined(_LIBUNWIND_TARGET_LINUX) && defined(_LIBUNWIND_TARGET_AARCH64)
+#if defined(_LIBUNWIND_CHECK_LINUX_AARCH64_SIGRETURN)
 template <typename A, typename R>
 bool UnwindCursor<A, R>::setInfoForSigReturn(Registers_arm64 &) {
   // Look for the sigreturn trampoline. The trampoline's body is two
   // specific instructions (see below). Typically the trampoline comes from the
   // vDSO[1] (i.e. the __kernel_rt_sigreturn function). A libc might provide its
   // own restorer function, though, or user-mode QEMU might write a trampoline
   // onto the stack.
   //
uint64_t value = _addressSpace.get64(sigctx + kOffsetGprs +
                                          static_cast<pint_t>(i * 8));
     _registers.setRegister(UNW_AARCH64_X0 + i, value);
   }
   _registers.setSP(_addressSpace.get64(sigctx + kOffsetSp));
   _registers.setIP(_addressSpace.get64(sigctx + kOffsetPc));
   _isSignalFrame = true;
   return UNW_STEP_SUCCESS;
 }
-#endif // defined(_LIBUNWIND_TARGET_LINUX) && defined(_LIBUNWIND_TARGET_AARCH64)
+#endif // defined(_LIBUNWIND_CHECK_LINUX_AARCH64_SIGRETURN)
 
 template <typename A, typename R>
 int UnwindCursor<A, R>::step() {
   // Bottom of stack is defined is when unwind info cannot be found.
   if (_unwindInfoMissing)
     return UNW_STEP_END;
 
   // Use unwinding info to modify register set as if function returned.
   int result;
-#if defined(_LIBUNWIND_TARGET_LINUX) && defined(_LIBUNWIND_TARGET_AARCH64)
+#if defined(_LIBUNWIND_CHECK_LINUX_AARCH64_SIGRETURN)
   if (_isSigReturn) {
     result = this->stepThroughSigReturn();
   } else
 #endif
   {
 #if defined(_LIBUNWIND_SUPPORT_COMPACT_UNWIND)
     result = this->stepWithCompactEncoding();
 #elif defined(_LIBUNWIND_SUPPORT_SEH_UNWIND)