This cleanup patch unifies all methods called GetByteSize() in the
ValueObject hierarchy to return an optional, like the methods in
CompilerType do. This means fewer magic 0 values, which could fix bugs
down the road in languages where types can have a size of zero, such
as Swift and C (but not C++).
Differential Revision: https://reviews.llvm.org/D84285
This re-lands the patch with bogus :m_byte_size(0) initalizations removed.
Summary:
This commit is somewhat NFC-ish today as the environment of triples
is not considered when comparing s if one of them is
not set (I plan to change that).
We have made simulator triples unambiguous these days, but the
simulator platforms still advertise triples without the
environment. This wasn't an issue when the sims ran only on
a very different architecure than the real device, but this
has changed with Apple Silicon.
This patch simplifies the way GetSupportedArchitectureAtIndex
is implemented for the sim platforms and adds the environment.
It also trivially adds support for Apple Silicon to those
platforms.
Reviewers: aprantl
Subscribers: lldb-commits
Summary: This way we can get rid of this 1024 char buffer workaround.
Reviewers: #lldb, labath
Reviewed By: labath
Subscribers: JDevlieghere
Differential Revision: https://reviews.llvm.org/D84528
Summary:
This effectively reverts r188124, which added code to handle
(DW_AT_)declarations of structures with some kinds of children as
definitions. The commit message claims this is a workaround for some
kind of debug info produced by gcc. However, it does not go into
specifics, so it's hard to reproduce or verify that this is indeed still a
problem.
Having this code is definitely a problem though, because it mistakenly
declares incomplete dwarf declarations to be complete. Both clang (with
-flimit-debug-info) and gcc (by default) generate DW_AT_declarations of
structs with children. This happens when full debug info for a class is
not emitted in a given compile unit (e.g. because of vtable homing), but
the class has inline methods which are used in the given compile unit.
In that case, the compilers emit a DW_AT_declaration of a class, but
add a DW_TAG_subprogram child to it to describe the inlined instance of
the method.
Even though the class tag has some children, it definitely does not
contain enough information to construct a full class definition (most
notably, it lacks any members). Keeping the class as incomplete allows
us to search for a real definition in other modules, helping the
-flimit-debug-info flow. And in case the definition is not found we can
display a error message saying that, instead of just showing an empty
struct.
Reviewers: clayborg, aprantl, JDevlieghere, shafik
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D83302
The function didn't combine a large entry which overlapped several other
entries, if those other entries were not overlapping among each other.
E.g., (0,20),(5,6),(10,11) produced (0,20),(10,11)
Now it just produced (0,20).
This cleanup patch unifies all methods called GetByteSize() in the
ValueObject hierarchy to return an optional, like the methods in
CompilerType do. This means fewer magic 0 values, which could fix bugs
down the road in languages where types can have a size of zero, such
as Swift and C (but not C++).
Differential Revision: https://reviews.llvm.org/D84285
If a module has debug info, the size of debug symbol will be displayed after the Symbols Loaded Message for each module in the VScode modules view.{F12335461}
Reviewed By: wallace, clayborg
Differential Revision: https://reviews.llvm.org/D83731
Summary: If a module has debug info, the size of debug symbol will be displayed after the Symbols Loaded Message for each module in the VScode modules view.{F12335461}
Reviewers: wallace, clayborg
Reviewed By: wallace, clayborg
Subscribers: cfe-commits, aprantl, lldb-commits
Tags: #lldb, #clang
Differential Revision: https://reviews.llvm.org/D83731
Once we start the definition of an ObjCInterfaceDecl we won't attempt to ImportDeclContext
later on. Unlike RecordDecl case which uses DefinitionCompleter to force completeDefinition
we don't seem to have a similar mechanism for ObjCInterfaceDecl.
This fix was needed due to a bug we see in LLDB expression parsing where an initial expression
cause an ObjCInterfaceDecl to be defined and subsequent expressions during import do not call
ImportDeclContext and we can end up in a situation where ivars are imported out of order and not all ivars are imported.
Differential Revision: https://reviews.llvm.org/D83972
When a process is notified that modules got loaded, currently only
existing language runtimes are given a chance to deal with that. This
means that if the runtime for a given language wasn't needed before it
won't be informed of the module chance.
This is wrong because the module change might be what triggers the need
for a certain runtime. Instead, we should give the language runtime for
every supported language a chance to deal with the modified modules.
Differential revision: https://reviews.llvm.org/D84475
This patch basically moves the disambiguation code from a place where
it was complicated to implement straight to where the load command is
parsed, which has the neat side affect of actually supporting all call
sites!
rdar://problem/66011909
Differential Revision: https://reviews.llvm.org/D84480
Summary:
The resolver addresses stored in the dyld trie are relative to the base
of the __TEXT segment. This is usually 0 in a dylib, so this was never
noticed, but it is not 0 for most dylibs integrated in the shared cache.
As we started using the shared cache images recently as symbol source,
this causes LLDB to fail to resolve symbols which go through a runtime
resolver.
Reviewers: jasonmolenda, jingham
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D84083
Rather than handling zlib handling manually, use find_package from CMake
to find zlib properly. Use this to normalize the LLVM_ENABLE_ZLIB,
HAVE_ZLIB, HAVE_ZLIB_H. Furthermore, require zlib if LLVM_ENABLE_ZLIB is
set to YES, which requires the distributor to explicitly select whether
zlib is enabled or not. This simplifies the CMake handling and usage in
the rest of the tooling.
This is a reland of abb0075 with all followup changes and fixes that
should address issues that were reported in PR44780.
Differential Revision: https://reviews.llvm.org/D79219
Rather than handling zlib handling manually, use find_package from CMake
to find zlib properly. Use this to normalize the LLVM_ENABLE_ZLIB,
HAVE_ZLIB, HAVE_ZLIB_H. Furthermore, require zlib if LLVM_ENABLE_ZLIB is
set to YES, which requires the distributor to explicitly select whether
zlib is enabled or not. This simplifies the CMake handling and usage in
the rest of the tooling.
This is a reland of abb0075 with all followup changes and fixes that
should address issues that were reported in PR44780.
Differential Revision: https://reviews.llvm.org/D79219
ConstString is essentially trivially copyable yet it has a user defined
copy constructor that copies its one member pointer. Remove it so it
qualifies as trivial in the eyes of the compiler.
This also fixes two unused variable warnings now that the compiler knows
that the constructor has no side-effects.
Differential revision: https://reviews.llvm.org/D84440
Summary:
The `string_escape` encoding used here was removed in Python 3 which makes the
test crash during tearDown:
```
File "lldb/third_party/Python/module/unittest2/unittest2/case.py", line 386, in run
self.tearDown()
File "lldb/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py", line 124, in tearDown
self._pump_queues.verify_queues_empty()
File "lldb/packages/Python/lldbsuite/test/tools/lldb-server/socket_packet_pump.py", line 55, in verify_queues_empty
_dump_queue(self.packet_queue())
File "lldb/packages/Python/lldbsuite/test/tools/lldb-server/socket_packet_pump.py", line 28, in _dump_queue
print(codecs.encode(the_queue.get(True), "string_escape"))
LookupError: unknown encoding: string_escape
```
Just replace it with `repr` which should work in both Python versions.
Reviewers: labath, JDevlieghere
Reviewed By: labath, JDevlieghere
Subscribers: JDevlieghere
Differential Revision: https://reviews.llvm.org/D84017
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
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
This reverts "Eliminate unneeded value parameters in Utility" for
ConstString. As Pavel pointed out on the mailing list, the class *is*
trivially copyable.
Summary:
Frame recognizers are stored alongside a flag that indicates whether they were
deleted by the user. If the flag is set, they are supposed to be ignored by the
rest of the frame recognizer code. 'frame recognizer delete' is supposed to set
that flag. 'frame recognizer clear' however actually deletes all frame
recognizers (so, it doesn't set the flag but directly deletes them from the
list).
The current implementation of this concept is pretty broken. `frame recognizer
delete` sets the flag, but it somehow thinks that the recognizer id is an index
in the recognizer list. That's not true as it's actually just a member of each
recognizer entry. So it actually just sets the `deleted` flag for a random other
recognizer. The tests for the recognizer still pass as `frame recognizer list`
is also broken and just completely ignored the `deleted` flag and lists all
recognizers. Also `frame recognizer delete` just ignores if it can't actually
delete a recognizer if the id is invalid.
I think we can simplify this whole thing by just actually deleting recognizers
instead of making sure all code is actually respecting the `deleted` flag. I
assume the intention of this was to make sure that all recognizers are getting
unique ids over the course of an LLDB session, but as `clear` is actually
deleting them and we keep recycling ids, that didn't really work to begin with.
This patch deletes the `deleted` flag and just actually deletes the stored
recognizer. Also adds the missing error message in case it find a recognizer
with a given id.
Reviewers: mib
Reviewed By: mib
Subscribers: abidh, JDevlieghere
Differential Revision: https://reviews.llvm.org/D84404
This patch refactors `emitDebugInfo()` to make the length field be
inferred from its content. Besides, the `Visitor` class is removed in
this patch. The original `Visitor` class helps us determine an
appropriate length and emit the .debug_info section. These two
processes can be merged into one process. Besides, the length field
should be inferred when it's missing rather than when it's zero.
Reviewed By: jhenderson, labath
Differential Revision: https://reviews.llvm.org/D84008
The patch was reverted 27d52cd86a2c because of failures in
TestWeakSymbols.py. These have now been addressed in D83552.
The original commit message was:
This function was documented to overwrite entries with D76111, which was
adding a couple of similar functions. However, this function (unlike the
functions added in that patch) was/is not actually overwriting variables
-- any pre-existing variables would get ignored.
This behavior does not seem to be intentional. In fact, before the refactor in
D41359, this function could introduce duplicate entries, which could
have very surprising effects both inside lldb and on other applications
(some applications would take the first value, some the second one; in
lldb, attempting to unset a variable could make the second variable
become active, etc.).
Overwriting seems to be the most reasonable behavior here, so change the
code to match documentation.
Differential Revision: https://reviews.llvm.org/D83306
This patch fixes a test failure in TestHistoryRecall caused by the move
of the `history` subcommand to the `session` command.
This change was introduced by commit 85fbb08fa2ac5195dc7a2f13eea7de1471da2a21.
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This patch moves the `history` subcommand from the `command` to `session`
command. I think it makes more sense to have it there because as the `command`
usage suggests, it should be used to manage custom LLDB commands.
However, `history` is essentially tied to a debugging session and holds
all the commands (not specifically custom ones).
This also makes it more discoverable by adding an alias for it (mimicking
the shell builtin).
Differential Revision: https://reviews.llvm.org/D84307
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
as it breaks bots with due to m_valid being an unused class member
except in assert builds.
This reverts commit 074b121642b286afb16adeebda5ec8236f7b8ea9.
This reapplies commit d4020ef7c474, reverted in ac0edc55887b because it
broke build of LLDB. This commit contains appropriate changes for LLDB.
The original commit message is below.
Documentation on CreateProcessW states that maximal size of command line
is 32767 characters including ternimation null character. In the
function llvm::sys::commandLineFitsWithinSystemLimits this limit was set
to 32768. As a result if command line was exactly 32768 characters long,
a response file was not created and CreateProcessW was called with
too long command line.
Differential Revision: https://reviews.llvm.org/D83772
add_compile_options is more sensitive to its location in the file than add_definitions--it only takes effect for sources that are added after it. This updated patch ensures that the add_compile_options is done before adding any source files that depend on it.
Using add_definitions caused the flag to be passed to rc.exe on Windows and thus broke Windows builds.
LLVM_TARGET_ARCH is not exported by LLVM so we can't use it from
standalone builds. Default to the architecture in LLVM_HOST_TRIPLE when
no LLDB_DEFAULT_TEST_ARCH was specified.
After lots of follow-up fixes, there are still problems, such as
-Wno-suggest-override getting passed to the Windows Resource Compiler
because it was added with add_definitions in the CMake file.
Rather than piling on another fix, let's revert so this can be re-landed
when there's a proper fix.
This reverts commit 21c0b4c1e8d6a171899b31d072a47dac27258fc5.
This reverts commit 81d68ad27b29b1e6bc93807c6e42b14e9a77eade.
This reverts commit a361aa5249856e333a373df90947dabf34cd6aab.
This reverts commit fa42b7cf2949802ff0b8a63a2e111a2a68711067.
This reverts commit 955f87f947fda3072a69b0b00ca83c1f6a0566f6.
This reverts commit 8b16e45f66e24e4c10e2cea1b70d2b85a7ce64d5.
This reverts commit 308a127a38d1111f3940420b98ff45fc1c17715f.
This reverts commit 274b6b0c7a8b584662595762eaeff57d61c6807f.
This reverts commit 1c7037a2a5576d0bb083db10ad947a8308e61f65.
- Remove the spurious argument to `CommandObjectScript`.
- Use make_shared instead of bare `new`.
- Move code duplication behind a macro.
Differential revision: https://reviews.llvm.org/D84336
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
