User Details
- User Since
- Aug 15 2016, 6:00 AM (243 w, 1 d)
Today
Rebase + clang-format.
Yesterday
clang-format
Fix missing QListThreadsInStopReply+.
Sun, Apr 11
Report vfork-done stop to the client as well.
Base class Did*Fork() definitions have been moved to the earlier patch.
Add 'vforkdone' stop reason. Move overrideable actions to this patch.
Let's close this as all the features are now part of other diffs.
(TODO: vfork support)
Copy software breakpoints to the forked process, to future-proof this patch for breakpoint support (I suppose there's no point in splitting it more).
Fri, Apr 9
Ok, found the culprit. Now it's ready ;-).
Fix uninitialized flags variable in GDBRemoteCommunicationServerLLGS::SetEnabledExtensions().
This is the final piece for moving minimal fork/vfork support to gdb-remote protocol. However, for some reason (unlike the original code in D99864), it crashes on random assertions about m_enabled_extensions value — probably memory corruption somewhere. I'm debugging it.
I've decided to take another approach for tracking forked processes. Rather than keeping them inside NativeProcess* and exposing via API to LLGS, I've decided to push them via NativeDelegate straight into LLGS and maintain there. This is now D100191.
Permit more-than-one-char 'D' packets.
Thu, Apr 8
Add to _KNOWN_QSUPPORTED_STUB_FEATURES and clang-format.
Note that I've included full fork-events+ and vfork-events+ as demo of the API. I can split them further and/or move to more relevant commits as I progress with the split.
And now moved Extension API to D100153. I've added an API to query features supported by platform plugin, so now server doesn't report them unless they're actually going to be used.
Client-side qSupported processing is now refactored in D100146.
The server-side qSupported handling is now split into D100140, and all relevant remarks were addressed there.
This is split from D99864 as a minimal independent change.
Implemented @labath's requests.
Ok, I think I've implemented all the requested changes. I'm going to test it on all three platforms now and attach the patch if it miraculously still works ;-).
Answered where answer was due, will update the rest once I finish retesting the multiprocess patch.
@labath, any further comments or is this good to go then?
Removed the hanging test.
Wed, Apr 7
Added breakpoint cleanup via gdb-remote protocol. Only minimal code coverage so far. If this approach is okay, I guess I'll add subprocess guards to all server commands.
Sun, Apr 4
Fri, Apr 2
@labath, I think I've made all the requested changes.
Simplified FreeBSD/NetBSD to use per-PID waitpid(). Removed arch restrictions from wp tests — made them consistent with Python tests.
Update the Linux plugin and tests, mostly.
Added a skip to the hanging new test.
Thu, Apr 1
Add some tests.
Changed GetCurrentProcessAndThreadIDs() to return the vector, and reformatted.
Wed, Mar 31
Added better PID mismatch handling in SetThreadStopInfo(). Not that most of the call sites actually check the return value...
Tue, Mar 30
Removed software breakpoint cleanup. Modified tests not to expect child's output at any specific point.
@labath, split GetCurrentThreadIDs() as suggested. I've also modified GetCurrentProcessID() to prefer explicit PID over TID when available.
Limited to server changes. Added definitions for constexpr vars.
Ok, I'm going to use this review to push the server part, then commit the uint64 client change separately, then create a new diff for client.
Mon, Mar 29
Fix wrongly using the debugged process' TID instead of PID.
Sat, Mar 27
Complete FreeBSD and NetBSD support. Includes a fix to Detach() on NetBSD.
Fri, Mar 26
Ahh, I've seen them fail randomly recently too. But then it suddenly worked again and I couldn't reproduce...
This change breaks cross-compilation now, as it tries running an executable built for the target system:
Thu, Mar 25
Now includes initial FreeBSD support. The watchpoint test still fails, we probably need to clean dbregs on fork too.
Move saved breakpoint list directly into NativeProcessProtocol.