Summary:
std::queue is just a fancy wrapper around another container, so all we
need to do is to delegate to the it.
Reviewers: jingham, EricWF
Subscribers: srhines, mgorny, lldb-commits, eugene
Differential Revision: https://reviews.llvm.org/D35666
llvm-svn: 317099
Summary:
This adds a data formatter for the implementation of forward_list in
libc++. I've refactored the existing std::list data formatter a bit to
enable more sharing of code (mainly the loop detection stuff).
Reviewers: jingham, EricWF
Subscribers: srhines, eugene, lldb-commits
Differential Revision: https://reviews.llvm.org/D35556
llvm-svn: 316992
Summary: It is simply unused, and the header for it is private, so there should be no external dependencies.
Reviewers: #lldb, zturner
Reviewed By: zturner
Subscribers: zturner, tberghammer, jingham, lldb-commits
Differential Revision: https://reviews.llvm.org/D32503
Patch by Scott Smith <scott.smith@purestorage.com>.
llvm-svn: 301903
Summary:
The iteration list through the available data formatters was undefined,
which meant that the vector<bool> formatter kicked in only in cases
where it happened to be queried before the general vector formatter. To
fix this, I merge the two data formatter entries into one, and select
which implementation to use in the factory function.
Reviewers: jasonmolenda, tberghammer, EricWF
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D31880
llvm-svn: 300047
Current implementation of CPlusPlusLanguage::MethodName::Parse() doesn't
get anywhere close to covering full extent of possible function declarations.
It causes incorrect behavior in avoid-stepping and sometimes messes
printing of thread backtrace.
This change implements more methodical parsing logic based on clang
lexer and simple recursive parser.
Examples:
void std::vector<Class, std::allocator<Class>>::_M_emplace_back_aux<Class const&>(Class const&)
void (*&std::_Any_data::_M_access<void (*)()>())()
Previous version of this change (D31451) was rolled back due to an issue
with Objective-C selectors being incorrectly recognized as a C++ identifier.
Differential Revision: https://reviews.llvm.org/D31451
llvm-svn: 299721
This caused a failure in the test case:
functionalities/breakpoint/objc/TestObjCBreakpoints.py
When we are parsing up names we stick interesting parts of the names
in various buckets, one of which is the ObjC selector bucket. The new
C++ name parser must be interfering with this process somehow.
<rdar://problem/31439305>
llvm-svn: 299489
Current implementation of CPlusPlusLanguage::MethodName::Parse() doesn't
get anywhere close to covering full extent of possible function declarations.
It causes incorrect behavior in avoid-stepping and sometimes messes
printing of thread backtrace.
This change implements more methodical parsing logic based on clang
lexer and simple recursive parser.
Examples:
void std::vector<Class, std::allocator<Class>>::_M_emplace_back_aux<Class const&>(Class const&)
void (*&std::_Any_data::_M_access<void (*)()>())()
Differential Revision: https://reviews.llvm.org/D31451
llvm-svn: 299374
All references to Host and Core have been removed, so this
class can now safely be lowered into Utility.
Differential Revision: https://reviews.llvm.org/D30559
llvm-svn: 296909
match but the 'is_regex' argument was not passed as true. Not sure
this is causing a bug, but noticed it while working on another bug.
These formatters gained a regex in r274489 for NDK but didn't pick
up the is_regex flag at the time.
<rdar://problem/30646077>
llvm-svn: 296243
Summary:
The std::call_once implementation in libstdc++ has problems on few systems: NetBSD, OpenBSD and Linux PPC. LLVM ships with a homegrown implementation llvm::call_once to help on these platforms.
This change is required in the NetBSD LLDB port. std::call_once with libstdc++ results with crashing the debugger.
Sponsored by <The NetBSD Foundation>
Reviewers: labath, joerg, emaste, mehdi_amini, clayborg
Reviewed By: labath, clayborg
Subscribers: #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D29288
llvm-svn: 294202
This moves the following classes from Core -> Utility.
ConstString
Error
RegularExpression
Stream
StreamString
The goal here is to get lldbUtility into a state where it has
no dependendencies except on itself and LLVM, so it can be the
starting point at which to start untangling LLDB's dependencies.
These are all low level and very widely used classes, and
previously lldbUtility had dependencies up to lldbCore in order
to use these classes. So moving then down to lldbUtility makes
sense from both the short term and long term perspective in
solving this problem.
Differential Revision: https://reviews.llvm.org/D29427
llvm-svn: 293941
This is a redux of [Ewan's patch](https://reviews.llvm.org/D17957) , refactored
to properly substitute primitive types using a hook in the itanium demangler,
and updated after the previous patch went stale
The new `SubsPrimitiveParmItanium` function takes a symbol name and replacement
primitive type parameter as before but parses it using the FastDemangler, which
has been modified to be able to notify clients of parse events (primitive types
at this point).
Additionally, we now use a `set` of `ConstStrings` instead of a `vector` so
that we don't try and resolve the same invalid candidate multiple times.
Differential Revision: https://reviews.llvm.org/D27223
Subscribers: lldb-commits
llvm-svn: 290117
Implement the C++ type lookup support in terms of this general scavenger
The idea is that we may want other languages to do debug info based search (exclusively, or as an add-on to runtime/module based searching) and it makes sense to avoid duplicating this functionality
llvm-svn: 285727
This updates getters and setters to use StringRef instead of
const char *. I tested the build on Linux, Windows, and OSX
and saw no build or test failures. I cannot test any BSD
or Android variants, however I expect the required changes
to be minimal or non-existant.
llvm-svn: 282079
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:
Firstly, merging this particular commit into a downstream fork may be a huge
effort. Alternatively, it may be worth merging all changes up to this commit,
performing the same reformatting operation locally, and then discarding the
merge for this particular commit. The commands used to accomplish this
reformatting were as follows (with current working directory as the root of
the repository):
find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} +
find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ;
The version of clang-format used was 3.9.0, and autopep8 was 1.2.4.
Secondly, “blame” style tools will generally point to this commit instead of
a meaningful prior commit. There are alternatives available that will attempt
to look through this change and find the appropriate prior commit. YMMV.
llvm-svn: 280751
Summary:
CPlusPlusLanguage::MethodName was not correctly parsing templated functions whose demangled name
included the return type -- the space before the function name was included in the "context" and
the context itself was not terminated correctly due to a misuse of the substr function (second
argument is length, not the end position). Fix that and add a regression test.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D23608
llvm-svn: 279038
The libc++ shipped with the android NDK is shipped using a different
internal namespace then the upstream libc++ (__ndk1 vs. __1) to avoid
an ODR violation between the platform and the user application. This
change fixes our pretty printers to be able to work with the types
from the android NDK libc++.
Differential revision: http://reviews.llvm.org/D21680
llvm-svn: 274489
Also added a data formatter that presents them as structs if you use frame
variable to look at their contents. Now the blocks testcase works.
<rdar://problem/15984431>
llvm-svn: 268307
(lldb) b ~Foo
(lldb) b Foo::~Foo
(lldb) b Bar::Foo::~Foo
Improved out C++ breakpoint locations tests as well to cover this issue.
<rdar://problem/25577252>
llvm-svn: 266139
On libc++ std::atomic is a fairly simple data type (layout wise, at least), wrapping actual contents in a member variable named "__a_"
All the formatters are doing is "peel away" this intermediate layer and exposing user data as direct children or values of the std::atomic root variable
Fixes rdar://24329405
llvm-svn: 260752
Summary:
This change is relevant for inferiors compiled with GCC. GCC does not
emit complete debug info for std::basic_string<...>, and consequently, Clang
(the LLDB compiler) does not generate correct mangled names for certain
functions.
This change removes the hard-coded alternate names in
ItaniumABILanguageRuntime.cpp.
Before the hard-coded names were put in ItaniumABILanguageRuntime.cpp, one could
not evaluate std::string methods (ex. std::string::length). After putting in
the hard-coded names, one could evaluate them. However, it did not still
enable one to call methods on, say for example, std::vector<string>.
This change makes that possible.
There is some amount of incompleteness in this change. Consider the
following example:
std::string hello("hello"), world("world");
std::map<std::string, std::string> m;
m[hello] = world;
One can still not evaluate the expression "m[hello]" in LLDB. Will
address this issue in another pass.
Reviewers: jingham, vharron, evgeny777, spyffe, dawn
Subscribers: clayborg, dawn, lldb-commits
Differential Revision: http://reviews.llvm.org/D12809
llvm-svn: 257113
* Remove an unneccessary re-computaion on arch spec from the ELF file
* Use a local cache to optimize name based section lookups in symtab
parsing
* Optimize C++ method basename validation with replacing a regex with
hand written code
These modifications reduce the time required to parse the symtab from
large applications by ~25% (tested with LLDB as inferior)
Differential revision: http://reviews.llvm.org/D14088
llvm-svn: 251402
The Language plugin is menat to answer language-specific questions that are not bound to the existence of a process. Those are still the domain of the LanguageRuntime plugin
The Language plugin will, instead, answer questions such as providing language-specific data formatters or expression evaluation
At the moment, the interface is hollowed out, and empty do-nothing plugins have been setup for ObjC, C++ and ObjC++
llvm-svn: 246212
