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.
_______________________________________________
lldb-dev mailing list
lldb-dev@cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
