I'm not going to put any more effort into this. If you have time and motivation to work on this, feel free to take it over.

This changed the API of RegisterInfoPOSIX_arm64 and broke the FreeBSD plugin. I'm going to try to fix it but next time it'd be nice if you checked that the class isn't used by something before making changes to its API.

In D101509#2725078, @JonChesterfield wrote:

In D101509#2724846, @mgorny wrote:

Is this going to block all direct builds of openmp or just these that don't have an LLVM source tree handy?

This is aimed at libomptarget, libopenmp can still build without llvm, provided it excludes the target part.

@labath, could you give me at least a rough idea how you feel about this one? I'd like to know if I need to change the test code before I start adding coredumps for more architectures.

Is this going to block all direct builds of openmp or just these that don't have an LLVM source tree handy? Also, do you really need *sources* and not just compiled libLLVM?

In D97282#2722937, @DavidSpickett wrote:

@mgorny Can you take a quick look and see if I'm adding this new feature correctly?

Use a temporary file if path-hint is not writable.

Send path-hint to the server. Add a test.

type → op.

In D100459#2721989, @rovka wrote:

This looks good to me, but I'll let others comment on whether or not we want to send extra leading zeroes for the thread ID. In my opinion it would be nice to 1) be consistent between all packages that deal with thread ids, and 2) send as little clutter as possible. But these are just theoretical concerns, I'm not sure if it matters in practice.

Thanks for the review. I'm going to update the tests as you suggested before pushing.

I need to implement path hints and add tests still.

Fix missing + in qSupported. Fix known stub features.

Add FreeBSD/aarch64 test.

Remove unnecessary const_cast, reformat.

Create a temporary file if path-hint is not provided.

Add tests.

Add gdb_remote_client tests for fork/vfork stop reason handling.

@labath, now's a curious problem I've seen very rarely (I mean, 1 out of 150 attempts or so):

Merged into D100206.

Merged D100541 and client fork/vfork stop infos from D100208 into this one. Included fork-events+ and vfork-events+ in client qSupported.

Synced to the Linux plugin.

Sync to changes in the Linux plugin.

Add multiprocess to supported features.

Fix tests to include multiprocess+ in qSupported.

Add the comment for mock stuff.

Actually, add asserts for fork/vfork extensions too.

Add an assert to make sure that process doesn't report fork/vfork stop reason without multiprocess support.

Added Extension bit for multiprocess. Made fork-events and vfork-events both depend on it — i.e. be implicitly disabled if multiprocess wasn't reported as supported.

Complete set of tests.

Now with complete set of amd64 tests.

Check for thread select instructions rather than output.

Use split code branches for i386 and amd64.

Also add FPU-specific checks to x86-32-freebsd-addr.test.

Implemented all the requests, modulo claim that PID and TID are duplicate ;-). Also found cases for bool() with Extension stuff.

In D100208#2705455, @labath wrote:

This seems reasonable.

Why don't we have tests that detach from the parent process (and maybe continue the child)? Does that already work? (or in general, what is expected to work after this patch?)

I'll try to keep this in mind. I expect to have some vacation time ~1 month from now, so maybe then ;-).

Now includes lldb-server tests.

Remove the test, update the API to pass std::unique_ptr<> instance instead of ref.

For other readers: as discussed in D100191, I've stripped client part of this (except for trivial enumerations). The server part will be used in tests but the stop reasons won't be reported to regular clients as they don't report fork-events support.

@labath, does this subset look better?

Implemented the suggested changes, including bool() use in SetEnabledExtensions(). Removed the client announcements of fork-events and vfork-events support.

In D100191#2704681, @labath wrote:

In D100191#2704492, @mgorny wrote:

In D100191#2704403, @labath wrote:

Let's identify the set of patches needed to make this testable via the lldb-server suite (this one, D100153, D100208 (or equivalent for some other os), and what else?) and test that?

In its current form, D100208 relies at least on D100196 as well. I suppose we might get away without other patches for now. My logic is that as long as client doesn't indicate fork support, the regular LLDB behavior won't change. We can mock-enable fork-events in the server tests to get things rolling, unless I'm missing something.

Sounds great.

I think we could avoid merging D100196 if I split D100208 into two parts, the earlier part just calling NewSubprocess() without actually reporting stop. This won't be really functional (or used in real sessions) but should suffice for testing.

I'm not sure how would that work -- you'd still have to provide a way to notify the client (test) about the new process and its pid, so that the test can assert something meaningful. Let's just keep D100196, but leave out the client specific parts -- just keep it about adding the new enums and relevant server code (trivial case switches are fine).

In D100191#2704403, @labath wrote:

Let's identify the set of patches needed to make this testable via the lldb-server suite (this one, D100153, D100208 (or equivalent for some other os), and what else?) and test that?

New sizes:

$ ls -lh *.core
-rw------- 1 mgorny mgorny  13K 04-19 17:11 x86-32-freebsd.core
-rw------- 1 mgorny mgorny 5,1K 04-19 17:11 x86-32-linux.core
-rw------- 1 mgorny mgorny 2,7K 04-19 17:11 x86-32-netbsd.core
-rw------- 1 mgorny mgorny  15K 04-19 17:11 x86-64-freebsd.core
-rw------- 1 mgorny mgorny 6,6K 04-19 17:11 x86-64-linux.core
-rw------- 1 mgorny mgorny 5,2K 04-19 17:11 x86-64-netbsd.core

Now includes a small-ish Python scripts to strip unnecessary data from coredumps. For now, it just strips everything but the PT_NOTE segment. Headers aren't modified, so holes are inserted before PT_NOTE segments, and the file is truncated after the last one. It uses the pyelftools library to portably read ELF headers.

Added a unittest covering the whole server life cycle, including attaching a (mocked) process, forking, detaching a child, detaching the parent, forking from the child and detaching all processes.

Fixed the iterator, formatting and added a test for adding, running and removing multiple handlers.

In D100191#2689489, @labath wrote:

We should also start thinking about tests. I suppose the smallest piece of functionality that could be usefully tested (with a lldb-server test) is debugging a process that forks, stopping after the fork, and detaching from the child. Shall we try making that work first?