[lldb-dev] Target::ReadMemory query

[Matthew Gardiner]

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.