Commit Graph

440 Commits

Author SHA1 Message Date
Dave Lee 2f9fc576be [lldb] Add setting for max depth of value object printing (NFC)
This adds a setting (`target.max-children-depth`) that will provide a default value for the `--depth` flag used by `expression` and `frame variable`.

The new setting uses the same default that's currently fixed in source: `UINT32_MAX`.

This provides two purposes:

1. Allowing downstream forks to provide a customized default.
2. Allowing users to set their own default.

Following `target.max-children-count`, a warning is emitted when the max depth is reached. The warning lets users know which flags or settings they can customize. This warning is shown only when the limit is the default value.

rdar://87466495

Differential Revision: https://reviews.llvm.org/D123954
2022-05-03 10:39:42 -07:00
Jonas Devlieghere fc54427e76
[lldb] Refactor DataBuffer so we can map files as read-only
Currently, all data buffers are assumed to be writable. This is a
problem on macOS where it's not allowed to load unsigned binaries in
memory as writable. To be more precise, MAP_RESILIENT_CODESIGN and
MAP_RESILIENT_MEDIA need to be set for mapped (unsigned) binaries on our
platform.

Binaries are mapped through FileSystem::CreateDataBuffer which returns a
DataBufferLLVM. The latter is backed by a llvm::WritableMemoryBuffer
because every DataBuffer in LLDB is considered to be writable. In order
to use a read-only llvm::MemoryBuffer I had to split our abstraction
around it.

This patch distinguishes between a DataBuffer (read-only) and
WritableDataBuffer (read-write) and updates LLDB to use the appropriate
one.

rdar://74890607

Differential revision: https://reviews.llvm.org/D122856
2022-04-05 13:46:37 -07:00
Pavel Labath 13a3b0bb4b [lldb] Remove usages of case-insensitive c-string functions
They are not portable (which meant we had a hand-rolled implementation
for windows), and llvm::StringRef provides equivalent functionality.
2022-03-29 17:59:17 +02:00
Shafik Yaghmour 28c878aeb2 [LLDB] Applying clang-tidy modernize-use-default-member-init over LLDB
Applied modernize-use-default-member-init clang-tidy check over LLDB.
It appears in many files we had already switched to in class member init but
never updated the constructors to reflect that. This check is already present in
the lldb/.clang-tidy config.

Differential Revision: https://reviews.llvm.org/D121481
2022-03-14 13:32:03 -07:00
Pavel Labath c34698a811 [lldb] Rename Logging.h to LLDBLog.h and clean up includes
Most of our code was including Log.h even though that is not where the
"lldb" log channel is defined (Log.h defines the generic logging
infrastructure). This worked because Log.h included Logging.h, even
though it should.

After the recent refactor, it became impossible the two files include
each other in this direction (the opposite inclusion is needed), so this
patch removes the workaround that was put in place and cleans up all
files to include the right thing. It also renames the file to LLDBLog to
better reflect its purpose.
2022-02-03 14:47:01 +01:00
Pavel Labath a007a6d844 [lldb] Convert "LLDB" log channel to the new API 2022-02-02 14:13:08 +01:00
Benjamin Kramer f15014ff54 Revert "Rename llvm::array_lengthof into llvm::size to match std::size from C++17"
This reverts commit ef82063207.

- It conflicts with the existing llvm::size in STLExtras, which will now
  never be called.
- Calling it without llvm:: breaks C++17 compat
2022-01-26 16:55:53 +01:00
serge-sans-paille ef82063207 Rename llvm::array_lengthof into llvm::size to match std::size from C++17
As a conquence move llvm::array_lengthof from STLExtras.h to
STLForwardCompat.h (which is included by STLExtras.h so no build
breakage expected).
2022-01-26 16:17:45 +01:00
Pavel Labath 31c7165a2b [lldb] Remove summary for signed char *
It conflicts with the summary for BOOL * (aka signed char *). This
partially reverts D112709.
2022-01-06 19:52:24 +01:00
Pavel Labath 35870c4422 [lldb] Summary provider for char flexible array members
Add a summary provider which can print char[] members at the ends of
structs.

Differential Revision: https://reviews.llvm.org/D113174
2021-12-20 12:30:34 +01:00
Pavel Labath 11dc235c7d [lldb] Fix matchers for char array formatters
They were being applied too narrowly (they didn't cover signed char *,
for instance), and too broadly (they covered SomeTemplate<char[6]>) at
the same time.

