This is an archive of the discontinued LLVM Phabricator instance.

Avoid going through Platform when creating a NativeProcessProtocol instance
ClosedPublic

Authored by labath on Jul 7 2015, 8:20 AM.

Details

Summary

This commit avoids the Platform instance when spawning or attaching to a process in lldb-server.
Instead, I have the server call a (static) method of NativeProcessProtocol directly. The reason
for this is that I believe that NativeProcessProtocol should be decoupled from the Platform
(after all, it always knows which platform it is running on, unlike the rest of lldb).
Additionally, the kind of platform actions a NativeProcessProtocol instance is likely to differ
greatly from the platform actions of the lldb client, so I think the separation makes sense.

After this, the only dependency NativeProcessLinux has on PlatformLinux is the ResolveExecutable
method, which needs additional refactoring.

Diff Detail

Repository
rL LLVM

Event Timeline

labath updated this revision to Diff 29183.Jul 7 2015, 8:20 AM
labath retitled this revision from to Avoid going through Platform when creating a NativeProcessProtocol instance.
labath updated this object.
labath added reviewers: ovyalov, clayborg.
labath added a subscriber: lldb-commits.
clayborg accepted this revision.Jul 7 2015, 10:08 AM
clayborg edited edge metadata.

So the reason we originally involved the platform is that you might want to select a different platform (like a simulator platform) and have it create its own NativeProcess (I concede that the "NativeProcess" is not quite right for this assumption). Fine to remove it for now and we can change the names around if we ever need this functionality.

This revision is now accepted and ready to land.Jul 7 2015, 10:08 AM
ovyalov accepted this revision.Jul 7 2015, 10:43 AM
ovyalov edited edge metadata.

lgtm

labath added a comment.Jul 8 2015, 2:01 AM

So the reason we originally involved the platform is that you might want to select a different platform (like a simulator platform) and have it create its own NativeProcess (I concede that the "NativeProcess" is not quite right for this assumption). Fine to remove it for now and we can change the names around if we ever need this functionality.

Thanks for the explanation. I was not aware of these plans, but I will keep them in mind for the future.

This revision was automatically updated to reflect the committed changes.