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