[libc-commits] [PATCH] D75802: [libc] Add sigaction

[Siva Chandra via Phabricator via libc-commits]

sivachandra added a comment.

In D75802#1913247 <https://reviews.llvm.org/D75802#1913247>, @abrachet wrote:

> There's just no portable way that I know of to ensure the compile will never make any stack allocations. It's not like like the memcpy intrinsic that @gchatelet added either where it is nice to have, so even if we add a `never_stack_alloc` attribute to clang (which sounds non trivial), it wouldn't just be slower on other compilers but not work at all. Any stack allocation and the kernel cannot return from the signal, I've gotten either `SIGSEGV` or `SIGBUS` when implementing this in C.
>
> Those errors were with ASan and UBSan turned on, and compiled at `O1`. When sanitizers are turned off and compiling at `O1` this function works when written in C (breaks at `O0`. One idea, is put this in a separate C file, implement it in C and then use `add_custom_command` so we always know how it is being compiled, ie no sanitizers no instrumentation and optimizations always turned on. This is hacky though because if someone has an alias for their compiler like `alias clang="clang -fsanitize=address"` then that solution breaks too. Not to mention there is no guarantee that with optimizations turned on the compiler will not emit any push instructions (although its a safe bet that none would).


Firstly, I should have mentioned something more in my previous message. The only inline assembly we want to restrict to for now is the syscall layer. If such a restriction makes it impossible to do certain things, then we will consider relaxing it case-by-case.

Coming back to this patch, if we require a certain optimization level, I think that's reasonable. FWIW, glibc has such requirements at many places.

If I have a function like this:

  __attribute__((no_sanitize("address"))) // Add the full list of sanitizers which can affect us
  void my_syscall(void) {
    __llvm_libc::syscall(5);
    __builtin_unreachable();
  }

And, I compile with `-O3 -fomit-frame-pointer`, it produces:

  0000000000000000 <_Z10my_syscallv>:
     0:   b8 05 00 00 00          mov    $0x5,%eax
     5:   0f 05                   syscall 

So, it seems to me like the only additional thing we need is to teach the compiler is to use `rax` instead of `eax`. That too, we need it so that it works with gdb? Other way around, can we teach gdb/lldb to work LLVM libc? I am OK to wait on "fixing" this aspect.

So, in conclusion, if we can put this new function in a `.cpp` file as you suggest, and set up the right compiler options, we are good for now? Our build rules are probably not setup to handle all this correctly/conveniently, so they might need some extension.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D75802/new/

https://reviews.llvm.org/D75802