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