Revert "Reapply: Add an error message to the default SIGPIPE handler"

This patch is spamming compiles with unhelpful and confusing messages.
E.g. the Linux kernel uses "grep -q" in several places. I

Revert "Reapply: Add an error message to the default SIGPIPE handler"

This patch is spamming compiles with unhelpful and confusing messages.
E.g. the Linux kernel uses "grep -q" in several places. It's meant to
quit with a return code of zero when the first match is found. This can
cause a SIGPIPE signal, but that's expected, and there's no way to turn
this error message off to avoid spurious error messages.

UNIX03 apparently doesn't require printing an error message on SIGPIPE,
but specifically when there's an error on the stdout stream in a normal
program flow, e.g. when SIGPIPE trap is disabled.

A separate patch is planned to address the specific case we care most
about (involving llvm-nm).

This reverts commit b89bcefa6202e310eb3167dd1c37f1807377ec8d.

Link: https://github.com/llvm/llvm-project/issues/59037
Link: https://github.com/ClangBuiltLinux/linux/issues/1651

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

(cherry picked from commit 4787efa38066adb51e2c049499d25b3610c0877b)

show more ...

Reapply: Add an error message to the default SIGPIPE handler

UNIX03 conformance requires utilities to flush stdout before exiting and raise
an error if writing fails. Flushing already happens on a c

Reapply: Add an error message to the default SIGPIPE handler

UNIX03 conformance requires utilities to flush stdout before exiting and raise
an error if writing fails. Flushing already happens on a call to exit
and thus automatically on a return from main. Write failure is then
detected by LLVM's default SIGPIPE handler. The handler already exits with
a non-zero code, but conformance additionally requires an error message.

First reapply attempt I hadn't noticed the test had changed, hopefully this
goes better.

show more ...

Revert "Add an error message to the default SIGPIPE handler"

It broke PPC bots.

Add an error message to the default SIGPIPE handler

UNIX03 conformance requires utilities to flush stdout before exiting and raise
an error if writing fails. Flushing already happens on a call to ex

Add an error message to the default SIGPIPE handler

UNIX03 conformance requires utilities to flush stdout before exiting and raise
an error if writing fails. Flushing already happens on a call to exit
and thus automatically on a return from main. Write failure is then
detected by LLVM's default SIGPIPE handler. The handler already exits with
a non-zero code, but conformance additionally requires an error message.

show more ...

[config] Remove RETSIGTYPE from config.h.cmake, NFC

This doesn't need to be configurable. It was hardcoded to void in all
LLVM build systems.

Revert "Add an error message to the default SIGPIPE handler"

It broke a PPC bot, for not immediately obvious reasons.

Add an error message to the default SIGPIPE handler

UNIX03 conformance requires utilities to flush stdout before exiting and raise
an error if writing fails. Flushing already happens on a call to ex

Add an error message to the default SIGPIPE handler

UNIX03 conformance requires utilities to flush stdout before exiting and raise
an error if writing fails. Flushing already happens on a call to exit
and thus automatically on a return from main. Write failure is then
detected by LLVM's default SIGPIPE handler. The handler already exits with
a non-zero code, but conformance additionally requires an error message.

show more ...

Revert "Rename llvm::array_lengthof into llvm::size to match std::size from C++17"

This reverts commit ef8206320769ad31422a803a0d6de6077fd231d2.

- It conflicts with the existing llvm::size in STLEx

Revert "Rename llvm::array_lengthof into llvm::size to match std::size from C++17"

This reverts commit ef8206320769ad31422a803a0d6de6077fd231d2.

- It conflicts with the existing llvm::size in STLExtras, which will now
never be called.
- Calling it without llvm:: breaks C++17 compat

show more ...

Rename llvm::array_lengthof into llvm::size to match std::size from C++17

