How to load core on a different machine?

Eugene_Birukov · January 5, 2016, 8:53pm

Hi,

I am using LLDB-3.7 on Ubuntu Linux.

I have a core dump file and all shared libraries from my server but I want to investigate them on a dev box. But I fail to correctly load it in LLDB - it shows wrong stacks. I.e. I am looking for something equivalent to GDB commands “set solib-absolute-prefix” and “set solib-search-path”.

I tried to play with “target modules search-paths insert”, but I cannot use it if there is no target and I cannot load core after I have a target - not sure what this command is intended to do…

Now, what I really need to do - it is load core in my custom debugger that uses C++ API. Here I made some progress:

Create target with NULL file name
Load core using SBTarget::LoadCore()
Manually load all executables - the initial a.out and all the shared libraries using SBTarget::AddModule() and SBTarget::SetModuleLoadAddress()
This kind of works, but there are two problems:

How would I find the list of modules and addresses to load from the core file? Currently I did it by loading core in the debugger on the server, but this is not acceptable for production run…
LLDB correctly prints stacks and resolves symbols, but I cannot disassembly any code - the ReadMemory retuns all zeroes from code addresses.

Any help would be greatly appreciated.

Thanks,
Eugene

Greg_Clayton1 · January 5, 2016, 11:04pm

Try this:

% lldb
(lldb) platform select --sysroot /path/to/remote/shared/libraries remote-linux
(lldb) <load core>

If this works, there are SBPlatform class calls in the API you can use the select the platform as done above if you need to not do this from the command line.

The other option is to chroot into /path/to/remote/shared/libraries and you will need to copy your core file into /path/to/remote/shared/libraries, then just run LLDB normally and it should work.

Greg Clayton

Eugene_Birukov · January 6, 2016, 7:03pm

Hmm… neither approach really works.

I created platform from lldb prompt, but when I create target from core file I see exactly the same wrong stacks. It seems that platform is ignored during core load in my case.
chroot requires the whole set of binaries there in the new root. I simply cannot copy everything from the server. Even if I do, lldb will use copied binaries which is not a good idea…

root@eugenebi-L2:~# chroot /home/eugene/tmp

chroot: failed to run command ‘/bin/bash’: No such file or directory

I tried SBDebugger::SetCurrentPlatformSDKRoot() but it does not have any visible effect on load core, not sure what it is supposed to do

Eugene

Tamas_Berghammer · January 6, 2016, 7:31pm

I would try to set target.exec-search-paths (before loading the core file) to the directory containing the binaries downloaded from the server. Then lldb should start searching for the shared libraries in the listed directories.

Greg_Clayton1 · January 6, 2016, 7:37pm

So this should work:

(lldb) platform select --sysroot /path/to/remote/shared/libraries remote-linux
(lldb) <load core>

So you need to make sure that your sysroot ("/path/to/remote/shared/libraries") contains files as they would appear on the remote system with the right paths ("/usr/lib/libc.so" should be in "/path/to/remote/shared/libraries/usr/lib/libc.so"). If that is true and you still are getting the wrong stack backtraces, then there are bugs in LLDB possibly in ProcessElfCore or possibly in DynamicLoaderPOSIXDYLD. What should happen is when we are asked to find "/usr/lib/libc.so", the platform that is selected should be the one that is asked to find "/usr/lib/libc.so", and it should check if the platform has a sysroot (like "/path/to/remote/shared/libraries") and it should prepend this when looking for "/usr/lib/libc.so", so it should be checking "/path/to/remote/shared/libraries/usr/lib/libc.so". So you will need to step through Target::GetSharedModule() and see what is going wrong.

If that still fails, it seems we do have a way around this with the "target modules search-paths add" command:

(lldb) target modules search-paths add /usr/lib /tmp

