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