[lldb-dev] Prologue instructions having line information

[Carlos Alberto Enciso via lldb-dev]

Hi,

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:

https://reviews.llvm.org/D37625
https://reviews.llvm.org/rL313047

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
++ config=(${1//,/ })
++ compiler=totclang
++ arch=i386
++ trap clean EXIT
++ '[' totclang == totclang ']'
++ compiler=/lldb-buildbot/lldbSlave/buildWorkingDir/scripts/../build/bin/clang
++ '[' / == / ']'
+++ dirname /lldb-buildbot/lldbSlave/buildWorkingDir/scripts/../build/bin/clang
++ ccdir=/lldb-buildbot/lldbSlave/buildWorkingDir/scripts/../build/bin/..
++ export 
LD_LIBRARY_PATH=/lldb-buildbot/lldbSlave/buildWorkingDir/scripts/../build/bin/../lib64:/lldb-buildbot/lldbSlave/buildWorkingDir/scripts/../build/bin/../lib32:/lldb-buildbot/lldbSlave/buildWorkingDir/scripts/../build/bin/../lib
++ 
LD_LIBRARY_PATH=/lldb-buildbot/lldbSlave/buildWorkingDir/scripts/../build/bin/../lib64:/lldb-buildbot/lldbSlave/buildWorkingDir/scripts/../build/bin/../lib32:/lldb-buildbot/lldbSlave/buildWorkingDir/scripts/../build/bin/../lib
++ cc_log=totclang
++ 
/lldb-buildbot/lldbSlave/buildWorkingDir/scripts/../llvm/tools/lldb/test/dotest.py
 --executable 
/lldb-buildbot/lldbSlave/buildWorkingDir/scripts/../build/bin/lldb -A i386 -C 
/lldb-buildbot/lldbSlave/buildWorkingDir/scripts/../build/bin/clang -v -s 
logs-totclang-i386 -u CXXFLAGS -u CFLAGS --env ARCHIVER=ar --env 
OBJCOPY=objcopy --channel 'gdb-remote packets' --channel 'lldb all' 
--skip-category lldb-mi
Testing: 597 test suites, 32 threads

  0 out of 597 test suites processed - 
['/lldb-buildbot/lldbSlave/buildWorkingDir/scripts/../llvm/tools/lldb/test/dotest.py',
 '--executable', 
'/lldb-buildbot/lldbSlave/buildWorkingDir/scripts/../build/bin/lldb', '-A', 
'i386', '-C', 
'/lldb-buildbot/lldbSlave/buildWorkingDir/scripts/../build/bin/clang', '-v', 
'-s', 'logs-totclang-i386', '-u', 'CXXFLAGS', '-u', 'CFLAGS', '--env', 
'ARCHIVER=ar', '--env', 'OBJCOPY=objcopy', '--channel', 'gdb-remote packets', 
'--channel', 'lldb all', '--skip-category', 'lldb-mi']

  1 out of 597 test suites processed - TestDarwinNSLogOutput.py
  2 out of 597 test suites processed - TestSequenceFunctions.py
  3 out of 597 test suites processed - TestBundleWithDotInFilename.py
  4 out of 597 test suites processed - TestAddDsymMidExecutionCommand.py
  5 out of 597 test suites processed - TestUniversal.py 
  6 out of 597 test suites processed - TestAppleTypesIsProduced.py  
  7 out of 597 test suites processed - TestDefaultCacheLineSize.py  
  8 out of 597 test suites processed - TestOrderFile.py 
  9 out of 597 test suites processed - TestSafeFuncCalls.py 
 10 out of 597 test suites processed - TestInterruptThreadNames.py  
 11 out of 597 test suites processed - TestAddDsymCommand.py
 12 out of 597 test suites processed - TestDeepBundle.py
 13 out of 597 test suites processed - TestQueues.py
 14 out of 597 test suites processed - TestIndirectSymbols.py   
 15 out of 597 test suites processed - TestSampleTest.py
 16 out of 597 test suites processed - TestMultipleTargets.py   
 17 out of 597 test suites processed - TestTargetSymbolsAddCommand.py   
 18 out of 597 test suites processed - TestImageListMultiArchitecture.py
 19 out of 597 test suites processed - TestPublicAPIHeaders.py  
 20 out of 597 test suites processed - TestMiniDump.py  
 21 out of 597 test suites processed - TestGCore.py 
 22 out of 597 test suites processed - TestLinuxCoreThreads.py  
 23 out of 597 test suites processed - TestWow64MiniDump.py 
 24 out of 597 test suites processed - TestPluginCommands.py
 25 out of 597 test suites processed - TestJITLoaderGDB.py  
 26 out of 597 test suites processed - TestLinuxCore.py 
 27 out of 597 test suites processed - TestBackticksWithoutATarget.py   
 28 out of 597 test suites processed - TestBuiltinTrap.py   
 29 out of 597 test suites processed - TestMultithreaded.py 
 30 out of 597 test suites processed - TestMemoryHistory.py 
 31 out of 597 test suites processed - TestSingleQuoteInFilename.py 
 32 out of 597 test suites processed - TestConcurrentManyWatchpoints.py 
 33 out of 597 test suites processed - TestMemoryCache.py   
 34 out of 597 test suites processed - TestCommandRegex.py  
 35 out of 597 test suites processed - TestMemoryRead.py
 36 out of 597 test suites processed - TestPythonOSPlugin.py
 37 out of 597

Re: [lldb-dev] Prologue instructions having line information

[Carlos Alberto Enciso via lldb-dev]

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,
Carlos

On Thu, Sep 14, 2017 at 11:20 AM, Tamas Berghammer 
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
> m-mirror/lldb/blob/26fea9dbbeb3020791cdbc46fbf3cc9d7685d7fd/
> packages/Python/lldbsuite/test/functionalities/inline-stepping/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.
>
> Tamas
>
> On Thu, Sep 14, 2017 at 9:59 AM Carlos Alberto Enciso via lldb-dev <
> lldb-dev@lists.llvm.org> wrote:
>
>> Hi,
>>
>> 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:
>>
>> https://reviews.llvm.org/D37625
>> https://reviews.llvm.org/rL313047
>>
>> 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@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>

<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.
www.avg.com
<http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] Prologue instructions having line information

[Carlos Alberto Enciso via lldb-dev]

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

https://lldb.llvm.org/build.html

2) With Python 2.7, the cmake process fails, as it can't locate the
following files:

