Page MenuHomePhabricator

[lldb-server] Add remote platform capabilities for Windows
Needs ReviewPublic

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

Details

Summary

Implement a few routines for Windows to support some basic process interaction and file system operations.

Diff Detail

Event Timeline

asmith created this revision.Wed, Jan 2, 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.Mon, Jan 7, 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.Tue, Jan 8, 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.Fri, Jan 11, 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