Re: [Lldb-commits] [PATCH] D19067: Make sure to use lib instead of lib64 for LLDB_LIB_DIR
labath added a comment.
In http://reviews.llvm.org/D19067#401416, @fjricci wrote:
> When I use LLVM_LIBDIR_SUFFIX=64, it looks like the python _lldb.so symlink
> still points to build/lib/liblldb.so, instead of using the lib64 directory.
> So if I do this, none of the tests will run on the check-lldb target, since
> importing lldb in python fails.
>
> Perhaps this symlink is the bug that should be fixed? However, it appears
> that finish-swig-Python-LLDB.sh already has the correct logic for this, so
> it's not immediately clear to me why the symlink is incorrect (if this seems
> like a bug we want fixed, I'll investigate):
>
> ln -s "../../../liblldb${SOEXT}" _lldb.so
>
Yes, I believe this would be a better fix for your problem.
Note that `finish-swig-Python-LLDB.sh` is not used anymore in the cmake build.
It's replacement is `finishSwigPythonLLDB.py` so you'll need to look for the
problem there.
http://reviews.llvm.org/D19067
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r266416 - Make destructor breakpoint location test more resilient
Author: labath
Date: Fri Apr 15 04:11:22 2016
New Revision: 266416
URL: http://llvm.org/viewvc/llvm-project?rev=266416&view=rev
Log:
Make destructor breakpoint location test more resilient
Summary:
The original breakpoint location test was failing for linux, because the
compilers here tend to
merge the full-object and subobject destructors even at -O0 (as a result, we
are getting only 2
breakpoint locations, and not 4 as the test expected. The fixup in r266164
substantially weakened
the test, as it now did not check whether both kinds of destructors were being
found.
Because of these contraints, I have altered the logic of the test. It sets the
breakpoint by name, and then independently verifies that the breakpoint is set
on the correct
demangled symbol name (which is not very meaningful since both kinds of
destructors demangle to
the same name) *and* the correct symbol address (which is obtained by looking
up the mangled
symbol name).
Reviewers: clayborg
Subscribers: ovyalov, zturner, lldb-commits
Differential Revision: http://reviews.llvm.org/D19052
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/cpp/TestCPPBreakpointLocations.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/cpp/main.cpp
Modified:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/cpp/TestCPPBreakpointLocations.py
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/cpp/TestCPPBreakpointLocations.py?rev=266416&r1=266415&r2=266416&view=diff
==
---
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/cpp/TestCPPBreakpointLocations.py
(original)
+++
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/cpp/TestCPPBreakpointLocations.py
Fri Apr 15 04:11:22 2016
@@ -26,7 +26,7 @@ class TestCPPBreakpointLocations(TestBas
name = bp_dict['name']
names = bp_dict['loc_names']
bp = target.BreakpointCreateByName (name)
-self.assertTrue (bp.GetNumLocations() <= len(names), "Make sure we
find the right number of breakpoint locations")
+self.assertEquals(bp.GetNumLocations(), len(names), "Make sure we find
the right number of breakpoint locations")
bp_loc_names = list()
for bp_loc in bp:
@@ -48,19 +48,48 @@ class TestCPPBreakpointLocations(TestBas
{ 'name' : 'func1', 'loc_names' : [ 'a::c::func1()',
'b::c::func1()'] },
{ 'name' : 'func2', 'loc_names' : [ 'a::c::func2()',
'c::d::func2()'] },
{ 'name' : 'func3', 'loc_names' : [ 'a::c::func3()',
'b::c::func3()', 'c::d::func3()'] },
-{ 'name' : '~c', 'loc_names' : [ 'a::c::~c()', 'b::c::~c()',
'a::c::~c()', 'b::c::~c()'] },
{ 'name' : 'c::func1', 'loc_names' : [ 'a::c::func1()',
'b::c::func1()'] },
{ 'name' : 'c::func2', 'loc_names' : [ 'a::c::func2()'] },
{ 'name' : 'c::func3', 'loc_names' : [ 'a::c::func3()',
'b::c::func3()'] },
-{ 'name' : 'c::~c', 'loc_names' : [ 'a::c::~c()', 'b::c::~c()',
'a::c::~c()', 'b::c::~c()'] },
{ 'name' : 'a::c::func1', 'loc_names' : [ 'a::c::func1()'] },
{ 'name' : 'b::c::func1', 'loc_names' : [ 'b::c::func1()'] },
{ 'name' : 'c::d::func2', 'loc_names' : [ 'c::d::func2()'] },
{ 'name' : 'a::c::func1()', 'loc_names' : [ 'a::c::func1()'] },
{ 'name' : 'b::c::func1()', 'loc_names' : [ 'b::c::func1()'] },
{ 'name' : 'c::d::func2()', 'loc_names' : [ 'c::d::func2()'] },
-{ 'name' : 'c::~c()', 'loc_names' : [ 'a::c::~c()', 'b::c::~c()',
'a::c::~c()', 'b::c::~c()'] },
]
for bp_dict in bp_dicts:
self.verify_breakpoint_locations(target, bp_dict)
+
+@expectedFailureAll(oslist=["windows"], bugnumber="llvm.org/pr24764")
+def test_destructors(self):
+self.build()
+exe = os.path.join(os.getcwd(), "a.out")
+target = self.dbg.CreateTarget(exe)
+
+# Don't skip prologue, so we can check the breakpoint address more
easily
+self.runCmd("settings set target.skip-prologue false")
+try:
+names = ['~c', 'c::~c', 'c::~c()']
+loc_names = {'a::c::~c()', 'b::c::~c()'}
+# TODO: For windows targets we should put windows mangled names
here
+symbols = ['_ZN1a1cD1Ev', '_ZN1a1cD2Ev', '_ZN1b1cD1Ev',
'_ZN1b1cD2Ev']
+
+for name in names:
+bp = target.BreakpointCreateByName(name)
+
+bp_loc_names = { bp_loc.GetAddress().GetFunction().GetName()
for bp_loc in bp }
+self.assertEquals(bp_loc_names, loc_names, "Breakpoint set on
the correct symbol")
+
+bp_addresses = { bp_loc.GetLoadAddress() for bp_loc in bp }
+symbol_addresses = set()
+
Re: [Lldb-commits] [PATCH] D19052: Make destructor breakpoint location test more resilient
This revision was automatically updated to reflect the committed changes.
Closed by commit rL266416: Make destructor breakpoint location test more
resilient (authored by labath).
Changed prior to commit:
http://reviews.llvm.org/D19052?vs=53694&id=53860#toc
Repository:
rL LLVM
http://reviews.llvm.org/D19052
Files:
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/cpp/TestCPPBreakpointLocations.py
lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/cpp/main.cpp
Index: lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/cpp/main.cpp
===
--- lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/cpp/main.cpp
+++ lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/cpp/main.cpp
@@ -12,8 +12,8 @@
namespace a {
class c {
public:
-c () {}
-~c() {}
+c();
+~c();
void func1()
{
puts (__PRETTY_FUNCTION__);
@@ -27,13 +27,16 @@
puts (__PRETTY_FUNCTION__);
}
};
+
+c::c() {}
+c::~c() {}
}
namespace b {
class c {
public:
-c () {}
-~c() {}
+c();
+~c();
void func1()
{
puts (__PRETTY_FUNCTION__);
@@ -43,6 +46,9 @@
puts (__PRETTY_FUNCTION__);
}
};
+
+c::c() {}
+c::~c() {}
}
namespace c {
Index: lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/cpp/TestCPPBreakpointLocations.py
===
--- lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/cpp/TestCPPBreakpointLocations.py
+++ lldb/trunk/packages/Python/lldbsuite/test/functionalities/breakpoint/cpp/TestCPPBreakpointLocations.py
@@ -26,7 +26,7 @@
name = bp_dict['name']
names = bp_dict['loc_names']
bp = target.BreakpointCreateByName (name)
-self.assertTrue (bp.GetNumLocations() <= len(names), "Make sure we find the right number of breakpoint locations")
+self.assertEquals(bp.GetNumLocations(), len(names), "Make sure we find the right number of breakpoint locations")
bp_loc_names = list()
for bp_loc in bp:
@@ -48,19 +48,48 @@
{ 'name' : 'func1', 'loc_names' : [ 'a::c::func1()', 'b::c::func1()'] },
{ 'name' : 'func2', 'loc_names' : [ 'a::c::func2()', 'c::d::func2()'] },
{ 'name' : 'func3', 'loc_names' : [ 'a::c::func3()', 'b::c::func3()', 'c::d::func3()'] },
-{ 'name' : '~c', 'loc_names' : [ 'a::c::~c()', 'b::c::~c()', 'a::c::~c()', 'b::c::~c()'] },
{ 'name' : 'c::func1', 'loc_names' : [ 'a::c::func1()', 'b::c::func1()'] },
{ 'name' : 'c::func2', 'loc_names' : [ 'a::c::func2()'] },
{ 'name' : 'c::func3', 'loc_names' : [ 'a::c::func3()', 'b::c::func3()'] },
-{ 'name' : 'c::~c', 'loc_names' : [ 'a::c::~c()', 'b::c::~c()', 'a::c::~c()', 'b::c::~c()'] },
{ 'name' : 'a::c::func1', 'loc_names' : [ 'a::c::func1()'] },
{ 'name' : 'b::c::func1', 'loc_names' : [ 'b::c::func1()'] },
{ 'name' : 'c::d::func2', 'loc_names' : [ 'c::d::func2()'] },
{ 'name' : 'a::c::func1()', 'loc_names' : [ 'a::c::func1()'] },
{ 'name' : 'b::c::func1()', 'loc_names' : [ 'b::c::func1()'] },
{ 'name' : 'c::d::func2()', 'loc_names' : [ 'c::d::func2()'] },
-{ 'name' : 'c::~c()', 'loc_names' : [ 'a::c::~c()', 'b::c::~c()', 'a::c::~c()', 'b::c::~c()'] },
]
for bp_dict in bp_dicts:
self.verify_breakpoint_locations(target, bp_dict)
+
+@expectedFailureAll(oslist=["windows"], bugnumber="llvm.org/pr24764")
+def test_destructors(self):
+self.build()
+exe = os.path.join(os.getcwd(), "a.out")
+target = self.dbg.CreateTarget(exe)
+
+# Don't skip prologue, so we can check the breakpoint address more easily
+self.runCmd("settings set target.skip-prologue false")
+try:
+names = ['~c', 'c::~c', 'c::~c()']
+loc_names = {'a::c::~c()', 'b::c::~c()'}
+# TODO: For windows targets we should put windows mangled names here
+symbols = ['_ZN1a1cD1Ev', '_ZN1a1cD2Ev', '_ZN1b1cD1Ev', '_ZN1b1cD2Ev']
+
+for name in names:
+bp = target.BreakpointCreateByName(name)
+
+bp_loc_names = { bp_loc.GetAddress().GetFunction().GetName() for bp_loc in bp }
+self.assertEquals(bp_loc_names, loc_names, "Breakpoint set on the correct symbol")
+
+bp_addresses = { bp_loc.GetLoadAddress() for bp_loc in bp }
+symbol_addresses = set()
+for symbol in symbols:
+sc_list = target.FindSymbols(symbol, lldb.eSymbolTypeCode)
+self.assertEquals(sc_list.
Re: [Lldb-commits] [PATCH] D18978: Support Linux on SystemZ as platform
Thanks a lot for cleaning that up. I hope you'll be able to find the cause of the 32-bit problems quickly. If you need help reproducing the errors, I can send you some of the detailed logs from our buildbots. cheers, pl On 14 April 2016 at 22:25, Ulrich Weigand wrote: > Ulrich Weigand/Germany/IBM wrote on 14.04.2016 18:20:20: > >> So there seem to be at least two different issues, looking at the build >> bot >> logs. After the main SystemZ patch went it, there was just a single >> failure, a timeout on the new s390x.core test. I guess we can just >> disable >> that test until we know what's going on here. >> >> After the rest of the patches went in, we're additionally seeing all those >> 32-bit failures. Not sure which of the patches is responsible (most >> likely >> the Scalar / APInt patch, just from the amount of changes). >> >> I'm currently rebuilding the Intel LLDB to see if I can reproduce locally. > > The current status is: > > - I've disabled the s390x.core test on all architectures except s390x; > there seems to be some problem with reading cross-architecture cores. > > - There was a regression introduced due to a thinko in my gnu_libstdcpp.py > patch; I've checked in a fix for that. > > - Support for the new files was missing in the XCode project file; > Greg checked in a fix for that. Thanks! > > - I was unable to reproduce the 32-bit failures on my system, so I just > reverted the Scalar / APInt patch, and that got the build bot going again. > Looking at the results, I think I now understand why I wasn't able to > reproduce: I was using gcc to compile the test cases, but apparently > the failure occurred only when using clang. I'll try again to reproduce. > > Right now, the build bots seem to be going green again one by one, hopefully > we'll be back to normal soon. Sorry for the breakage! > > Bye, > Ulrich > ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r266417 - Fix ABISysV_s390x::GetArgumentValues
Author: uweigand
Date: Fri Apr 15 04:14:32 2016
New Revision: 266417
URL: http://llvm.org/viewvc/llvm-project?rev=266417&view=rev
Log:
Fix ABISysV_s390x::GetArgumentValues
This routine contained a stray "return false;" making part of the code
never executed. Also, the stack offset where to find on-stack arguments
was incorrect.
Modified:
lldb/trunk/source/Plugins/ABI/SysV-s390x/ABISysV_s390x.cpp
Modified: lldb/trunk/source/Plugins/ABI/SysV-s390x/ABISysV_s390x.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Plugins/ABI/SysV-s390x/ABISysV_s390x.cpp?rev=266417&r1=266416&r2=266417&view=diff
==
--- lldb/trunk/source/Plugins/ABI/SysV-s390x/ABISysV_s390x.cpp (original)
+++ lldb/trunk/source/Plugins/ABI/SysV-s390x/ABISysV_s390x.cpp Fri Apr 15
04:14:32 2016
@@ -365,7 +365,7 @@ ABISysV_s390x::GetArgumentValues(Thread
if (!sp)
return false;
-addr_t current_stack_argument = sp;
+addr_t current_stack_argument = sp + 160;
uint32_t argument_register_ids[5];
@@ -382,7 +382,6 @@ ABISysV_s390x::GetArgumentValues(Thread
unsigned int current_argument_register = 0;
-return false;
for (value_index = 0; value_index < num_values; ++value_index)
{
Value *value = values.GetValueAtIndex(value_index);
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r266419 - Fix Scalar::MakeSigned for 128- and 256-bit types.
Author: uweigand Date: Fri Apr 15 04:15:22 2016 New Revision: 266419 URL: http://llvm.org/viewvc/llvm-project?rev=266419&view=rev Log: Fix Scalar::MakeSigned for 128- and 256-bit types. Obvious fix for incorrect result types of the operation. Originally committed as part of (now reverted) r266311. Modified: lldb/trunk/source/Core/Scalar.cpp Modified: lldb/trunk/source/Core/Scalar.cpp URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/Scalar.cpp?rev=266419&r1=266418&r2=266419&view=diff == --- lldb/trunk/source/Core/Scalar.cpp (original) +++ lldb/trunk/source/Core/Scalar.cpp Fri Apr 15 04:15:22 2016 @@ -1369,9 +1369,9 @@ Scalar::MakeSigned () case e_slonglong: success = true; break; case e_ulonglong: m_type = e_slonglong; success = true; break; case e_sint128: success = true; break; -case e_uint128: m_type = e_sint;success = true; break; +case e_uint128: m_type = e_sint128; success = true; break; case e_sint256: success = true; break; -case e_uint256: m_type = e_sint;success = true; break; +case e_uint256: m_type = e_sint256; success = true; break; case e_float: success = true; break; case e_double: success = true; break; case e_long_double: success = true; break; ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r266418 - Fix Scalar::SetValueFromData for 128- and 256-bit types
Author: uweigand
Date: Fri Apr 15 04:14:59 2016
New Revision: 266418
URL: http://llvm.org/viewvc/llvm-project?rev=266418&view=rev
Log:
Fix Scalar::SetValueFromData for 128- and 256-bit types
Obvious fix for incorrect use of GetU64 offset pointer.
Originally committed as part of (now reverted) r266311.
Modified:
lldb/trunk/source/Core/Scalar.cpp
Modified: lldb/trunk/source/Core/Scalar.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/Scalar.cpp?rev=266418&r1=266417&r2=266418&view=diff
==
--- lldb/trunk/source/Core/Scalar.cpp (original)
+++ lldb/trunk/source/Core/Scalar.cpp Fri Apr 15 04:14:59 2016
@@ -2652,12 +2652,12 @@ Scalar::SetValueFromData (DataExtractor
if (data.GetByteOrder() == eByteOrderBig)
{
int128.x[1] = (uint64_t)data.GetU64 (&offset);
-int128.x[0] = (uint64_t)data.GetU64 (&offset + 1);
+int128.x[0] = (uint64_t)data.GetU64 (&offset);
}
else
{
int128.x[0] = (uint64_t)data.GetU64 (&offset);
-int128.x[1] = (uint64_t)data.GetU64 (&offset + 1);
+int128.x[1] = (uint64_t)data.GetU64 (&offset);
}
operator=(llvm::APInt(BITWIDTH_INT128, NUM_OF_WORDS_INT128,
int128.x));
break;
@@ -2665,16 +2665,16 @@ Scalar::SetValueFromData (DataExtractor
if (data.GetByteOrder() == eByteOrderBig)
{
int256.x[3] = (uint64_t)data.GetU64 (&offset);
-int256.x[2] = (uint64_t)data.GetU64 (&offset + 1);
-int256.x[1] = (uint64_t)data.GetU64 (&offset + 1);
-int256.x[0] = (uint64_t)data.GetU64 (&offset + 1);
+int256.x[2] = (uint64_t)data.GetU64 (&offset);
+int256.x[1] = (uint64_t)data.GetU64 (&offset);
+int256.x[0] = (uint64_t)data.GetU64 (&offset);
}
else
{
int256.x[0] = (uint64_t)data.GetU64 (&offset);
-int256.x[1] = (uint64_t)data.GetU64 (&offset + 1);
-int256.x[2] = (uint64_t)data.GetU64 (&offset + 1);
-int256.x[3] = (uint64_t)data.GetU64 (&offset + 1);
+int256.x[1] = (uint64_t)data.GetU64 (&offset);
+int256.x[2] = (uint64_t)data.GetU64 (&offset);
+int256.x[3] = (uint64_t)data.GetU64 (&offset);
}
operator=(llvm::APInt(BITWIDTH_INT256, NUM_OF_WORDS_INT256,
int256.x));
break;
@@ -2698,12 +2698,12 @@ Scalar::SetValueFromData (DataExtractor
if (data.GetByteOrder() == eByteOrderBig)
{
int128.x[1] = (uint64_t)data.GetU64 (&offset);
-int128.x[0] = (uint64_t)data.GetU64 (&offset + 1);
+int128.x[0] = (uint64_t)data.GetU64 (&offset);
}
else
{
int128.x[0] = (uint64_t)data.GetU64 (&offset);
-int128.x[1] = (uint64_t)data.GetU64 (&offset + 1);
+int128.x[1] = (uint64_t)data.GetU64 (&offset);
}
operator=(llvm::APInt(BITWIDTH_INT128, NUM_OF_WORDS_INT128,
int128.x));
break;
@@ -2711,16 +2711,16 @@ Scalar::SetValueFromData (DataExtractor
if (data.GetByteOrder() == eByteOrderBig)
{
int256.x[3] = (uint64_t)data.GetU64 (&offset);
-int256.x[2] = (uint64_t)data.GetU64 (&offset + 1);
-int256.x[1] = (uint64_t)data.GetU64 (&offset + 1);
-int256.x[0] = (uint64_t)data.GetU64 (&offset + 1);
+int256.x[2] = (uint64_t)data.GetU64 (&offset);
+int256.x[1] = (uint64_t)data.GetU64 (&offset);
+int256.x[0] = (uint64_t)data.GetU64 (&offset);
}
else
{
int256.x[0] = (uint64_t)data.GetU64 (&offset);
-int256.x[1] = (uint64_t)data.GetU64 (&offset + 1);
-int256.x[2] = (uint64_t)data.GetU64 (&offset + 1);
-int256.x[3] = (uint64_t)data.GetU64 (&offset + 1);
+int256.x[1] = (uint64_t)data.GetU64 (&offset);
+int256.x[2] = (uint64_t)data.GetU64 (&offset);
+int256.x[3] = (uint64_t)data.GetU64 (&offset);
}
operator=(llvm::APInt(BITWIDTH_INT256, NUM_OF_WORDS_INT256,
int256.x));
break;
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r266420 - Make Scalar::SChar return an explicit signed type
Author: uweigand
Date: Fri Apr 15 04:15:47 2016
New Revision: 266420
URL: http://llvm.org/viewvc/llvm-project?rev=266420&view=rev
Log:
Make Scalar::SChar return an explicit signed type
This is needed for platforms where the default "char" type is unsigned.
Originally committed as part of (now reverted) r266311.
Modified:
lldb/trunk/include/lldb/Core/Scalar.h
lldb/trunk/source/Core/Scalar.cpp
Modified: lldb/trunk/include/lldb/Core/Scalar.h
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Core/Scalar.h?rev=266420&r1=266419&r2=266420&view=diff
==
--- lldb/trunk/include/lldb/Core/Scalar.h (original)
+++ lldb/trunk/include/lldb/Core/Scalar.h Fri Apr 15 04:15:47 2016
@@ -254,7 +254,7 @@ public:
unsigned char
UChar(unsigned char fail_value = 0) const;
-char
+signed char
SChar(char fail_value = 0) const;
unsigned short
Modified: lldb/trunk/source/Core/Scalar.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/Scalar.cpp?rev=266420&r1=266419&r2=266420&view=diff
==
--- lldb/trunk/source/Core/Scalar.cpp (original)
+++ lldb/trunk/source/Core/Scalar.cpp Fri Apr 15 04:15:47 2016
@@ -1380,7 +1380,7 @@ Scalar::MakeSigned ()
return success;
}
-char
+signed char
Scalar::SChar(char fail_value) const
{
switch (m_type)
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D18978: Support Linux on SystemZ as platform
Pavel Labath wrote on 15.04.2016 11:19:35:
> Thanks a lot for cleaning that up. I hope you'll be able to find the
> cause of the 32-bit problems quickly. If you need help reproducing the
> errors, I can send you some of the detailed logs from our buildbots.
I did manage to find the cause of the 32-bit problems now. The
modified Scalar::Promote routine made incorrect decisions on when
to zero-extend and when to sign-extend the incoming value. This
needs to be done based on the signedness of the *source* type of
the Promote, not the target type, which my patch got wrong.
This caused LLDB to incorrectly sign-extend 32-bit target pointer
values to 64-bit host values, which resulted in ptrace errors when
attempting to access target memory at those locations:
AssertionError: False is not True : 'frame variable one' returns expected
result, got '(i_am_cool) one = {
integer =
floating =
character =
I've fixed this now, and those tests no longer fail on my system.
I'm planning on recommitted the fixed patch shortly.
Bye,
Ulrich
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [PATCH] D19153: Work around a linux libc bug causing a crash in TaskPool
labath created this revision.
labath added a reviewer: tberghammer.
labath added a subscriber: lldb-commits.
Doing a pthread_detach while the thread is exiting can cause crashes or other
mischief, so we
make sure the thread stays around long enough. The performance impact of the
added
synchronization should be minimal, as the parent thread is already holding a
mutex, so I am just
making sure it holds it for a little while longer. It's possible the new thread
will block on
this mutex immediately after startup, but it should be unblocked really quickly
and some
blocking is unavoidable if we actually want to have this synchronization.
http://reviews.llvm.org/D19153
Files:
source/Utility/TaskPool.cpp
Index: source/Utility/TaskPool.cpp
===
--- source/Utility/TaskPool.cpp
+++ source/Utility/TaskPool.cpp
@@ -61,8 +61,9 @@
if (m_thread_count < max_threads)
{
m_thread_count++;
-lock.unlock();
-
+// Note that this detach call needs to happen with the m_tasks_mutex
held. This prevents the thread
+// from exiting prematurely and triggering a linux libc bug
+// (https://sourceware.org/bugzilla/show_bug.cgi?id=19951).
std::thread (Worker, this).detach();
}
}
Index: source/Utility/TaskPool.cpp
===
--- source/Utility/TaskPool.cpp
+++ source/Utility/TaskPool.cpp
@@ -61,8 +61,9 @@
if (m_thread_count < max_threads)
{
m_thread_count++;
-lock.unlock();
-
+// Note that this detach call needs to happen with the m_tasks_mutex held. This prevents the thread
+// from exiting prematurely and triggering a linux libc bug
+// (https://sourceware.org/bugzilla/show_bug.cgi?id=19951).
std::thread (Worker, this).detach();
}
}
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r266422 - Fix usage of APInt.getRawData for big-endian systems
Author: uweigand
Date: Fri Apr 15 04:55:52 2016
New Revision: 266422
URL: http://llvm.org/viewvc/llvm-project?rev=266422&view=rev
Log:
Fix usage of APInt.getRawData for big-endian systems
Recommit modified version of r266311 including build bot regression fix.
This differs from the original r266311 by:
- Fixing Scalar::Promote to correctly zero- or sign-extend value depending
on signedness of the *source* type, not the target type.
- Omitting a few stand-alone fixes that were already committed separately.
Modified:
lldb/trunk/include/lldb/Core/Scalar.h
lldb/trunk/include/lldb/Symbol/Type.h
lldb/trunk/source/Core/Scalar.cpp
lldb/trunk/source/Expression/IRInterpreter.cpp
lldb/trunk/source/Plugins/ExpressionParser/Clang/IRForTarget.cpp
lldb/trunk/source/Symbol/ClangASTContext.cpp
lldb/trunk/unittests/Core/ScalarTest.cpp
Modified: lldb/trunk/include/lldb/Core/Scalar.h
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Core/Scalar.h?rev=266422&r1=266421&r2=266422&view=diff
==
--- lldb/trunk/include/lldb/Core/Scalar.h (original)
+++ lldb/trunk/include/lldb/Core/Scalar.h Fri Apr 15 04:55:52 2016
@@ -162,6 +162,9 @@ public:
bool
MakeSigned ();
+bool
+MakeUnsigned ();
+
static const char *
GetValueTypeAsCString (Scalar::Type value_type);
@@ -239,18 +242,6 @@ public:
int
SInt(int fail_value = 0) const;
-// Return the raw unsigned integer without any casting or conversion
-unsigned int
-RawUInt () const;
-
-// Return the raw unsigned long without any casting or conversion
-unsigned long
-RawULong () const;
-
-// Return the raw unsigned long long without any casting or conversion
-unsigned long long
-RawULongLong () const;
-
unsigned char
UChar(unsigned char fail_value = 0) const;
@@ -299,9 +290,6 @@ public:
long double
LongDouble(long double fail_value = 0.0) const;
-uint64_t
-GetRawBits64 (uint64_t fail_value) const;
-
Error
SetValueFromCString (const char *s, lldb::Encoding encoding, size_t
byte_size);
Modified: lldb/trunk/include/lldb/Symbol/Type.h
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/include/lldb/Symbol/Type.h?rev=266422&r1=266421&r2=266422&view=diff
==
--- lldb/trunk/include/lldb/Symbol/Type.h (original)
+++ lldb/trunk/include/lldb/Symbol/Type.h Fri Apr 15 04:55:52 2016
@@ -958,13 +958,13 @@ public:
uint64_t
GetValueAsUnsigned () const
{
-return *m_value.getRawData();
+return m_value.getZExtValue();
}
int64_t
GetValueAsSigned () const
{
-return (int64_t) *m_value.getRawData();
+return m_value.getSExtValue();
}
protected:
Modified: lldb/trunk/source/Core/Scalar.cpp
URL:
http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Core/Scalar.cpp?rev=266422&r1=266421&r2=266422&view=diff
==
--- lldb/trunk/source/Core/Scalar.cpp (original)
+++ lldb/trunk/source/Core/Scalar.cpp Fri Apr 15 04:55:52 2016
@@ -16,6 +16,8 @@
#include
// Other libraries and framework includes
+#include "llvm/ADT/SmallString.h"
+
// Project includes
#include "lldb/Interpreter/Args.h"
#include "lldb/Core/Error.h"
@@ -134,10 +136,10 @@ bool
Scalar::GetData (DataExtractor &data, size_t limit_byte_size) const
{
size_t byte_size = GetByteSize();
-static float f_val;
-static double d_val;
if (byte_size > 0)
{
+const uint8_t *bytes = reinterpret_cast(GetBytes());
+
if (limit_byte_size < byte_size)
{
if (endian::InlHostByteOrder() == eByteOrderLittle)
@@ -145,105 +147,19 @@ Scalar::GetData (DataExtractor &data, si
// On little endian systems if we want fewer bytes from the
// current type we just specify fewer bytes since the LSByte
// is first...
-switch(m_type)
-{
-case e_void:
-break;
-case e_sint:
-case e_uint:
-case e_slong:
-case e_ulong:
-case e_slonglong:
-case e_ulonglong:
-case e_sint128:
-case e_uint128:
-case e_sint256:
-case e_uint256:
-data.SetData((const uint8_t *)m_integer.getRawData(),
limit_byte_size, endian::InlHostByteOrder());
-return true;
-case e_float:
-f_val = m_float.convertToFloat();
-data.SetData((uint8_t *)&f_val, limit_byte_size,
endian::InlHostByteOrder());
-return true;
-case e_double:
-d_val = m_float.convertToDouble();
-
Re: [Lldb-commits] [PATCH] D19153: Work around a linux libc bug causing a crash in TaskPool
tberghammer accepted this revision. tberghammer added a comment. This revision is now accepted and ready to land. Looks good http://reviews.llvm.org/D19153 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] [lldb] r266423 - Work around a linux libc bug causing a crash in TaskPool
Author: labath Date: Fri Apr 15 05:49:07 2016 New Revision: 266423 URL: http://llvm.org/viewvc/llvm-project?rev=266423&view=rev Log: Work around a linux libc bug causing a crash in TaskPool Summary: Doing a pthread_detach while the thread is exiting can cause crashes or other mischief, so we make sure the thread stays around long enough. The performance impact of the added synchronization should be minimal, as the parent thread is already holding a mutex, so I am just making sure it holds it for a little while longer. It's possible the new thread will block on this mutex immediately after startup, but it should be unblocked really quickly and some blocking is unavoidable if we actually want to have this synchronization. Reviewers: tberghammer Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D19153 Modified: lldb/trunk/source/Utility/TaskPool.cpp Modified: lldb/trunk/source/Utility/TaskPool.cpp URL: http://llvm.org/viewvc/llvm-project/lldb/trunk/source/Utility/TaskPool.cpp?rev=266423&r1=266422&r2=266423&view=diff == --- lldb/trunk/source/Utility/TaskPool.cpp (original) +++ lldb/trunk/source/Utility/TaskPool.cpp Fri Apr 15 05:49:07 2016 @@ -61,8 +61,9 @@ TaskPoolImpl::AddTask(std::functionhttps://sourceware.org/bugzilla/show_bug.cgi?id=19951). std::thread (Worker, this).detach(); } } ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D19153: Work around a linux libc bug causing a crash in TaskPool
This revision was automatically updated to reflect the committed changes.
Closed by commit rL266423: Work around a linux libc bug causing a crash in
TaskPool (authored by labath).
Changed prior to commit:
http://reviews.llvm.org/D19153?vs=53865&id=53869#toc
Repository:
rL LLVM
http://reviews.llvm.org/D19153
Files:
lldb/trunk/source/Utility/TaskPool.cpp
Index: lldb/trunk/source/Utility/TaskPool.cpp
===
--- lldb/trunk/source/Utility/TaskPool.cpp
+++ lldb/trunk/source/Utility/TaskPool.cpp
@@ -61,8 +61,9 @@
if (m_thread_count < max_threads)
{
m_thread_count++;
-lock.unlock();
-
+// Note that this detach call needs to happen with the m_tasks_mutex
held. This prevents the thread
+// from exiting prematurely and triggering a linux libc bug
+// (https://sourceware.org/bugzilla/show_bug.cgi?id=19951).
std::thread (Worker, this).detach();
}
}
Index: lldb/trunk/source/Utility/TaskPool.cpp
===
--- lldb/trunk/source/Utility/TaskPool.cpp
+++ lldb/trunk/source/Utility/TaskPool.cpp
@@ -61,8 +61,9 @@
if (m_thread_count < max_threads)
{
m_thread_count++;
-lock.unlock();
-
+// Note that this detach call needs to happen with the m_tasks_mutex held. This prevents the thread
+// from exiting prematurely and triggering a linux libc bug
+// (https://sourceware.org/bugzilla/show_bug.cgi?id=19951).
std::thread (Worker, this).detach();
}
}
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D18848: Add PDBASTParser and parse type information from PDB
clayborg added a comment. Shouldn't the SymbolFilePDB be only enabled in windows since it is useless on any other system since you are using the Windows system DLL to parse the info? http://reviews.llvm.org/D18848 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D18848: Add PDBASTParser and parse type information from PDB
I wrote a library in llvm which is independent of the Windows system dll and is abstracted such that we can plug in a non Windows specific version of a pdb parser once we understand the format well enough. For now, if you're not on Windows this library will just return an error if you try to create one, which results in SymbolFilePDB returning 0 capabilities. In the future though, all we have to do is add a non Windows implementation of the parser in llvm and everything will just magically work on any platform. There's an active effort into understanding the format because clang needs to know how to generate pdb when cross compiling for Windows on linux, so there should be something concrete here in the future On Fri, Apr 15, 2016 at 10:33 AM Greg Clayton wrote: > clayborg added a comment. > > Shouldn't the SymbolFilePDB be only enabled in windows since it is useless > on any other system since you are using the Windows system DLL to parse the > info? > > > http://reviews.llvm.org/D18848 > > > > ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D18848: Add PDBASTParser and parse type information from PDB
zturner added a comment. I wrote a library in llvm which is independent of the Windows system dll and is abstracted such that we can plug in a non Windows specific version of a pdb parser once we understand the format well enough. For now, if you're not on Windows this library will just return an error if you try to create one, which results in SymbolFilePDB returning 0 capabilities. In the future though, all we have to do is add a non Windows implementation of the parser in llvm and everything will just magically work on any platform. There's an active effort into understanding the format because clang needs to know how to generate pdb when cross compiling for Windows on linux, so there should be something concrete here in the future http://reviews.llvm.org/D18848 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
[Lldb-commits] Buildbot numbers for the week of 4/03/2016 - 4/09/2016
Hello everyone, Below are some buildbot numbers for the last week of 4/03/2016 - 4/09/2016. Thanks Galina "Status change ratio" by active builder (percent of builds that changed the builder status from greed to red or from red to green): buildername| builds | changes | status change ratio ++-+- clang-ppc64le-linux-lnt| 72 | 40 |55.6 perf-x86_64-penryn-O3-polly| 52 | 27 |51.9 lldb-x86_64-darwin-13.4|102 | 30 |29.4 clang-x64-ninja-win7 |153 | 32 |20.9 clang-cmake-aarch64-full | 48 | 10 |20.8 clang-x86-win2008-selfhost |103 | 20 |19.4 clang-cmake-mips | 83 | 16 |19.3 clang-cmake-thumbv7-a15-full-sh| 21 | 4 |19.0 clang-cmake-armv7-a15-selfhost | 32 | 6 |18.8 clang-cmake-aarch64-quick |153 | 28 |18.3 clang-cmake-armv7-a15 |134 | 22 |16.4 clang-cmake-aarch64-42vma |139 | 22 |15.8 clang-ppc64be-linux-multistage |114 | 18 |15.8 clang-cmake-thumbv7-a15|149 | 22 |14.8 perf-x86_64-penryn-O3-polly-before-vectorizer | 14 | 2 |14.3 lldb-x86_64-ubuntu-14.04-cmake |249 | 34 |13.7 llvm-mips-linux| 59 | 8 |13.6 perf-x86_64-penryn-O3-polly-before-vectorizer-detect-only | 15 | 2 |13.3 lldb-windows7-android | 77 | 10 |13.0 clang-cmake-armv7-a15-full | 79 | 10 |12.7 llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast |308 | 39 |12.7 clang-ppc64le-linux|173 | 22 |12.7 clang-ppc64be-linux-lnt|208 | 26 |12.5 sanitizer-x86_64-linux | 97 | 12 |12.4 sanitizer-x86_64-linux-fast|157 | 17 |10.8 clang-cmake-mipsel | 19 | 2 |10.5 lldb-x86_64-ubuntu-14.04-android | 98 | 10 |10.2 clang-ppc64be-linux|258 | 26 |10.1 clang-x86_64-debian-fast |120 | 12 |10.0 llvm-clang-lld-x86_64-debian-fast |145 | 14 | 9.7 clang-cmake-armv7-a15-selfhost-neon| 23 | 2 | 8.7 clang-atom-d525-fedora-rel | 71 | 6 | 8.5 clang-s390x-linux |258 | 20 | 7.8 lldb-x86_64-ubuntu-14.04-buildserver |131 | 9 | 6.9 sanitizer-ppc64be-linux| 90 | 6 | 6.7 sanitizer-windows |332 | 22 | 6.6 sanitizer-ppc64le-linux| 46 | 3 | 6.5 lld-x86_64-darwin13|284 | 18 | 6.3 lldb-x86-windows-msvc2015 |163 | 10 | 6.1 sanitizer-x86_64-linux-bootstrap | 53 | 3 | 5.7 clang-bpf-build|286 | 16 | 5.6 clang-hexagon-elf |293 | 16 | 5.5 lld-x86_64-win7|321 | 17 | 5.3 lldb-amd64-ninja-netbsd7 |133 | 6 | 4.5 lld-x86_64-freebsd |181 | 8 | 4.4 llvm-hexagon-elf |244 | 10 | 4.1 perf-x86_64-penryn-O3 |
Re: [Lldb-commits] [PATCH] D18975: Fix unwind failures when PC points beyond the end of a function
uweigand added reviewers: clayborg, tberghammer.
uweigand updated this revision to Diff 53951.
uweigand added a comment.
Add fix for a related problem that still caused unwind failures on SystemZ.
The ResolveSymbolContextForAddress sometimes returns a "symbol" with empty
name. This turns out to be an ELF section symbol. Now, usually those get type
eSymbolTypeInvalid. However, there is code in ObjectFileELF::ParseSymbols
that tries to change the type of invalid symbols to eSymbolTypeCode or
eSymbolTypeData if the symbol lies within the code or data section.
Unfortunately, this check also hits the symbol for the code section
itself, which is then marked as eSymbolTypeCode. While the size of
the section symbol is 0 according to the ELF file, LLDB considers
this size invalid and attempts to figure out the "correct" size.
Depending on how this goes, we may end up with a symbol that overlays
part of the code section, even outside areas covered by real function
symbols.
Therefore, if we call ResolveSymbolContextForAddress with PC pointing
beyond the end of a function, we may get this bogus section symbol.
This again means InitializeNonZerothFrame thinks we have a valid PC,
but then we don't find any unwind info for it.
The fix for this problem seems to me to simply always leave ELF section
symbols as type eSymbolTypeInvalid.
http://reviews.llvm.org/D18975
Files:
source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
source/Plugins/Process/Utility/RegisterContextLLDB.cpp
Index: source/Plugins/Process/Utility/RegisterContextLLDB.cpp
===
--- source/Plugins/Process/Utility/RegisterContextLLDB.cpp
+++ source/Plugins/Process/Utility/RegisterContextLLDB.cpp
@@ -470,11 +470,13 @@
return;
}
-bool resolve_tail_call_address = true; // m_current_pc can be one past the
address range of the function...
- // This will handle the case where
the saved pc does not point to
- // a function/symbol because it is
beyond the bounds of the correct
- // function and there's no symbol
there. ResolveSymbolContextForAddress
- // will fail to find a symbol, back
up the pc by 1 and re-search.
+bool resolve_tail_call_address = false; // m_current_pc can be one past
the address range of the function...
+// If the saved pc does not point
to a function/symbol because it is
+// beyond the bounds of the
correct function and there's no symbol there,
+// we do *not* want
ResolveSymbolContextForAddress to back up the pc by 1,
+// because then we might not find
the correct unwind information later.
+// Instead, let
ResolveSymbolContextForAddress fail, and handle the case
+// via
decr_pc_and_recompute_addr_range below.
const uint32_t resolve_scope = eSymbolContextFunction |
eSymbolContextSymbol;
uint32_t resolved_scope = pc_module_sp->ResolveSymbolContextForAddress
(m_current_pc,
resolve_scope,
Index: source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
===
--- source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
+++ source/Plugins/ObjectFile/ELF/ObjectFileELF.cpp
@@ -2148,7 +2148,7 @@
}
}
-if (symbol_type == eSymbolTypeInvalid)
+if (symbol_type == eSymbolTypeInvalid && symbol.getType() !=
STT_SECTION)
{
if (symbol_section_sp)
{
Index: source/Plugins/Process/Utility/RegisterContextLLDB.cpp
===
--- source/Plugins/Process/Utility/RegisterContextLLDB.cpp
+++ source/Plugins/Process/Utility/RegisterContextLLDB.cpp
@@ -470,11 +470,13 @@
return;
}
-bool resolve_tail_call_address = true; // m_current_pc can be one past the address range of the function...
- // This will handle the case where the saved pc does not point to
- // a function/symbol because it is beyond the bounds of the correct
- // function and there's no symbol there. ResolveSymbolContextForAddress
- // will fail to find a symbol, back up the pc by 1 and re-search.
+bool resolve_tail_call_address = false; // m_current_pc can be one past the address range of the function...
+// If the saved pc does not point to a function/symbol because it is
+
Re: [Lldb-commits] [PATCH] D18975: Fix unwind failures when PC points beyond the end of a function
clayborg accepted this revision. clayborg added a comment. This revision is now accepted and ready to land. I am OK with this, but Jason Molenda needs to be OK as well. Seems like we should have a function on the right object that would return the PC that we should use when looking up symbols for a given stack frame so we don't mess this up at any point. http://reviews.llvm.org/D18975 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D19067: Make sure to use lib instead of lib64 for LLDB_LIB_DIR
fjricci added a comment.
So I looked at `finishSwigPythonLLDB.py`, and it does look like that's where
the bug is. This script sets the end of the symlink path with:
strSrc = os.path.join("lib", "liblldb" + strLibFileExtn)
Note here that "lib" is hardcoded, and doesn't use the `LLVM_LIBDIR_SUFFIX`,
which is why the symlink is broken. The only way I can think of to communicate
this suffix from cmake into python would be by having cmake set an environment
variable (presumably with the same name). Does this seem reasonable, or do you
think there's a better solution?
The solution from `finish-swig-Python-LLDB.sh` would also probably work
(enforcing that liblldb.so and python2.7/site-packages/lldb be in the same
directory). That solution actually would be more consistent with the way the
unit test suite works anyway. It does seem less flexible though.
http://reviews.llvm.org/D19067
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D19067: Make sure to use lib instead of lib64 for LLDB_LIB_DIR
Don't use an environment variable, add a command line flag to the script
instead
On Fri, Apr 15, 2016 at 3:27 PM Francis Ricci wrote:
> fjricci added a comment.
>
> So I looked at `finishSwigPythonLLDB.py`, and it does look like that's
> where the bug is. This script sets the end of the symlink path with:
>
> strSrc = os.path.join("lib", "liblldb" + strLibFileExtn)
>
> Note here that "lib" is hardcoded, and doesn't use the
> `LLVM_LIBDIR_SUFFIX`, which is why the symlink is broken. The only way I
> can think of to communicate this suffix from cmake into python would be by
> having cmake set an environment variable (presumably with the same name).
> Does this seem reasonable, or do you think there's a better solution?
>
> The solution from `finish-swig-Python-LLDB.sh` would also probably work
> (enforcing that liblldb.so and python2.7/site-packages/lldb be in the same
> directory). That solution actually would be more consistent with the way
> the unit test suite works anyway. It does seem less flexible though.
>
>
> http://reviews.llvm.org/D19067
>
>
>
>
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
Re: [Lldb-commits] [PATCH] D19067: Make sure to use lib instead of lib64 for LLDB_LIB_DIR
zturner added a subscriber: zturner. zturner added a comment. Don't use an environment variable, add a command line flag to the script instead http://reviews.llvm.org/D19067 ___ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