python_d.exe
python27_d.lib
python27_d.dll

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
PYTHON_INCLUDE=%PYTHONHOME%\Include
PYTHON_LIB=%PYTHONHOME%\Libs

5) SWIG

Download the distribution specified in the LLDB documentation:

http://prdownloads.sourceforge.net/swig/swigwin-3.0.12.zip

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
line.

At the end, with the following command line I managed to get a successful
build.

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_DEBUG_TEST_CRASHES=1
-DLLDB_RELOCATABLE_PYTHON=1
-DLLDB_TEST_COMPILER=

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  wrote:

> Which platform are you building on?  I have been unable to build on OS X.
>
> John
>
>
> On Sep 14, 2017, at 10:08 AM, Carlos Alberto Enciso via lldb-dev <
> lldb-dev@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,
> Carlos
>
> On Thu, Sep 14, 2017 at 11:20 AM, Tamas Berghammer  > 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
>> m-mirror/lldb/blob/26fea9dbbeb3020791cdbc46fbf3cc9d7685d7fd/
>> packages/Python/lldbsuite/test/functionalities/inline-steppi
>> 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.
>>
>> Tamas
>>
>> On Thu, Sep 14, 2017 at 9:59 AM Carlos Alberto Enciso via lldb-dev <
>> lldb-dev@lists.llvm.org> wrote:
>>
>>> Hi,
>>>
>>> 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:
>>>
>>> https://reviews.llvm.org/D37625
>>> https://reviews.llvm.org/rL313047
>>>
>>> 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@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>
>>
>
>
> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
> Virus-free. www.avg.com
> <http://www.avg.com/email-signature?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail>
> ___
> 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] Prologue instructions having line information

