[lldb-dev] Target::ReadMemory query
gclayton at apple.com
Mon Jun 9 10:13:38 PDT 2014
> On Jun 5, 2014, at 11:14 PM, Matthew Gardiner <mg11 at csr.com> wrote:
> I have a question regarding some of the logic of "Target::ReadMemory".
> I'm looking at this code:
> (in my copy this is line 1314)
> if (!addr.IsSectionOffset())
> SectionLoadList §ion_load_list = GetSectionLoadList();
> if (section_load_list.IsEmpty())
> // No sections are loaded, so we must assume
> // we are not running yet and anything we are given is
> // a file address.
> file_addr = addr.GetOffset();
> // "addr" doesn't have a section, so its offset is the
> //file address
> m_images.ResolveFileAddress (file_addr, resolved_addr);
> // We have at least one section loaded. This can be becuase
> // we have manually loaded some sections with
> // "target modules load ..."
> // or because we have have a live process that has
> // sections loaded
> // through the dynamic loader
> load_addr = addr.GetOffset();
> // "addr" doesn't have a section,
> //so its offset is the load address
> section_load_list.ResolveLoadAddress (load_addr, resolved_addr);
> My question is why is section_load_list.IsEmpty() used (according to the comment below it) to deduce that the target is not running?
Its not that it is running, it is for cases where you are symbolicating or manually loading images at various addresses. For symbolication we do things like:
1 - create target with /bin/ls (and it will load a bunch of shared libraries)
(lldb) file /bin/ls
2 - take a crash log and load all executable images at their crash site location:
(lldb) image load --file "/bin/ls .text 0x10000
(lldb) image load --file "/usr/lib/libc.so .text 0x10000000
3 - make a memory request using the PC from the crash log:
(lldb) memory read 0x10018
So if the target has mapped any modules to any addresses, we wish to be able to resolve these addresses. If they are section/offset addresses, then often these sections have data in the object files that can be read (like all code in your .text segments).
> Further down the Target::ReadMemory I see the invocation ProcessIsValid() to discover the reverse. So why don't we just use
> if(!ProcessIsValid()) instead of section_load_list.IsEmpty() earlier on in this function?
Because of the above case.
> (To be clear: I'm looking at this as I'm trying to debug a loaded/running embedded target, over a gdb-remote, and my debug of the lldb session reports section_load_list.IsEmpty(). Possibly another issue, yes, but I think my question above still applies.)
> I'm wondering if anyone in lldb-dev can comment on this?
The the basic answer is that Target::ReadMemory is often used to be able to read data from the sections of your object files when you aren't running yet and can do so using faked "load addresses" when the target's section load list has some valid entries. The target's section load list will be empty unless a dynamic loader modifies them at runtime or the user manually loaded section addresses using "target modules load" or one of the SBTarget APIs.
Your embedded target should be using "<arch>-unknown-unknown" for a triple. This will cause your target at runtime to use the DynamicLoaderStatic plug-in which will set the "load" address for all of your binary images to match the "file" address in the file and should give you the result you are looking for.
> 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 at cs.uiuc.edu
More information about the lldb-dev