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

Alex Brachet via Phabricator via libc-commits libc-commits at lists.llvm.org
Mon Mar 9 14:03:39 PDT 2020


abrachet added a subscriber: gchatelet.
abrachet added a comment.

Going to quote this here because the file it was commented on has since been deleted

> While I understand (thanks to your comments and other references) why this is required, adding an assembly file in LLVM libc is a complete no go at least at this point in time. For example, options like inline assembly are OK but I do think it helps here.
> 
> Sorry, I am not trying to discourage here. In fact, I totally appreciate the effort you put in to do the investigation because it hastened my own learning. I want to make sure we have exhausted all other options. Will do my own research and get back to you. Feel free to propose other options if you can think of any.

I can't think of any way to do this without handwriting this function. If we don't want an assembly file thats fine but it would need to be inline asm. My personal opinion is that inline asm will get uglier in the future when more architectures are supported but thats not a huge concern right now.

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).


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

https://reviews.llvm.org/D75802





More information about the libc-commits mailing list