[lldb-dev] Prologue instructions having line information
Carlos Alberto Enciso via lldb-dev
lldb-dev at lists.llvm.org
Tue Sep 19 07:21:24 PDT 2017
Results from 'check-all' project:
Additional requirement: the regression tests requires the python 'psutil'
There is a common error when trying to build 'check-all' project. One of
the instances can be seen on:
# Setup clang binary.
compiler_path = getattr(config, 'clang', None)
if (not compiler_path) or (not os.path.exists(compiler_path)):
lit_config.fatal("Can't find compiler on path %r" % compiler_path)
that generates the following error:
"Can't find compiler on path <pathname>"
with pathname pointing to the required clang.exe, but having the
$(Configuration) string. Basically, that cmake attribute not being
expanded. Is was building the 'Release' configuration.
Using the option -DLLVM_BUILD_RUNTIME=OFF, seems to fix the problems. But I
do not know about any side effects on the LLDB tests.
On Tue, Sep 19, 2017 at 11:19 AM, Carlos Alberto Enciso <
international.phantom at gmail.com> wrote:
> 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
> following files:
> 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
> 5) SWIG
> 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
> -DSWIG_DIR=C:\ProgramData\SWIG -DPYTHON_HOME=C:\ProgramData\Python36
> -DPYTHON_EXECUTABLE=C:\ProgramData\Python36\python.exe ..\llvm
> 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