caio/clang-p2996
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Fix a problem where if a uint64_t value is placed into a python dictionary and sent up to LLDB and converted to StructuredData, it would not be able to parse the full 64 bit value. A number like 0xf000000000000000L could be placed into a dictionary, and sent to LLDB and it would end up being 0xffffffffffffffff since it would overflow a int64_t. We leave the old code there, but if it overflows, we treat the number like a uint64_t and get it to decode correctly. Added a gtest to cover this so we don't regress. I verified the gtest failed prior to the fix, and it succeeds after it.

Browse Source 
<rdar://problem/27409265>

llvm-svn: 278304
This commit is contained in:
Greg Clayton
2016-08-10 23:25:57 +00:00
parent 357f1be2ca
commit 008ec44644
2 changed files with 36 additions and 1 deletions
Download Patch File Download Diff File Expand all files Collapse all files

13
lldb/source/Plugins/ScriptInterpreter/Python/PythonDataObjects.cpp
View File

@@ -624,7 +624,18 @@ PythonInteger::GetInteger() const
{
assert(PyLong_Check(m_py_obj) && "PythonInteger::GetInteger has a PyObject that isn't a PyLong");
return PyLong_AsLongLong(m_py_obj);
int overflow = 0;
int64_t result = PyLong_AsLongLongAndOverflow(m_py_obj, &overflow);
if (overflow != 0)
{
// We got an integer that overflows, like 18446744072853913392L
// we can't use PyLong_AsLongLong() as it will return
// 0xffffffffffffffff. If we use the unsigned long long
// it will work as expected.
const uint64_t uval = PyLong_AsUnsignedLongLong(m_py_obj);
result = *((int64_t *)&uval);
}
return result;
}
return UINT64_MAX;
}