Now, the curious thing is that so far I have 2 more test failures with this. I'll investigate closer, maybe it's just flakiness.

Applied requested changes.

Thanks for the review. Addressed comments.

Covered more callsites.

Got rid of close() and fclose() wrapping, for now.

Hmm, I also see that LLVM has signal-safe Process::SafelyCloseFileDescriptor(). Should I use that, or just ignore potential issues with close()?

In D59606#1436796, @labath wrote:

The "problem" I have with this is that (IIRC) retrying close(2) on EINTR is the *wrong* thing to do on linux (because the fd will be closed anyway, and so we may end up closing someone else's file the second time around). I'll try to dig up more info about that tomorrow.

I'd also like to update the output of lldb-instr but I think that'd be better done in a separate patch.

Declare 'R' in unittest to fix build failure.

Hmm but the tests fail to build for me ;-). I'm going to update this shortly.

Correct rebase: account for LLDB_DISABLE_PYTHON removal correctly.

Ok, here's the complete version, rebased. Note that I've built it before rebasing, and it's going to take a while before I rebuild it.

Hmm, actually with that local R declaration I don't have to have an additional set of macros ;-).

Does this look right? I've added temporary *2 versions of the macros to make it build without having to port everything. If it looks fine, I'll go with other files.

Ok, here's my first attempt at moving stuff but I'm getting load of errors and I can't figure out what I need to do to get the right symbols.

Implemented @ruiu's suggestions.

In D59109#1427659, @saugustine wrote:

-lunwind has the disadvantage of picking up whatever libunwind happens to be first in the search path. Fixing that would require moving llvm-libunwind into compiler-rt and naming it differently.

Updated to use dedicated header checks, as requested by @krytarowski

Updated as requested by @krytarowski

This is causing build failures to some of our users: https://bugs.gentoo.org/674662

If you have to bundle a new hash, have you considered using one of the modern fast hashes (such as xxHash, CityHash, …)?

I've added one more test case, and added stop reason/signal checking for both threads. I think it's ready for review now.

This is still breaking NetBSD buildbot: http://lab.llvm.org:8011/builders/netbsd-amd64/builds/19339/steps/ninja%20build%20local/logs/stdio

Added two tests, more pending. Sadly, I wasn't able to reuse even the test cases since -nostdlib doesn't really work on NetBSD (resulting executables are not recognized as valid executables).

Updated to read PID and make unknown notes non-fatal.

I've attempted to rebase Kamil's patch against the current sources. Please note that this is not the final version; I'll add a test case and PID reading later.

Updated to make it all conditional to NetBSD, as discussed.

I'm not going to pursue this further.

Reverted in r355302. It seems that it is unreliable and sometimes evaluates to empty path, breaking clang.

Thanks. I'm going to retest/update it for master first.