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

[David Spickett via lldb-dev]

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

Since we already have the host vs remote with native arch situation,
is it any different to ask users to do "platform select qemu-user" if
they really want qemu-user? Preferring host to qemu-user seems
logical.
For non native it would come up when you're currently connected to a
remote but want qemu-user on the host. So again you explicitly select
qemu-user.

Does that solve all the ambiguous situations?

> Do you mean like, each platform would advertise its kind (host/emulator/remote), and the relative kind priorities would be hardcoded in lldb?

Yes. Though I think that opens more issues than it solves. Host being
higher priority than everything else seems ok. Then you have to think
about how many emulation/connection hops each one has, but sometimes
that's not the metric that matters. E.g. an armv7 file on a Mac would
make more sense going to an Apple Watch simulator than qemu-user.

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

Seems like starting with a single "qemu-user" platform is the way to
go for now. When it's not configured it just won't be able to claim
anything.

The hypothetical I had was shipping a development kit that included
qemu-arch1 and qemu-arch2. Would you rather ship one init file that
can set all those settings at once (since each one has its own
namespace) or symlink lldb-arch1 to be "lldb -s <init with settings
for arch1>". However anyone who's looking at shipping lldb has control
of the sources so they could make their own platform entries. Or
choose a command line based on an IDE setting.

On Fri, 29 Oct 2021 at 10:13, Pavel Labath <pavel at labath.sk> wrote:
>
> 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