Your problem seems to be that ELF files all claim to have the host OS and
vendor:
bool
ObjectFileELF::GetArchitecture (ArchSpec &arch)
{
if (!ParseHeader())
return false;
arch.SetArchitecture (eArchTypeELF, m_header.e_machine,
LLDB_INVALID_CPUTYPE);
arch.GetTriple().setOSName (Host::GetOSString().GetCString());
arch.GetTriple().setVendorName(Host::GetVendorString().GetCString());
return true;
}
This code should probably check if the host architecture has the same CPU type
before setting this:
bool
ObjectFileELF::GetArchitecture (ArchSpec &arch)
{
if (!ParseHeader())
return false;
arch.SetArchitecture (eArchTypeELF, m_header.e_machine,
LLDB_INVALID_CPUTYPE);
// TODO: add code to look at .note sections and anything else in the
program headers,
// section headers, symbol table, etc to properly determine the vendor and
OS.
ArchSpec host_arch_32(Host::GetArchitecture
(Host::eSystemDefaultArchitecture32);
ArchSpec host_arch_64(Host::GetArchitecture
(Host::eSystemDefaultArchitecture32);
// Only set the vendor and os to the host values if the architectures match
if ((host_arch_32.IsValid() && arch.IsCompatibleMatch(host_arch_32) ||
(host_arch_64.IsValid() && arch.IsCompatibleMatch(host_arch_64))
{
arch.GetTriple().setOSName (Host::GetOSString().GetCString());
arch.GetTriple().setVendorName(Host::GetVendorString().GetCString());
}
return true;
}
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.
> On Jun 10, 2014, at 6:28 AM, Matthew Gardiner <[email protected]> wrote:
>
> Matthew Gardiner wrote:
>> (I get the DynamicLoaderPOSIXDYLD used, regardless of whether my triple
>> string is kalimba-unknown-unknown or i386-unknown-unknown. kalimba is our
>> chip's name).
>>
>> I'll spend the rest of my day trying to figure out why DynamicLoaderStatic
>> is not being used.
>>
> My hunch was correct (thanks for the hint Greg!) - the dynamic loader plugin,
> was previously DynamicLoaderPOSIXDYLD, if I *hack* stuff, and arrange that
> DynamicLoaderStatic is used, then my ELF has it's sections loaded, and a
> memory read from a known global variable address works. (At that moment a
> smile appears on my face!).
>
> The problem is figuring out why DynamicLoaderPOSIXDYLD was used as the
> dynamic loader in my "embedded target debug".
>
> The first issue I've seen, as to the cause of the above, is that when the
> DYLDers are being queried by plugin discovery, my target's architecture, is
> being reported as having os=linux.
>
> {Data = "unknown--linux"
> Arch = llvm::Triple::UnknownArch
> Vendor = llvm::Triple::UnknownVendor
> OS = llvm::Triple::Linux
> ..}
>
> This is despite my stub, reporting "unknown" in the os part of the triple:
>
> -> qHostInfo
> <- pid:1;endian:little;triple:kalimba-unknown-unknown;ptrsize:4;
> ...
> -> qProcessInfo
> <- pid:1;endian:little;triple:kalimba-unknown-unknown;ptrsize:4;
>
> I guess, I'll have to dig deeper into the Target/Get/Set/Architecture code.
> (After doing more digging, since I first started to pen this mail, I believe
> that upon "target create", my lldb Target object initially acquires the host
> OS's id in it's triple. Perhaps the issue is that ProcessGDBRemote fails to
> subsequently override this? That's what I'm looking at now.)
>
> After forcing my copy's DynamicLoaderPOSIXDYLD::CreateInstance to return
> NULL, the next issue to hack around was:
>
> DynamicLoader *
> DynamicLoaderStatic::CreateInstance (Process* process, bool force)
> {
> ...
> create = (object_file->GetStrata() == ObjectFile::eStrataRawImage);
> ...
> }
>
> when parsing my ELF object_file->GetStrata() returns eStrataUser as the
> strata, and thus initially the DynamicLoaderStatic was not created.
>
> So does not DynamicLoaderStatic::CreateInstance require some modification e.g.
>
> if (object_file)
> {
> const ObjectFile::Strata s = object_file->GetStrata();
> create = (s == ObjectFile::eStrataRawImage) ||
> (s == ObjectFile::eStrataUser);
> }
>
> ?
>
> 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
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/lldb-dev