[Carlos Alberto Enciso via lldb-dev]

Results from 'check-all' project:
-

Additional requirement: the regression tests requires the python 'psutil'
module.

There is a common error when trying to build 'check-all' project. One of
the instances can be seen on:

llvm\projects\compiler-rt\test\lit.common.cfg:34

# 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 "

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.

Thanks,
Carlos

On Tue, Sep 19, 2017 at 11:19 AM, Carlos Alberto Enciso <
international.phan...@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
>
> https://lldb.llvm.org/build.html
>
> 2) With Python 2.7, the cmake process fails, as it can't locate the
> following files:
>
> python_d.exe
> python27_d.lib
> python27_d.dll
>
> 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
> PYTHON_INCLUDE=%PYTHONHOME%\Include
> PYTHON_LIB=%PYTHONHOME%\Libs
>
> 5) SWIG
>
> Download the distribution specified in the LLDB documentation:
>
> http://prdownloads.sourceforge.net/swig/swigwin-3.0.12.zip
>
> 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
> line.
>
> At the end, with the following command line I managed to get a successful
> build.
>
> 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_DEBUG_TEST_CRASHES=1
> -DLLDB_RELOCATABLE_PYTHON=1
> -DLLDB_TEST_COMPILER=
>
> 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  wrote:
>
>> Which platform are you building on?  I have been unable to build on OS X.
>>
>> John
>>
>>
>> On Sep 14, 2017, at 10:08 AM, Carlos Alberto Enciso via lldb-dev <
>> lldb-dev@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,
>> Carlos
>>
>> On Thu, Sep 14, 2017 at 11:20 AM, Tamas Berghammer > .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
>>> m-mirror/lldb/blob/26fea9dbbeb3020791cdbc46fbf3cc9d7685d7fd/
>>> packages/Python/lldbsuite/test/functionalities/inline-steppi
>>> 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_

[lldb-dev] LLDB tests unable to find 'lldb-mi' on Windows

[Carlos Alberto Enciso via lldb-dev]

Hi,

I been trying to run the LLDB test suite on Windows (check-lldb).

The LLDB used was build with VS2015 and ninja.

When I try to run an specific test, using the commands:

cd D:\LLVM\llvm\tools\lldb\test
python dotest.py --executable "D:\LLVM\build-ninja-lldb\bin\lldb.exe" -p
TestInlineStepping.py ..\packages\Python\lldbsuite\test

I get the following output:

==
LLDB library dir: D:\LLVM\build-ninja-lldb\bin
LLDB import library dir: D:\LLVM\build-ninja-lldb\bin\..\lib
lldb version 6.0.0 (http://llvm.org/svn/llvm-project/lldb/trunk revision
313964)
  clang revision 313964
  llvm revision 313964
The 'lldb-mi' executable cannot be located.  The lldb-mi tests can not be
run as a result.
==

However, 'lldb-mi.exe' is located in the same directory as 'lldb.exe'.

There is an existence reference mentioned in:

https://reviews.llvm.org/D25486

Thanks,

Carlos Enciso
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Bug 34676] check-lldb target fails on Windows due to incomplete compiler path

[Carlos Alberto Enciso via lldb-dev]

Hi Adrian,

As you are working on the above Windows issue, I am assuming you are
running LLDB on Windows.
I have managed to build LLDB on Windows 10, after getting the correct
dependencies.

But from the LLDB home page, it seems that LLDB is only built and no tests
are run:

   - LLDB Windows Server 2008 x86 (CMake, MSVS 2013, Windows SDK 8.1, no
   tests) 
   - LLDB Windows 7 x86 (CMake, MSVS 2013, Windows SDK 8.1, no tests)
   

I run the tests via 'check-lldb' and these are the results:

63>  ===

