[lldb-dev] Multiple platforms with the same name

[Pavel Labath via lldb-dev]

On 19/01/2022 00:38, Greg Clayton wrote:
> Platforms can contain connection specific setting and data. You might want to create two different "remote-linux" platforms and connect each one to a different remote linux machine. Each target which uses this platform would each be able to fetch files, resolve symbol files, get OS version/build string/kernel info, get set working directory from the remote server they are attached. Since each platform tends to belong to a target and since you might want to create two different targets and have each one connected to a different remote machine, I believe it is fine to have multiple instances.
> 
> I would vote to almost always create a new instance unless it is the host platform. Though it should be possible to create to targets and possibly set the platform on one target using the platform from another that might already be connected.
> 
> I am open to suggestions if anyone has any objections.
> 
> Greg

I agree that permitting multiple platforms would be a more principled 
position, but it was not clear to me if that was ever planned to be the 
case.

If it was (or if we want it to be), then I think we need to start making 
bigger distinctions between the platform plugins (classes), and the 
actual instantiations of those classes. Currently there is no way to 
refer to "older" instances of the platforms as they all share the same 
name (the name of the plugin). Like, you can enumerate them through 
SBDebugger.GetPlatformAtIndex(), but that's about the only thing you can 
do as all the interfaces (including the SB ones) take a platform _name_ 
as an argument. This gets particularly confusing as in some 
circumstances we end up choosing the newer one (e.g. if its the 
"current" platform) and sometimes the older.

If we want to do that, then this is what I'd propose:
a) Each platform plugin and each platform instance gets a name. We 
enforce the uniqueness of these names (within their category).
b) "platform list" outputs two block -- the list of available plugins 
and the list of plugin instances
c) a new "platform create" command to create a platform
   - e.g. "platform create my-arm-test-machine --plugin remote-linux"
d) "platform select" selects the platform with the given /instance/ name
   - for convenience and compatibility if the name does not refer to any 
existing platform instance, but it *does* refer to a platform plugin, it 
would create a platform instance with the same name as the class. (So 
the first "platform select remote-linux" would create a new instance 
(also called remote-linux) and all subsequent selects would switch to 
that one -- a change to existing behavior)
e) SBPlatform gets a static factory function taking two string arguments
f) existing SBPlatform constructor (taking one string) creates a new 
platform instance with a name selected by us (remote-linux, 
remote-linux-2, etc.), but its use is discouraged/deprecated.
g) all other existing APIs (command line and SB) remain unchanged but 
any "platform name" argument is taken to mean the platform instance 
name, and it has the "platform select" semantics (select if it exists, 
create if it doesn't)

I think this would strike a good balance between a consistent interface 
and preserving existing semantics. The open questions are:
- is it worth it? While nice in theory, personally I have never actually 
needed to connect to more than one machine at the same time.
- what to do about platform-specific settings. The functionality has 
existed for a long time, but there was only one plugin 
(PlatformDarwinKernel) using it. I've now added a bunch of settings to 
the qemu-user platform on the assumption that there will only be one 
instance of the class. These are global, but they would really make more 
sense on a per-instance basis. We could either leave it be (I don't need 
multiple instances now), or come up with a way to have per-platform 
settings, similar like we do for targets. We could also do something 
with the "platform settings" command, which currently only sets the 
working directory.

Let me know what you think,
Pavel