Differential Revision: https://reviews.llvm.org/D112709
2021-12-17 10:06:38 +01:00
Jason Molenda 223e8ca026 Set a default number of address bits on Darwin arm64 systems
With arm64e ARMv8.3 pointer authentication, lldb needs to know how
many bits are used for addressing and how many are used for pointer
auth signing.  This should be determined dynamically from the inferior
system / corefile, but there are some workflows where it still isn't
recorded and we fall back on a default value that is correct on some
Darwin environments.

This patch also explicitly sets the vendor of mach-o binaries to
Apple, so we select an Apple ABI instead of a random other ABI.

It adds a function pointer formatter for systems where pointer
authentication is in use, and we can strip the ptrauth bits off
of the function pointer address and get a different value that
points to an actual symbol.

Differential Revision: https://reviews.llvm.org/D115431
rdar://84644661
2021-12-09 22:53:01 -08:00
Pavel Labath 4c56f734b3 [lldb] (Partially) enable formatting of utf strings before the program is started
The StringPrinter class was using a Process instance to read memory.
This automatically prevented it from working before starting the
program.

This patch changes the class to use the Target object for reading
memory, as targets are always available. This required moving
ReadStringFromMemory from Process to Target.

This is sufficient to make frame/target variable work, but further
changes are necessary for the expression evaluator. Preliminary analysis
indicates the failures are due to the expression result ValueObjects
failing to provide an address, presumably because we're operating on
file addresses before starting. I haven't looked into what would it take
to make that work.

Differential Revision: https://reviews.llvm.org/D113098
2021-11-18 14:45:17 +01:00
Med Ismail Bennani 42e4959253 [lldb/Formatters] Remove space from vector type string summaries (NFCI)
This patch changes the string summaries for vector types by removing the
space between the type and the bracket, conforming to 277623f4d5.

This should also fix TestCompactVectors failure.

Differential Revision: https://reviews.llvm.org/D112340

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2021-10-22 21:18:54 +02:00
David Blaikie aee4925507 Recommit: Compress formatting of array type names (int [4] -> int[4])
Based on post-commit review discussion on
2bd8493847 with Richard Smith.

Other uses of forcing HasEmptyPlaceHolder to false seem OK to me -
they're all around pointer/reference types where the pointer/reference
token will appear at the rightmost side of the left side of the type
name, so they make nested types (eg: the "int" in "int *") behave as
though there is a non-empty placeholder (because the "*" is essentially
the placeholder as far as the "int" is concerned).

This was originally committed in 277623f4d5

Reverted in f9ad1d1c77 due to breakages
outside of clang - lldb seems to have some strange/strong dependence on
"char [N]" versus "char[N]" when printing strings (not due to that name
appearing in DWARF, but probably due to using clang to stringify type
names) that'll need to be addressed, plus a few other odds and ends in
other subprojects (clang-tools-extra, compiler-rt, etc).
2021-10-21 11:34:43 -07:00
Pavel Labath 8093c2ea57 [lldb] Make char[N] formatters respect the end of the array (PR44649)
I believe this is a more natural behavior, and it also matches what gdb
does.

Differential Revision: https://reviews.llvm.org/D111399
2021-10-11 12:47:11 +02:00
Jan Kratochvil 14f443030c [nfc] [lldb] Prevent needless copies of DataExtractor
lldb_private::DataExtractor contains DataBufferSP m_data_sp which is
relatively expensive to copy (due to multi-threading locking).

llvm::DataExtractor does not have this problem as it uses StringRef
instead.

The copy constructor is explicit as otherwise it is easy to make
unintended modification of a local copy instead of a caller's instance
(D107470 but that is llvm::DataExtractor).

Reviewed By: clayborg

Differential Revision: https://reviews.llvm.org/D107485
2021-08-04 20:35:53 +02:00
Jonas Devlieghere fd2433e139 [lldb] Replace default bodies of special member functions with = default;
Replace default bodies of special member functions with = default;

$ run-clang-tidy.py -header-filter='lldb' -checks='-*,modernize-use-equals-default' -fix ,

https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-equals-default.html

