Reapply "lldb: Cache string hash during ConstString pool queries/insertions"

Reverted due to an internally discovered lld crash due to the underlying
StringMap changes, which turned out to be an exi

Reapply "lldb: Cache string hash during ConstString pool queries/insertions"

Reverted due to an internally discovered lld crash due to the underlying
StringMap changes, which turned out to be an existing lld bug that got
tickled by the StringMap changes. That's addressed in
dee8786f70a3d62b639113343fa36ef55bdbad63 so let's have another go with
this change.

Original commit message:
lldb was rehashing the string 3 times (once to determine which StringMap
to use, once to query the StringMap, once to insert) on insertion (twice
on successful lookup).

This patch allows the lldb to benefit from hash improvements in LLVM
(from djbHash to xxh3).

Though further changes would be needed to cache this value to disk - we
shouldn't rely on the StringMap::hash remaining the same in the
future/this value should not be serialized to disk. If we want cache
this value StringMap should take a hashing template parameter to allow
for a fixed hash to be requested.

This reverts commit 5bc1adff69315dcef670e9fcbe04067b5d5963fb.
Effectively reapplying the original 2e197602305be18b963928e6ae024a004a95af6d.

show more ...

Revert "lldb: Cache string hash during ConstString pool queries/insertions"

Underlying StringMap API for providing a hash has caused some problems
(observed a crash in lld) - so reverting this until

Revert "lldb: Cache string hash during ConstString pool queries/insertions"

Underlying StringMap API for providing a hash has caused some problems
(observed a crash in lld) - so reverting this until I can figure out/fix
what's going on there.

This reverts commit 52ba075571958e2fec8d871ddfa1ef56486b86d3.
This reverts commit 2e197602305be18b963928e6ae024a004a95af6d.

show more ...

lldb: Cache string hash during ConstString pool queries/insertions

lldb was rehashing the string 3 times (once to determine which StringMap
to use, once to query the StringMap, once to insert) on in

lldb: Cache string hash during ConstString pool queries/insertions

lldb was rehashing the string 3 times (once to determine which StringMap
to use, once to query the StringMap, once to insert) on insertion (twice
on successful lookup).

This patch allows the lldb to benefit from hash improvements in LLVM
(from djbHash to xxh3).

Though further changes would be needed to cache this value to disk - we
shouldn't rely on the StringMap::hash remaining the same in the
future/this value should not be serialized to disk. If we want cache
this value StringMap should take a hashing template parameter to allow
for a fixed hash to be requested.

show more ...

[lldb][NFCI] ConstString methods should take StringRefs by value

StringRef was made to be passed by value efficiently.

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

[lldb] Remove LLDB reproducers

This patch removes the remaining reproducer code. The SBReproducer class
remains for ABI stability but is just an empty shell. This completes the
removal process outli

[lldb] Remove LLDB reproducers

This patch removes the remaining reproducer code. The SBReproducer class
remains for ABI stability but is just an empty shell. This completes the
removal process outlined on the mailing list [1].

[1] https://lists.llvm.org/pipermail/lldb-dev/2021-September/017045.html

show more ...

[lldb] Remove ConstString::StaticMemorySize

Remove ConstString::StaticMemorySize as it is unused and superseded by
GetMemoryStats. It is referenced in a bunch of doc comments but I don't
really unde

[lldb] Remove ConstString::StaticMemorySize

Remove ConstString::StaticMemorySize as it is unused and superseded by
GetMemoryStats. It is referenced in a bunch of doc comments but I don't
really understand why. My best guess it that the comments were
copy-pasted from ConstString::MemorySize() even though it didn't make
sense there either. The implementation of StaticMemorySize was being
called on the MemoryPool, not on the ConstString itself.

Differential revision: https://reviews.llvm.org/D118091

show more ...

[lldb] Add ConstString memory usage statistics

Add statistics about the memory usage of the string pool. I'm
particularly interested in the memory used by the allocator, i.e. the
number of bytes act

[lldb] Add ConstString memory usage statistics

Add statistics about the memory usage of the string pool. I'm
particularly interested in the memory used by the allocator, i.e. the
number of bytes actually used by the allocator it self as well as the
number of bytes allocated through the allocator.

Differential revision: https://reviews.llvm.org/D117914

show more ...

[lldb] Rename StringRef _lower() method calls to _insensitive()