As a conquence move llvm::array_lengthof from STLExtras.h to
STLForwardCompat.h (which is included by STLExtras.h so no buil

Rename llvm::array_lengthof into llvm::size to match std::size from C++17

As a conquence move llvm::array_lengthof from STLExtras.h to
STLForwardCompat.h (which is included by STLExtras.h so no build
breakage expected).

show more ...

Add LLVM_ATTRIBUTE_USED to fix problems which could be exposed by aggressive global pointer variable removal

Note to BuryPointer.cpp:GraveYard. 'unused' cannot prevent (1) dead store
elimination and

Add LLVM_ATTRIBUTE_USED to fix problems which could be exposed by aggressive global pointer variable removal

Note to BuryPointer.cpp:GraveYard. 'unused' cannot prevent (1) dead store
elimination and (2) removal of the global pointer variable (D69428) but 'used' can.

Discovered when comparing link maps between HEAD+D69428 and HEAD.

Reviewed By: lattner

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

show more ...

[Signal] Re-raise SIGPIPE if the handler is uninstalled

Instead of falling through to RunSignalHandlers after the SIGPIPE
handler is uninstalled and we get a SIGPIPE, re-raise the signal, just
like

[Signal] Re-raise SIGPIPE if the handler is uninstalled

Instead of falling through to RunSignalHandlers after the SIGPIPE
handler is uninstalled and we get a SIGPIPE, re-raise the signal, just
like we do for other IntSigs.

This was discussed and informally OK'd here:

https://reviews.llvm.org/rG9a3f892d018238dce5181e458905311db8e682f5#856804

show more ...

Hint how to get a symbolized stack trace if llvm-symbolizer is not found on crashes

Most users of LLVM tools hit the raw traces and don't know how to get LLVM to
symbolize automatically for them.

W

Hint how to get a symbolized stack trace if llvm-symbolizer is not found on crashes

Most users of LLVM tools hit the raw traces and don't know how to get LLVM to
symbolize automatically for them.

When we print the non-symbolized stack trace, we will add information about
how to get it symbolized.

Reviewed By: MaskRay

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

show more ...

[Support] On Unix, let the CrashRecoveryContext return the signal code

Before this patch, the CrashRecoveryContext was returning -2 upon a signal, like ExecuteAndWait does. This didn't match the beh

[Support] On Unix, let the CrashRecoveryContext return the signal code

Before this patch, the CrashRecoveryContext was returning -2 upon a signal, like ExecuteAndWait does. This didn't match the behavior on Windows, where the the exception code was returned.

We now return the signal's code, which optionally allows for re-throwing the signal later. Doing so requires all custom handlers to be removed first, through llvm::sys::unregisterHandlers() which we made a public API.

This is part of https://reviews.llvm.org/D70378

show more ...

[SystemZ/ZOS] Add header file to encapsulate use of <sysexits.h>

The non-standard header file `<sysexits.h>` provides some return values.
`EX_IOERR` is used to as a special value to signal a broken

[SystemZ/ZOS] Add header file to encapsulate use of <sysexits.h>

The non-standard header file `<sysexits.h>` provides some return values.
`EX_IOERR` is used to as a special value to signal a broken pipe to the clang driver.
On z/OS Unix System Services, this header file does not exists. This patch

- adds a check for `<sysexits.h>`, removing the dependency on `LLVM_ON_UNIX`
- adds a new header file `llvm/Support/ExitCodes`, which either includes
`<sysexits.h>` or defines `EX_IOERR`
- updates the users of `EX_IOERR` to include the new header file

Reviewed By: hubert.reinterpretcast

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

show more ...

[Support] Allow printing the stack trace only for a given depth

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

Use llvm::is_contained where appropriate (NFC)

Use llvm::is_contained where appropriate (NFC)

Reviewed By: kazu

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

[Support] Optionally call signal handlers when a function wrapped by the the CrashRecoveryContext fails

This patch allows for handling a failure inside a CrashRecoveryContext in the same way as the

[Support] Optionally call signal handlers when a function wrapped by the the CrashRecoveryContext fails

This patch allows for handling a failure inside a CrashRecoveryContext in the same way as the global exception/signal handler. A failure will have the same side-effect, such as cleanup of temporarty file, printing callstack, calling relevant signal handlers, and finally returning an exception code. This is an optional feature, disabled by default.
This is a support patch for D69825.

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

show more ...

[Signal] Allow one-shot SIGPIPE handler to be reached

As SIGPIPE is no longer in the IntSigs array, handle SIGPIPE before
handling any interrupt signals.

Thanks to Alexandre Ganea for pointing out

[Signal] Allow one-shot SIGPIPE handler to be reached

As SIGPIPE is no longer in the IntSigs array, handle SIGPIPE before
handling any interrupt signals.

Thanks to Alexandre Ganea for pointing out the issue here.

show more ...

[Signal] Allow llvm clients to opt into one-shot SIGPIPE handling

Allow clients of the llvm library to opt-in to one-shot SIGPIPE
handling, instead of forcing them to undo llvm's SIGPIPE handler
reg

[Signal] Allow llvm clients to opt into one-shot SIGPIPE handling

Allow clients of the llvm library to opt-in to one-shot SIGPIPE
handling, instead of forcing them to undo llvm's SIGPIPE handler
registration (which is brittle).

The current behavior is preserved for all llvm-derived tools (except
lldb) by means of a default-`true` flag in the InitLLVM constructor.

This prevents "IO error" crashes in long-lived processes (lldb is the
motivating example) which both a) load llvm as a dynamic library and b)
*really* need to ignore SIGPIPE.

