My openSUSE 15.2 has /usr/include/curses.h as a symlink to
/usr/include/ncurses/curses.h , but there's no such symlink
for panel.h . Prefer using /usr/include/ncurses for the includes
if they are found there by the CMake check.
Differential Revision: https://reviews.llvm.org/D85219
This patch is similar in spirit to https://reviews.llvm.org/D84480,
but does the maccatalyst/macosx disambiguation. I also took the
opportunity to factor out the gdb-remote packet log scanning used by
several testcases into lldbutil functions.
rdar://problem/66059257
Differential Revision: https://reviews.llvm.org/D84576
lldb-platform contains a very minimal support for the qfProcessInfo
packet, only allowing the simplest query to get most of the testsuite
running, and returning very little information about the matched
processes.
When lldb cannot find source file thus IDE renders a disassembly view, add syntax highlighting for constants, registers and final line comments for better debugging experience.
The original plain disassembly view looks like:
{F12401687}
An ideal view is like the screenshot attached.
{F12401515}
In this diff, the mimeType is a kind of media type for formatting the content in the response to a source request. Elements in the disassembly view, like constants, registers and final line comments are colored for highlighting.
A built-in support in the VSCode IDE for syntax highlighting will identify the which mimeType to apply and render the disassembly view as expected.
Reviewed By: wallace, clayborg
Differential Revision: https://reviews.llvm.org/D84555
This is a followup to 817b3a6fe3a4452eb61a2503c8beaa7267ca0351: in `builder_base` we should use abspath, not realpath, because the name is significant.
This is used by test cases that use `@skipIf(compiler="clang", compiler_version=['<', <version>])`
Upstream the code for dealing with TCC introduced in macOS Mojave. This
will make the debuggee instead of the debugger responsible for the
privileges it needs.
Differential revision: https://reviews.llvm.org/D85217
In these two cases, use of `os.path.realpath` is problematic:
- The name of the compiler is significant [1] . For testing purposes, we might
provide a compiler called "clang" which is actually a symlink to some build
script (which does some flag processing before invoking the real clang). The
destination the symlink may not be called "clang", but we still want it to be
treated as such.
- When using a build system that puts build artifacts in an arbitrary build
location, and later creates a symlink for it (e.g. creates a
"<lldb root>/lldbsuite/test/dotest.py" symlinks that points to
"/build/artifact/<hash>/dotest.py"), looking at the realpath will not match
the "test" convention required here.
[1] See `Makefile.rules` in the lldb tree, e.g. we use different flags if the compiler is named "clang"
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D85175
Sometimes the decorator is used on a common function rather than the
test method, which can return a value. This fails with decorators that
use skipTestIfFn under the hood.
If the test suite is misconfigured when it's run (a bad regexp, wrong test directory, etc.), the test suite may not discover any tests. When this happens, the test runner exits happily because no tests failed:
```
Ran 0 tests in 0.000s
RESULT: PASSED (0 passes, 0 failures, 0 errors, 0 skipped, 0 expected failures, 0 unexpected successes)
```
Change this to return an error so the misconfiguration can be more easily detected. Verified that `lldb-dotest -p TestDoesNotExist.py` successfully fails.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D85169
The lldb test-suite on Windows reports a 'CLEANUP ERROR' when attempting to kill
an exited/detached process. This change makes ProcessWindows consistent with
the other processes which only log the error. After this change a number of
'CLEANUP ERROR' messages are now removed.
Differential Revision: https://reviews.llvm.org/D84957
I have made the DW_FORM_ref4 relative. One could also use relocated
DW_FORM_ref_addr instead.
Tested with:
echo 'void f(){}'|clang -o 1.o -c -Wall -g -x c -;./bin/clang -o 1 1.o ../llvm-monorepo/lldb/test/Shell/SymbolFile/DWARF/DW_TAG_GNU_call_site-DW_AT_low_pc.s;./bin/lldb --no-lldbinit ./1 -o r -o 'p p' -o exit
As is common with curses apps, this allows to redraw everything
in case something corrupts the screen. Apparently key modifiers
are difficult with curses (curses FAQ it "doesn't do that"),
thankfully Ctrl+key are simply control characters, so it's
(ascii & 037) => 12.
Differential Revision: https://reviews.llvm.org/D84972
On an iOS device, if debugserver is left to figure out how to launch
the binary provided, it looks at the filename to see if it contains
".app" and asks FrontBoard to launch it. However, if this is actually
a command line app with the characters ".app" in the name, it would
end up trying to launch that via the FrontBoard calls even though it
needed to be launched via posix_spawn. For instance, a command line
program called com.application.tester.
Jim suggested this patch where we only send binaries that end in ".app"
to FrontBoard.
Often debugsever is invoked with a --launch command line argument to
specify the launch method, and none of this code is hit in that
instance.
<rdar://problem/65297100>
This test was added in D74217 (and the `.categories` file later added in ccf1c30cde) around the same time I moved the test tree from `lldb/packages/Python/lldbsuite/test` to `lldb/test/API` (D71151). Since this got lost in the move, it isn't running. (I introduced an intentional syntax error, and `ninja check-lldb` passes).
I moved it to the correct location, and now it runs and passes -- locally, at least -- as `ninja check-lldb-api-tools-lldb-server-registers-target-xml-reading`.
Let's just return a std::string to make this safe. formatv seemed overkill for formatting
the return values as they all just append an integer value to a constant string.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D84505
Move the finish_swig logic into a function in the bindings directory. By
making this a function I can reuse the logic internally where we ship
two Python versions and therefore need to finish the bindings twice.
We saw a crash recently (rdar://problem/65276489) that looks related to an invalid ValueObjectSP in a summary providers in Cocoa.cpp e.g. NSBundleSummaryProvider(...).
This adds checks before we use them usually by calling NSStringSummaryProvider.
Differential Revision: https://reviews.llvm.org/D84272
'd' would be much better used for up/down shortcuts, and this also removes
the possibility of ruining the whole debugging session by accidentally
hitting 'd' or 'k'. Also change menu to have both 'detach and resume'
and 'detach suspended' to make it clear which one is which. See
discussion at https://reviews.llvm.org/D68541 .
Differential Revision: https://reviews.llvm.org/D68908
Both of BreakpointLocation and BreakpointSite were inherited from StoppointLocation. However, the only thing
they shared was hit counting logic. The patch encapsulates those logic into StoppointHitCounter, renames
StoppointLocation to StoppointSite, and stops BreakpointLocation's inheriting from it.
Differential Revision: https://reviews.llvm.org/D84527
Most process plugins (if not all) don't set hardware index for breakpoints. They even
are not able to determine this index.
This patch makes StoppointLocation::IsHardware pure virtual and lets BreakpointSite
override it using more accurate BreakpointSite::Type.
It also adds assertions to be sure that a breakpoint site is hardware when this is required.
Differential Revision: https://reviews.llvm.org/D84257
Currently, `target create` has no --platform option. However,
TargetList::CreateTargetInternal which is called under the hood, will
return an error when either no platform or multiple matching platforms
are found, saying that a platform should be specified with --platform.
This patch adds the platform option, but that doesn't solve either of
these errors.
- If more than one platform matches, specifying the platform isn't
going to fix that. The current code will only look at the
architecture instead. I've updated the error message to ask the user
to specify an architecture.
- If no architecture is found, specifying a new one via platform isn't
going to change that either because we already try to find one that
matches the given architecture.
Differential revision: https://reviews.llvm.org/D84809
Summary:
Initially, Apple simulator binarie triples didn't use a `-simulator`
environment and were just differentiated based on the architecture.
For example, `x86_64-apple-ios` would obviously be a simualtor as iOS
doesn't run on x86_64. With Catalyst, we made the disctinction
explicit and today, all simulator triples (even the legacy ones) are
constructed with an environment. This is especially important on Apple
Silicon were the architecture is not different from the one of the
simulated device.
This change makes the simulator part of the environment always part of
the criteria to detect whether 2 `ArchSpec`s are equal or compatible.
Reviewers: aprantl
Subscribers: inglorion, dexonsmith, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D84716
This way, downstream projects don't have to invoke find_package(ZLIB)
reducing the amount of boilerplate.
Differential Revision: https://reviews.llvm.org/D84691
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 27d52cd86a 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 85fbb08fa2.
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>
This reapplies commit d4020ef7c4, reverted in ac0edc5588 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 21c0b4c1e8.
This reverts commit 81d68ad27b.
This reverts commit a361aa5249.
This reverts commit fa42b7cf29.
This reverts commit 955f87f947.
This reverts commit 8b16e45f66.
This reverts commit 308a127a38.
This reverts commit 274b6b0c7a.
This reverts commit 1c7037a2a5.
Luboš Luňák