So if you have "/usr/lib/libc.so", it should look in "/tmp/libc.so". But I would prefer it if we get this working by the platform method by debugging what is going wrong in Target::GetSharedModule(). The target has a platform and it should consult the platform when asked to find a module given a ModuleSpec. The ModuleSpec contains the path, and optionally the architecture and UUID. If any code in ProcessElfCore or DynamicLoaderPOSIXDYLD is not using Target::GetSharedModule(), then that might be the bug (code should never just call the static ModuleList::GetSharedModule() to locate files for a target.

Let me know what you come up with,

Greg Clayton

Eugene_Birukov · January 6, 2016, 11:39pm

OK, I’ll try to see what happens with the platform. The truth is that shipped lldb-3.7.0 does not load core on Linux at all and I am using custom version that has been patched (by restoring some 3.6.0 code). So, there might be a problem there.

Meanwhile, I found a way around. In my C++ code I do this:

m_Target = m_Debugger.CreateTarget(target);
m_Debugger.HandleCommand(“target modules search-paths add /lib/x86_64-linux-gnu /home/eugene/tmp”);
m_Debugger.HandleCommand(“target modules search-paths add /usr/lib/x86_64-linux-gnu /home/eugene/tmp”);
m_Process = m_Target.LoadCore(core);

This does get the stacks right. Still, I have a problem with it: when I try to disassemble the code, it is all zeroes. Any advice where I should look to figure out what’s wrong? Also, if I iterate loaded modules, all of the shared libraries are mentioned twice, which doesn’t look right:

Modules: 20

(x86_64) /home/eugene/tmp/a.out

(x86_64) /home/eugene/tmp/libpthread.so.0

(x86_64) /home/eugene/tmp/librt.so.1

(x86_64) /home/eugene/tmp/libdl.so.2

(x86_64) /home/eugene/tmp/libjemalloc.so.1

(x86_64) /home/eugene/tmp/libc++.so.1

(x86_64) /home/eugene/tmp/libm.so.6

(x86_64) /home/eugene/tmp/libgcc_s.so.1

(x86_64) /home/eugene/tmp/libc.so.6

(x86_64) /home/eugene/tmp/ld-linux-x86-64.so.2

(x86_64) /home/eugene/tmp/libpthread.so.0

(x86_64) /home/eugene/tmp/librt.so.1

(x86_64) /home/eugene/tmp/libdl.so.2

(x86_64) /home/eugene/tmp/libjemalloc.so.1

(x86_64) /home/eugene/tmp/libc++.so.1

(x86_64) /home/eugene/tmp/libm.so.6

(x86_64) /home/eugene/tmp/libgcc_s.so.1

(x86_64) /home/eugene/tmp/libc.so.6

(x86_64) /home/eugene/tmp/libunwind.so.8

(x86_64) /home/eugene/tmp/liblzma.so.5

Eugene

Greg_Clayton1 · January 7, 2016, 12:21am

OK, I'll try to see what happens with the platform. The truth is that shipped lldb-3.7.0 does not load core on Linux at all and I am using custom version that has been patched (by restoring some 3.6.0 code). So, there might be a problem there.

Meanwhile, I found a way around. In my C++ code I do this:

    m_Target = m_Debugger.CreateTarget(target);
    m_Debugger.HandleCommand("target modules search-paths add /lib/x86_64-linux-gnu /home/eugene/tmp");
    m_Debugger.HandleCommand("target modules search-paths add /usr/lib/x86_64-linux-gnu /home/eugene/tmp");
    m_Process = m_Target.LoadCore(core);

This does get the stacks right. Still, I have a problem with it: when I try to disassemble the code, it is all zeroes. Any advice where I should look to figure out what's wrong?

You can check ProcessElfCore::DoReadMemory() to see what happens when it reads the memory it is trying to disassemble. What you type "disassemble --frame", it will try and read the memory from the process (and instance of ProcessElfCore) and the memory read will try to read the data from the core memory. Make sure this is correctly accessing the memory and getting non-zeroes back from the memory read. Anything that was mapped into the process should be saved in the core file and be available to read as valid memory.

What does the output of "image list" show? It should show the load addresses of all the shared libraries as the location that it was loaded when the core file was made. If you see a bunch of zeros as the load location, then maybe the shared libraries aren't getting loaded correctly?

Also, if I iterate loaded modules, all of the shared libraries are mentioned twice, which doesn't look right:

Modules: 20
(x86_64) /home/eugene/tmp/a.out
(x86_64) /home/eugene/tmp/libpthread.so.0
(x86_64) /home/eugene/tmp/librt.so.1
(x86_64) /home/eugene/tmp/libdl.so.2
(x86_64) /home/eugene/tmp/libjemalloc.so.1
(x86_64) /home/eugene/tmp/libc++.so.1
(x86_64) /home/eugene/tmp/libm.so.6
(x86_64) /home/eugene/tmp/libgcc_s.so.1
(x86_64) /home/eugene/tmp/libc.so.6
(x86_64) /home/eugene/tmp/ld-linux-x86-64.so.2
(x86_64) /home/eugene/tmp/libpthread.so.0
(x86_64) /home/eugene/tmp/librt.so.1
(x86_64) /home/eugene/tmp/libdl.so.2
(x86_64) /home/eugene/tmp/libjemalloc.so.1
(x86_64) /home/eugene/tmp/libc++.so.1
(x86_64) /home/eugene/tmp/libm.so.6
(x86_64) /home/eugene/tmp/libgcc_s.so.1
(x86_64) /home/eugene/tmp/libc.so.6
(x86_64) /home/eugene/tmp/libunwind.so.8
(x86_64) /home/eugene/tmp/liblzma.so.5

That is probably your problem... The first copy is probably not loaded, but the second one is? It will be interesting to see what the output of the "image list" command shows. The first one might claim 0x0 as the load location and the second one might be valid. This seems like this is a bug in the dynamic loader plugin (DynamicLoaderPOSIXDYLD). So try to figure out why two copies are getting added and then make sure they are loaded at valid non-overlapping addresses.

Eugene_Birukov · January 7, 2016, 12:34am

Correction: platform trick almost works. For some reason two libraries are not affected, but the rest are OK.
Hmm… image list does not have load addresses.
I’ll trace what read memory does… Does the core contain this memory or is it loaded from the library file?

eugene@EUGENEBI-L1:~/tmp$ ~/llvm-1-Release/bin/lldb-3.7.0
(lldb) platform select --sysroot ~/tmp/x remote-linux
Platform: remote-linux
Connected: no
(lldb) target create a.out -c core.36736
Core file ‘/home/eugene/tmp/core.36736’ (x86_64) was loaded.
(lldb) bt

thread #1: tid = 36737, 0x00007fd696af1b13 libc.so.6`epoll_wait + 51
frame #0: 0x00007fd696af1b13 libc.so.6epoll_wait + 51 frame #1: 0x00007fd6980bde4b palrunepoll_thread_func((null)=0x0000000000000000) + 43 at sockets.cpp:773
frame #2: 0x00007fd697c12182 libpthread.so.0start_thread + 194 frame #3: 0x00007fd696af147d libc.so.6clone + 109

(lldb) image list
[ 0] AB5E3D5B-4CFF-A55B-3A81-C7DD1E76DDEC-24786ADE /home/eugene/tmp/a.out
[ 1] 9318E8AF-0BFB-E444-731B-B0461202EF57-F7C39542 /home/eugene/tmp/libpthread.so.0
[ 2] 92FCF41E-FE01-2D61-86E3-1A59AD05BDBB-487769AB /home/eugene/tmp/librt.so.1
[ 3] C1AE4CB7-195D-337A-77A3-C689051DABAA-3980CA0C /home/eugene/tmp/libdl.so.2
[ 4] B18D9892-DF6A-E4E9-48BA-0FE2FBDDD200-95730E73 /home/eugene/tmp/libjemalloc.so.1
[ 5] 9FDCDABA-45B5-5C28-D057-7C9B96A75CC7-73D83B3B /home/eugene/tmp/libc++.so.1
[ 6] 1D76B71E-905C-B867-B27C-EF230FCB20F0-1A3178F5 /home/eugene/tmp/libm.so.6
[ 7] 8D0AA714-1158-0EE6-C088-09695C398476-9F25725B /home/eugene/tmp/libgcc_s.so.1
[ 8] 30C94DC6-6A1F-E951-80C3-D68D2B89E576-D5AE213C /home/eugene/tmp/libc.so.6
[ 9] 9F00581A-B3C7-3E3A-EA35-995A0C50D24D-59A01D47 /home/eugene/tmp/ld-linux-x86-64.so.2
[ 10] 9318E8AF-0BFB-E444-731B-B0461202EF57-F7C39542 /home/eugene/tmp/libpthread.so.0
[ 11] 92FCF41E-FE01-2D61-86E3-1A59AD05BDBB-487769AB /home/eugene/tmp/librt.so.1
[ 12] C1AE4CB7-195D-337A-77A3-C689051DABAA-3980CA0C /home/eugene/tmp/libdl.so.2
[ 13] B18D9892-DF6A-E4E9-48BA-0FE2FBDDD200-95730E73 /home/eugene/tmp/libjemalloc.so.1
[ 14] 9FDCDABA-45B5-5C28-D057-7C9B96A75CC7-73D83B3B /home/eugene/tmp/libc++.so.1
[ 15] 1D76B71E-905C-B867-B27C-EF230FCB20F0-1A3178F5 /home/eugene/tmp/libm.so.6
[ 16] 8D0AA714-1158-0EE6-C088-09695C398476-9F25725B /home/eugene/tmp/libgcc_s.so.1
[ 17] 30C94DC6-6A1F-E951-80C3-D68D2B89E576-D5AE213C /home/eugene/tmp/libc.so.6
[ 18] 11E7491E-E391-903D-EE47-1D098DD64A94-D4F3553F /usr/lib/x86_64-linux-gnu/libunwind.so.8
[ 19] 15AED485-5920-E5A0-FB87-91B683EB88C7-E1199260 /lib/x86_64-linux-gnu/liblzma.so.5
(lldb) disas --frame
libc.so.6`epoll_wait:
0x7fd696af1ae0 <+0>: addb %al, (%rax)
0x7fd696af1ae2 <+2>: addb %al, (%rax)
0x7fd696af1ae4 <+4>: addb %al, (%rax)
0x7fd696af1ae6 <+6>: addb %al, (%rax)
0x7fd696af1ae8 <+8>: addb %al, (%rax)
0x7fd696af1aea <+10>: addb %al, (%rax)

…

Eugene

Greg_Clayton1 · January 7, 2016, 1:30am

Correction: platform trick almost works. For some reason two libraries are not affected, but the rest are OK.
Hmm... image list does not have load addresses.

Does something show when you just debug something on linux like /bin/ls? Try doing:

(lldb) file /bin/ls
(lldb) b malloc
(lldb) r
(lldb) image list

Maybe Linux hasn't implemented this yet.

I'll trace what read memory does... Does the core contain this memory or is it loaded from the library file?

It should try to read any memory that it tracks down from the core file if it is available. It should try to fall back to reading from the library file if the memory read fails from the core.

Eugene_Birukov · January 7, 2016, 5:02pm

Forking the thread since image list looks like an independent issue.

There is no image base addresses on Linux. Is this a known issue?
I did not find any C++ API to get it in my program. Did I miss it? Seems useful…

eugene@EUGENEBI-L1:~/Z/Drawbridge/Debugger$ ~/llvm-1-Release/bin/lldb-3.7.0 /bin/ls

(lldb) target create “/bin/ls”

Current executable set to ‘/bin/ls’ (x86_64).

(lldb) b malloc

Breakpoint 1: no locations (pending).

WARNING: Unable to resolve breakpoint to any actual locations.

(lldb) r

Process 47762 launched: ‘/bin/ls’ (x86_64)

1 location added to breakpoint 1

1 location added to breakpoint 1

Process 47762 stopped

thread #1: tid = 47762, 0x00007ffff766c759 libc.so.6`__GI___libc_malloc(bytes=5) + 9 at malloc.c:2881, name = ‘ls’, stop reason = breakpoint 1.1

frame #0: 0x00007ffff766c759 libc.so.6`__GI___libc_malloc(bytes=5) + 9 at malloc.c:2881

(lldb) image list

[ 0] BD39C071-94A7-78CC-C066-FC963CA152BD-FAA3F971 /bin/ls

[ 1] CC197F7A-4642-CE21-32C9-9AE1F5598A60-1650EF0C /lib/x86_64-linux-gnu/libselinux.so.1

[ 2] 3CF5E1E8-C7CB-082F-1CF3-44BFA4954781-52AC3149 /lib/x86_64-linux-gnu/libacl.so.1

[ 3] 30C94DC6-6A1F-E951-80C3-D68D2B89E576-D5AE213C /lib/x86_64-linux-gnu/libc.so.6

/usr/lib/debug/lib/x86_64-linux-gnu/libc-2.19.so

[ 4] F6B728A5-93A7-7751-9A7A-08ABB3BCAC87-4BB743EE /lib/x86_64-linux-gnu/libpcre.so.3

[ 5] C1AE4CB7-195D-337A-77A3-C689051DABAA-3980CA0C /lib/x86_64-linux-gnu/libdl.so.2

/usr/lib/debug/lib/x86_64-linux-gnu/libdl-2.19.so

[ 6] 9F00581A-B3C7-3E3A-EA35-995A0C50D24D-59A01D47 /lib64/ld-linux-x86-64.so.2

[ 7] 27396D0C-D0F5-F629-3CC3-D9C70B32E7FE-4D1A8E49 /lib/x86_64-linux-gnu/libattr.so.1

(lldb)

Eugene

Greg_Clayton1 · January 7, 2016, 5:35pm

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.

Eugene_Birukov · January 7, 2016, 5:48pm

> 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.1
0xffffffffffffffff [0x0000000000000000-0x0000000000000000) libjemalloc.so.1.
0x7fc7125ff200 [0x0000000000000200-0x0000000000000224) libjemalloc.so.1…note.gnu.build-id
0x7fc7125ff228 [0x0000000000000228-0x0000000000000328) libjemalloc.so.1…gnu.hash
0x7fc7125ff328 [0x0000000000000328-0x0000000000000b08) libjemalloc.so.1…dynsym
0x7fc7125ffb08 [0x0000000000000b08-0x0000000000000f01) libjemalloc.so.1…dynstr
0x7fc7125fff02 [0x0000000000000f02-0x0000000000000faa) libjemalloc.so.1…gnu.version
0x7fc7125fffb0 [0x0000000000000fb0-0x0000000000001040) libjemalloc.so.1…gnu.version_r
0x7fc712600040 [0x0000000000001040-0x0000000000002c00) libjemalloc.so.1…rela.dyn
0x7fc712601c00 [0x0000000000002c00-0x0000000000003008) libjemalloc.so.1…rela.plt
0x7fc712602008 [0x0000000000003008-0x0000000000003022) libjemalloc.so.1…init
0x7fc712602030 [0x0000000000003030-0x00000000000032f0) libjemalloc.so.1…plt
0x7fc7126022f0 [0x00000000000032f0-0x00000000000286fa) libjemalloc.so.1…text
0x7fc7126276fc [0x00000000000286fc-0x0000000000028705) libjemalloc.so.1…fini
0x7fc712627740 [0x0000000000028740-0x000000000002a344) libjemalloc.so.1…rodata
0x7fc712629344 [0x000000000002a344-0x000000000002afa0) libjemalloc.so.1…eh_frame_hdr
0x7fc712629fa0 [0x000000000002afa0-0x000000000002fdcc) libjemalloc.so.1…eh_frame
0x7fc71282f710 [0x0000000000230710-0x0000000000230714) libjemalloc.so.1…tdata
0x7fc71282f718 [0x0000000000230718-0x0000000000230748) libjemalloc.so.1…tbss
0x7fc71282f718 [0x0000000000230718-0x0000000000230728) libjemalloc.so.1…init_array
0x7fc71282f728 [0x0000000000230728-0x0000000000230730) libjemalloc.so.1…fini_array
0x7fc71282f730 [0x0000000000230730-0x0000000000230738) libjemalloc.so.1…jcr
0x7fc71282f740 [0x0000000000230740-0x0000000000231d70) libjemalloc.so.1…data.rel.ro
0x7fc712830d70 [0x0000000000231d70-0x0000000000231f70) libjemalloc.so.1…dynamic
0x7fc712830f70 [0x0000000000231f70-0x0000000000232000) libjemalloc.so.1…got
0x7fc712831000 [0x0000000000232000-0x0000000000232170) libjemalloc.so.1…got.plt
0x7fc712831180 [0x0000000000232180-0x0000000000232209) libjemalloc.so.1…data
0x7fc712831220 [0x0000000000232220-0x00000000002334b0) libjemalloc.so.1…bss
0xffffffffffffffff [0x0000000000000000-0x0000000000000000) libjemalloc.so.1…gnu_debuglink
0xffffffffffffffff [0x0000000000000000-0x0000000000000000) libjemalloc.so.1…shstrtab

Thanks,Eugene

Greg_Clayton1 · January 7, 2016, 5:54pm

> It is now!

Good :). Any plans to fix it? I guess I should just file a bug, right?

