[lldb-dev] Multiple platforms with the same name

[Jim Ingham via lldb-dev]

> On Jan 19, 2022, at 4:28 AM, Pavel Labath <pavel at labath.sk> wrote:
> 
> 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.

We made a choice early on in lldb that it would be a one-to-many debugger (as opposed to gdb where you use one gdb process to debug one inferior).  The idea was to allow people who have more complex inter-app communications to use the scripting features of lldb to make the process of debugging IPC and such-like more natural (like a “step-in” that steps across process boundaries when you step into a message dispatch).  Or to run two instances that are slightly different and compare the paths through some bit of code.  Or other cool uses we hadn’t thought of.  I don’t do this kind of debugging much either, but then I just debug lldb all the time which is a fairly simple process, and it’s communication with the stub is pretty simple.  So I don’t think that’s dispositive for how useful this design actually is...

Since the Platform class holds details about the current debug sessions on that platform, it has to take part in this design, which means either allowing one Platform to connect to all instances of it’s kind that lldb might want to debug, or making one Platform per instance.  The latter design was what we had always intended, it is certainly how we’ve talked about it for as long as I can remember.  OTOH, the whole Platform class is a bit of a mashup, since it holds both “things you need to know about a class of systems in order to debug on them” and “the connection you make to a particular instance”.  I think the intention would be clearer if we separated the “PlatformExpert” part of Platform and the “the Remote machine I’m talking to” part of Platform.

> 
> 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.

Definitely worth it IMO.  I don’t know about you, but I mostly debug lldb which is a pretty simple debugging scenario.  There are lots of complicated things folks do with lldb that I seldom do...

Also, it would be weird if we went to all this effort to make it possible for one lldb to debug several processes at the same time, even allowing it if the two processes are on different platforms, but disallowed it if the processes happened to be on two machines with the same platform.

> - 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.

W.r.t. the qemu settings, at least the architecture and env-vars are specific to the instance, so it really seems like these should be per instance; setting the working directory is also something that is specific to one targeted system.  I could also imagine if you were working on qemu, being able to step through something running on two instances at the same time might be useful for figuring out why one or the other qemu instance was misbehaving.  So “how to launch” the emulator also seems like it should be per-instance.

Moreover, it seems to me that if you wanted to debug a problem with two machine intercommunication where you were following message flow from a process on machine A to one on machine B, having two VM’s talking to one another would be a very convenient workbench for those investigations.   So supporting multiple instances seems worth doing.

Jim


> 
> Let me know what you think,
> Pavel