<html>
<head>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style></head>
<body class='hmmessage'><div dir='ltr'>Forking the thread since image list looks like an independent issue.<div><br></div><div><ol><li><span style="font-size: 12pt;">There is no image base addresses on Linux. Is this a known issue? </span></li><li>I did not find any C++ API to get it in my program. Did I miss it? Seems useful...</li></ol></div><div><br></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><div><font face="Courier New, sans-serif" size="2">eugene@EUGENEBI-L1:~/Z/Drawbridge/Debugger$ ~/llvm-1-Release/bin/lldb-3.7.0 /bin/ls</font></div></div><div><div><font face="Courier New, sans-serif" size="2">(lldb) target create "/bin/ls"</font></div></div><div><div><font face="Courier New, sans-serif" size="2">Current executable set to '/bin/ls' (x86_64).</font></div></div><div><div><font face="Courier New, sans-serif" size="2">(lldb) b malloc</font></div></div><div><div><font face="Courier New, sans-serif" size="2">Breakpoint 1: no locations (pending).</font></div></div><div><div><font face="Courier New, sans-serif" size="2">WARNING: Unable to resolve breakpoint to any actual locations.</font></div></div><div><div><font face="Courier New, sans-serif" size="2">(lldb) r</font></div></div><div><div><font face="Courier New, sans-serif" size="2">Process 47762 launched: '/bin/ls' (x86_64)</font></div></div><div><div><font face="Courier New, sans-serif" size="2">1 location added to breakpoint 1</font></div></div><div><div><font face="Courier New, sans-serif" size="2">1 location added to breakpoint 1</font></div></div><div><div><font face="Courier New, sans-serif" size="2">Process 47762 stopped</font></div></div><div><div><font face="Courier New, sans-serif" size="2">* 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</font></div></div><div><div><font face="Courier New, sans-serif" size="2"> frame #0: 0x00007ffff766c759 libc.so.6`__GI___libc_malloc(bytes=5) + 9 at malloc.c:2881</font></div></div><div><div><font face="Courier New, sans-serif" size="2">(lldb) image list</font></div></div><div><div><font face="Courier New, sans-serif" size="2">[ 0] BD39C071-94A7-78CC-C066-FC963CA152BD-FAA3F971 /bin/ls</font></div></div><div><div><font face="Courier New, sans-serif" size="2">[ 1] CC197F7A-4642-CE21-32C9-9AE1F5598A60-1650EF0C /lib/x86_64-linux-gnu/libselinux.so.1</font></div></div><div><div><font face="Courier New, sans-serif" size="2">[ 2] 3CF5E1E8-C7CB-082F-1CF3-44BFA4954781-52AC3149 /lib/x86_64-linux-gnu/libacl.so.1</font></div></div><div><div><font face="Courier New, sans-serif" size="2">[ 3] 30C94DC6-6A1F-E951-80C3-D68D2B89E576-D5AE213C /lib/x86_64-linux-gnu/libc.so.6</font></div></div><div><div><font face="Courier New, sans-serif" size="2"> /usr/lib/debug/lib/x86_64-linux-gnu/libc-2.19.so</font></div></div><div><div><font face="Courier New, sans-serif" size="2">[ 4] F6B728A5-93A7-7751-9A7A-08ABB3BCAC87-4BB743EE /lib/x86_64-linux-gnu/libpcre.so.3</font></div></div><div><div><font face="Courier New, sans-serif" size="2">[ 5] C1AE4CB7-195D-337A-77A3-C689051DABAA-3980CA0C /lib/x86_64-linux-gnu/libdl.so.2</font></div></div><div><div><font face="Courier New, sans-serif" size="2"> /usr/lib/debug/lib/x86_64-linux-gnu/libdl-2.19.so</font></div></div><div><div><font face="Courier New, sans-serif" size="2">[ 6] 9F00581A-B3C7-3E3A-EA35-995A0C50D24D-59A01D47 /lib64/ld-linux-x86-64.so.2</font></div></div><div><div><font face="Courier New, sans-serif" size="2">[ 7] 27396D0C-D0F5-F629-3CC3-D9C70B32E7FE-4D1A8E49 /lib/x86_64-linux-gnu/libattr.so.1</font></div></div><div><div><font face="Courier New, sans-serif" size="2">(lldb)</font></div></div></blockquote><div><br></div><div>Eugene<br><br><div>> Subject: Re: [lldb-dev] How to load core on a different machine?<br>> From: gclayton@apple.com<br>> Date: Wed, 6 Jan 2016 17:30:04 -0800<br>> CC: lldb-dev@lists.llvm.org<br>> To: eugenebi@hotmail.com<br>> <br>> <br>> > On Jan 6, 2016, at 4:34 PM, Eugene Birukov <eugenebi@hotmail.com> wrote:<br>> > <br>> > Correction: platform trick almost works. For some reason two libraries are not affected, but the rest are OK. <br>> > Hmm... image list does not have load addresses.<br>> <br>> Does something show when you just debug something on linux like /bin/ls? Try doing:<br>> <br>> (lldb) file /bin/ls<br>> (lldb) b malloc<br>> (lldb) r<br>> (lldb) image list<br>> <br>> Maybe Linux hasn't implemented this yet.<br>> <br>> > I'll trace what read memory does... Does the core contain this memory or is it loaded from the library file?<br>> <br>> 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.<br>> <br>> <br>> > <br>> > eugene@EUGENEBI-L1:~/tmp$ ~/llvm-1-Release/bin/lldb-3.7.0<br>> > (lldb) platform select --sysroot ~/tmp/x remote-linux<br>> > Platform: remote-linux<br>> > Connected: no<br>> > (lldb) target create a.out -c core.36736<br>> > Core file '/home/eugene/tmp/core.36736' (x86_64) was loaded.<br>> > (lldb) bt<br>> > * thread #1: tid = 36737, 0x00007fd696af1b13 libc.so.6`epoll_wait + 51<br>> > * frame #0: 0x00007fd696af1b13 libc.so.6`epoll_wait + 51<br>> > frame #1: 0x00007fd6980bde4b palrun`epoll_thread_func((null)=0x0000000000000000) + 43 at sockets.cpp:773<br>> > frame #2: 0x00007fd697c12182 libpthread.so.0`start_thread + 194<br>> > frame #3: 0x00007fd696af147d libc.so.6`clone + 109<br>> > (lldb) image list<br>> > [ 0] AB5E3D5B-4CFF-A55B-3A81-C7DD1E76DDEC-24786ADE /home/eugene/tmp/a.out<br>> > [ 1] 9318E8AF-0BFB-E444-731B-B0461202EF57-F7C39542 /home/eugene/tmp/libpthread.so.0<br>> > [ 2] 92FCF41E-FE01-2D61-86E3-1A59AD05BDBB-487769AB /home/eugene/tmp/librt.so.1<br>> > [ 3] C1AE4CB7-195D-337A-77A3-C689051DABAA-3980CA0C /home/eugene/tmp/libdl.so.2<br>> > [ 4] B18D9892-DF6A-E4E9-48BA-0FE2FBDDD200-95730E73 /home/eugene/tmp/libjemalloc.so.1<br>> > [ 5] 9FDCDABA-45B5-5C28-D057-7C9B96A75CC7-73D83B3B /home/eugene/tmp/libc++.so.1<br>> > [ 6] 1D76B71E-905C-B867-B27C-EF230FCB20F0-1A3178F5 /home/eugene/tmp/libm.so.6<br>> > [ 7] 8D0AA714-1158-0EE6-C088-09695C398476-9F25725B /home/eugene/tmp/libgcc_s.so.1<br>> > [ 8] 30C94DC6-6A1F-E951-80C3-D68D2B89E576-D5AE213C /home/eugene/tmp/libc.so.6<br>> > [ 9] 9F00581A-B3C7-3E3A-EA35-995A0C50D24D-59A01D47 /home/eugene/tmp/ld-linux-x86-64.so.2<br>> > [ 10] 9318E8AF-0BFB-E444-731B-B0461202EF57-F7C39542 /home/eugene/tmp/libpthread.so.0<br>> > [ 11] 92FCF41E-FE01-2D61-86E3-1A59AD05BDBB-487769AB /home/eugene/tmp/librt.so.1<br>> > [ 12] C1AE4CB7-195D-337A-77A3-C689051DABAA-3980CA0C /home/eugene/tmp/libdl.so.2<br>> > [ 13] B18D9892-DF6A-E4E9-48BA-0FE2FBDDD200-95730E73 /home/eugene/tmp/libjemalloc.so.1<br>> > [ 14] 9FDCDABA-45B5-5C28-D057-7C9B96A75CC7-73D83B3B /home/eugene/tmp/libc++.so.1<br>> > [ 15] 1D76B71E-905C-B867-B27C-EF230FCB20F0-1A3178F5 /home/eugene/tmp/libm.so.6<br>> > [ 16] 8D0AA714-1158-0EE6-C088-09695C398476-9F25725B /home/eugene/tmp/libgcc_s.so.1<br>> > [ 17] 30C94DC6-6A1F-E951-80C3-D68D2B89E576-D5AE213C /home/eugene/tmp/libc.so.6<br>> > [ 18] 11E7491E-E391-903D-EE47-1D098DD64A94-D4F3553F /usr/lib/x86_64-linux-gnu/libunwind.so.8<br>> > [ 19] 15AED485-5920-E5A0-FB87-91B683EB88C7-E1199260 /lib/x86_64-linux-gnu/liblzma.so.5<br>> > (lldb) disas --frame<br>> > libc.so.6`epoll_wait:<br>> > 0x7fd696af1ae0 <+0>: addb %al, (%rax)<br>> > 0x7fd696af1ae2 <+2>: addb %al, (%rax)<br>> > 0x7fd696af1ae4 <+4>: addb %al, (%rax)<br>> > 0x7fd696af1ae6 <+6>: addb %al, (%rax)<br>> > 0x7fd696af1ae8 <+8>: addb %al, (%rax)<br>> > 0x7fd696af1aea <+10>: addb %al, (%rax)<br>> > ...<br>> > <br>> > Eugene<br>> > <br>> > <br>> > > Subject: Re: [lldb-dev] How to load core on a different machine?<br>> > > From: gclayton@apple.com<br>> > > Date: Wed, 6 Jan 2016 16:21:22 -0800<br>> > > CC: lldb-dev@lists.llvm.org<br>> > > To: eugenebi@hotmail.com<br>> > > <br>> > > <br>> > > > On Jan 6, 2016, at 3:39 PM, Eugene Birukov <eugenebi@hotmail.com> wrote:<br>> > > > <br>> > > > 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.<br>> > > > <br>> > > > Meanwhile, I found a way around. In my C++ code I do this:<br>> > > > <br>> > > > m_Target = m_Debugger.CreateTarget(target); <br>> > > > m_Debugger.HandleCommand("target modules search-paths add /lib/x86_64-linux-gnu /home/eugene/tmp");<br>> > > > m_Debugger.HandleCommand("target modules search-paths add /usr/lib/x86_64-linux-gnu /home/eugene/tmp");<br>> > > > m_Process = m_Target.LoadCore(core);<br>> > > > <br>> > > > 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?<br>> > > <br>> > > 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. <br>> > > <br>> > > 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?<br>> > > <br>> > > > Also, if I iterate loaded modules, all of the shared libraries are mentioned twice, which doesn't look right:<br>> > > > <br>> > > > Modules: 20<br>> > > > (x86_64) /home/eugene/tmp/a.out<br>> > > > (x86_64) /home/eugene/tmp/libpthread.so.0<br>> > > > (x86_64) /home/eugene/tmp/librt.so.1<br>> > > > (x86_64) /home/eugene/tmp/libdl.so.2<br>> > > > (x86_64) /home/eugene/tmp/libjemalloc.so.1<br>> > > > (x86_64) /home/eugene/tmp/libc++.so.1<br>> > > > (x86_64) /home/eugene/tmp/libm.so.6<br>> > > > (x86_64) /home/eugene/tmp/libgcc_s.so.1<br>> > > > (x86_64) /home/eugene/tmp/libc.so.6<br>> > > > (x86_64) /home/eugene/tmp/ld-linux-x86-64.so.2<br>> > > > (x86_64) /home/eugene/tmp/libpthread.so.0<br>> > > > (x86_64) /home/eugene/tmp/librt.so.1<br>> > > > (x86_64) /home/eugene/tmp/libdl.so.2<br>> > > > (x86_64) /home/eugene/tmp/libjemalloc.so.1<br>> > > > (x86_64) /home/eugene/tmp/libc++.so.1<br>> > > > (x86_64) /home/eugene/tmp/libm.so.6<br>> > > > (x86_64) /home/eugene/tmp/libgcc_s.so.1<br>> > > > (x86_64) /home/eugene/tmp/libc.so.6<br>> > > > (x86_64) /home/eugene/tmp/libunwind.so.8<br>> > > > (x86_64) /home/eugene/tmp/liblzma.so.5<br>> > > <br>> > > 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.<br>> > > <br>> > > > Eugene<br>> > > <br>> <br></div></div> </div></body>
</html>