[lldb-dev] Target::ReadMemory query

[Greg Clayton]

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 <mg11 at csr.com> 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.