[lldb-dev] issue with StackFrame::GetSymbolContext

[Jim Ingham via lldb-dev]

A "raw image" is one that loads all the code at some address and doesn't have a dynamic loading mechanism.  So it really just means "a binary that doesn't use a dynamic loader."  I'm not sure why it was called "Strata"...

But the Strata is used to disambiguate cases where the object file format gets used both for user processes that have a dynamic linker, and for embedded uses that don't.  See for instance ObjectFile::Strata ObjectFileMachO::CalculateStrata which figures out from data in the object file whether it runs with the dynamic linker or not...

Jim

> On Jul 12, 2019, at 3:58 AM, Romaric Jodin <rjodin at upmem.com> wrote:
> 
> Thanks Jim, it helped a lot. But it bings other questions.
> I managed to get the symbol by forcing the use of the DynamicLoaderStatic, which is use only if the Strata is set to "eStrataRawImage".
> What is "Strata" ?
> Why is the Static DynamicLoader only use with the eStrataRawImage?
> 
> Right now, I don't feel the need to implement a DynamicLoader specific for my backend as the static seems to be doing the job just fine. But maybe I'll have to at some point.
> Anyway, Thanks again, it helps me going forward with the implementation.
> 
> Romaric
> 
> On Tue, Jul 9, 2019 at 7:53 PM Jim Ingham <jingham at apple.com> wrote:
> It looks like you don't have a DynamicLoader plugin that tells lldb where your binaries ended up in memory when the process ran.  The [ADDRESS] means we are reading instructions from memory not from the on-disk binary.
> 
> Jim
> 
> 
> > On Jul 9, 2019, at 2:14 AM, Romaric Jodin via lldb-dev <lldb-dev at lists.llvm.org> wrote:
> > 
> > HI everyone,
> > 
> > I'm adding my architecture into lldb.
> > I'm having some trouble with the debug information on the stack frame.
> > LLDB is never displaying any source code. It seems that we I get in "StackFrame::GetSymbolContext" "m_flags" is always set to "0xffffffff" but my "m_sc" does not contains the information needed about the module ("module_sp=0x0").
> > But LLDB can read the elf file and find information like here:
> > 
> > Process 21312 stopped
> > * thread #1, name = 'DPUthread0', stop reason = suspended
> >     frame #0: 0x80000018
> > test`__bootstrap:
> >     test[0x80000018] <+24>: sub    r0, r0, 0x1, pl, 0x80000010
> >     test[0x80000020] <+32>: jgeu   id, 0x3, 0x80000058
> >     test[0x80000028] <+40>: jeq    id, 0x2, 0x80000038
> >     test[0x80000030] <+48>: boot   id, 0x1
> > 
> > or here:
> > 
> > (lldb) b main
> > Breakpoint 1: where = test`main + 32 at test.c:29, address = 0x80000080
> > 
> > Do someone get what I'm missing?
> > 
> > Thanks,
> > -- 
> > Romaric JODIN
> > UPMEM
> > Software Engineer
> > 
> > <logo signature mail 50x50.png>
> > _______________________________________________
> > lldb-dev mailing list
> > lldb-dev at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> 
> 
> 
> -- 
> Romaric JODIN
> UPMEM
> Software Engineer
> 
> <logo signature mail 50x50.png>