63>  Test Result Summary

63>  ===

63>  Test Methods:   1299

63>  Reruns:   68

63>  Success: 365

63>  Expected Failure:233

*63>  Failure:  34*

63>CUSTOMBUILD : error : 14

63>  Exceptional Exit:  0

*63>  Unexpected Success:5*

63>  Skip:648

63>  Timeout:   0

63>  Expected Timeout:  0

I am wondering if these results match yours.

Thanks very much,

Carlos Enciso

On Tue, Sep 19, 2017 at 11:08 PM, via lldb-dev 
wrote:

> Adrian McCarthy  changed bug 34676
> 
> What Removed Added
> Assignee lldb-dev@lists.llvm.org amcca...@google.com
>
> *Comment # 1  on bug 34676
>  from Adrian McCarthy
>  *
>
> I'm starting with git bisect to see if I can pinpoint when this got broken.  
> It
> looks like it may have been a while back already.
>
> --
> You are receiving this mail because:
>
>- You are the assignee for the bug.
>
>
> ___
> 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] [Bug 34676] check-lldb target fails on Windows due to incomplete compiler path

[Carlos Alberto Enciso via lldb-dev]

Hi Adrian,

Thanks very much for sharing your results.

Carlos

On Tue, Sep 26, 2017 at 4:31 PM, Adrian McCarthy 
wrote:

> I haven't spent too much time in LLDB lately.  The number of failures you
> see seems a little high.  On Windows 7, I get:
>
> ===
> Test Result Summary
> ===
> Test Methods:   1301
> Reruns:   28
> Success: 387
> Expected Failure:237
> Failure:   4
> Error:11
> Exceptional Exit:  0
> Unexpected Success:3
> Skip:659
> Timeout:   0
> Expected Timeout:  0
>
>
> On Tue, Sep 26, 2017 at 5:31 AM, Carlos Alberto Enciso <
> international.phan...@gmail.com> wrote:
>
>> Hi Adrian,
>>
>> As you are working on the above Windows issue, I am assuming you are
>> running LLDB on Windows.
>> I have managed to build LLDB on Windows 10, after getting the correct
>> dependencies.
>>
>> But from the LLDB home page, it seems that LLDB is only built and no
>> tests are run:
>>
>>- LLDB Windows Server 2008 x86 (CMake, MSVS 2013, Windows SDK 8.1, no
>>tests) 
>>- LLDB Windows 7 x86 (CMake, MSVS 2013, Windows SDK 8.1, no tests)
>>
>>
>> I run the tests via 'check-lldb' and these are the results:
>>
>> 63>  ===
>>
>> 63>  Test Result Summary
>>
>> 63>  ===
>>
>> 63>  Test Methods:   1299
>>
>> 63>  Reruns:   68
>>
>> 63>  Success: 365
>>
>> 63>  Expected Failure:233
>>
>> *63>  Failure:  34*
>>
>> 63>CUSTOMBUILD : error : 14
>>
>> 63>  Exceptional Exit:  0
>>
>> *63>  Unexpected Success:5*
>>
>> 63>  Skip:648
>>
>> 63>  Timeout:   0
>>
>> 63>  Expected Timeout:  0
>>
>> I am wondering if these results match yours.
>>
>> Thanks very much,
>>
>> Carlos Enciso
>>
>> On Tue, Sep 19, 2017 at 11:08 PM, via lldb-dev 
>> wrote:
>>
>>> Adrian McCarthy  changed bug 34676
>>> 
>>> What Removed Added
>>> Assignee lldb-dev@lists.llvm.org amcca...@google.com
>>>
>>> *Comment # 1  on bug
>>> 34676  from Adrian McCarthy
>>>  *
>>>
>>> I'm starting with git bisect to see if I can pinpoint when this got broken. 
>>>  It
>>> looks like it may have been a while back already.
>>>
>>> --
>>> You are receiving this mail because:
>>>
>>>- You are the assignee for the bug.
>>>
>>>
>>> ___
>>> 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