[lldb-dev] Questions for module/symbol load/unload events

[Jeffrey Tan via lldb-dev]

My assumption is that different sections of the binary will be mapped
continuously in memory; and the first section(which should be a header
section for the binary) will stands for the base address of the whole
module.
Is this assumption not true for all platforms? Basically, I would like to
show the memory range of the whole module, instead of just text section, so
that if a debugger user got a magic address, he can quickly examine the
image list to see which binary this address falls into. I guess I can
calculate and combine all sections, but it is a bit cumbersome to do.

On Mon, Feb 29, 2016 at 4:02 PM, Greg Clayton <gclayton at apple.com> wrote:

> As Jim said there really isn't just one address per module. You will want
> to display the address of each of the sections for a module under that
> module. So something like:
>
>
> a.out
>   |- .text @ 0x10000
>   |- .data @ 0x20000
>   \- .bss  @ 0x30000
>
>
> > On Feb 29, 2016, at 2:02 PM, Jeffrey Tan <jeffrey.fudan at gmail.com>
> wrote:
> >
> > Btw: I did not find an API to retrieve the load address of the SBModule?
> This seems to be weird to me, did I miss anything?
> >
> >
> > On Mon, Feb 29, 2016 at 1:34 PM, Jeffrey Tan <jeffrey.fudan at gmail.com>
> wrote:
> > I see why I did not find them in the first place. These two APIs are not
> listed in the official doc:
> > http://lldb.llvm.org/python_reference/index.html
> >
> > Someone might want to add it.
> >
> > Thanks
> > Jeffrey
> >
> > On Mon, Feb 29, 2016 at 11:59 AM, Jeffrey Tan <jeffrey.fudan at gmail.com>
> wrote:
> > This is very useful, thanks for the info!
> >
> > On Mon, Feb 29, 2016 at 10:36 AM, Jim Ingham <jingham at apple.com> wrote:
> >
> >> On Feb 27, 2016, at 8:34 PM, Jeffrey Tan via lldb-dev <
> lldb-dev at lists.llvm.org> wrote:
> >>
> >> Hi,
> >>
> >> I am trying to listen for module/symbol load/unload events and display
> them in output UI so that debugger users can have a basic clue what is
> debugger busy doing while launching a big executable linking many shared
> libraries.
> >>
> >> Questions:
> >> 1. I did not find an API to get current load/unload module during
> module events. I was expecting some static API like lldb.SBModule(or
> SBTarget).GetModuleFromEvent(SBEvent), but this does not exists. I tried to
> treat current PC's module as loading module in module load/unload events.
> But that does not work too(I think because process is not stopped in module
> load/unload events). Do I miss something here?
> >
> > From SBTarget.h:
> >
> >     static uint32_t
> >     GetNumModulesFromEvent (const lldb::SBEvent &event);
> >
> >     static lldb::SBModule
> >     GetModuleAtIndexFromEvent (const uint32_t idx, const lldb::SBEvent
> &event);
> >
> > Note, you can also cause the process to stop with modules are loaded
> with the setting:
> >
> > target.process.stop-on-sharedlibrary-events
> >
> > if that is more convenient for you.
> >
> >>
> >> 2. Even though "image list" shows I have around 42 modules loaded in
> process, I only got two module load events. Why is that?
> >
> > On OS X the loader loads the closure of modules for whatever it is
> loading, and only stops and informs the debugger when this is all done.  So
> it is quite usual to see only a few load events even though many modules
> get loaded.
> >
> >
> >>
> >> 3. Even though I added lldb.SBTarget.eBroadcastBitSymbolsLoaded, there
> is no event of type eBroadcastBitSymbolsLoaded generated. Is it expected?
> Apparently I have the symbols next to the binary.
> >
> > That event gets sent when symbols are added to an already loaded
> module.  It is so a UI will know to refresh the backtrace, local variables,
> source view, etc when code goes from having no symbols to having some
> symbols.  Those actions are not needed if the library & its symbols get
> loaded simultaneously, so it isn’t sent in that case.
> >
> > Jim
> >
> >
> >>
> >> This is tested on mac OSX lldb.
> >>
> >> Jeffrey
> >> _______________________________________________
> >> lldb-dev mailing list
> >> lldb-dev at lists.llvm.org
> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
> >
> >
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20160229/bc01b221/attachment-0001.html>