[lldb-dev] Prologue instructions having line information
Carlos Alberto Enciso via lldb-dev
lldb-dev at lists.llvm.org
Tue Sep 19 03:19:57 PDT 2017
I have been trying to build LLDB on Windows (7) and after couple of days, I
managed to have a successfull build.
These are my findings:
1) Follow the instructions from
2) With Python 2.7, the cmake process fails, as it can't locate the
3) During the installation of Python 3.6, make sure to include the Debug
Symbols, which are the missing files from (2).
4) Set the following environment variables:
PYTHONHOME -> Directory where Python 3.6 is installed
PYTHONPATH=%PYTHONHOME%\Lib <- Lib
Download the distribution specified in the LLDB documentation:
Unzipp the whole contents and add an environment variable like
SWIG_DIR -> Directory where the zip file was unzipped.
It seems that the only way for cmake to pick up some of the previous
environment variables, is to specifiy them as parameters in the command
At the end, with the following command line I managed to get a successful
cmake -G "Visual Studio 14 2015 Win64" -DCMAKE_BUILD_TYPE=Release
You can add the following options if needed:
-DLLDB_TEST_COMPILER=<path to compiler to be used for testing>
My next tasks are:
try: check-all, check_lldb configurations.
I will post my findings.
Hope this help.
On Thu, Sep 14, 2017 at 6:10 PM, John Lindal <lldb.jafl at gmail.com> wrote:
> Which platform are you building on? I have been unable to build on OS X.
> On Sep 14, 2017, at 10:08 AM, Carlos Alberto Enciso via lldb-dev <
> lldb-dev at lists.llvm.org> wrote:
> Hi Tamas,
> Thanks very much for your reply and the useful information.
> In order to properly test my changes (I have another Debug Information
> ready for submission) I would like be able to build LLDB on my local
> machine. Once I reach that point, I will follow the process you described
> (compile calling.cpp) and I would let you know my progress.
> Best regards,
> On Thu, Sep 14, 2017 at 11:20 AM, Tamas Berghammer <tberghammer at google.com
> > wrote:
>> Hi Carlos,
>> Thank your for looking into the LLDB failure. I looked into it briefly
>> and the issue is that we have have 2 function f and g where g is inlined
>> into f as the first call and this causes the first non-prologue line entry
>> of f to be inside the address range of g what means that when we step info
>> f from outside we will end up inside g instead. Previously the first line
>> entry for f matched with the start address of the inlined copy of g where
>> LLDB was able to handle the stepping properly.
>> For the concrete example you should compile https://github.com/llv
>> ng/calling.cpp with "/mnt/ssd/ll/git/build/host-release/bin/clang-5.0
>> -std=c++11 -g -O0 -fno-builtin -m32 --driver-mode=g++ calling.cpp" and then
>> observe that caller_trivial_2 have a DW_AT_low_pc = 0x8048790 and the
>> inlined inline_trivial_1 inside it have a DW_AT_low_pc = 0x8048793 but the
>> first line entry after "Set prologue_end to true" is at 0x8048796 while
>> previously it was at 0x8048793.
>> On Thu, Sep 14, 2017 at 9:59 AM Carlos Alberto Enciso via lldb-dev <
>> lldb-dev at lists.llvm.org> wrote:
>>> I have been working on a compiler issue, where instructions associated
>>> to the function prolog are assigned line information, causing the debugger
>>> to show incorrectly the beginning of the function body.
>>> For a full description, please see:
>>> The submitted patch caused some LLDB tests to fail. I have attached the
>>> log failure.
>>> I have no knowledge about the test framework used by LLDB.
>>> What is the best way to proceed in this case?
>>> Thanks very much for your feedback.
>>> Carlos Enciso
>>> lldb-dev mailing list
>>> lldb-dev at lists.llvm.org
> Virus-free. www.avg.com
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the lldb-dev