llvm-project/lldb/source/DataFormatters/DataVisualization.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

197 lines
6.6 KiB
C++
Raw Normal View History

//===-- DataVisualization.cpp ---------------------------------------------===//
//
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
//
//===----------------------------------------------------------------------===//
#include "lldb/DataFormatters/DataVisualization.h"
using namespace lldb;
using namespace lldb_private;
static FormatManager &GetFormatManager() {
static FormatManager g_format_manager;
return g_format_manager;
}
void DataVisualization::ForceUpdate() { GetFormatManager().Changed(); }
uint32_t DataVisualization::GetCurrentRevision() {
return GetFormatManager().GetCurrentRevision();
}
bool DataVisualization::ShouldPrintAsOneLiner(ValueObject &valobj) {
return GetFormatManager().ShouldPrintAsOneLiner(valobj);
}
lldb::TypeFormatImplSP
DataVisualization::GetFormat(ValueObject &valobj,
lldb::DynamicValueType use_dynamic) {
return GetFormatManager().GetFormat(valobj, use_dynamic);
}
lldb::TypeFormatImplSP
DataVisualization::GetFormatForType(lldb::TypeNameSpecifierImplSP type_sp) {
return GetFormatManager().GetFormatForType(type_sp);
}
lldb::TypeSummaryImplSP
DataVisualization::GetSummaryFormat(ValueObject &valobj,
lldb::DynamicValueType use_dynamic) {
return GetFormatManager().GetSummaryFormat(valobj, use_dynamic);
}
lldb::TypeSummaryImplSP
DataVisualization::GetSummaryForType(lldb::TypeNameSpecifierImplSP type_sp) {
return GetFormatManager().GetSummaryForType(type_sp);
}
lldb::SyntheticChildrenSP
DataVisualization::GetSyntheticChildren(ValueObject &valobj,
lldb::DynamicValueType use_dynamic) {
return GetFormatManager().GetSyntheticChildren(valobj, use_dynamic);
}
lldb::TypeFilterImplSP
DataVisualization::GetFilterForType(lldb::TypeNameSpecifierImplSP type_sp) {
return GetFormatManager().GetFilterForType(type_sp);
}
lldb::ScriptedSyntheticChildrenSP
DataVisualization::GetSyntheticForType(lldb::TypeNameSpecifierImplSP type_sp) {
return GetFormatManager().GetSyntheticForType(type_sp);
}
bool DataVisualization::AnyMatches(
ConstString type_name, TypeCategoryImpl::FormatCategoryItems items,
bool only_enabled, const char **matching_category,
TypeCategoryImpl::FormatCategoryItems *matching_type) {
return GetFormatManager().AnyMatches(type_name, items, only_enabled,
matching_category, matching_type);
}
bool DataVisualization::Categories::GetCategory(ConstString category,
lldb::TypeCategoryImplSP &entry,
bool allow_create) {
entry = GetFormatManager().GetCategory(category, allow_create);
return (entry.get() != nullptr);
}
bool DataVisualization::Categories::GetCategory(
lldb::LanguageType language, lldb::TypeCategoryImplSP &entry) {
if (LanguageCategory *lang_category =
GetFormatManager().GetCategoryForLanguage(language))
entry = lang_category->GetCategory();
return (entry.get() != nullptr);
}
void DataVisualization::Categories::Add(ConstString category) {
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
2011-09-07 03:20:51 +08:00
GetFormatManager().GetCategory(category);
}
bool DataVisualization::Categories::Delete(ConstString category) {
GetFormatManager().DisableCategory(category);
return GetFormatManager().DeleteCategory(category);
}
void DataVisualization::Categories::Clear() {
GetFormatManager().ClearCategories();
}
void DataVisualization::Categories::Clear(ConstString category) {
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
2011-09-07 03:20:51 +08:00
GetFormatManager().GetCategory(category)->Clear(
eFormatCategoryItemSummary | eFormatCategoryItemRegexSummary);
}
void DataVisualization::Categories::Enable(ConstString category,
TypeCategoryMap::Position pos) {
if (GetFormatManager().GetCategory(category)->IsEnabled())
GetFormatManager().DisableCategory(category);
2019-12-04 06:54:59 +08:00
GetFormatManager().EnableCategory(category, pos, {});
}
void DataVisualization::Categories::Enable(lldb::LanguageType lang_type) {
if (LanguageCategory *lang_category =
GetFormatManager().GetCategoryForLanguage(lang_type))
lang_category->Enable();
}
void DataVisualization::Categories::Disable(ConstString category) {
if (GetFormatManager().GetCategory(category)->IsEnabled())
GetFormatManager().DisableCategory(category);
}
void DataVisualization::Categories::Disable(lldb::LanguageType lang_type) {
if (LanguageCategory *lang_category =
GetFormatManager().GetCategoryForLanguage(lang_type))
lang_category->Disable();
}
void DataVisualization::Categories::Enable(
const lldb::TypeCategoryImplSP &category, TypeCategoryMap::Position pos) {
if (category.get()) {
if (category->IsEnabled())
GetFormatManager().DisableCategory(category);
GetFormatManager().EnableCategory(category, pos);
}
}
void DataVisualization::Categories::Disable(
const lldb::TypeCategoryImplSP &category) {
if (category.get() && category->IsEnabled())
GetFormatManager().DisableCategory(category);
}
void DataVisualization::Categories::EnableStar() {
GetFormatManager().EnableAllCategories();
}
void DataVisualization::Categories::DisableStar() {
GetFormatManager().DisableAllCategories();
}
void DataVisualization::Categories::ForEach(
TypeCategoryMap::ForEachCallback callback) {
GetFormatManager().ForEachCategory(callback);
}
uint32_t DataVisualization::Categories::GetCount() {
return GetFormatManager().GetCategoriesCount();
}
lldb::TypeCategoryImplSP
DataVisualization::Categories::GetCategoryAtIndex(size_t index) {
return GetFormatManager().GetCategoryAtIndex(index);
}
bool DataVisualization::NamedSummaryFormats::GetSummaryFormat(
ConstString type, lldb::TypeSummaryImplSP &entry) {
[lldb][NFC] Remove FormatMap Summary: FormattersContainer.h has two containers: FormatMap and FormattersContainer itself. FormatMap is essentially just a SetVector with a listener interface that is aspiring to be thread-safe as most of its functions lock its member mutex. FormattersContainer is for the most part just calling the matching functions of internal FormatMap instance and essentially acts as a wrapper class with some minor formatter search functionality on top. The only difference is that the FormattersContainer's public `Get` function is actually searching formatters in the list of formatters (and for example doing regex-matching) while FormatMap's `Get` function is just looking up a a format by the type matcher string. This patch deletes `FormatMap` by just renaming it to `FormattersContainer` and pulling in the two `Get` functions from the original `FormattersContainer` class. The only other user of `FormatMap` was the `NamedSummariesMap` in the `FormatManager` which I migrated by just making it also a `FormattersContainer` and replaced the only call to the `Get` function (which now has new semantics) with `GetExact` (which is FormattersContainer's function that has the semantics of FormatMap's `Get`). As `NamedSummariesMap` only stores non-regex-based formatters, both `Get` and `GetExact` would have worked, so this was mostly to clarify that this is supposed to be NFC. I also added the missing mutex lock in the `GetCount` function which was previously missing in the `FormatMap` implementation. Technically not "NFC" but I anyway had to change the function... Reviewers: labath, mib Reviewed By: labath Subscribers: abidh, JDevlieghere Differential Revision: https://reviews.llvm.org/D84296
2020-07-24 00:18:25 +08:00
return GetFormatManager().GetNamedSummaryContainer().GetExact(type, entry);
}
void DataVisualization::NamedSummaryFormats::Add(
ConstString type, const lldb::TypeSummaryImplSP &entry) {
Reland [lldb] Unify type name matching in FormattersContainer II This was originally reverted because the m_valid member in TypeMatcher was unused in builds with disabled asserts. Now the member is gone and the default constructor is deleted (thanks Eric for the idea!). Summary: FormattersContainer stores LLDB's formatters. It's implemented as a templated map-like data structures that supports any kind of value type and only allows ConstString and RegularExpression as the key types. The keys are used for matching type names (e.g., the ConstString key `std::vector` matches the type with the same name while RegularExpression keys match any type where the RegularExpression instance matches). The fact that a single FormattersContainer can only match either by string comparison or regex matching (depending on the KeyType) causes us to always have two FormatterContainer instances in all the formatting code. This also leads to us having every type name matching logic in LLDB twice. For example, TypeCategory has to implement every method twice (one string matching one, one regex matching one). This patch changes FormattersContainer to instead have a single `TypeMatcher` key that wraps the logic for string-based and regex-based type matching and is now the only possible KeyType for the FormattersContainer. This means that a single FormattersContainer can now match types with both regex and string comparison. To summarize the changes in this patch: * Remove all the `*_Impl` methods from `FormattersContainer` * Instead call the FormatMap functions from `FormattersContainer` with a `TypeMatcher` type that does the respective matching. * Replace `ConstString` with `TypeMatcher` in the few places that directly interact with `FormattersContainer`. I'm working on some follow up patches that I split up because they deserve their own review: * Unify FormatMap and FormattersContainer (they are nearly identical now). * Delete the duplicated half of all the type matching code that can now use one interface. * Propagate TypeMatcher through all the formatter code interfaces instead of always offering two functions for everything. There is one ugly design part that I couldn't get rid of yet and that is that we have to support getting back the string used to construct a `TypeMatcher` later on. The reason for this is that LLDB only supports referencing existing type matchers by just typing their respective input string again (without even supplying if it's a regex or not). Reviewers: davide, mib Reviewed By: mib Subscribers: mgorny, JDevlieghere Differential Revision: https://reviews.llvm.org/D84151
2020-07-22 00:44:16 +08:00
GetFormatManager().GetNamedSummaryContainer().Add(type, entry);
}
bool DataVisualization::NamedSummaryFormats::Delete(ConstString type) {
return GetFormatManager().GetNamedSummaryContainer().Delete(type);
}
void DataVisualization::NamedSummaryFormats::Clear() {
GetFormatManager().GetNamedSummaryContainer().Clear();
}
void DataVisualization::NamedSummaryFormats::ForEach(
Reland [lldb] Unify type name matching in FormattersContainer II This was originally reverted because the m_valid member in TypeMatcher was unused in builds with disabled asserts. Now the member is gone and the default constructor is deleted (thanks Eric for the idea!). Summary: FormattersContainer stores LLDB's formatters. It's implemented as a templated map-like data structures that supports any kind of value type and only allows ConstString and RegularExpression as the key types. The keys are used for matching type names (e.g., the ConstString key `std::vector` matches the type with the same name while RegularExpression keys match any type where the RegularExpression instance matches). The fact that a single FormattersContainer can only match either by string comparison or regex matching (depending on the KeyType) causes us to always have two FormatterContainer instances in all the formatting code. This also leads to us having every type name matching logic in LLDB twice. For example, TypeCategory has to implement every method twice (one string matching one, one regex matching one). This patch changes FormattersContainer to instead have a single `TypeMatcher` key that wraps the logic for string-based and regex-based type matching and is now the only possible KeyType for the FormattersContainer. This means that a single FormattersContainer can now match types with both regex and string comparison. To summarize the changes in this patch: * Remove all the `*_Impl` methods from `FormattersContainer` * Instead call the FormatMap functions from `FormattersContainer` with a `TypeMatcher` type that does the respective matching. * Replace `ConstString` with `TypeMatcher` in the few places that directly interact with `FormattersContainer`. I'm working on some follow up patches that I split up because they deserve their own review: * Unify FormatMap and FormattersContainer (they are nearly identical now). * Delete the duplicated half of all the type matching code that can now use one interface. * Propagate TypeMatcher through all the formatter code interfaces instead of always offering two functions for everything. There is one ugly design part that I couldn't get rid of yet and that is that we have to support getting back the string used to construct a `TypeMatcher` later on. The reason for this is that LLDB only supports referencing existing type matchers by just typing their respective input string again (without even supplying if it's a regex or not). Reviewers: davide, mib Reviewed By: mib Subscribers: mgorny, JDevlieghere Differential Revision: https://reviews.llvm.org/D84151
2020-07-22 00:44:16 +08:00
std::function<bool(const TypeMatcher &, const lldb::TypeSummaryImplSP &)>
callback) {
GetFormatManager().GetNamedSummaryContainer().ForEach(callback);
}
uint32_t DataVisualization::NamedSummaryFormats::GetCount() {
return GetFormatManager().GetNamedSummaryContainer().GetCount();
}