[lldb-dev] How to load core on a different machine? - image base addresses

[Eugene Birukov via lldb-dev]

> It is now!
Good :). Any plans to fix it? I guess I should just file a bug, right?
> The main question is what do you consider to be your "image address"?
I need the address that I feed to SBTarget::SetModuleLoadAddress() if I load modules manually.
I iterated over module sections. As I understand, the base address  is 0x7fc7125ff000. I verified it by really calling SetModuleLoadAddress() and looking at stacks that LLDB produces. But to find it programmatically I'll need to do some math: pick any section with non-zero size and subtract its file address form its memory address. Hmm... seems like a workaround, but it would be better to have a more direct way.
(x86_64) /home/eugene/joe/so/libjemalloc.so.10xffffffffffffffff [0x0000000000000000-0x0000000000000000) libjemalloc.so.1.0x7fc7125ff200 [0x0000000000000200-0x0000000000000224) libjemalloc.so.1..note.gnu.build-id0x7fc7125ff228 [0x0000000000000228-0x0000000000000328) libjemalloc.so.1..gnu.hash0x7fc7125ff328 [0x0000000000000328-0x0000000000000b08) libjemalloc.so.1..dynsym0x7fc7125ffb08 [0x0000000000000b08-0x0000000000000f01) libjemalloc.so.1..dynstr0x7fc7125fff02 [0x0000000000000f02-0x0000000000000faa) libjemalloc.so.1..gnu.version0x7fc7125fffb0 [0x0000000000000fb0-0x0000000000001040) libjemalloc.so.1..gnu.version_r0x7fc712600040 [0x0000000000001040-0x0000000000002c00) libjemalloc.so.1..rela.dyn0x7fc712601c00 [0x0000000000002c00-0x0000000000003008) libjemalloc.so.1..rela.plt0x7fc712602008 [0x0000000000003008-0x0000000000003022) libjemalloc.so.1..init0x7fc712602030 [0x0000000000003030-0x00000000000032f0) libjemalloc.so.1..plt0x7fc7126022f0 [0x00000000000032f0-0x00000000000286fa) libjemalloc.so.1..text0x7fc7126276fc [0x00000000000286fc-0x0000000000028705) libjemalloc.so.1..fini0x7fc712627740 [0x0000000000028740-0x000000000002a344) libjemalloc.so.1..rodata0x7fc712629344 [0x000000000002a344-0x000000000002afa0) libjemalloc.so.1..eh_frame_hdr0x7fc712629fa0 [0x000000000002afa0-0x000000000002fdcc) libjemalloc.so.1..eh_frame0x7fc71282f710 [0x0000000000230710-0x0000000000230714) libjemalloc.so.1..tdata0x7fc71282f718 [0x0000000000230718-0x0000000000230748) libjemalloc.so.1..tbss0x7fc71282f718 [0x0000000000230718-0x0000000000230728) libjemalloc.so.1..init_array0x7fc71282f728 [0x0000000000230728-0x0000000000230730) libjemalloc.so.1..fini_array0x7fc71282f730 [0x0000000000230730-0x0000000000230738) libjemalloc.so.1..jcr0x7fc71282f740 [0x0000000000230740-0x0000000000231d70) libjemalloc.so.1..data.rel.ro0x7fc712830d70 [0x0000000000231d70-0x0000000000231f70) libjemalloc.so.1..dynamic0x7fc712830f70 [0x0000000000231f70-0x0000000000232000) libjemalloc.so.1..got0x7fc712831000 [0x0000000000232000-0x0000000000232170) libjemalloc.so.1..got.plt0x7fc712831180 [0x0000000000232180-0x0000000000232209) libjemalloc.so.1..data0x7fc712831220 [0x0000000000232220-0x00000000002334b0) libjemalloc.so.1..bss0xffffffffffffffff [0x0000000000000000-0x0000000000000000) libjemalloc.so.1..gnu_debuglink0xffffffffffffffff [0x0000000000000000-0x0000000000000000) libjemalloc.so.1..shstrtab
Thanks,Eugene
> Subject: Re: [lldb-dev] How to load core on a different machine? - image base addresses
> From: gclayton at apple.com
> Date: Thu, 7 Jan 2016 09:35:40 -0800
> CC: lldb-dev at lists.llvm.org
> To: eugenebi at hotmail.com
> 
> 
> > On Jan 7, 2016, at 9:02 AM, Eugene Birukov <eugenebi at hotmail.com> wrote:
> > 
> > Forking the thread since image list looks like an independent issue.
> > 
> > 	• There is no image base addresses on Linux. Is this a known issue? 
> 
> It is now!
> 
> > 	• I did not find any C++ API to get it in my program. Did I miss it? Seems useful...
> 
> The main question is what do you consider to be your "image address"? For MachO files on MacOSX, it is the address of the mach header in memory. If the ELF header and all of the program headers and sections headers are actually in memory, then the address should be the address of the ELF header.
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20160107/dc4e35e6/attachment.html>