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

[Pavel Labath via lldb-dev]

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