Hi,
I am sorry if the following questions have already been answered in previous posts but I have
seen that you have been actively updating the code and I am interested in using lldb for my research in debugging (reverse debugging and program slicing)
Thank you,
~Ioannis
Hi,
I am sorry if the following questions have already been answered in previous posts but I have
seen that you have been actively updating the code and I am interested in using lldb for my research in debugging (reverse debugging and program slicing)1. Are you planning to release lldb along with llvm on September 29th ?
LLDB isn't planned to be in the LLVM 2.8 release. Hopefully it will be ready for the 2.9 release in ~ 6 months.
2. In the next release will you also support linux?
We'd like this, but this depends on someone making it happen. If you're interested, it would be great to get help to make this happen.
-Chris
> 2. In the next release will you also support linux?
We'd like this, but this depends on someone making it happen. If you're interested, it would be great to get help to make this happen.
I'm trying to start with _building_ it. Unfortunately, i couldn't figure out how the Makefile infrastructure is supposed to work.
It appears to me, it should be built within some other project, since the root Makefile depends on ../Makefile.common
I rewrote them all from scratch, but i guess it should use some sort of makefile generator. Do you have a favorite one?
Secondly, in include/lldb/Target/Thread.h can we do the unwind.h include a bit different? On linux, you'd have to use a different lib,
which is incompatible with the included headers. #include "libunwind.h" and extend the includepath to the local libunwind/include/ on osx
would work,
Secondly, in include/lldb/Target/Thread.h can we do the unwind.h include a bit different? On linux, you'd have to use a different lib,
which is incompatible with the included headers. #include "libunwind.h" and extend the includepath to the local libunwind/include/ on osx
would work,
Seems to be as simple as that. The attached patch makes it still compile under xcode for me, while enabling correct inclusion under Linux by
removing the local unwind headers from the includes. Please test yourself before applying, as i'm fairly new to xcode and might have done something wrong.
libunwind.patch (438 Bytes)
Eli Freiman wrote the Makefile system. Presumably you're supposed to
check out lldb into llvm/tools/lldb/ , and build from the root of the
LLVM project. But I'm just guessing, I've never built it.
Reid
That’s correct.
Eli Freiman wrote the Makefile system. Presumably you're supposed to
check out lldb into llvm/tools/lldb/ , and build from the root of the
LLVM project. But I'm just guessing, I've never built it.
I see, thanks for that info. With the attached patch, it indeed seems to work for llvm from svn.
Makefile_llvm_git.patch (1.22 KB)
Reid is correct!
You want to use the libunwind that is built into linux unless it can unwind when there is no EH frame info.
The remote unwind that we implemented that is used by LLDB will handle cases where there is no EH frame and it will disassemble the function and it will handle non-callsite locations. The EH frame info built into binaries is sparsely populated with info that is only valid at call sites which means you can't use it to unwind the first frame, nor any frame after a complete register state backup (sigtramp).
We are about to replace the libunwind stack backtracing soon with a new stack crawling engine that doesn't use libunwind, so this issue will go away soon (this week hopefully).
Until then, you will want to compile with our version of libuwnind that is statically linked into the lldb shared library.
If you have a patch once you get this working, let us know and we will evaluate that patch.
Let me know if you have any questions.
Greg Clayton
That first line should have been:
You _don't_ want to use the libunwind that is built into linux...
You want to use the libunwind that is built into linux unless it can unwind when there is no EH frame info.
The remote unwind that we implemented that is used by LLDB will handle cases where there is no EH frame
and it will disassemble the function and it will handle non-callsite locations. The EH frame info built into binaries
is sparsely populated with info that is only valid at call sites which means you can't use it to unwind the first frame,
nor any frame after a complete register state backup (sigtramp).
I see, that makes things more difficult.
We are about to replace the libunwind stack backtracing soon with a new stack crawling engine that doesn't use
libunwind, so this issue will go away soon (this week hopefully).
Nice! I will wait for said change then.
In the meantime, i have started to push my patches to a git clone here http://gitorious.org/lldb/lldb-linux.
Please feel free to pull from there, whatever you find useful.