[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++ equivale

[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

show more ...

[lldb] Pass ConstString by value (again) (NFC)

This reverts "Eliminate unneeded value parameters in Utility" for
ConstString. As Pavel pointed out on the mailing list, the class *is*
trivially copya

[lldb] Pass ConstString by value (again) (NFC)

This reverts "Eliminate unneeded value parameters in Utility" for
ConstString. As Pavel pointed out on the mailing list, the class *is*
trivially copyable.

show more ...

[lldb] Eliminate unneeded value parameters in Utility (NFC)

Eliminates value parameter for types that are not trivially copyable.

[lldb/Utility] Add YAML traits for ConstString and FileSpec.

Add YAML traits for the ConstString and FileSpec classes so they can be
serialized as part of ProcessInfo. The latter needs to be seriali

[lldb/Utility] Add YAML traits for ConstString and FileSpec.

Add YAML traits for the ConstString and FileSpec classes so they can be
serialized as part of ProcessInfo. The latter needs to be serializable
for the reproducers.

Differential revision: https://reviews.llvm.org/D76002

show more ...

[lldb][NFC] Remove several inefficient ConstString -> const char * -> StringRef conversions

StringRef will call strlen on the C string which is inefficient (as ConstString already
knows the string l

[lldb][NFC] Remove several inefficient ConstString -> const char * -> StringRef conversions

StringRef will call strlen on the C string which is inefficient (as ConstString already
knows the string lenght and so does StringRef). This patch replaces all those calls
with GetStringRef() which doesn't recompute the length.

show more ...

Reland "[lldb] Increase the rate at which ConstString's memory allocator scales the memory chunks it allocates""

The parent revision is now passing the sanitizer bots and landed as 46e5603c8a08de6c5

Reland "[lldb] Increase the rate at which ConstString's memory allocator scales the memory chunks it allocates""

The parent revision is now passing the sanitizer bots and landed as 46e5603c8a08de6c5983ed7eb4f12828bbfcbd78,
so this can now actually land.

show more ...

Revert "[lldb] Increase the rate at which ConstString's memory allocator scales the memory chunks it allocates"

This reverts commit 500c324fa13eec2b171f4ea4dbed2ac1251f5aae because its parent commit

Revert "[lldb] Increase the rate at which ConstString's memory allocator scales the memory chunks it allocates"

This reverts commit 500c324fa13eec2b171f4ea4dbed2ac1251f5aae because its parent commit
b848b510a8d52dbf50ee53a9a1ce844abb60d9bd is failing on the sanitizer bots.

show more ...

[lldb] Increase the rate at which ConstString's memory allocator scales the memory chunks it allocates

Summary:
We currently do far more malloc calls than necessary in the ConstString BumpPtrAllocat

[lldb] Increase the rate at which ConstString's memory allocator scales the memory chunks it allocates

Summary:
We currently do far more malloc calls than necessary in the ConstString BumpPtrAllocator. This is due to the 256 BumpPtrAllocators
our ConstString implementation uses internally which end up all just receiving a small share of the total allocated memory
and therefore keep allocating memory in small chunks for far too long. This patch fixes this by increasing the rate at which we increase the
memory chunk size so that our collection of BumpPtrAllocators behaves in total similar to a single BumpPtrAllocator.

Reviewers: llunak

Reviewed By: llunak

Subscribers: abidh, JDevlieghere, lldb-commits

Tags: #lldb

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

show more ...

[lldb][NFC] Fix all formatting errors in .cpp file headers

Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp ----------------------------------------

[lldb][NFC] Fix all formatting errors in .cpp file headers

Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp -------------------------------------------------===//
```
However in LLDB most of our source files have arbitrary changes to this format and
these changes are spreading through LLDB as folks usually just use the existing
source files as templates for their new files (most notably the unnecessary
editor language indicator `-*- C++ -*-` is spreading and in every review
someone is pointing out that this is wrong, resulting in people pointing out that this
is done in the same way in other files).

This patch removes most of these inconsistencies including the editor language indicators,
all the different missing/additional '-' characters, files that center the file name, missing
trailing `===//` (mostly caused by clang-format breaking the line).

Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere

Reviewed By: JDevlieghere

Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits

Tags: #lldb

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

show more ...

[lldb][NFC] Remove unused includes in Utility's source files

Revert "make ConstString allocate memory in non-tiny chunks"

As discussed in https://reviews.llvm.org/D68549, the actual issue
here seems to be that the BumpPtrAllocator is growing far too slow
beca

Revert "make ConstString allocate memory in non-tiny chunks"

As discussed in https://reviews.llvm.org/D68549, the actual issue
here seems to be that the BumpPtrAllocator is growing far too slow
because of the 256 different StringPools used as the backend for ConstString.
At the same time the original patch made ConstString allocate memory in
256MiB slabs for the same reason, meaning that the RSS usage of LLDB increased
by a few hundred MiB for all users without bringing any noticeable speedup
for most of them.

llvm-svn: 375062

show more ...

make ConstString allocate memory in non-tiny chunks

BumpPtrAllocator allocates in 4KiB chunks, which with any larger
project is going to result in a large number of allocations.
Increasing allocatio

make ConstString allocate memory in non-tiny chunks

BumpPtrAllocator allocates in 4KiB chunks, which with any larger
project is going to result in a large number of allocations.
Increasing allocation size this way can save 10%-20% of symbol
load time for a huge C++ project with correctly built debuginfo.

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

llvm-svn: 374583

show more ...

Remove unused function 'SetMangledCounterparts' (NFC)

This function is not referenced.

llvm-svn: 367975

Prevent unnecessary conversion from StringRef to C-string [NFC]

There is an alternative method to GetConstCStringWithLength that
takes a StringRef. GetConstCStringWithLength also calls this
method i

Prevent unnecessary conversion from StringRef to C-string [NFC]

There is an alternative method to GetConstCStringWithLength that
takes a StringRef. GetConstCStringWithLength also calls this
method in the end, so directly calling the StringRef saves
us from a unnecessary conversion to a C-string.

llvm-svn: 358357

show more ...

[NFC] Remove ASCII lines from comments

A lot of comments in LLDB are surrounded by an ASCII line to delimit the
begging and end of the comment.

Its use is not really consistent across the code base

[NFC] Remove ASCII lines from comments

A lot of comments in LLDB are surrounded by an ASCII line to delimit the
begging and end of the comment.

Its use is not really consistent across the code base, sometimes the
lines are longer, sometimes they are shorter and sometimes they are
omitted. Furthermore, it looks kind of weird with the 80 column limit,
where the comment actually extends past the line, but not by much.
Furthermore, when /// is used for Doxygen comments, it looks
particularly odd. And when // is used, it incorrectly gives the
impression that it's actually a Doxygen comment.

I assume these lines were added to improve distinguishing between
comments and code. However, given that todays editors and IDEs do a
great job at highlighting comments, I think it's worth to drop this for
the sake of consistency. The alternative is fixing all the
inconsistencies, which would create a lot more churn.

Differential revision: https://reviews.llvm.org/D60508

llvm-svn: 358135

show more ...

Pass ConstString by value (NFC)

My apologies for the large patch. With the exception of ConstString.h
itself it was entirely produced by sed.

ConstString has exactly one const char * data member, s

Pass ConstString by value (NFC)

My apologies for the large patch. With the exception of ConstString.h
itself it was entirely produced by sed.

ConstString has exactly one const char * data member, so passing a
ConstString by reference is not any more efficient than copying it by
value. In both cases a single pointer is passed. But passing it by
value makes it harder to accidentally return the address of a local
object.

(This fixes rdar://problem/48640859 for the Apple folks)

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

llvm-svn: 355553

show more ...

Fix strlen() of unbound array undefined behavior

LLDB testsuite fails when built by GCC8 on:
LLDB :: SymbolFile/DWARF/find-basic-namespace.cpp

This is because this code in LLDB codebase has undef

Fix strlen() of unbound array undefined behavior

LLDB testsuite fails when built by GCC8 on:
LLDB :: SymbolFile/DWARF/find-basic-namespace.cpp

This is because this code in LLDB codebase has undefined behavior:

#include <algorithm>
#include <string.h>
// lldb/source/Plugins/ObjectFile/Mach-O/ObjectFileMachO.cpp:1731
static struct section_64 {
char sectname[16];
char segname[16];
} sect64 = { {'_','_','a','p','p','l','e','_','n','a','m','e','s','p','a','c'}, "__DWARF" };
int main() {
return std::min<size_t>(strlen(sect64.sectname), sizeof(sect64.sectname));
}

It has been discussed as a (false) bugreport to GCC:
wrong-code: LLDB testcase fails: SymbolFile/DWARF/find-basic-namespace.cpp
https://bugzilla.redhat.com/show_bug.cgi?id=1672436

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

llvm-svn: 353280

show more ...