[lldb-dev] Target::ReadMemory query

[Matthew Gardiner]

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.

then using gdb-remote to map to the inferior?

for example:

(lldb) gdb-remote <port>
...
(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.
> 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.

thanks again
Matt



Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Keep up to date with CSR on our technical blog, www.csr.com/blog, CSR people blog, www.csr.com/people, YouTube, www.youtube.com/user/CSRplc, Facebook, www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter at www.twitter.com/CSR_plc.
New for 2014, you can now access the wide range of products powered by aptX at www.aptx.com.