Greg Clayton wrote:
Your problem seems to be that ELF files all claim to have the host OS and vendor:
ObjectFileELF::GetArchitecture (ArchSpec &arch)
However, in my working copy (only a week old), GetArchitecture's logic is duplicated by GetModuleSpecifications, and upon invoking "target create" my lldb ends up using the host's specification:
ObjectFileELF::GetModuleSpecifications (const lldb_private::FileSpec& file,
// We could parse the ABI tag information ...
But regardless of this, i.e. ObjectFileELF::Get* returning unreliable OS type at "target create", I think the problem is when the target's inferior is first attached, particularly in the case of embedded targets modeled by "ProcessGDBRemote", the target architecture is not correctly "adjusted" when the qHostInfo/qProcessInfo are received from the stub (why have the messages if they are not acted on?).
In ProcessGDBRemote::DoConnectRemote, we have:
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? In my opinion, this is the cause of a lot of my problems.
However, if I comment out "if (!m_target.GetArchitecture().IsValid())" and allow the SetArchitectures to proceed, I still run into problems, since:
Target::SetArchitecture (const ArchSpec &arch_spec)
m_arch = arch_spec;
==> SetExecutableModule (executable_sp, true);
That is, the arch_spec my gdb-remote passes to SetArchitecture, is firstly assigned to m_arch, but is then overwritten by SetExecutableModule.
It turns out that SetExecutableModule overwrites the archspec supplied by my stub, since
==>m_arch = executable_sp->GetArchitecture();
!m_arch.IsValid() occurred, seemingly, because my stub was not setting cputype. However, when I setup the "cputype" in qHostInfo, more problems arise:
GDBRemoteCommunicationClient::GetHostInfo (bool force)
if (cpu != LLDB_INVALID_CPUTYPE)
since the code inside this logic then sets up some very apple/ios/macosx behaviour.
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?
But it would be better to also look around in the ELF file and look for .note sections or anything else that can help you determine the correct triple for a given ELF file. If "kalimba" architectures are never native you can put an extra check in here. You might be able to also look at the type of the ELF file in the ELF header (e_type) and see if it is:
ET_NONE - probably best not to set the os and vendor to host (is this the kind of file you have?)
ET_EXEC, ET_DYN, ET_CORE - do what is being done above with host architectures and maybe add some .note code to see if you can identify anything more about the binary. I am guessing linux ELF files for executables and shared libraries have something that you will be able to use to properly identify them.
So some more intelligent code in the ObjectFileELF can help us to classify the binaries more correctly, it should improve things in LLDB.
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.
Out of interest the ELF for one of our kalimba variants is as follows:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: <unknown>: 0x72ec
Entry point address: 0x80000000
(Sooner or later I'd like to submit a patch to upstream lldb with core definitions for this chip. )
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.