Differential revision: https://reviews.llvm.org/D104041
2021-07-02 11:31:16 -07:00
Jonas Devlieghere 9494c510af [lldb] Use C++11 default member initializers
This converts a default constructor's member initializers into C++11
default member initializers. This patch was automatically generated with
clang-tidy and the modernize-use-default-member-init check.

$ run-clang-tidy.py -header-filter='lldb' -checks='-*,modernize-use-default-member-init' -fix

This is a mass-refactoring patch and this commit will be added to
.git-blame-ignore-revs.

Differential revision: https://reviews.llvm.org/D103483
2021-06-09 09:43:13 -07:00
Raphael Isemann 76e47d4887 [lldb][NFC] Use C++ versions of the deprecated C standard library headers
The C headers are deprecated so as requested in D102845, this is replacing them
all with their (not deprecated) C++ equivalent.

Reviewed By: shafik

Differential Revision: https://reviews.llvm.org/D103084
2021-05-26 12:46:12 +02:00
Raphael Isemann 03310c1e95 [lldb][NFC] Give CompilerType's IsArrayType/IsVectorType/IsBlockPointerType out-parameters default values
We already do this for most functions that have out-parameters, so let's do
the same here and avoid all the `nullptr, nullptr, nullptr` in every call.
2021-02-23 11:15:31 +01:00
Raphael Isemann d77e3c6aec [lldb][NFC] Don't inherit from UserID in ValueObject
ValueObject inherits from UserID which is just a bad idea:

