Page MenuHomePhabricator

[lldb-server] Add remote platform capabilities for Windows
ClosedPublic

Authored by asmith on Jan 2 2019, 4:26 PM.

Diff Detail

Event Timeline

asmith created this revision.Jan 2 2019, 4:26 PM
labath added a subscriber: labath.

All of these functions seem identical to their PlatformPOSIX counterparts. Is that right? And I seem to remember already seeing a lot of code duplication between PlatformPOSIX and PlatformWindows.

It sounds to me like we should create a new common base class for PlatformWindows and PlatformPOSIX (RemoteAwarePlatform?), and put the common code there.

All of these functions seem identical to their PlatformPOSIX counterparts. Is that right? And I seem to remember already seeing a lot of code duplication between PlatformPOSIX and PlatformWindows.

It sounds to me like we should create a new common base class for PlatformWindows and PlatformPOSIX (RemoteAwarePlatform?), and put the common code there.

Is that even necessary? If a platform is not remote aware, IsHost() will always just return true by definition. So we could put all of this in the existing Platform base class.

zturner added inline comments.Jan 7 2019, 10:09 AM
source/Plugins/Platform/Windows/PlatformWindows.cpp
189–195

Remove the else here since the if branch already has a return.

193–194

And this else too.

labath added a comment.Jan 8 2019, 2:17 AM

Is that even necessary? If a platform is not remote aware, IsHost() will always just return true by definition. So we could put all of this in the existing Platform base class.

I remember looking at this a while a go and concluding against it, but i'm not sure if it was impossible of just I didn't like the result.

The issue here is that PlatformWindows and PlatformPosix already have a m_remote_platform member (which normally is an instance of PlatformRemoteGDBServer). To move the common class into the base one, we'd need to move this member too. That would mean that any platform has a "remote" member, even those that already are "remote". That sounds a bit weird.

Hui added a subscriber: Hui.Jan 11 2019, 4:51 PM

Is that even necessary? If a platform is not remote aware, IsHost() will always just return true by definition. So we could put all of this in the existing Platform base class.

I remember looking at this a while a go and concluding against it, but i'm not sure if it was impossible of just I didn't like the result.

The issue here is that PlatformWindows and PlatformPosix already have a m_remote_platform member (which normally is an instance of PlatformRemoteGDBServer). To move the common class into the base one, we'd need to move this member too. That would mean that any platform has a "remote" member, even those that already are "remote". That sounds a bit weird.

Yes. I think the thing is the existing design makes PlatformWindows plugin play dual roles: a "host" and "remote-windows" platform which simplily is a pass-through to PlatformRemoteGDBServer. Not quite sure about such intent of design. Maybe to avoid creating new plugin for a remote platform or just to simplifying the init/release in plugin manager. To break them apart, adding back the plugin, maybe PlatformRemoteWindows

PlatformWindows: host implementation only. Most common parts will go to the platform base.

PlatformRemoteWindows: for communicating with remote only. Could just be RemoteAwarePlatform

labath requested changes to this revision.Feb 12 2019, 3:22 AM

RemoteAwarePlatform is a thing now, so you should be able to take the methods from PlatformPOSIX which make sense for you, and sink them into the new class.

This revision now requires changes to proceed.Feb 12 2019, 3:22 AM
Herald added a project: Restricted Project. · View Herald TranscriptFeb 12 2019, 3:22 AM
asmith updated this revision to Diff 186580.Feb 12 2019, 6:53 PM
labath accepted this revision.Feb 12 2019, 10:34 PM

Looks good. Just for future patches, please make sure to only clang-format the lines you actually touch. This patch includes a lot of formatting changes to lines that haven't been substantially changed. If you're using git, there's a plugin command for it, which will allow you to do just that via something like git clang-format HEAD^. I don't know if there's such an easy equivalent for svn, but it should at least be achievable by piping the diff through clang-format.

This revision is now accepted and ready to land.Feb 12 2019, 10:34 PM
asmith updated this revision to Diff 186591.Feb 12 2019, 11:53 PM
asmith closed this revision.Feb 13 2019, 9:34 PM