Please file a bug. Someone probably will from the linux community, possibly even you?

> 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.1
0xffffffffffffffff [0x0000000000000000-0x0000000000000000) libjemalloc.so.1.
0x7fc7125ff200 [0x0000000000000200-0x0000000000000224) libjemalloc.so.1..note.gnu.build-id
0x7fc7125ff228 [0x0000000000000228-0x0000000000000328) libjemalloc.so.1..gnu.hash
0x7fc7125ff328 [0x0000000000000328-0x0000000000000b08) libjemalloc.so.1..dynsym
0x7fc7125ffb08 [0x0000000000000b08-0x0000000000000f01) libjemalloc.so.1..dynstr
0x7fc7125fff02 [0x0000000000000f02-0x0000000000000faa) libjemalloc.so.1..gnu.version
0x7fc7125fffb0 [0x0000000000000fb0-0x0000000000001040) libjemalloc.so.1..gnu.version_r
0x7fc712600040 [0x0000000000001040-0x0000000000002c00) libjemalloc.so.1..rela.dyn
0x7fc712601c00 [0x0000000000002c00-0x0000000000003008) libjemalloc.so.1..rela.plt
0x7fc712602008 [0x0000000000003008-0x0000000000003022) libjemalloc.so.1..init
0x7fc712602030 [0x0000000000003030-0x00000000000032f0) libjemalloc.so.1..plt
0x7fc7126022f0 [0x00000000000032f0-0x00000000000286fa) libjemalloc.so.1..text
0x7fc7126276fc [0x00000000000286fc-0x0000000000028705) libjemalloc.so.1..fini
0x7fc712627740 [0x0000000000028740-0x000000000002a344) libjemalloc.so.1..rodata
0x7fc712629344 [0x000000000002a344-0x000000000002afa0) libjemalloc.so.1..eh_frame_hdr
0x7fc712629fa0 [0x000000000002afa0-0x000000000002fdcc) libjemalloc.so.1..eh_frame
0x7fc71282f710 [0x0000000000230710-0x0000000000230714) libjemalloc.so.1..tdata
0x7fc71282f718 [0x0000000000230718-0x0000000000230748) libjemalloc.so.1..tbss
0x7fc71282f718 [0x0000000000230718-0x0000000000230728) libjemalloc.so.1..init_array
0x7fc71282f728 [0x0000000000230728-0x0000000000230730) libjemalloc.so.1..fini_array
0x7fc71282f730 [0x0000000000230730-0x0000000000230738) libjemalloc.so.1..jcr
0x7fc71282f740 [0x0000000000230740-0x0000000000231d70) libjemalloc.so.1..data.rel.ro
0x7fc712830d70 [0x0000000000231d70-0x0000000000231f70) libjemalloc.so.1..dynamic
0x7fc712830f70 [0x0000000000231f70-0x0000000000232000) libjemalloc.so.1..got
0x7fc712831000 [0x0000000000232000-0x0000000000232170) libjemalloc.so.1..got.plt
0x7fc712831180 [0x0000000000232180-0x0000000000232209) libjemalloc.so.1..data
0x7fc712831220 [0x0000000000232220-0x00000000002334b0) libjemalloc.so.1..bss
0xffffffffffffffff [0x0000000000000000-0x0000000000000000) libjemalloc.so.1..gnu_debuglink
0xffffffffffffffff [0x0000000000000000-0x0000000000000000) libjemalloc.so.1..shstrtab

So try the following:

(lldb) memory read 0x7fc7125ff000

See if you see the "ELF\x7d" magic byte string. If so, then this is definitely the address you are looking for. You can also set a breakpoint when the shared libraries get loaded and see where the image is being loaded since I believe the POSIX Dynamic Loader loads things using a single address that it gets from somewhere. This address that is used by the dynamic loader should be the address that is displayed...

Greg

jingham · January 7, 2016, 6:34pm

Note, you shouldn't need to set a breakpoint to inspect this, just put:

settings set target.process.stop-on-sharedlibrary-events 1

and lldb will stop when the libraries load.

Jim