* The inheritance gives ValueObject some member functions that are at best
  misleading (such as `Clear()` which doesn't clear any value beside `id`).

* It allows passing ValueObject to the overloaded operators for UserID (such as
  `==` or `<<` which won't actually compare or print anything in the ValueObject).

* It exposes the `SetID` and `Clear` which both allow users to change the
  internal id value.

Similar to D91699 which did the same for Process

Reviewed By: #lldb, JDevlieghere

Differential Revision: https://reviews.llvm.org/D97205
2021-02-23 10:15:42 +01:00
Adrian Prantl 057efa9916 Make the error condition in Value::ValueType explicit (NFC)
The comment for ValueType claims that all values <1 are errors, but
not all switch statements take this into account. This patch
introduces an explicit Error case and deletes all default: cases, so
we get warned about incomplete switch coverage.

https://reviews.llvm.org/D96537
2021-02-12 16:12:31 -08:00
Raphael Isemann 839e845277 [lldb] Remove assumption from Clang-based data formatters that their types are in the scratch AST
Several data formatters assume their types are in the Target's scratch AST and
build new types from that scratch AST instance. However, types from different
ASTs shouldn't be mixed, so this (unchecked) assumption may lead to problems if
we ever have more than one scratch AST or someone somehow invokes data
formatters on a type that are not in the scratch AST.

Instead we can use in all the formatters just the TypeSystem of the type we're
formatting. That's much simpler and avoids all the headache of finding the right
TypeSystem that matches the one of the formatted type.

Right now LLDB only has one scratch TypeSystemClang instance and we format only
types that are in the scratch AST, so this doesn't change anything in the
current way LLDB works. The intention here is to allow follow up refactorings
that introduce multiple scratch ASTs with the same Target.

Differential Revision: https://reviews.llvm.org/D92757
2020-12-10 17:35:03 +01:00
Jonas Devlieghere 406ad18748 [lldb/DataFormatters] Display null C++ pointers as nullptr
Display null pointer as `nullptr`, `nil` and `NULL` for C++,
Objective-C/Objective-C++ and C respectively. The original motivation
for this patch was to display a null std::string pointer as nullptr
instead of "", but the fix seemed generic enough to be done for all
summary providers.

Differential revision: https://reviews.llvm.org/D77153
2020-11-12 15:24:06 -08:00
Raphael Isemann 77ae06b8c6 [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-23 18:34:59 +02:00
Raphael Isemann 4d489e9f91 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-23 18:17:42 +02:00
Eric Christopher 3a75466f41 Temporarily Revert "Reland [lldb] Unify type name matching in FormattersContainer"
as it breaks bots with due to m_valid being an unused class member
except in assert builds.

This reverts commit 074b121642.
2020-07-23 00:47:05 -07:00
Adrian Prantl 02f5837363 Thread ExecutionContextScope through GetByteSize where possible (NFC-ish)
This patch has no effect for C and C++. In more dynamic languages,
such as Objective-C and Swift GetByteSize() needs to call into the
language runtime, so it's important to pass one in where possible. My
primary motivation for this is some work I'm doing on the Swift
branch, however, it looks like we are also seeing warnings in
Objective-C that this may resolve.  Everything in the SymbolFile
hierarchy still passes in nullptrs, because we don't have an execution
context in SymbolFile, since SymbolFile transcends processes.

Differential Revision: https://reviews.llvm.org/D84267
2020-07-22 08:56:29 -07:00
Raphael Isemann 074b121642 Reland [lldb] Unify type name matching in FormattersContainer
This was originally reverted because the Linux bots were red after this landed,
but it seems that was actually caused by a different commit. I double checked
that this works on Linux, so let's reland this on Linux.

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 09:32:28 +02:00
Raphael Isemann e031eda08d Revert "[lldb] Unify type name matching in FormattersContainer"
This reverts commit 5b0de5756c.

Apparently that caused some test to get stuck on Linuxx. Reverting for now.
2020-07-21 19:03:33 +02:00
Raphael Isemann 5b0de5756c [lldb] Unify type name matching in FormattersContainer
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-21 18:44:50 +02:00
Raphael Isemann 5c15426d7c [lldb] Remove FormattersContainer's name member
Summary:

FormattersContainer currently has an unused `m_name` member. Usually LLDB allows
giving objects names, but for the FormattersContainer it seems excessive. There
are only 4 FormattersContainer variables in LLDB and they are not usually passed
around, so one can always just go up a few frames when debugging to find out
which FormattersContainer you're dealing with.

Reviewers: mib, davide

Reviewed By: mib

Subscribers: JDevlieghere

Differential Revision: https://reviews.llvm.org/D84154
2020-07-21 13:54:38 +02:00
Jonas Devlieghere 58e34ede5b [lldb] Small improvements in ValueObjectPrinter::PrintDecl (NFC)
Remove unused argument, simply code and reformat.
2020-06-12 21:05:05 -07:00
Vedant Kumar 4699a7e230 [lldb/StringPrinter] Support strings with invalid utf8 sub-sequences
Support printing strings which contain invalid utf8 sub-sequences, e.g.
strings like "hello world \xfe", instead of bailing out with "Summary
Unavailable".

I took the opportunity here to delete some hand-rolled utf8 -> utf32
conversion code and replace it with calls into llvm's Support library.

rdar://61554346
2020-06-03 12:24:23 -07:00
Vedant Kumar 7822b8a817 [lldb/StringPrinter] Convert DecodedCharBuffer to a class, NFC
The m_size and m_data members of DecodedCharBuffer are meant to be
private.
2020-06-03 12:24:23 -07:00
Vedant Kumar a37caebc2d [lldb/DataFormatters] Delete GetStringPrinterEscapingHelper
Summary:
Languages can have different ways of formatting special characters.
E.g. when debugging C++ code a string might look like "\b", but when
debugging Swift code the same string would look like "\u{8}".

To make this work, plugins override GetStringPrinterEscapingHelper.
However, because there's a large amount of subtly divergent work done in
each override, we end up with large amounts of duplicated code. And all
the memory smashers fixed in one copy of the logic (see D73860) don't
get fixed in the others.

IMO the GetStringPrinterEscapingHelper is overly general and hard to
use. I propose deleting it and replacing it with an EscapeStyle enum,
which can be set as needed by each plugin.

A fix for some swift-lldb memory smashers falls out fairly naturally
from this deletion (https://github.com/apple/llvm-project/pull/1046). As
the swift logic becomes really tiny, I propose moving it upstream as
part of this change. I've added unit tests to cover it.

rdar://61419673

Reviewers: JDevlieghere, davide

Subscribers: mgorny, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D77843
2020-05-04 14:06:55 -07:00
Pavel Labath 9cd9f3f1b8 [lldb] Fix gcc warnings in TypeCategory.cpp
The cleanup in 3e3701f8a0 left these variable unused.
2020-04-20 16:12:51 +02:00
Raphael Isemann 3e3701f8a0 [lldb][NFC] Remove FormatterChoiceCriterion
Summary:
The formatters code has a lot of 'reason' or 'why' values that we keep or-ing FormatterChoiceCriterion
enum values into. These values are only read by a single log statement and don't have any functional
purpose. It also seems the implementation is not finished (for example, display names and type
names don't have any dedicated enum values). Also everything is of course not tested or documented.

Let's just remove all of this.

Reviewers: labath, JDevlieghere, jingham, davide, vsk

Reviewed By: labath, vsk

Subscribers: JDevlieghere

Differential Revision: https://reviews.llvm.org/D77968
2020-04-15 09:47:15 +02:00
Raphael Isemann 6b6a779ca8 [lldb][NFC] Always update m_cache_{hits/misses} in FormatCache
Summary:
These two variables are only incremented under LLDB_CONFIGURATION_DEBUG but their
value is always logged when verbose lldb formatter logging is enabled, which causes that our
cache hit/miss log looks like this in non-Debug builds:

```
Cache hits: 0 - Cache Misses: 0
...
Cache hits: 0 - Cache Misses: 0
...
Cache hits: 0 - Cache Misses: 0
```

This just always increments those two counters independent of build mode.

Reviewers: JDevlieghere

Reviewed By: JDevlieghere

Differential Revision: https://reviews.llvm.org/D76687
2020-03-24 20:16:43 +01:00
shafik a567d6809e [DataFormatters] Add formatter for libc++ std::unique_ptr
This adds a formatter for libc++ std::unique_ptr.

I also refactored GetValueOfCompressedPair(...) out of LibCxxList.cpp since I need the same functionality and it made sense to share it.

Differential Revision: https://reviews.llvm.org/D76476
2020-03-23 11:48:20 -07:00
Raphael Isemann 7b2442584e Reland [lldb] Fix string summary of an empty NSPathStore2
(This is D68010 but I also set the new parameter in LibStdcpp.cpp to fix
the Debian tests).

Summary:
Printing a summary for an empty NSPathStore2 string currently prints random bytes behind the empty string pointer from memory (rdar://55575888).

It seems the reason for this is that the SourceSize parameter in the `ReadStringAndDumpToStreamOptions` - which is supposed to contain the string
length - actually uses the length 0 as a magic value for saying "read as much as possible from the buffer" which is clearly wrong for empty strings.

This patch adds another flag that indicates if we have know the string length or not and makes this behaviour dependent on that (which seemingly
was the original purpose of this magic value).

Reviewers: aprantl, JDevlieghere, shafik

Reviewed By: aprantl

Subscribers: christof, abidh, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D68010
2020-03-19 18:50:26 +01:00
Raphael Isemann 718d94187d Revert "[lldb] Fix string summary of an empty NSPathStore2"
This reverts commit 939ca455e7.

This failed on the debian bot for some reason:
  File "/home/worker/lldb-x86_64-debian/lldb-x86_64-debian/llvm-project/lldb/test/API/functionalities/data-formatter/data-formatter-stl/libstdcpp/string/TestDataFormatterStdString.py", line 67, in test_with_run_command
    "s summary wrong")
AssertionError: 'L"hello world! מזל טוב!\\0!\\0!!!!\\0\\0A\\0\\U0000fffd\\U0000fffd\\U0000fffd\\ [truncated]... != 'L"hello world! מזל טוב!"'
Diff is 2156 characters long. Set self.maxDiff to None to see it. : s summary wrong
2020-03-19 13:08:39 +01:00
Raphael Isemann 939ca455e7 [lldb] Fix string summary of an empty NSPathStore2
Summary:
Printing a summary for an empty NSPathStore2 string currently prints random bytes behind the empty string pointer from memory (rdar://55575888).

It seems the reason for this is that the SourceSize parameter in the `ReadStringAndDumpToStreamOptions` - which is supposed to contain the string
length - actually uses the length 0 as a magic value for saying "read as much as possible from the buffer" which is clearly wrong for empty strings.

This patch adds another flag that indicates if we have know the string length or not and makes this behaviour dependent on that (which seemingly
was the original purpose of this magic value).

Reviewers: aprantl, JDevlieghere, shafik

Reviewed By: aprantl

Subscribers: christof, abidh, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D68010
2020-03-19 12:20:35 +01:00
Raphael Isemann 785df61680 [lldb] Let TypeSystemClang::GetDisplayTypeName remove anonymous and inline namespaces.
Summary:
Currently when printing data types we include implicit scopes such as inline namespaces or anonymous namespaces.
This leads to command output like this (for `std::set<X>` with X being in an anonymous namespace):

```
(lldb) print my_set
(std::__1::set<(anonymous namespace)::X, std::__1::less<(anonymous namespace)::X>, std::__1::allocator<(anonymous namespace)::X> >) $0 = size=0 {}
```

This patch removes all the implicit scopes when printing type names in TypeSystemClang::GetDisplayTypeName
so that our output now looks like this:

```
(lldb) print my_set
(std::set<X, std::less<X>, std::allocator<X> >) $0 = size=0 {}
```

As previously GetDisplayTypeName and GetTypeName had the same output we actually often used the
two as if they are the same method (they were in fact using the same implementation), so this patch also
fixes the places where we actually want the display type name and not the actual type name.

Note that this doesn't touch the `GetTypeName` class that for example the data formatters use, so this patch
is only changes the way we display types to the user. The full type name can also still be found when passing
'-R' to see the raw output of a variable in case someone is somehow interested in that.

Partly fixes rdar://problem/59292534

Reviewers: shafik, jingham

Reviewed By: shafik

Subscribers: christof, JDevlieghere, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D74478
2020-02-19 10:30:11 +01:00
Vedant Kumar 7aabad1312 [lldb/StringPrinter] Avoid reading garbage in uninitialized strings
This patch fixes a few related out-of-bounds read bugs in the
string data formatters. These issues have to do with mishandling of un-
initialized strings. These manifest as ASan exceptions when debugging a
clang binary.

The first issue was that the std::string formatter treated strings in
"short mode" with length greater than the size of the inline buffer as
valid.

The second issue was that the StringPrinter facility did not check that
a full utf8 codepoint sequence can be read from the buffer (i.e. there
are some missing range checks). I took the opportunity here to delete
some untested code that was meant to deal with invalid input and replace
it with fail-on-invalid logic ([1][2][3]). This means we'll give up on
formatting an invalid string instead of guessing our way through it.

The third issue is that StringPrinter did not check that a utf8 sequence
could actually be fully read from the string payload. This one is especially
tricky as we may overflow the buffer pointer while reading the sequence.

I also noticed that the std::string formatter would spew the raw version of
the underlying ValueObject when garbage is detected. I've changed this to
just print "Summary Unavailable" instead, as we do elsewhere.

I've added regression tests for these issues to
test/functionalities/data-formatter/data-formatter-stl/libcxx/string.

[1]
http://lab.llvm.org:8080/coverage/coverage-reports/coverage/Users/buildslave/jenkins/workspace/coverage/llvm-project/lldb/source/DataFormatters/StringPrinter.cpp.html#L136
[2]
http://lab.llvm.org:8080/coverage/coverage-reports/coverage/Users/buildslave/jenkins/workspace/coverage/llvm-project/lldb/source/DataFormatters/StringPrinter.cpp.html#L163
[3]
http://lab.llvm.org:8080/coverage/coverage-reports/coverage/Users/buildslave/jenkins/workspace/coverage/llvm-project/lldb/source/DataFormatters/StringPrinter.cpp.html#L357

rdar://59080026

Differential Revision: https://reviews.llvm.org/D73860
2020-02-12 11:24:03 -08:00
Raphael Isemann 30ce956aec [lldb][NFC] Remove GetConstTypeName and GetConstQualifiedTypeName from CompilerType
Beside these two functions just being wrappers around GetTypeName they are also
just a leftover from migrating the CompilerType interface to ConstString.
2020-02-12 09:49:39 +01:00
Martin Storsjö 5bbaf54358 [LLDB] Fix compilation with GCC 5
Differential Revision: https://reviews.llvm.org/D74084
2020-02-06 10:16:32 +02:00
Vedant Kumar 63e6508221 [lldb/StringPrinter] Simplify StringPrinterBufferPointer, NFC
Remove its template arguments and delete its copy/assign methods.
2020-02-03 15:57:33 -08:00
Alex Langford 3014efe071 [lldb] Remove unused parameter from ValueObject::GetExpressionPath
I previously removed the code in ValueObject::GetExpressionPath that
took advantage of the parameter `qualify_cxx_base_classes`. As a result,
this is now unused and can be removed.
2020-02-03 10:50:38 -08:00