For anyone following along, I have now posted the first patch for this
feature here: <https://reviews.llvm.org/D114509>.
pl
On 08/11/2021 11:03, David Spickett wrote:
I actually did consider this, but it was not clear to me how this would tie in
to the rest of lldb.
The "run qemu and connect to it" part could be reused, of course, but what else?
That part seems like a good start. I'm sure a lot of other things
would break/not work like you said but if I was shipping a modified
lldb anyway maybe I'd put the effort in to make it work nicely.
Again not something this work needs to consider. Just me relating the
idea to something I have more experience with and has some parallels
with the qemu-user idea.
On Fri, 5 Nov 2021 at 14:08, Pavel Labath via lldb-dev
<lldb-dev@lists.llvm.org> wrote:
On 04/11/2021 22:46, Jessica Clarke via lldb-dev wrote:
On Fri, Oct 29, 2021 at 05:55:02AM +0000, David Spickett via lldb-dev wrote:
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)
Please make sure you don't forget that bsd-user also exists (and after
living in a fork for many years for various boring reasons is in the
middle of being upstreamed), so don't tie it entirely to remote-linux.
I am. In fact one of the reason's I haven't started putting up patches
yet is because I'm trying to figure out the best way to handle this. :)
My understanding is (let me know if I'm wrong) is that user-mode qemu
can emulate a different arhitecture, but not a different os. So, the
idea is that the "qemu" platform would forward all operations that don't
need special handling to the "host" platform. That would mean you get
freebsd behavior when running on freebsd, etc.
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
