labath added a comment.
As I said in the other discussion, though this is a (small) step in what I
consider to be the right direction for this, it still seems like a workaround
to me. But if everyone else is fine with that, then I won't stand in your way.
One thing I am not sure of is why you've chosen clang as the only recipient of
the old SIGPIPE behavior. It seems like pretty much every non-interactive llvm
utility would benefit from the previously-default SIGPIPE behavior. This is why
I was talking about building this functionality into InitLLVM somehow -- one
could make it so that InitLLVM installs the sigpipe handler by default, and
lldb could pass some extra argument or something to disable that behavior.
================
Comment at: llvm/lib/Support/Unix/Signals.inc:328
registerHandler(S, SignalKind::IsKill);
+ if (OneShotPipeSignalFunction)
+ registerHandler(SIGPIPE, SignalKind::IsKill);
----------------
This bit is tricky. It means that `SetOneShotPipeSignalFunction` will take
effect only if it is called before we install any signal handlers. Calling it
later will not cause the handler to be installed. However, if one does set a
handler function before signals are installed, then it is possible to change it
with `SetOneShotPipeSignalFunction`. This makes its behavior a lot more complex
than `SetInfoSignalFunction`, which it tries to emulate.
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D70277/new/
https://reviews.llvm.org/D70277
_______________________________________________
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
