[lldb-dev] Target::ReadMemory query
mg11 at csr.com
Tue Jun 10 00:14:04 PDT 2014
Greg Clayton wrote:
> 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.
The DynamicLoader fails to load my sections because GetEntryPoint
returns invalid address:
if (m_entry_point != LLDB_INVALID_ADDRESS)
if (m_auxv.get() == NULL)
AuxVector::iterator I = m_auxv->FindEntry(AuxVector::AT_ENTRY);
if (I == m_auxv->end())
==> return LLDB_INVALID_ADDRESS;
Is one of my problems, the fact that DynamicLoaderPOSIXDYLD is being
used not DynamicLoaderStatic? (Of course my simple embedded target has
no OS, processes, or loaders. However, I do have an ELF file, which I
load prior to gdb-remote using "target create <elf-file>").
Incidentally the first part of my GDB-RSP is:
(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.
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.
More information about the lldb-dev