[all-commits] [llvm/llvm-project] 94b08b: [Support] Improve the logic for re-raising signals...

[Alex Rønne Petersen via All-commits]

  Branch: refs/heads/main
  Home:   https://github.com/llvm/llvm-project
  Commit: 94b08b5de90dc21453a1dcde10cc1cd44ba93f7c
      https://github.com/llvm/llvm-project/commit/94b08b5de90dc21453a1dcde10cc1cd44ba93f7c
  Author: Alex Rønne Petersen <alex at alexrp.com>
  Date:   2026-07-18 (Sat, 18 Jul 2026)

  Changed paths:
    M llvm/lib/Support/Unix/Signals.inc

  Log Message:
  -----------
  [Support] Improve the logic for re-raising signals (#177864)

On most systems, checking `si_pid` is not actually valid unless
`si_code` equals one of the relevant signal codes (`SI_USER`,
`SI_QUEUE`, and on some OSs, `SI_LWP`), or the signal is `SIGCHLD`. So
on e.g. NetBSD, we would misinterpret the `SIGSEGV` fault address as the
sending PID and incorrectly conclude that the signal came from a
different process.

But as far as I can tell, there's not even a valid reason for us to be
checking `si_pid != getpid()`, because the signal could very well have
been explicitly sent by another thread in the current process. So we
really just need to check `si_code` for the aforementioned signal codes.

Darwin is the exception because it just doesn't set `si_code` at all in
the case of the `SI_*` signal codes. So keep the old logic there, even
though it misses the corner case of signals sent by a thread in the
current process.

While here, I also changed the error check for Linux
`rt_tgsigqueueinfo()` as it was not at all clear to me how we would ever
see `EPERM` from sending a signal to the current thread. Besides, it's
sensible to go to the `raise()` path as a last resort regardless of how
`rt_tgsigqueueinfo()` failed (e.g. `ENOSYS` on an old kernel).



To unsubscribe from these emails, change your notification settings at https://github.com/llvm/llvm-project/settings/notifications