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

[David Spickett via lldb-dev]

> Yeah, I think we can start with that.

No need to consider this now but it could easily be adapted to
qemu-system as well. Spinning up qemu-system for Cortex-M debug might
be a future use case. Once you've got a "run this program and connect
to this port" platform you can sub in almost anything that talks GDB.

> Having some mechanism to resolve ambiguities might also help with that.

Cool, I figured someone would have thought about it on the ELF side.
So as long as Linux remains the standout things work ok.

Most importantly, the way it's currently handled doesn't contradict
anything you want to do here.

On Wed, 3 Nov 2021 at 10:34, Pavel Labath <pavel at labath.sk> wrote:
>
> On 29/10/2021 14:55, David Spickett 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)
> Great, thanks for clarifying.
>
> >> 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.
> Yeah, I think we can start with that.
>
> > 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?
> This is actually one of the pain points in lldb. The overall design
> assumes that you can precisely identify the platform(triple) that the
> file is meant to be run on by looking at the object file. This is
> definitely true on Apple platforms (where lldb originated) as even the
> "simulator" binaries have their own triples.
>
> The situation is more fuzzy in the elf world. TTe *bsd oses have (and
> use) a ELFOSABI_ constant to identify the binary. Linux uses
> ELFOSABI_NONE even though there is a dedicated constant it could use
> (there's probably an interesting story in there). This makes it hard to
> positively identify a file as a linux binary, but we can mostly get away
> with it because there's just one OS like that. Having some mechanism to
> resolve ambiguities might also help with that.
>
> I'm also not sure how much do the OSes actually validate the contents of
> the elf headers. I wouldn't be surprised if one could create "polyglot"
> elf binaries that can run on multiple operating systems.
>
> > (I see that platform CreateInstance gets an ArchSpec but having
> > trouble finding where that comes from)
> It gets called from
> TargetList::CreateTargetInternal->Platform::CreateTargetForArchitecture->Platform::Create.
> There may be other callers, but I think this is the relevant one.
>
> pl