[all-commits] [llvm/llvm-project] 73fb96: [asan][test] Several Posix/unpoison-alternate-stac...

[rorth via All-commits]

  Branch: refs/heads/master
  Home:   https://github.com/llvm/llvm-project
  Commit: 73fb9698c0573778787e77a8ffa57e7fa3caebd4
      https://github.com/llvm/llvm-project/commit/73fb9698c0573778787e77a8ffa57e7fa3caebd4
  Author: Rainer Orth <ro at gcc.gnu.org>
  Date:   2020-09-30 (Wed, 30 Sep 2020)

  Changed paths:
    M compiler-rt/test/asan/TestCases/Posix/unpoison-alternate-stack.cpp

  Log Message:
  -----------
  [asan][test] Several Posix/unpoison-alternate-stack.cpp fixes

`Posix/unpoison-alternate-stack.cpp` currently `FAIL`s on Solaris/i386.
Some of the problems are generic:

- `clang` warns compiling the testcase:

  compiler-rt/test/asan/TestCases/Posix/unpoison-alternate-stack.cpp:83:7: warning: nested designators are a C99 extension [-Wc99-designator]
        .sa_sigaction = signalHandler,
        ^~~~~~~~~~~~~
  compiler-rt/test/asan/TestCases/Posix/unpoison-alternate-stack.cpp:84:7: warning: ISO C++ requires field designators to be specified in declaration order; field '_funcptr' will be initialized after field 'sa_flags' [-Wreorder-init-list]
        .sa_flags = SA_SIGINFO | SA_NODEFER | SA_ONSTACK,
        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  and some more instances.  This can all easily be avoided by initializing
  each field separately.

- The test `SEGV`s in `__asan_memcpy`.  The default Solaris/i386 stack size
  is only 4 kB, while `__asan_memcpy` tries to allocate either 5436
  (32-bit) or 10688 bytes (64-bit) on the stack.  This patch avoids this by
  requiring at least 16 kB stack size.

- Even without `-fsanitize=address` I get an assertion failure:

  Assertion failed: !isOnSignalStack(), file compiler-rt/test/asan/TestCases/Posix/unpoison-alternate-stack.cpp, line 117

  The fundamental problem with this testcase is that `longjmp` from a
  signal handler is highly unportable; XPG7 strongly warns against it and
  it is thus unspecified which stack is used when `longjmp`ing from a
  signal handler running on an alternative stack.

  So I'm `XFAIL`ing this testcase on Solaris.

Tested on `amd64-pc-solaris2.11` and `x86_64-pc-linux-gnu`.

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