Re: [lldb-dev] [RFC] lldb integration with (user mode) qemu
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
Re: [lldb-dev] [RFC] lldb integration with (user mode) qemu
> 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. 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? > 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 ". 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. On Fri, 29 Oct 2021 at 10:13, Pavel Labath wrote: > > 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 wor
Re: [lldb-dev] [RFC] lldb integration with (user mode) qemu
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 ". 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
Re: [lldb-dev] [RFC] lldb integration with (user mode) qemu
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 ". 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-
Re: [lldb-dev] [RFC] lldb integration with (user mode) qemu
> 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 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'
