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
_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
