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

[Pavel Labath via lldb-dev]

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 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