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

[Pavel Labath via lldb-dev]

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