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

[Greg Clayton via lldb-dev]

> On Feb 29, 2016, at 11:02 PM, Jeffrey Tan <jeffrey.fudan at gmail.com> wrote:
> 
> 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. 

That is not correct for all platforms. On MacOSX, any shared library in your DYLD shared cache will have its sections mapped all over the place:

libfoo.dylib __TEXT 0x100000
barfoo.dylib __TEXT 0x200000
libfoo.dylib __DATA 0x8100000
barfoo.dylib __TEXT 0x8200000
libfoo.dylib __OBJC 0x9100000
barfoo.dylib __OBJC 0x9200000

So you can't make any assumptions. That being said, each platform has the notion of where a library is actually loaded. For MacOSX, this is the address of the __TEXT segment. Not sure for other platforms.

The easy thing for you to do it to show the largest address range that contains all sections in a shared library. Get all sections from the module and then calculate the min and max address of all sections and then use the largest address range so show the addresses that the shared library could contain. It doesn't mean that a shared library does contain and address since the above shared libraries from my example above would be something like:


libfoo.dylib [0x100000 - 0x91fffff]
barfoo.dylib [0x200000 - 0x92fffff]


Note that they overlap, but this does show correct info to the user...