summaryrefslogtreecommitdiffstats
path: root/lldb/source/Core/FormatClasses.cpp
diff options
context:
space:
mode:
authorEnrico Granata <granata.enrico@gmail.com>2011-09-06 19:20:51 +0000
committerEnrico Granata <granata.enrico@gmail.com>2011-09-06 19:20:51 +0000
commit9128ee2f7accbb6225858416c8a956e6102b86b8 (patch)
treed2765b8f8ac9f66fe4232e016913c0313436b1ea /lldb/source/Core/FormatClasses.cpp
parentf2641e1bc11b28db5722f7f6adec2ac416dd0f6c (diff)
downloadbcm5719-llvm-9128ee2f7accbb6225858416c8a956e6102b86b8.tar.gz
bcm5719-llvm-9128ee2f7accbb6225858416c8a956e6102b86b8.zip
Redesign of the interaction between Python and frozen objects:
- introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored in frozen objects ; now such reads transparently move from host to target as required - as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also removed code that enabled to recognize an expression result VO as such - introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO representing a T* or T[], and doing dereferences transparently in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData - as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it en lieu of doing the raw read itself - introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers, this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory) in public layer this returns an SBData, just like GetPointeeData() - introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values - added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing Solved a bug where global pointers to global variables were not dereferenced correctly for display New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128 Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file addresses that generate file address children UNLESS we have a live process) Updated help text for summary-string Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers Edited the syntax and help for some commands to have proper argument types llvm-svn: 139160
Diffstat (limited to 'lldb/source/Core/FormatClasses.cpp')
-rw-r--r--lldb/source/Core/FormatClasses.cpp80
1 files changed, 2 insertions, 78 deletions
diff --git a/lldb/source/Core/FormatClasses.cpp b/lldb/source/Core/FormatClasses.cpp
index a23225d3825..ee689307ac1 100644
--- a/lldb/source/Core/FormatClasses.cpp
+++ b/lldb/source/Core/FormatClasses.cpp
@@ -41,30 +41,6 @@ ValueFormat::ValueFormat (lldb::Format f,
{
}
-std::string
-ValueFormat::FormatObject(lldb::ValueObjectSP object)
-{
- if (!object.get())
- return "NULL";
-
- StreamString sstr;
-
- if (ClangASTType::DumpTypeValue (object->GetClangAST(), // The clang AST
- object->GetClangType(), // The clang type to display
- &sstr,
- m_format, // Format to display this type with
- object->GetDataExtractor(), // Data to extract from
- 0, // Byte offset into "data"
- object->GetByteSize(), // Byte size of item in "data"
- object->GetBitfieldBitSize(), // Bitfield bit size
- object->GetBitfieldBitOffset())) // Bitfield bit offset
- return (sstr.GetString());
- else
- {
- return ("unsufficient data for value");
- }
-}
-
SummaryFormat::SummaryFormat(bool casc,
bool skipptr,
bool skipref,
@@ -186,29 +162,8 @@ ScriptSummaryFormat::ScriptSummaryFormat(bool casc,
std::string
ScriptSummaryFormat::FormatObject(lldb::ValueObjectSP object)
{
- lldb::ValueObjectSP target_object;
- if (object->GetIsExpressionResult() &&
- ClangASTContext::IsPointerType(object->GetClangType()) &&
- object->GetValue().GetValueType() == Value::eValueTypeHostAddress)
- {
- // when using the expression parser, an additional layer of "frozen data"
- // can be created, which is basically a byte-exact copy of the data returned
- // by the expression, but in host memory. because Python code might need to read
- // into the object memory in non-obvious ways, we need to hand it the target version
- // of the expression output
- lldb::addr_t tgt_address = object->GetValueAsUnsigned(LLDB_INVALID_ADDRESS);
- target_object = ValueObjectConstResult::Create (object->GetExecutionContextScope(),
- object->GetClangAST(),
- object->GetClangType(),
- object->GetName(),
- tgt_address,
- eAddressTypeLoad,
- object->GetUpdatePoint().GetProcessSP()->GetAddressByteSize());
- }
- else
- target_object = object;
return std::string(ScriptInterpreterPython::CallPythonScriptFunction(m_function_name.c_str(),
- target_object).c_str());
+ object).c_str());
}
std::string
@@ -282,25 +237,6 @@ SyntheticScriptProvider::FrontEnd::FrontEnd(std::string pclass,
return;
}
- if (be->GetIsExpressionResult() &&
- ClangASTContext::IsPointerType(be->GetClangType()) &&
- be->GetValue().GetValueType() == Value::eValueTypeHostAddress)
- {
- // when using the expression parser, an additional layer of "frozen data"
- // can be created, which is basically a byte-exact copy of the data returned
- // by the expression, but in host memory. because Python code might need to read
- // into the object memory in non-obvious ways, we need to hand it the target version
- // of the expression output
- lldb::addr_t tgt_address = be->GetValueAsUnsigned(LLDB_INVALID_ADDRESS);
- m_backend = ValueObjectConstResult::Create (be->GetExecutionContextScope(),
- be->GetClangAST(),
- be->GetClangType(),
- be->GetName(),
- tgt_address,
- eAddressTypeLoad,
- be->GetUpdatePoint().GetProcessSP()->GetAddressByteSize());
- }
-
m_interpreter = m_backend->GetUpdatePoint().GetTargetSP()->GetDebugger().GetCommandInterpreter().GetScriptInterpreter();
if (m_interpreter == NULL)
@@ -315,19 +251,7 @@ SyntheticScriptProvider::FrontEnd::GetChildAtIndex (uint32_t idx, bool can_creat
if (m_wrapper == NULL || m_interpreter == NULL)
return lldb::ValueObjectSP();
- PyObject* py_return = (PyObject*)m_interpreter->GetChildAtIndex(m_wrapper, idx);
- if (py_return == NULL || py_return == Py_None)
- {
- Py_XDECREF(py_return);
- return lldb::ValueObjectSP();
- }
-
- lldb::SBValue *sb_ptr = m_interpreter->CastPyObjectToSBValue(py_return);
-
- if (py_return == NULL || sb_ptr == NULL)
- return lldb::ValueObjectSP();
-
- return sb_ptr->m_opaque_sp;
+ return m_interpreter->GetChildAtIndex(m_wrapper, idx);
}
std::string
OpenPOWER on IntegriCloud