> 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
