[lldb-dev] [RFC] lldb integration with (user mode) qemu

[Pavel Labath via lldb-dev]

Thanks for reading this. Responses inline.

On 28/10/2021 16:28, David Spickett wrote:
> Glad to hear the gdb server in qemu plays nicely with lldb. Perhaps
> some of that is the compatibility work that has been going on.
> 
>> The introduction of a qemu platform would introduce such an ambiguity, since (when running on a linux host) a linux executable would be claimed by both the qemu plugin and the existing remote-linux platform. This would prevent "target create arm-linux.exe" from working out-of-the-box.
> 
> I assume you wouldn't get a 3 way tie here because in connecting to a
> remote-linux you've "disconnected" the host platform, right?
IIUC, the host platform is not consulted at this step. It can only be 
claim an executable when it is selected as the "current" platform, 
because the current platform is consulted first. (And this is what 
happens in most "normal" debug sessions.)

So there wouldn't be a three-way tie, but if you actually wanted to 
debug a native executable under qemu, you would have to explicitly 
select the qemu platform. This is the same thing that already happens 
when you want to debug a native executable remotely, but there it's kind 
of expected because you need to connect to the remote machine anyway.

> 
>> To resolve this, I'd like to create some kind of a mechanism to give preference to some plugin.
> 
> This choosing of plugin, does it mostly take place automatically at
> the moment or is there a good spot where we could say "X and Y could
> load this file, please choose one/resolve the tie"?
This currently happens in TargetList::CreateTargetInternal, and one 
cannot create a prompt there, as that code is also used by the 
non-interactive paths (SBDebugger::CreateTarget, for instance). But I 
like the idea, and it may not be too difficult to refactor this to make 
that work. (I am imagining changing this code to use llvm::Error, and 
then creating a special AmbiguousPlatformError type, which could get 
caught by the command line code and transformed into a prompt.)

> 
> My first thought for automatic resolve is a native/emulator/remote
> sort of hierarchy if you were going to order them. (with some nice
> message "preferring X to Y because..." when it starts up)
Do you mean like, each platform would advertise its kind 
(host/emulator/remote), and the relative kind priorities would be 
hardcoded in lldb?

> 
>> a) have just a single set of settings, effectively limiting the user to emulating just a single architecture per session. While it would most likely be enough for most use cases, this kind of limitation seems artificial.
> 
> One aspect here is the way you configure them if you want to use many
> architectures of qemu-user.
> 
> If I have only one platform, I set qemu-user.foo to some Arm focused
> value. Then if I want to work on AArch64 I edit my lldbinit to switch
> it. (or have many init files)
> If there's one platform per arch I can set qemu-arm.foo and qemu-aarch64.foo.
Yes, those were my thoughts as well, but I am unsure how often would 
that occur in practice (I'm pretty sure I'll need to care for only one 
arch for my use case).

> 
> Not much between them without having a specific use case for it. You
> could work around either in various ways.
> 
> Wouldn't most of the platform entries just be subclasses of some
> generic qemu-user-platform? So code wise it wouldn't be that much
> extra to add them.
Yeah, it's possible they wouldn't even be actual classes, just different 
instances of the same class.

> You could say it's bad to list qemu-xyz-platform when that isn't
> installed, but then again, lldb lists a "local Mac OSX user platform
> plug in" even on Linux. So not a big deal.
Yeah, I don't think it's a big deal either. The reason I'm asking this 
is to try to create a consistent experience. For example, we have a 
bunch of PlatformApple{Watch,TV,...}{Remote,Simulator} platforms (only 
available on apple hosts). These don't differ in architectures, but they 
do differ in the environment part of the triples, so you (almost) have a 
one-to-one mapping between triples and architectures.

However, they're also automatically configured (based on the xcode 
installation), and they don't create ambiguities (simulators have 
separate triples), so I'm not sure what kind of parallels to draw from that.

pl