Greg Clayton wrote:
Your problem seems to be that ELF files all claim to have the host OS and
vendor:
Yes, indeed.
bool
ObjectFileELF::GetArchitecture (ArchSpec &arch)
{
if (!ParseHeader())
return false;
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,
...
{
<snip>
if (spec.GetArchitecture().IsValid())
{
// We could parse the ABI tag information ...
==>spec.GetArchitecture().GetTriple().setOSName
(Host::GetOSString().GetCString());
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:
if (!m_target.GetArchitecture().IsValid())
{
if (m_gdb_comm.GetProcessArchitecture().IsValid())
{
m_target.SetArchitecture(m_gdb_comm.GetProcessArchitecture());
}
else
{
m_target.SetArchitecture(m_gdb_comm.GetHostArchitecture());
}
}
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:
bool
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
void
Target::SetExecutableModule
{
....
if (!m_arch.IsValid())
{
==>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:
bool
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:
ELF Header:
Magic: 7f 45 4c 46 01 01 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: EXEC (Executable file)
Machine: <unknown>: 0x72ec
Version: 0x1
Entry point address: 0x80000000
....
(Sooner or later I'd like to submit a patch to upstream lldb with core
definitions for this chip. )
thanks
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
