The added tests are failing for me, both on NetBSD and on one of my Linux systems:
http://lab.llvm.org:8011/builders/netbsd-amd64/builds/21070/steps/run%20unit%20tests

Makes sense. I suppose you want to update LLDBStandalone as well. And probably Python_ADDITIONAL_VERSIONS in clang & co are outdated.

Filed https://gitlab.kitware.com/cmake/cmake/issues/19492 for that.

To be honest, I don't think this is the correct solution. After all, lit-cpuid isn't installed, is it? (or are you using LLVM_INSTALL_UTILS?)

That said, I ended up having mixed feelings about this.

In D64881#1590330, @amccarth wrote:

Testing the matrix of 32/64, 64/32, Python 2/3, debug/release, seems like a lot of work. I'd be pretty surprised to learn that CMake did extra, Windows-specific work necessary to make find_package do the right thing in the face of registry and/or filesystem redirection.

Am I guessing correctly that this happens when you installed combined llvm+lldb build, and then try to build lldb standalone against that?

In D64812#1588040, @JDevlieghere wrote:

If that works in 3.4 I'm happy to go that way!

Hmm, I've just looked through CMake docs, and I think a better solution might be:

In D64647#1583429, @krytarowski wrote:

Something that we do not cover here is that once a tracee reports a signal (like someone poked it with SIGUSR1) and we want to pass it over to the tracee, we will reset siginfo.

This scenario should be covered by a test and we should handle it properly..

The solution in NetBSD for passing over signals without changing siginfo, is to not calling PT_SET_SIGINFO as the default one will be kept by the kernel. Optionally pick old siginfo with PT_GET_SIGINFO and optionally change destination lwp.

In D64647#1583125, @labath wrote:

Shouldn't there be some tests that come along with this patch?

In D63883#1574132, @ldionne wrote:

The build bots must specify -DLIBCXX_CXX_ABI=libcxxabi at the CMake configure step. Otherwise, they'll end up using the default ABI library on Linux, which uses the xxx_fallback.ipp files from libc++, and that doesn't implement everything we need.

Unless I'm mistaken, this commit broke building Polly:

Could you tell me specifically what change to buildbot is requested? I must've missed the original thread.

Am I guessing correctly that this broke the buildbots (again)?

LGTM.

LGTM. According to CMake manual, plain + is the only correct form and if \+ worked at all, it was probably only by accident.

The API has changed, and so the patch is no longer correct.

LGTM.

This seems to have broken the build for us:
http://lab.llvm.org:8011/builders/netbsd-amd64/builds/20658

Updated per review.

I'm going to ask Kamil to stamp those patches anyway but I always appreciate your advice wrt LLDB coding style and general integration. After all, we all want LLDB codebase to be more unified.

That's probably one of the reasons why NetBSD normally prevents unprivileged users from setting DRs.

Ping.

Ping.

Ping.

I'm sorry that nobody has replied to your request earlier. AFAICS the libcxx code has changed. Does it work now, or do we need to make thread_win32.cpp conditional to LIBCXX_HAS_WIN32_THREAD_API still?

This is ready to be reviewed now.

Removed XFAIL for tests fixed by this.

…and removed stale declarations.

Updated to use new XState conversion methods.

In D63610#1553143, @labath wrote:

It's not much, but it definitely does help.

// NB: I have no clue why FreeBSD code claims to belong in 'POSIX', and Linux does not.

I think that somehow fell out of the fact that FreeBSD uses an in-process debugging plugin, while linux uses lldb-server.

…and confirmed.

In D63346#1552271, @EricWF wrote:

Is this backwards compatible as well?

How about this? I've removed almost all abstraction, leaving only simple ptrace() wrapper.

I'll try to simplify it in a few steps and see how that goes. All I'm saying is that ultimately having some DoRegisterSet() wrapper that calls ptrace() and avoids repeating getting PID/TID may help. Though admittely it saves very little actual code.

In D63594#1551702, @labath wrote:

BTW, is ReadGPR even called from some other place than NativeRegisterContextNetBSD_x86_64::ReadRegisterSet ? If not, then we could remove all of these functions (except the ReadRegisterSet I suggest above), and inline everything into NativeRegisterContextNetBSD_x86_64::ReadRegisterSet (one of these should be renamed, obviously), removing about 5 layers of indirection...

In D63545#1551681, @labath wrote:

In D63545#1551675, @mgorny wrote:

In D63545#1551627, @labath wrote:

We have the same XSTATE<->YMM conversion functions in NativeProcessLinux. It would be nice to extract them to some common place (Plugins/Process/Utility, I guess :P).

Hmm, I guess that's doable if we pass the relevant struct fields as pointers.

Maybe have GetYMM(unsigned num, YMM& reg)/SetYMM(unsigned num, const YMM &reg) methods on the XSAVE struct ?

In D63545#1551627, @labath wrote:

We have the same XSTATE<->YMM conversion functions in NativeProcessLinux. It would be nice to extract them to some common place (Plugins/Process/Utility, I guess :P).

Rebased for changes in NativeRegisterContextNetBSD_x86_64::GetSetForNativeRegNum(), and removed the conditions there.

@stella.stamenova could you try running the lldb invocation manually like I did? I'm wondering if you're getting the same issue.

The added test broke NetBSD buildbot: http://lab.llvm.org:8011/builders/netbsd-amd64/builds/109/steps/run%20unit%20tests/logs/FAIL%3A%20LLDB%3A%3ATestProcessAttach.test

Marshall, std/containers/associative/map/map.cons/deduct_const.pass.cpp test seems to be reliably failing from commit one on both Gentoo Linux and NetBSD. Could you please look at the classical example of totally cryptic C++ error? ;-)