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

[Pavel Labath via lldb-dev]

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

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.


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