As llvm signal handlers can be installed when calling into libclang
(say, via RemoveFileOnSignal), thereby overriding a previous SIG_IGN for
SIGPIPE, there is no clean way to opt-out of "exit-on-SIGPIPE" in the
current model.

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

show more ...

Revert "Disable exit-on-SIGPIPE in lldb"

This reverts commit 32ce14e55e5a99dd99c3b4fd4bd0ccaaf2948c30.

In post-commit review, Pavel pointed out that there's a simpler way to
ignore SIGPIPE in lldb

Revert "Disable exit-on-SIGPIPE in lldb"

This reverts commit 32ce14e55e5a99dd99c3b4fd4bd0ccaaf2948c30.

In post-commit review, Pavel pointed out that there's a simpler way to
ignore SIGPIPE in lldb that doesn't rely on llvm's handlers.

show more ...

Disable exit-on-SIGPIPE in lldb

Occasionally, during test teardown, LLDB writes to a closed pipe.
Sometimes the communication is inherently unreliable, so LLDB tries to
avoid being killed due to SIG

Disable exit-on-SIGPIPE in lldb

Occasionally, during test teardown, LLDB writes to a closed pipe.
Sometimes the communication is inherently unreliable, so LLDB tries to
avoid being killed due to SIGPIPE (it calls `signal(SIGPIPE, SIG_IGN)`).
However, LLVM's default SIGPIPE behavior overrides LLDB's, causing it to
exit with IO_ERR.

Opt LLDB out of the default SIGPIPE behavior. I expect that this will
resolve some LLDB test suite flakiness (tests randomly failing with
IO_ERR) that we've seen since r344372.

rdar://55750240

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

llvm-svn: 375288

show more ...

Replace llvm::MutexGuard/UniqueLock with their standard equivalents

All supported platforms have <mutex> now, so we don't need our own
copies any longer. No functionality change intended.

llvm-svn:

Replace llvm::MutexGuard/UniqueLock with their standard equivalents

All supported platforms have <mutex> now, so we don't need our own
copies any longer. No functionality change intended.

llvm-svn: 368149

show more ...

Support for dumping current PrettyStackTrace on SIGINFO (Ctrl-T)

Support SIGINFO (and SIGUSR1 for POSIX purposes) to tell what
long-running jobs are doing, as inspired by BSD tools (including on
mac

Support for dumping current PrettyStackTrace on SIGINFO (Ctrl-T)

Support SIGINFO (and SIGUSR1 for POSIX purposes) to tell what
long-running jobs are doing, as inspired by BSD tools (including on
macOS), by dumping the current PrettyStackTrace.

This adds a new kind of signal handler for non-fatal "info" signals,
similar to the "interrupt" handler that already exists for SIGINT
(Ctrl-C). It then uses that handler to update a "generation count"
managed by the PrettyStackTrace infrastructure, which is then checked
whenever a PrettyStackTraceEntry is pushed or popped on each
thread. If the generation has changed---i.e. if the user has pressed
Ctrl-T---the stack trace is dumped, though unfortunately it can't
include the deepest entry because that one is currently being
constructed/destructed.

https://reviews.llvm.org/D63750

llvm-svn: 365911

show more ...

[llvm] [Support] Clean PrintStackTrace() ptr arithmetic up

Use '%tu' modifier for pointer arithmetic since we are using C++11
already. Prefer static_cast<> over C-style cast. Remove unnecessary
co

[llvm] [Support] Clean PrintStackTrace() ptr arithmetic up

Use '%tu' modifier for pointer arithmetic since we are using C++11
already. Prefer static_cast<> over C-style cast. Remove unnecessary
conversion of result, and add const qualifier to converted pointers,
to silence the following warning:

In file included from /home/mgorny/llvm-project/llvm/lib/Support/Signals.cpp:220:0:
/home/mgorny/llvm-project/llvm/lib/Support/Unix/Signals.inc: In function ‘void llvm::sys::PrintStackTrace(llvm::raw_ostream&)’:
/home/mgorny/llvm-project/llvm/lib/Support/Unix/Signals.inc:546:53: warning: cast from type ‘const void*’ to type ‘char*’ casts away qualifiers [-Wcast-qual]
(char*)dlinfo.dli_saddr));
^~~~~~~~~

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

llvm-svn: 364912

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...