Re: [lldb-dev] How to load core on a different machine?
Hmm... neither approach really works. 1. 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.2. 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/tmpchroot: failed to run command ‘/bin/bash’: No such file or directory 3. I tried SBDebugger::SetCurrentPlatformSDKRoot() but it does not have any visible effect on load core, not sure what it is supposed to do :) Eugene > Subject: Re: [lldb-dev] How to load core on a different machine? > From: gclay...@apple.com > Date: Tue, 5 Jan 2016 15:04:36 -0800 > CC: lldb-dev@lists.llvm.org > To: eugen...@hotmail.com > > Try this: > > % lldb > (lldb) platform select --sysroot /path/to/remote/shared/libraries remote-linux > (lldb) > > 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 > > > On Jan 5, 2016, at 12:53 PM, Eugene Birukov via lldb-dev > > wrote: > > > > 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 > > ___ > > lldb-dev mailing list > > lldb-dev@lists.llvm.org > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] How to load core on a different machine?
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. On Wed, Jan 6, 2016 at 7:03 PM Eugene Birukov via lldb-dev < lldb-dev@lists.llvm.org> wrote: > Hmm... neither approach really works. > > 1. 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. > 2. 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* > > > 3. I tried SBDebugger::SetCurrentPlatformSDKRoot() but it does not have > any visible effect on load core, not sure what it is supposed to do :) > > Eugene > > > Subject: Re: [lldb-dev] How to load core on a different machine? > > From: gclay...@apple.com > > Date: Tue, 5 Jan 2016 15:04:36 -0800 > > CC: lldb-dev@lists.llvm.org > > To: eugen...@hotmail.com > > > > > Try this: > > > > % lldb > > (lldb) platform select --sysroot /path/to/remote/shared/libraries > remote-linux > > (lldb) > > > > 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 > > > > > On Jan 5, 2016, at 12:53 PM, Eugene Birukov via lldb-dev < > lldb-dev@lists.llvm.org> wrote: > > > > > > 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 > > > ___ > > > lldb-dev mailing list > > > lldb-dev@lists.llvm.org > > > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > > > ___ > lldb-dev mailing list > lldb-dev@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev > ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] How to load core on a different machine?
So this should work:
(lldb) platform select --sysroot /path/to/remote/shared/libraries remote-linux
(lldb)
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
> On Jan 6, 2016, at 11:03 AM, Eugene Birukov wrote:
>
> Hmm... neither approach really works.
>
> 1. 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.
> 2. 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
>
> 3. I tried SBDebugger::SetCurrentPlatformSDKRoot() but it does not have any
> visible effect on load core, not sure what it is supposed to do :)
>
> Eugene
>
> > Subject: Re: [lldb-dev] How to load core on a different machine?
> > From: gclay...@apple.com
> > Date: Tue, 5 Jan 2016 15:04:36 -0800
> > CC: lldb-dev@lists.llvm.org
> > To: eugen...@hotmail.com
> >
> > Try this:
> >
> > % lldb
> > (lldb) platform select --sysroot /path/to/remote/shared/libraries
> > remote-linux
> > (lldb)
> >
> > 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
> >
> > > On Jan 5, 2016, at 12:53 PM, Eugene Birukov via lldb-dev
> > > wrote:
> > >
> > > 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
> > > __
[lldb-dev] [3.8 Release] One week to the branch
Just a quick reminder: the branch point is coming up in one week, on 13 January. Cheers, Hans ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
[lldb-dev] Patch to fix REPL for ARMv7 & ARMv6 on linux
Hi All, There is a small change that enables correct calculation of arm sub architectures while using the REPL on arm-linux. As you may of may or may not know, linux appends ‘l’ to arm architecture versions to denote little endian. This sometimes interferes with the determination of the architecture in the triple. I experimented with adding sub architecture entries for these within lldb, but I discovered a simpler (and less invasive) method. Because LLVM already knows how to handle some of these cases (I have a patch submitted for review that enables v6l; v7l already works), I am relying on llvm to clean it up. The gist of it is that the llvm constructor (when given a triple string) retains the provided string unless an accessor mutates it. Meanwhile, the accessors for the components go through the aliasing and parsing logic. This code detects whether the sub-architecture that armv6l or armv7l aliases to is detected, and re-sets the architecture in the triple. This overwrites the architecture that comes from linux, thus sanitizing it. Some kind of solution is required for the REPL to on arm-linux. Thoughts? - Will lldb.diff Description: Binary data ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] How to load core on a different machine?
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
> Subject: Re: [lldb-dev] How to load core on a different machine?
> From: gclay...@apple.com
> Date: Wed, 6 Jan 2016 11:37:02 -0800
> CC: lldb-dev@lists.llvm.org
> To: eugen...@hotmail.com
>
>
> So this should work:
>
> (lldb) platform select --sysroot /path/to/remote/shared/libraries remote-linux
> (lldb)
>
> 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
>
>
>
> > On Jan 6, 2016, at 11:03 AM, Eugene Birukov wrote:
> >
> > Hmm... neither approach really works.
> >
> > 1. 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.
> > 2. 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
> >
> > 3. I tried SBDebugger::SetCurrentPlatformSDKRoot() but it does not have any
> > visible effect on load core, not sure what it is supposed to do :)
> >
> > Eugene
> >
> > > Subject: Re: [lldb-dev] How to load core on a different machine?
> > > From: gclay...@apple.com
> > > Date: Tue, 5 Jan 2016 15:04:36 -0800
> > > CC: lldb-dev@lists.llvm.org
> > > To: eugen...@hotmail.com
> > >
> > > Try this:
> > >
> > > % lldb
> > > (lldb) platform select --sysroot /path/to/remote/shared/libraries
> > > remote-linux
> > > (lldb)
> > >
> > > If th
Re: [lldb-dev] How to load core on a different machine?
> On Jan 6, 2016, at 3:39 PM, Eugene Birukov wrote:
>
> 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
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] How to load core on a different machine?
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.36736Core file '/home/eugene/tmp/core.36736'
(x86_64) was loaded.(lldb) bt* thread #1: tid = 36737, 0x7fd696af1b13
libc.so.6`epoll_wait + 51 * frame #0: 0x7fd696af1b13 libc.so.6`epoll_wait
+ 51frame #1: 0x7fd6980bde4b
palrun`epoll_thread_func((null)=0x) + 43 at sockets.cpp:773
frame #2: 0x7fd697c12182 libpthread.so.0`start_thread + 194frame #3:
0x7fd696af147d libc.so.6`clone + 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 --framelibc.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
> Subject: Re: [lldb-dev] How to load core on a different machine?
> From: gclay...@apple.com
> Date: Wed, 6 Jan 2016 16:21:22 -0800
> CC: lldb-dev@lists.llvm.org
> To: eugen...@hotmail.com
>
>
> > On Jan 6, 2016, at 3:39 PM, Eugene Birukov wrote:
> >
> > 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
Re: [lldb-dev] How to load core on a different machine?
> On Jan 6, 2016, at 4:34 PM, Eugene Birukov wrote:
>
> 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@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, 0x7fd696af1b13 libc.so.6`epoll_wait + 51
> * frame #0: 0x7fd696af1b13 libc.so.6`epoll_wait + 51
> frame #1: 0x7fd6980bde4b
> palrun`epoll_thread_func((null)=0x) + 43 at sockets.cpp:773
> frame #2: 0x7fd697c12182 libpthread.so.0`start_thread + 194
> frame #3: 0x7fd696af147d libc.so.6`clone + 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
>
>
> > Subject: Re: [lldb-dev] How to load core on a different machine?
> > From: gclay...@apple.com
> > Date: Wed, 6 Jan 2016 16:21:22 -0800
> > CC: lldb-dev@lists.llvm.org
> > To: eugen...@hotmail.com
> >
> >
> > > On Jan 6, 2016, at 3:39 PM, Eugene Birukov wrote:
> > >
> > > 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 shoul
[lldb-dev] lldb status at windows
Where can i look lldb status for native debug at Windows? ___ lldb-dev mailing list lldb-dev@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
