[lldb-dev] Target::ReadMemory query

[Greg Clayton]

> On Jun 12, 2014, at 12:29 AM, Matthew Gardiner <mg11 at csr.com> wrote:
> 
> Greg Clayton wrote:
>>> So in my case, since my target's architecture is already "valid" (i.e. m_core is defined, etc.), the DoConnectRemote code doesn't consider the stub's opinion on the target. Surely in the remote/embedded case we must trust the stub's host info if supplied?
>> Not necessarily. A host can be "x86_64-apple-macosx", yet if we are debugging an iOS simulator app we will get "x86_64-apple-ios" as the process triple. So really we want to really trust the process info over the host info.
>> 
> Sorry, Greg, I didn't make my point that well, what I meant was that we should trust the information that the stub returns to us, in the form of the qHostInfo and qProcessInfo messages. I don't think we should be overwriting this data with data from the ELF, which I saw happening in lldb earlier on in my analysis.
> 
>>> I apologise for the above braindump, but my conclusion is that to get lldb to work properly for non-apple, non-linux, etc. bare-metal embedded architectures, I need to submit several patches, in particular to the gdb-remote handling logic.
>>> 
>>> With your blessing, are you happy for me to do this?
>> We need to watch out for certain pitfalls, but yes, this should work better than it does now and fixes are required. We just need to make sure not to regress on the desktop and remote targets with any changes we make.
> Cool, thanks.
>>> I'm happy to supply some better ObjectFileELF code in lldb. But my opinion as stated above is that the information received from the stub should *strongly* influence the specification of the architecture/OS etc. in the final Target object.
>> We need both to be correct. The object files often determine the triple before we run and we want to get this right in the object file. After we run, you might have created a target with a completely wrong file and arch and we might need to change things once we attach. So both should be possible and be as correct as they can be.
> 
> Yes, agreed. In an embedded debugging session it is the information regarding the running inferior, modeled by the gdb-remote, which reflects the reality of the situation.
> 
> Incidentally, do you ever envisage a scenario where lldb could create an empty target, that is, from the command-line:
> 
> (lldb) target create
> Target container created.
> 

We could allow with an option:

(lldb) target create --empty

The lldb::SB API currently allows you to create an empty target by specifying None for the path and triple:

(lldb) script target = lldb.debugger.CreateTarget(None)

> then using gdb-remote to map to the inferior?
> 
> for example:
> 
> (lldb) gdb-remote <port>

You can currently do this:

% lldb
(lldb) gdb-remote <port>

The problem is if you already have a target it will try to re-use the currently selected target, but if you are starting from scratch it will work as it will create a target if there isn't one.

> ...
> (lldb) target list
> Current targets:
> * target #0: (empty) ( arch=devicename-unknown-unknown, state=running, etc. )
> 
> In this scenario, clearly there would be no symbolic lookup, address/line mapping, and so on. However, disassembly (with breakpoints and instruction step), and memory/register access, would still be possible. Such a feature does have value in the embedded world. I believe that gdb can currently achieve this.

We can too. Just don't create a target and call "gdb-remote ...". This is where the world of lldb_private::Platform instances come in. When we attach to a binary, you might have a dynamic loader that can find all loaded images (executables and shared libraries, or just a collection of ROM images) and using the UUID and the image names, your Platform might be able to locate the required files on disk. For iOS for example, we might be asked to find a "/usr/lib/libfoo.dylib" with UUID 8AA96CBA-EFD6-31B1-AC82-75ED1CEEDE77. The PlatformRemoteiOS knows to go look in the SDK on disk for a local copy of this image which we can find in "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS8.0.sdk/usr/lib/libfoo.dylib", so if your embedded platform has a common way of storing files or can use some system search features (like Spotlight on MacOSX, and I am sure there is some similar window and linux system wide searching APIs) to locate the required files and make it "just work".


>> You could currently assume if the Elf header contains kalimba (0x72ec) that its triple is always then unknown-unknown.
> Indeed. But also nice to also extract that information from the gdb-remote packets mentioned above. I'm going to try achieve this.

I look forward to seeing what you come up with.