Page MenuHomePhabricator

Move common functionality from processwindows into processdebugger
ClosedPublic

Authored by asmith on Jun 11 2019, 1:49 PM.

Details

Summary

This change extracts functionalities from processwindows into a
introduced processdebugger that can be reused in native process
debugging.

The main reason is that the native process debugging
can't directly be based on processwindows or be implemented
as a pass-through to this plugin since the plugin has ties to
Target and Process classes that are needed in host debugging but
not necessary in native debugging.

Diff Detail

Event Timeline

asmith created this revision.Jun 11 2019, 1:49 PM
Herald added a project: Restricted Project. · View Herald TranscriptJun 11 2019, 1:49 PM
labath added a subscriber: amccarth.

Given that you're just moving code around, this should be fine, but I am including @amccarth, as I believe he is more familiar with this code.

The thing I would consider in your place is whether putting this into a separate class is enough, or if you want to put it into a separate module/subfolder as well. The reason for that is that if this is in the same module as the liblldb stuff, then you will still end up pulling the all the transitive deps into lldb-server. If you put that into a separate module then you can control the dependencies more precisely. I don't think this is that important, since hopefully the local codepath (along with the deps) will disappear once lldb-server starts to work, but you know.. temporary solutions have a tendency for becoming permanent... Anyway, I'll leave the decision up to you..

source/Plugins/Process/Windows/Common/ProcessDebugger.cpp
33

llvm prefers static functions over those in anonymous namespaces

Hui added a comment.Jun 12 2019, 3:15 PM

Given that you're just moving code around, this should be fine, but I am including @amccarth, as I believe he is more familiar with this code.

The thing I would consider in your place is whether putting this into a separate class is enough, or if you want to put it into a separate module/subfolder as well. The reason for that is that if this is in the same module as the liblldb stuff, then you will still end up pulling the all the transitive deps into lldb-server. If you put that into a separate module then you can control the dependencies more precisely. I don't think this is that important, since hopefully the local codepath (along with the deps) will disappear once lldb-server starts to work, but you know.. temporary solutions have a tendency for becoming permanent... Anyway, I'll leave the decision up to you..

I think ProcessWindows is based on Windows Basic Debugging Framework which can be leveraged by nativeprocess. So after the extraction of common codes into ProcessDebugger, they end up having same dependencies on DebuggerThread and ProcessDebugger in the same folder. (The native delegate is independent since the local delegate relies on a shareable process which native process is not).

labath added inline comments.Jun 12 2019, 11:28 PM
source/Plugins/Process/Windows/Common/ProcessDebugger.cpp
170–171

BTW, looking at the other patch, I just realized that this api is extremely redundant:
a) ProcessAttachInfo already contains a pid field so passing it separately makes no sense
b) DebuggerThread does not seem to be doing anything with the ProcessAttachInfo struct anyway.

It's been a while for me, so I'm not super-familiar with the code being changed, but I'm okay with factoring out common code. I agree with labath's open points and will try to look at it in more detail tomorrow.

I would rather see this stuff just moved into NativeProcessWindows (or some class in the windows lldb-server plug-in) and have all code in ProcessWindow.cpp and ProcessDebugger.cpp go away once lldb-server works on windows? The goal is to get rid of the ProcessWindows.cpp once lldb-server is running. Better to not maintain two different plug-ins (one for native and one for remote). The remote version will always work less well in that case.

I'm OK with moving common stuff out for now, and I like the separation of ProcessWindows and ProcessDebugger.

I agree that we don't want to live too long in a state with a regular plugin and a remote plugin, I still think there's advantage to having common Windows stuff grouped together (though, perhaps, not exactly this grouping in the long run). I'm trying to think through the implications on cross-platform post-mortem debugging, e.g., debugging a Windows minidump on a Linux host without spinning up a remote on an actual Windows machine.

This LGTM as an incremental step if you address some of the naming slips and others' feedback.

source/Plugins/Process/Windows/Common/ProcessDebugger.cpp
126

s/ProcessWindows/ProcessDebugger/ (2x)

216

s/ProcessWindows/ProcessDebugger/ ?

source/Plugins/Process/Windows/Common/ProcessDebugger.h
2

Please fix file title.

31

Arguably, this should be renamed to ProcessDebuggerData, but that's not a sticking point right now.

Hui added inline comments.Jun 14 2019, 1:02 PM
source/Plugins/Process/Windows/Common/ProcessDebugger.cpp
170–171

I once checked the pid shipped in attach_info. It was LLDB_INVALID_PROCESS_ID. Maybe it is an issue to fix.

Hui added inline comments.Jun 14 2019, 2:07 PM
source/Plugins/Process/Windows/Common/ProcessDebugger.cpp
170–171

Just double checked. The pid shipped in attach_info is correct. So the pid field can be removed.
However the Process class does have a virtual method DoAttachToProcessWithID that requires pid as an input.

labath added inline comments.Jun 17 2019, 6:51 AM
source/Plugins/Process/Windows/Common/ProcessDebugger.cpp
170–171

Hm.., I didn't realize this comes all the way down from the Process. Maybe let's keep this as is for now, since this patch is just about moving code.

asmith updated this revision to Diff 205178.Jun 17 2019, 1:56 PM
asmith marked 8 inline comments as done.
labath accepted this revision.Jun 18 2019, 12:06 AM
This revision is now accepted and ready to land.Jun 18 2019, 12:06 AM
asmith closed this revision.Mon, Jun 24, 10:43 AM
Hui added inline comments.Wed, Jul 3, 6:38 PM
source/Plugins/Process/Windows/Common/ProcessDebugger.cpp
170–171

There is a build bot reported about attaching process by id/name error. When I looked into that, it turned out that the attach_info did not carry the correct process id at all (pid = 0). This resulted some test cases fail and timeout.

labath added inline comments.Thu, Jul 4, 11:28 PM
source/Plugins/Process/Windows/Common/ProcessDebugger.cpp
170–171

I am fine with keeping the pid field here as this seems to be a larger issue that ought to be handled separately.