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

[David Spickett via lldb-dev]

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