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

[David Spickett via lldb-dev]

> I don't think it does. Or at least I'm not sure how do you propose to solve them (who is "you" in the paragraph above?).

I tend to use "you" meaning "you or I" in hypotheticals. Same thing as
"if I had" but for whatever reason I phrase it like that to include
the other person, and it does have its ambiguities.

What I was proposing is, if I was correct (which I wasn't) then having
the user "platform select qemu-user" would solve things. (which it
doesn't)

> What currently happens is that when you open a non-native (say, linux) executable, the appropriate remote platform gets selected automatically.

...because of this. I see where the blocker is now. I thought remote
platforms had to be selected before they could claim.

> If we do have a prompt, then this may not be so critical, though I expect that most users would still prefer it we automatically selected qemu.

Seems reasonable to put qemu-user above remote-linux. Only claiming if
qemu-user has been configured sufficiently. I guess architecture would
be the minimum setting, given we can't find the qemu binary without
it.

Is this similar in any way to how the different OS remote platforms
work? For example there is a remote-linux and a remote-netbsd, is
there enough information in the program file itself to pick just one
or is there an implicit default there too?
(I see that platform CreateInstance gets an ArchSpec but having
trouble finding where that comes from)

On Fri, 29 Oct 2021 at 13:10, Pavel Labath <pavel at labath.sk> wrote:
>
> On 29/10/2021 14:00, Pavel Labath via lldb-dev wrote:
> > On 29/10/2021 12:39, David Spickett wrote:
> >>> 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.
> > It does. I am perfectly fine with preferring host over qemu-user.
> >
> >> 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?
> > I don't think it does. Or at least I'm not sure how do you propose to
> > solve them (who is "you" in the paragraph above?).
> >
> > What currently happens is that when you open a non-native (say, linux)
> > executable, the appropriate remote platform gets selected automatically.
> > $ lldb aarch64/bin/lldb
> > (lldb) target create "aarch64/bin/lldb"
> > Current executable set to 'aarch64/bin/lldb' (aarch64).
> > (lldb) platform status
> >    Platform: remote-linux
> >   Connected: no
> >
> > That happens because the remote-linux platform unconditionally claims
> > the non-native executables (well.. it claims all of them, but it is
> > overridden by the host platform for native ones). It does not check
> > whether it is connected or anything like that.
> >
> > And I think that behavior is fine, because for a lot of actions you
> > don't actually need to connect to anything. For example, you usually
> > don't connect anywhere when inspecting core files (though you can do
> > that, and it would mean lldb can download relevant shared libraries).
> > And you can always connect at a later time, if needed.
> >
> > Now the question is what should the new platform do. If it followed the
> > remote-linux pattern, it would also claim those executables
> > unconditionally, we would always have a conflict (*).
>
> I meant to add an explanation for this asterisk. I was going to say that
> in the current setup, I believe we would just choose whichever platform
> comes first (which is the first platform to get initialized), but that
> is not that great -- ideally, our behavior should not depend on the
> initialization order.
>
> >
> > Or, it can try to be a bit less greedy and claim an executable only when
> > it is configured. That would mean that in a clean state, everything
> > would behave as it. However, the conflict would reappear as soon as the
> > platform is configured (which will be always, for our users). The idea
> > behind this (sub)feature was that there would be a way to configure lldb
> > so that the qemu plugin comes out on top (of remote-linux, not host).
> >
> > If we do have a prompt, then this may not be so critical, though I
> > expect that most users would still prefer it we  automatically selected
> > qemu.
>
> I also realized that implementing the prompt for the case where the
> executable is specified on the command line will be a bit tricky,
> because at that lldb hasn't gone interactive yet. I don't think there's
> any reason why it shouldn't prompt a user in this case, but doing it may
> require refactoring some of our startup code.
>
> >
> >
> >>
> >>> 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.
> >
> > Yes, that's the hypothetical I had in mind too. I don't think we will be
> > doing it, but I can imagine _somebody_ wanting to do it.
> >
> >
> > pl
> > _______________________________________________
> > lldb-dev mailing list
> > lldb-dev at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>