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 simpl
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
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 b
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
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 archi
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
> 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
> pr
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$ ~/ll
> 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? Tr
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
10 matches
Mail list logo
