This patch adds a way to fetch breakpoint metadatas as a serialized
`Structured` Data format (JSON). This can be used by IDEs to update
their UI when a breakpoint is set or modified from the console.
rdar://11013798
Differential Revision: https://reviews.llvm.org/D87491
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
They are currently not being set correctly for the case of multi-config generators like XCode and VS. There's also a typo in one of the cmake files.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D87466
Extract a function for turning `eLaunchFlavorDefault` into a concreate `eLaunchFlavor` value.
This new function encapsulates the few compile time variables involved, and also prevents clang unused code diagnostics.
Differential Revision: https://reviews.llvm.org/D87327
This adds support for substituting std::pair instantiations with enabled
import-std-module.
With the fixes in parent revisions we can currently substitute a single pair
(however, a result that returns a second pair currently causes LLDB to crash
while importing the second template instantiation).
Reviewed By: aprantl
Differential Revision: https://reviews.llvm.org/D85141
The ASTImporter has an `Imported(From, To)` callback that notifies subclasses
that a declaration has been imported in some way. LLDB uses this in the
`CompleteTagDeclsScope` to see which records have been imported into the scratch
context. If the record was declared inside the expression, then the
`CompleteTagDeclsScope` will forcibly import the full definition of that record
to the scratch context so that the expression AST can safely be disposed later
(otherwise we might end up going back to the deleted AST to complete the
minimally imported record). The way this is implemented is that there is a list
of decls that need to be imported (`m_decls_to_complete`) and we keep completing
the declarations inside that list until the list is empty. Every `To` Decl we
get via the `Imported` callback will be added to the list of Decls to be
completed.
There are some situations where the ASTImporter will actually give us two
`Imported` calls with the same `To` Decl. One way where this happens is if the
ASTImporter decides to merge an imported definition into an already imported
one. Another way is that the ASTImporter just happens to get two calls to
`ASTImporter::Import` for the same Decl. This for example happens when importing
the DeclContext of a Decl requires importing the Decl itself, such as when
importing a RecordDecl that was declared inside a function.
The bug addressed in this patch is that when we end up getting two `Imported`
calls for the same `To` Decl, then we would crash in the
`CompleteTagDeclsScope`. That's because the first time we complete the Decl we
remove the Origin tracking information (that maps the Decl back to from where it
came from). The next time we try to complete the same `To` Decl the Origin
tracking information is gone and we hit the `to_context_md->getOrigin(decl).ctx
== m_src_ctx` assert (`getOrigin(decl).ctx` is a nullptr the second time as the
Origin was deleted).
This is actually a regression coming from D72495. Before D72495
`m_decls_to_complete` was actually a set so every declaration in there could
only be queued once to be completed. The set was changed to a vector to make the
iteration over it deterministic, but that also causes that we now potentially
end up trying to complete a Decl twice.
This patch essentially just reverts D72495 and makes the `CompleteTagDeclsScope`
use a SetVector for the list of declarations to be completed. The SetVector
should filter out the duplicates (as the original `set` did) and also ensure that
the completion order is deterministic. I actually couldn't find any way to cause
LLDB to reproduce this bug by merging declarations (this would require that we
for example declare two namespaces in a non-top-level expression which isn't
possible). But the bug reproduces very easily by just declaring a class in an
expression, so that's what the test is doing.
Reviewed By: shafik
Differential Revision: https://reviews.llvm.org/D85648
SemaSourceWithPriorities is a special SemaSource that wraps our normal LLDB
ExternalASTSource and the ASTReader (which is used for the C++ module loading).
It's only active when the `import-std-module` setting is turned on.
The `CompleteType` function there in `SemaSourceWithPriorities` is looping over
all ExternalASTSources and asks each to complete the type. However, that loop is
in another loop that keeps doing that until the type is complete. If that
function is ever called on a type that is a forward decl then that causes LLDB
to go into an infinite loop.
I remember I added that second loop and the comment because I thought I saw a
similar pattern in some other Clang code, but after some grepping I can't find
that code anywhere and it seems the rest of the code base only calls
CompleteType once (It would also be kinda silly to have calling it multiple
times). So it seems that's just a silly mistake.
The is implicitly tested by importing `std::pair`, but I also added a simpler
dedicated test that creates a dummy libc++ module with some forward declarations
and then imports them into the scratch AST context. At some point the
ASTImporter will check if one of the forward decls could be completed by the
ExternalASTSource, which will cause the `SemaSourceWithPriorities` to go into an
infinite loop once it receives the `CompleteType` call.
Reviewed By: shafik
Differential Revision: https://reviews.llvm.org/D87289
This patch removes register set definitions and other redundant code from
NativeRegisterContextLinux/RegisterContextPOSIX*_arm. Register sets are now
moved under RegisterInfosPOSIX_arm which now uses RegisterInfoAndSetInterface.
This is similar to what we earlier did for AArch64.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D86962
targetHasSVE helper function was added to test for availability of SVE support
by connected platform. We now intend to use this function in other testcases
and I am moving it to a generic location in lldbtest.py to allow usage by
other upcoming testcases.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D86872
TestCPP11EnumTypes is one of the most expensive tests on my system and takes
around 35 seconds to run. A relatively large amount of that time is actually
doing CPU intensive work it seems (and not waiting on timeouts like other
slow tests).
The main issue is that this test repeatedly compiles the same source files
with different compiler defines. The test is also including standard library
headers, so it will also build all system modules with the gmodules debug
info variant. This leads to the problem that this test ends up compiling all
system Clang modules 8 times (one for each subtest with a unique define). As
the system modules are quite large, this causes that this test spends most
of its runtime just recompiling all system modules on macOS.
There is also the small issue that this test is starting and start-stopping
the test process a few hundred times.
This rewrites the test to instead just use a macro to instantiate all the
enum types in a single source and uses global variables to test the values
(which means there is no more need to continue/stop or even start a process).
I kept running all the debug info variants (event though it doesn't seem really
relevant) to keep this as NFC as possible.
This reduced the test runtime by around 1.5 seconds on my system (or in relative
numbers, the runtime of this test decreases by 95%).
This is one of the most expensive tests and runs for nearly half a minute on
my machine. Beside this test just doing a lot of work by iterating 15k times on
one ValueObject (which seems to be the point), it also runs this for every
debug info variant which doesn't seem relevant to just iterating ValueObject.
This marks it as no_debug_info_test to only run one debug info variation
and cut down the runtime to around 7 seconds on my machine.
This reverts commit f369d51896. The bug this
fixes was already fixed by 1c5a0cb1c3 with the
same approach and this commit is now just giving the variable a second fallback
value.
The tests are unsupported on linux, but they assert in
Thread::GetStopDescriptionRaw() because of empty stop reason
description. And it is empty because
InstrumentationRuntimeTSan::NotifyBreakpointHit() fails
to get report from InstrumentationRuntimeTSan::RetrieveReportData(),
which is possibly(?) the reason why this is unsupported on linux.
Add a dummy stop reason description for this case, which changes
the test result from failing to unsupported.
Caused by D86662. The fix is only checking some fields when the expect_debug_info_size flag is true. For some reason this was not failing on a local linux machine.
This updates the errors reported by expect()
to something like:
```
Ran command:
"help"
Got output:
Debugger commands:
<...>
Expecting start string: "Debugger commands:" (was found)
Expecting end string: "foo" (was not found)
```
(see added tests for more examples)
This shows the user exactly what was run,
what checks passed and which failed. Along with
whether that check was supposed to pass.
(including what regex patterns matched)
These lines are also output to the test
trace file, whether the test passes or not.
Note that expect() will still fail at the first failed
check, in line with previous behaviour.
Also I have flipped the wording of the assert
message functions (.*_MSG) to describe failures
not successes. This makes more sense as they are
only shown on assert failures.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D86792
Previously, before loading the REPL language-specific init file, lldb
checked the selected target language in which case it returned an unknown
language type with the REPL target.
Instead, the patch calls `Language::GetLanguagesSupportingREPLs` and
look for the first element of that set. In case lldb was not configured
with a REPL language, then, it will just stop sourcing the REPL init
file and fallback to the original logic (continuing with the default
init file).
rdar://65836048
Differential Revision: https://reviews.llvm.org/D87076
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
`image dump symtab` seems to output the symbols in whatever order they appear in
the DenseMap that is used to filter out symbols with non-unique addresses. As
DenseMap is a hash map this order can change at any time so the output of this
command is pretty unstable. This also causes the `Breakpad/symtab.test` to fail
with enabled reverse iteration (which reverses the DenseMap order to find issues
like this).
This patch makes the DenseMap a std::vector and uses a separate DenseSet to do
the address filtering. The output order is now dependent on the order in which
the symbols are read (which should be deterministic). It might also avoid a bit
of work as all the work for creating the Symbol constructor parameters is only
done when we can actually emplace a new Symbol.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D87036
The test only checks the exit code that the debug server sends back, but
not the following explanation which is different for debugserver and lldb-server.
If our process terminates due to an unhandled signal, we are supposed to get the
signal code via WTERMSIG. However, we instead try to get the exit status via
WEXITSTATUS which just ends up always calculating signal code 0 (at least on the
macOS implementation where it just shifts the signal code bits away and we're
left with only 0 bits).
The exit status calculation on the LLDB side also seems a bit off as it claims
an exit status that is just the signal code (instead of for example 128 + signal
code), but that will be another patch.
Reviewed By: jasonmolenda
Differential Revision: https://reviews.llvm.org/D86336
Add a reproducer verifier that catches:
- Missing or invalid home directory
- Missing or invalid working directory
- Missing or invalid module/symbol paths
- Missing files from the VFS
The verifier is enabled by default during replay, but can be skipped by
passing --reproducer-no-verify.
Differential revision: https://reviews.llvm.org/D86497
When compiling an Objective-C++ file, __has_feature(cxx_exceptions) will
return true with -fno-exceptions but without -fno-objc-exceptions. This
was causing LLVM_ENABLE_EXCEPTIONS to be defined for a subset of files.
This is currently causing msan warnings in the API tests when run under msan, e.g. `commands/gui/basic/TestGuiBasic.py`.
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D86825
The /proc/<pid>/status parsing is missing a few cases:
- Idle
- Parked
- Dead
If we encounter an unknown proc state, this leads to an msan warning. In reality, we only check that the state != Zombie, so it doesn't really matter that we handle all cases, but handle them anyway (current list: [1]). Also explicitly set it to unknown if we encounter an unknown state. There will still be an msan warning if the proc entry has no `State:` line, but that should not happen.
Use a StringSwitch to make the handling of proc states a little more compact.
[1] https://github.com/torvalds/linux/blob/master/fs/proc/array.c
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D86818
This patch adds the ability to use a custom interpreter with the
`platform shell` command. If the user set the `-s|--shell` option
with the path to a binary, lldb passes it down to the platform's
`RunShellProcess` method and set it as the shell to use in
`ProcessLaunchInfo to run commands.
Note that not all the Platforms support running shell commands with
custom interpreters (i.e. RemoteGDBServer is only expected to use the
default shell).
This patch also makes some refactoring and cleanups, like swapping
CString for StringRef when possible and updating `SBPlatformShellCommand`
with new methods and a new constructor.
rdar://67759256
Differential Revision: https://reviews.llvm.org/D86667
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Move the CommandObjectScript and CommandObjectRegexCommand under
Commands where all the other CommandObject implementations live.
Although neither implementations currently use the TableGen-generated
CommandOptions.inc, this move would have been necessary anyway if they
were to in the future.
The Symbol Status in modules view is simplified so that only when the module has debug info and its size is non-zero, will the status message be displayed. The symbol status message is renamed to debug info size and flag message like "Symbols not found" and "Symbols loaded" is deleted.
Differential Revision: https://reviews.llvm.org/D86662
This patch changes the command interpreter sourcing logic for the REPL
init file. Instead of looking for a arbitrary file name, it standardizes
the REPL init file name to match to following scheme:
`.lldbinit-<language>-repl`
This will make the naming more homogenous and the sourcing logic future-proof.
rdar://65836048
Differential Revision: https://reviews.llvm.org/D86987
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Currently it is hard to avoid having LLVM link to the system install of
ncurses, since it uses check_library_exists to find e.g. libtinfo and
not find_library or find_package.
With this change the ncurses lib is found with find_library, which also
considers CMAKE_PREFIX_PATH. This solves an issue for the spack package
manager, where we want to use the zlib installed by spack, and spack
provides the CMAKE_PREFIX_PATH for it.
This is a similar change as https://reviews.llvm.org/D79219, which just
landed in master.
Patch By: haampie
Differential Revision: https://reviews.llvm.org/D85820
Add a reproducer verifier that catches:
- Missing or invalid home directory
- Missing or invalid working directory
- Missing or invalid module/symbol paths
- Missing files from the VFS
The verifier is enabled by default during replay, but can be skipped by
passing --reproducer-no-verify.
Differential revision: https://reviews.llvm.org/D86497
1. Added a dedicated completion to class `CommandObjectTypeFormatterDelete`
which can be used by these commands: `type filter/format/summary/synthetic delete`;
2. Added a related test case.
Reviewed By: teemperor
Differential Revision: https://reviews.llvm.org/D84142
TestCompletion is randomly failing on some bots. The error message however states
that the computed completions actually do contain the expected pid we're
looking for, so there shouldn't be any test failure.
The reason for that turns out to be that complete_from_to is actually used
for testing two different features. It can be used for testing what the
common prefix for the list of completions is and *also* for checking all the
possible completions that are returned for a command. Which one of the two
things should be checked can't be defined by a parameter to the function, but
is instead guessed by the test method instead based on the results that were
returned. If there is a common prefix in all completions, then that prefix
is searched and otherwise all completions are searched.
For TestCompletion's pid test this behaviour leads to the strange test failures.
If all the pid's that our test LLDB can see have a common prefix (e.g., it
can only see pids [123, 122, 10004, 10000] -> common prefix '1'), then
complete_from_to check that the common prefix contains our pid, which is
always fails ('1' doesn't contain '123' or any other valid pid). If there
isn't a common prefix (e.g., pids are [123, 122, 10004, 777]) then
complete_from_to will check the list of completions instead which works correctly.
This patch is fixing this by adding a simple check method that doesn't
have this behaviour and is simply searching the returned list of completions.
This should get the bots green while I'm working on a proper fix that fixes
complete_from_to.
Right now all tsan tests are crashing on Linux. The tests were already marked as
expected failures, but since commit 20ce8affce added an assert that every
StopInfo needs a non-empty stop description the tests actually started crash
(which is even with an expectedFailure a failed test).
The reason for that is that we never had any stop description when hitting tsan
errors on Linux. Before the assert that just made the test fail, but now the
empty description is hitting the assert. This patch just adds a generic stop
description mentioning tsan to prevent that we hit that assert on platforms
where we don't support extracting the tsan report.
Reviewed By: friss
Differential Revision: https://reviews.llvm.org/D86593
The Length, AbbrOffset and Values fields of the debug_info section are
optional. This patch helps remove them and simplify test cases.
Reviewed By: MaskRay
Differential Revision: https://reviews.llvm.org/D86857
LIT uses a model where the test suite is configurable trough a
lit.site.cfg file. Most of the time we use the lit.site.cfg with values
that match the current build configuration, generated by CMake.
Nothing prevents you from running the test suite with a different
configuration, either by overriding some of these values from the
command line, or by passing a different lit.site.cfg.
The latter is currently tedious. Many configuration values are optional
but they still need to be set because lit.cfg.py is accessing them
directly. This patch changes the code to use getattr to return the
attribute if it exists. This makes it possible to specify a minimal
lit.site.cfg with only the mandatory/desired configuration values.
Differential revision: https://reviews.llvm.org/D86821
This patch removes the rather confusing LLDB_LIB_DIR and LLDB_IMPLIB_DIR
environment variables. They are confusing because LLDB_LIB_DIR would
point to the bin subdirectory in the build root while LLDB_IMPLIB_DIR
would point to the lib subdirectory. The reason far this was
LLDB.framework, which gets build under bin.
This patch replaces their uses with configuration.lldb_framework_path
and configuration.lldb_libs_dir respectively.
Differential revision: https://reviews.llvm.org/D86817
TestStandardUnwind uses the full absolute path to a set of C/C++ files as the test case name, which in turn is used in the name of a log file. When the source file is long, and the directory where log files are stored is also long, this causes an OSError because the log filename is too long.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D86752
Annotating `PExpectTest` with `@skipIfWindows` instead of marking it as an empty class will make the test runner recognize it as a test class, which should allow me to reland adb5c23f8c.
I don't have a windows machine to verify this works, but I did some tests using `@skipIfLinux` and they all worked as expected. In case the `pexpect` import is not at all available on windows, I moved it to within the method where it's used.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D86745
This patch is mostly about removing the "Category" enum, which was
very useful when the Type enum contained a large number of types, but
now the two are completely identical.
It also removes some other artifacts like unused typedefs and macros.
The introduction of find_library for ncurses caused more issues than it solved problems. The current open issue is it makes the static build of LLVM fail. It is better to revert for now, and get back to it later.
Revert "[CMake] Fix an issue where get_system_libname creates an empty regex capture on windows"
This reverts commit 1ed1e16ab8.
Revert "Fix msan build"
This reverts commit 34fe9613dd.
Revert "[CMake] Always mark terminfo as unavailable on Windows"
This reverts commit 76bf26236f.
Revert "[CMake] Fix OCaml build failure because of absolute path in system libs"
This reverts commit 8e4acb82f7.
Revert "[CMake] Don't look for terminfo libs when LLVM_ENABLE_TERMINFO=OFF"
This reverts commit 495f91fd33.
Revert "Use find_library for ncurses"
This reverts commit a52173a3e5.
Differential revision: https://reviews.llvm.org/D86521
Fixes error: no matching constructor for initialization of
'std::pair<std::__cxx11::basic_string<char>, std::__cxx11::basic_string<char> >'
with older toolchain (clang/libcxx) on Ubuntu 16.04. The issue is the
StringRef-to-std::string conversion.
Always make lldb-argdumper a dependency of liblldb. Currently it is only
a dependency of the python swig target because of the relative symlink
in the python resource directory. That means that the dependency won't
be there when LLDB_ENABLE_PYTHON is disabled.
Differential revision: https://reviews.llvm.org/D86722
The function was returning an incorrect (empty) value on the first
invocation. Given that this only affected the first invocation, this
bug/typo went mostly unaffected. DW_AT_const_value were particularly
badly affected by this as the GetByteSize call is
SymbolFileDWARF::ParseVariableDIE is likely to be the first call of this
function, and its effects cannot be undone by retrying.
Depends on D86348.
Differential Revision: https://reviews.llvm.org/D86436
This applies the same fix that D84748 did for macro definitions.
Appropriate include path is now automatically set for all libraries
which link against gtest targets, which avoids the need to set
include_directories in various parts of the project.
Differential Revision: https://reviews.llvm.org/D86616
Class-level static constexpr variables can have both DW_AT_const_value
(in the "declaration") and a DW_AT_location (in the "definition")
attributes. Our code was trying to handle this, but it was brittle and
hard to follow (and broken) because it was processing the attributes in
the order in which they were found.
Refactor the code to make the intent clearer -- DW_AT_location trumps
DW_AT_const_value, and fix the bug which meant that we were not
displaying these variables properly (the culprit was the delayed parsing
of the const_value attribute due to a need to fetch the variable type.
Differential Revision: https://reviews.llvm.org/D86615
Specify type when constructing PromotionKeys,
this fixes error:
"chosen constructor is explicit in copy-initialization"
when compiling lldb with GCC 5.4.0.
This is due to std::tuple having an explicit
default constructor, see:
http://cplusplus.github.io/LWG/lwg-defects.html#2193
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D86690
Breakpad creates minidump files that can a module loaded multiple times. We found that when a process mmap's the object file for a library, this can confuse breakpad into creating multiple modules in the module list. This patch fixes the GetFilteredModules() to check the linux maps for permissions and use the one that has execute permissions. Typically when people mmap a file into memory they don't map it as executable. This helps people to correctly load minidump files for post mortem analysis.
Differential Revision: https://reviews.llvm.org/D86375
This fixes several issues in handling of DW_AT_const_value attributes:
- the first is that the size of the data given by data forms does not
need to match the size of the underlying variable. We already had the
case to handle this for DW_FORM_(us)data -- this extends the handling
to other data forms. The main reason this was not picked up is because
clang uses leb forms in these cases while gcc prefers the fixed-size
ones.
- The handling of DW_AT_strp form was completely broken -- we would end
up using the pointer value as the result. I've reorganized this code
so that it handles all string forms uniformly.
- In case of a completely bogus form we would crash due to
strlen(nullptr).
Depends on D86311.
Differential Revision: https://reviews.llvm.org/D86348
EXP_MSG generates a message to show on assert
failure. Currently it looks like:
AssertionError: False is not True : '<cmd>'
returns expected result, got '<actual output>'
Which seems to say that the test failed but
also got the expected result.
It should say:
AssertionError: False is not True : '<cmd>'
returned unexpected result, got '<actual output>'
Reviewed By: teemperor, #lldb
Differential Revision: https://reviews.llvm.org/D86603
This test appears to have never worked on Linux but it seems none of the current
bots ever ran this test as it required enabling compiler-rt (otherwise it
would have just been skipped).
This just copies over the XFAIL decorator that are already on all other sanitizer
tests.
Update the "image show-unwind" command output to show if the function
being shown is listed as a user-setting or platform trap handler.
Update the individual UnwindPlan dumps to show whether the unwind plan
is registered as a trap handler.
Remove `SetObjectModificationTime` which is not currently used, and assigns to the wrong member.
Differential Revision: https://reviews.llvm.org/D86493
Since a842950b62 this test started using
the reproducer subsystem but we never initialized it in the test. The
Subsystem takes an argument, so we can't use the usual SubsystemRAII at the
moment to do this for us.
This just adds the initialize/terminate calls to get the test passing again.
TestQueues is curiously failing for me as my queue for QOS_CLASS_UNSPECIFIED
is named "Utility" and not "User Initiated" or "Default". While debugging, this
I noticed that this test isn't actually using this API right from what I understand. The API documentation
for `dispatch_get_global_queue` specifies for the parameter: "You may specify the value
QOS_CLASS_USER_INTERACTIVE, QOS_CLASS_USER_INITIATED, QOS_CLASS_UTILITY, or QOS_CLASS_BACKGROUND."
QOS_CLASS_UNSPECIFIED isn't listed as one of the supported values. swift-corelibs-libdispatch
even checks for this value and returns a DISPATCH_BAD_INPUT. The
libdispatch shipped on macOS seems to also check for QOS_CLASS_UNSPECIFIED and seems to
instead cause a "client crash", but somehow this doesn't trigger in this test and instead we just
get whatever queue
This patch just removes that part of the test as it appears the code is just incorrect.
Reviewed By: jasonmolenda
Differential Revision: https://reviews.llvm.org/D86211
psutil isn't reall a dependency of the test suite so this shouldn't be
unconditionally be imported here. Instead just check for the process name
by looking for the "a.out" string to get the bots green again.
There was typo left from changes in CalculateSVEOffset where we moved
FPSR/FPCR offset calculation into WriteRegister and ReadRegister.
Differential Revision: https://reviews.llvm.org/D79699
In some cases when we have a DW_AT_const_value and the data can be found in the
DWARFExpression then ValueObjectVariable does not handle it properly and we end
up with an extracting data from value failed error.
The test is a very stripped down assembly file since reproducing this relies on the results of compiling with -O1 which may not be stable over time.
Differential Revision: https://reviews.llvm.org/D86311
When replaying a reproducer captured from a core file, we always use
dsymForUUID for the kernel binary. When enabled, we also use it to find
kexts. Since these files are already contained in the reproducer,
there's no reason to call out to an external tool. If the tool returns a
different result, e.g. because the dSYM got garbage collected, it will
break reproducer replay. The SymbolFileProvider solves the issue by
mapping UUIDs to module and symbol paths in the reproducer.
Differential revision: https://reviews.llvm.org/D86389
Breakpad will always have a UUID for binaries when it creates minidump files. If an ELF files has a GNU build ID, it will use that. If it doesn't, it will create one by hashing up to the first 4096 bytes of the .text section. LLDB was not able to load these binaries even when we had the right binary because the UUID didn't match. LLDB will use the GNU build ID first as the main UUID for a binary and fallback onto a 8 byte CRC if a binary doesn't have one. With this fix, we will check for the Breakpad hash or the Facebook hash (a modified version of the breakpad hash that collides a bit less) and accept binaries when these hashes match.
Differential Revision: https://reviews.llvm.org/D86261
1. Added a new common completion TypeCategoryNames to provide a list of category names for completion;
2. Applied the completion to these commands: type category delete/enable/disable/list/define;
3. Added a related test case;
4. Bound the completion to the arguments of the type 'eArgTypeName'.
Reviewed By: teemperor, JDevlieghere
Differential Revision: https://reviews.llvm.org/D84124
1. Extended the gdb-remote communication related classes with disk file/directory
completion functions;
2. Added two common completion functions RemoteDiskFiles and
RemoteDiskDirectories based on the functions above;
3. Added completion for these commands:
A. platform get-file <remote-file> <local-file>;
B. platform put-file <local-file> <remote-file>;
C. platform get-size <remote-file>;
D. platform settings -w <remote-dir>;
E. platform open file <remote-file>.
4. Added related tests for client and server;
5. Updated docs/lldb-platform-packets.txt.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D85284
1. Added two common completions: `ProcessIDs` and `ProcessNames`, which are
refactored from their original dedicated option completions;
2. Removed the dedicated option completion functions of `process attach` and
`platform process attach`, so that they can use arg-type-bound common
completions instead;
3. Bound `eArgTypePid` to the pid completion, `eArgTypeProcessName` to the
process name completion in `CommandObject.cpp`;
4. Added a related test case.
Reviewed By: teemperor
Differential Revision: https://reviews.llvm.org/D80700
`struct Py_buffer_RAII` definition uses explicit deleted functions which are not supported by SWIG 2 (only 3).
To get around this I moved this struct to an .h file that is included to avoid being parsed by swig.
Reviewed By: lawrence_danna
Differential Revision: https://reviews.llvm.org/D86381
Extract all the provider related logic from Reproducer.h and move it
into its own header ReproducerProvider.h. These classes are seeing most
of the development these days and this reorganization reduces
incremental compilation from ~520 to ~110 files when making changes to
the new header.
When `Target::GetEntryPointAddress()` calls `exe_module->GetObjectFile()->GetEntryPointAddress()`, and the returned
`entry_addr` is valid, it can immediately be returned.
However, just before that, an `llvm::Error` value has been setup, but in this case it is not consumed before returning, like is done further below in the function.
In https://bugs.freebsd.org/248745 we got a bug report for this, where a very simple test case aborts and dumps core:
```
* thread #1, name = 'testcase', stop reason = breakpoint 1.1
frame #0: 0x00000000002018d4 testcase`main(argc=1, argv=0x00007fffffffea18) at testcase.c:3:5
1 int main(int argc, char *argv[])
2 {
-> 3 return 0;
4 }
(lldb) p argc
Program aborted due to an unhandled Error:
Error value was Success. (Note: Success values must still be checked prior to being destroyed).
Thread 1 received signal SIGABRT, Aborted.
thr_kill () at thr_kill.S:3
3 thr_kill.S: No such file or directory.
(gdb) bt
#0 thr_kill () at thr_kill.S:3
#1 0x00000008049a0004 in __raise (s=6) at /usr/src/lib/libc/gen/raise.c:52
#2 0x0000000804916229 in abort () at /usr/src/lib/libc/stdlib/abort.c:67
#3 0x000000000451b5f5 in fatalUncheckedError () at /usr/src/contrib/llvm-project/llvm/lib/Support/Error.cpp:112
#4 0x00000000019cf008 in GetEntryPointAddress () at /usr/src/contrib/llvm-project/llvm/include/llvm/Support/Error.h:267
#5 0x0000000001bccbd8 in ConstructorSetup () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:67
#6 0x0000000001bcd2c0 in ThreadPlanCallFunction () at /usr/src/contrib/llvm-project/lldb/source/Target/ThreadPlanCallFunction.cpp:114
#7 0x00000000020076d4 in InferiorCallMmap () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/Utility/InferiorCallPOSIX.cpp:97
#8 0x0000000001f4be33 in DoAllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Plugins/Process/FreeBSD/ProcessFreeBSD.cpp:604
#9 0x0000000001fe51b9 in AllocatePage () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:347
#10 0x0000000001fe5385 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Memory.cpp:383
#11 0x0000000001974da2 in AllocateMemory () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2301
#12 CanJIT () at /usr/src/contrib/llvm-project/lldb/source/Target/Process.cpp:2331
#13 0x0000000001a1bf3d in Evaluate () at /usr/src/contrib/llvm-project/lldb/source/Expression/UserExpression.cpp:190
#14 0x00000000019ce7a2 in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Target/Target.cpp:2372
#15 0x0000000001ad784c in EvaluateExpression () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:414
#16 0x0000000001ad86ae in DoExecute () at /usr/src/contrib/llvm-project/lldb/source/Commands/CommandObjectExpression.cpp:646
#17 0x0000000001a5e3ed in Execute () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandObject.cpp:1003
#18 0x0000000001a6c4a3 in HandleCommand () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:1762
#19 0x0000000001a6f98c in IOHandlerInputComplete () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2760
#20 0x0000000001a90b08 in Run () at /usr/src/contrib/llvm-project/lldb/source/Core/IOHandler.cpp:548
#21 0x00000000019a6c6a in ExecuteIOHandlers () at /usr/src/contrib/llvm-project/lldb/source/Core/Debugger.cpp:903
#22 0x0000000001a70337 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/Interpreter/CommandInterpreter.cpp:2946
#23 0x0000000001d9d812 in RunCommandInterpreter () at /usr/src/contrib/llvm-project/lldb/source/API/SBDebugger.cpp:1169
#24 0x0000000001918be8 in MainLoop () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:675
#25 0x000000000191a114 in main () at /usr/src/contrib/llvm-project/lldb/tools/driver/Driver.cpp:890```
Fix the incorrect error catch by only instantiating an `Error` object if it is necessary.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D86355
LLVM install component targets needs to be in the form of: install-{target}[-stripped]
I tested with:
```
cmake ... -DLLVM_ENABLE_PROJECTS="clang;lldb" -DLLVM_DISTRIBUTION_COMPONENTS="lldb;liblldb;lldb-python-scripts;" ...
DESTDIR=... ninja install-distribution
```
@JDevlieghere `finish_swig_python_scripts` is a really weird name for a distribution component, any reason that it has to be this way?
Differential Revision: https://reviews.llvm.org/D86235
The logic behind --rerun-all-issues was removed when we switched to LIT
as the test driver. This patch just removes the dotest option and
corresponding entry in configuration.py.
Before e5d08fcbac the Makefile would always compute the min-version,
even if it wasn't set in the triple. This nuance got lost when passing
the ARCH_CFLAGS directly from TestSimulatorPlatform.
Refuse to run the shell tests when %lldb cannot be substituted. This
prevents the test from silently running again the `lldb` in your PATH.
I noticed because when this happens, %lldb-init gets substituted with
lldb-init, which does not exists.
With the log file being a build artifact we don't need to clean it up.
If this happens before the reproducer is captured, the file will be
missing from the reproducer root but being part of the mapping.
1. Complete `process load` with the common disk file completion, so there is not test provided for it;
2. Complete `process unload` with the tokens of valid loaded images.
Thanks for Raphael's help on the test for `process unload`.
Reviewed By: teemperor
Differential Revision: https://reviews.llvm.org/D79887
Use the append_if CMake function from HandleLLVMOptions. Since we
include this file in LLDBStandalone it should work in both for in-tree
and out-of-tree builds.
This patch adds support for emitting multiple abbrev tables. Currently,
compilation units will always reference the first abbrev table.
Reviewed By: jhenderson, labath
Differential Revision: https://reviews.llvm.org/D86194
When replaying the reproducer, lldb should source the .lldbinit file
that was captured by the reproducer and not the one in the current home
directory. This requires that we store the home directory as part of the
reproducer. By returning the virtual home directory during replay, we
ensure the correct virtual path gets constructed which the VFS can then
find and remap to the correct file in the reproducer root.
This patch adds a new HomeDirectoryProvider, similar to the existing
WorkingDirectoryProvider. As the home directory is not part of the VFS,
it is stored in LLDB's FileSystem instance.
This method is used to get the DataExtractor when the expression is a location list.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D86090
The FileSystem initialization depends on the reproducer mode. It has
been growing organically to the point where it deserves its own helper
function. This also allows for early returns to simplify the code.
Provider a wrapper around llvm::sys::path::home_directory in the
FileSystem class. This will make it possible for the reproducers to
intercept the call in a central place.
1. created a common completion for breakpoint names;
2. bound the breakpoint name common completion with eArgTypeBreakpointName;
3. implemented the dedicated completion for breakpoint read -N.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D80693
`lldb_private::ScriptInterpreterPython::CommandDataPython` inherits from `lldb_private::BreakpointOptions::CommandData`, but the latter does not have a virtual destructor. This leads to a new-delete-type-mismatch error when running certain tests (such as `functionalities/breakpoint/breakpoint_command/TestBreakpointCommand.py`) under asan.
Similarly to D85836, collapse all Scalar float types to a single enum
value, and use APFloat semantics to differentiate between. This
simplifies the code, and opens to door to supporting other floating
point semantics (which would be needed for fully supporting
architectures with more interesting float types such as PPC).
Differential Revision: https://reviews.llvm.org/D86220
This is very similar to D85968, only more elusive to since we were not
adding the typedef type to the relevant DeclContext until D86140, which
meant that the DeclContext was populated (and the relevant assertion
hit) only after importing the type into the expression ast in a
particular way.
I haven't checked whether this situation can be hit in the gmodules
case, but my money is on "yes".
Differential Revision: https://reviews.llvm.org/D86216
I move the triple (de)composition logic into the builder in e5d08fcbac
but this test is relying on Make to construct the set the ARCH,
ARCH_CFLAGS and SDKROOT based on the given TRIPLE. This patch updates
the test to pass these variables directly.
Differential revision: https://reviews.llvm.org/D86244
This patch adds the infrastructure to have language specific REPL init
files. It's the foundation work to a following patch that will introduce
Swift REPL init file.
When lldb is launched with the `--repl` option, it will look for a REPL
init file in the home directory and source it. This overrides the
default `~/.lldbinit`, which content might make the REPL behave
unexpectedly. If the REPL init file doesn't exists, lldb will fall back
to the default init file.
rdar://65836048
Differential Revision: https://reviews.llvm.org/D86242
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Print which load command we were looking for when the sanity check
fails:
AssertionError: 0 != 1 : wrong number of load commands for
LC_VERSION_MIN_MACOSX
Instead of a new method for each variable any subclass might want to
set, have a method getExtraMakeArgs that each subclass can use to return
whatever extra Make arguments it wants.
As per Pavel's suggestion in D85539.
Rather than have different modules for different platforms, use
inheritance so we can have a Builer base class and optional child
classes that override platform specific methods.
Differential revision: https://reviews.llvm.org/D86174
TypeSystemClang::CreateTypedef was creating a typedef in the right
DeclContext, but it was not actually adding it as a child of the
context. The resulting inconsistent state meant that we would be unable
to reference the typedef from an expression directly, but we could use
them if they end up being pulled in by some previous subexpression
(because the ASTImporter will set up the correct links in the expression
ast).
This patch adds the typedef to the decl context it is created in.
Differential Revision: https://reviews.llvm.org/D86140
This adds a minor test case fix to previously submitted AArch64 SVE
ptrace support. This was failing on LLDB/AArch64 Linux buildbot.
Differential Revision: https://reviews.llvm.org/D79699
This patch adds NativeRegisterContext_arm64 ptrace routines to access
AArch64 SVE register set. This patch also adds a test-case to test
AArch64 SVE register access and dynamic size configuration capability.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D79699
In our discussion D79699 SVE ptrace register access support we decide to
invalidate register context cached data on every stop instead of doing
at before Step/Resume.
InvalidateAllRegisters was added to facilitate flushing of SVE register
context configuration and cached register values. It now makes more
sense to move invalidation after every stop where we initiate SVE
configuration update if needed by calling ConfigureRegisterContext.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D84501
This patch updates LLDB's in house version of SVE ptrace/sig macros by
converting them into constants and inlines. They are housed under sve
namespace and are used by process elf-core for reading SVE register data.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D85641
Checking if an object file is in memory should use the ObjectFile::IsInMemory(), not test ObjectFile::BaseAddress(). ObjectFile::BaseAddress() is designed to be overridden by all classes and is for mach-o, ELF and COFF plug-ins. They find the header base adddress and return that as a section offset address. The default implementation of ObjectFile::BaseAddress() does try and make an Address() from the ObjectFile::m_memory_addr, but I switched it to a correct function call.
Differential Revision: https://reviews.llvm.org/D86122
Parsing DWARFv5 debug_loclist offsets when a CU is parsed is weighing
down memory usage of symbolizers that don't need to parse this data at
all. There's not much benefit to caching these anyway - since they are
O(1) lookup and reading once you know where the offset list starts (and
can do bounds checking with the offset list size too).
In general, I think it might be time to start paying down some of the
technical debt of loc/loclist/range/rnglist parsing to try to unify it a
bit more.
eg:
* Currently DWARFUnit has: RangeSection, RangeSectionBase, LocSection,
LocSectionBase, LocTable, RngListTable, LoclistTableHeader (be nice if
these were all wrapped up in two variables - one for loclists, one for
rnglists)
* rnglists and loclists are handled differently (see:
LoclistTableHeader, but no RnglistTableHeader)
* maybe all these types could be less stateful - lazily parse what they
need to, even reparsing rather than caching because it doesn't seem
too expensive, for instance. (though admittedly so long as it's
constantcost/overead per compilatiton that's probably adequate)
* Maybe implementing and using a DWARFDataExtractor that can be
sub-ranged (so we could slice it up to just the single contribution) -
though maybe that's not so useful because loc/ranges need to refer to
it by absolute, not contribution-relative mechanisms
Differential Revision: https://reviews.llvm.org/D86110
D85968 started to use `split-file` and while buildbots run fine while
doing `make check-lldb` by hand I get:
.../llvm-monorepo-clangassert/tools/lldb/test/SymbolFile/DWARF/Output/DW_AT_declaration-with-children.s.script: line 2: split-file: command not found
failed:
lldb-shell :: SymbolFile/DWARF/DW_AT_declaration-with-children.s
Differential Revision: https://reviews.llvm.org/D86144
I intentionally decided not to reset the column automatically
anywhere, because I don't know where and if at all that should happen.
There should be always an indication of being scrolled (too much)
to the right, so I'll leave this to whoever has an opinion.
Differential Revision: https://reviews.llvm.org/D85290
Currently it is hard to avoid having LLVM link to the system install of
ncurses, since it uses check_library_exists to find e.g. libtinfo and
not find_library or find_package.
With this change the ncurses lib is found with find_library, which also
considers CMAKE_PREFIX_PATH. This solves an issue for the spack package
manager, where we want to use the zlib installed by spack, and spack
provides the CMAKE_PREFIX_PATH for it.
This is a similar change as https://reviews.llvm.org/D79219, which just
landed in master.
Differential revision: https://reviews.llvm.org/D85820
Rename the existing expectedFailure to expectedFailureIfFn to better
describe its purpose and provide an overload for
unittest2.expectedFailure in decorators.py.
Only link against Python3_LIBRARY when LLDB_ENABLE_PYTHON is true. We
have to be more strict now becuase Python3_LIBRARY might be set to
NOTFOUND instead of being not set at all.
The comment says that TestMultipleDebuggers was XFAILed because it was
failing nondeterministically in which case it should be skipped not
failed (as XPASS will cause the test suite to fail).
The reason it fails is because it was not marked as a no-debug-info test
case. I've ran the test in a loop and it has been passing consistently.
Let's enable it and see if the bots agree, if not we can skip it.
This patch is a big sed to rename the following variables:
s/PYTHON_LIBRARIES/Python3_LIBRARIES/g
s/PYTHON_INCLUDE_DIRS/Python3_INCLUDE_DIRS/g
s/PYTHON_EXECUTABLE/Python3_EXECUTABLE/g
s/PYTHON_RPATH/Python3_RPATH/g
I've also renamed the CMake module to better express its purpose and for
consistency with FindLuaAndSwig.
Differential revision: https://reviews.llvm.org/D85976
CreateFunctionDeclaration should just take a StringRef. GetDeclarationName is
(only) used by CreateFunctionDeclaration so that's why now also takes a
StringRef.
This is the error message from the OS, so we shouldn't check against the
OS-specific part of the string.
Fixes the test on Windows which returns a different error message.
In D83876 the consensus seems that LLDB should never deleted orphaned modules
implicitly. However, SBDebugger::DeleteTarget is currently doing exactly that.
This code was added in 753406221b but I don't see
any explanation in the commit, so I think we should delete it.
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D83933
The class contains an enum listing all host integer types as well as
some non-host types. This setup is a remnant of a time when this class
was actually implemented in terms of host integer types. Now that we are
using llvm::APInt, they are mostly useless and mean that each function
needs to enumerate all of these cases even though it treats most of them
identically.
I only leave e_sint and e_uint to denote the integer signedness, but I
want to remove that in a follow-up as well.
Removing these cases simplifies most of these functions, with the only
exception being PromoteToMaxType, which can no longer rely on a simple
enum comparison to determine what needs to be promoted.
This also makes the class ready to work with arbitrary integer sizes, so
it does not need to be modified when someone needs to add a larger
integer size.
Differential Revision: https://reviews.llvm.org/D85836
With -flimit-debug-info, we can run into cases when we only have a class
as a declaration, but we do have a definition of a nested class. In this
case, clang will hit an assertion when adding a member to an incomplete
type (but only if it's adding a c++ class, and not C struct).
It turns out we already had code to handle a similar situation arising
in the -gmodules scenario. This extends the code to handle
-flimit-debug-info as well, and reorganizes bits of other code handling
completion of types to move functions doing similar things closer
together.
Differential Revision: https://reviews.llvm.org/D85968
Right now the only places in the SB API where lldb:: ModuleSP instances are
destroyed are in SBDebugger::MemoryPressureDetected (where it's just attempted
but not guaranteed) and in SBDebugger::DeleteTarget (which will be removed in
D83933). Tests that directly create an lldb::ModuleSP and never create a target
therefore currently leak lldb::Module instances. This triggers the sanity checks
in lldbtest that make sure that the global module list is empty after a test.
This patch adds SBModule::GarbageCollectAllocatedModules as an explicit way to
clean orphaned lldb::ModuleSP instances. Also we now start calling this method
at the end of each test run and move the sanity check behind that call to make
this work. This way even tests that don't create targets can pass the sanity
check.
This fixes TestUnicodeSymbols.py when D83865 is applied (which makes that the
sanity checks actually fail the test).
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D83876
We didn't do anything with the llvm::Error we get from `Open`, so when we end up in the
error case we just crash due to the llvm::Error sanity check. Also add the missing newline
behind the error message so it no longer messes with the next (lldb) prompt.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D85970
`lldb-server platform --socket-file /any/path` currently always fails to create
the socket file. This stopped working after D67424 which changed the
input variables of `writeFileAtomically` slightly. We're expected to
pass in a temporary path template (`/tmp/foo-%%%%%`) and the final
path we want to write. Instead we currently pass in the never set
`temp_file_path` as the temporary path (which will make this function always
fail) and pass in the temp_file_spec's path as the final path (which is actually
the template path such as `/tmp/foo-%%%%%`) instead of the actual path
we want to write (e.g. `/tmp/foo`).
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D85890
This parameter isn't used anywhere in LLDB nor the Swift downstream branch. It
also doesn't really fit into the TypeSystem APIs that usually don't return
additional related functionality via some output parameters. Also the
implementations already states that the calculated value there is wrong.
Let's remove it. If we need this functionality at some point then Swift's much
nicer `GetByteStride` function seems like the way to go.
Reviewed By: aprantl
Differential Revision: https://reviews.llvm.org/D84299
Right now if the test suite encounters a cleanup error it just prints "CLEANUP
ERROR:" but not any additional information.
This patch just prints the exception that caused the cleanup error. This should
make debugging the failing tests for D83865 easier (and seems in general nice to
have).
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D83874
This removes the fallback to Python 2 and makes Python 3 the only
supported configuration. This is the first step to fully migrate to
Python 3 over the coming releases as discussed on the mailing list.
http://lists.llvm.org/pipermail/lldb-dev/2020-August/016388.html
As a reminder, for the current release the test suite and the generated
bindings should remain compatible with Python 2.
Differential revision: https://reviews.llvm.org/D85942
Currently these two tests use an arbitrary wait of 5 seconds for the
inferior to finish setting up. When the test machine is under heavy load
this sometimes is insufficient leading to spurious test failures. This
patch adds synchronization trough a token on the file system. In
addition to making the test more reliable it also makes it much faster
because we no longer have to wait the full 5 seconds if the setup was
completed faster than that.
Differential revision: https://reviews.llvm.org/D85915
In sanitized builds the last packet this function finds for the
TestMacCatalyst and TestPlatformSimulator tests is for the asan runtime.
```
< 69> send packet: $jGetLoadedDynamicLibrariesInfos:{"solib_addresses":[4296048640]}]#3a <
715> read packet: ${"images":[{"load_address":4296048640,"mod_date":0,"pathname":
"/Users/buildslave/jenkins/workspace/lldb-cmake-sanitized/host-compiler/lib/clang/12.0.0/lib/darwin/libclang_rt.asan_osx_dynamic.dylib",
"uuid":"8E38A2CD-753F-3E0F-8EB0-F4BD5788A5CA",
"min_version_os_name":"macosx","min_version_os_sdk":"10.9",
"mach_header":{"magic":4277009103,"cputype":16777223,"cpusubtype":3,"filetype":6,
"flags":43090053}],"segments":[{"name":"__TEXT","vmaddr":0,"vmsize":565248,"fileoff":0,
"filesize":565248,"maxprot":5}],{"name":"__DATA","vmaddr":565248,"vmsize":13152256,"fileoff":565248,
"filesize":20480,"maxprot":3}],{"name":"__LINKEDIT","vmaddr":13717504,"vmsize":438272,"fileoff":585728,
"filesize":435008,"maxprot":1}]]}]]}]#00
```
This just fetches the last package which has fetch_all_solibs and we know
it will contain the image of our test executable to get the tests running again.
This test is flaky on Green Dragon as it often fails when the process state
is "Invalid" in the assert:
self.assertEqual(process.GetState(), lldb.eStateExited)
It seems this is related to just doing "run" which apparently invalidates
the Target's process in case it's still running and needs to be restarted.
Just doing 'continue' on the process (and ignoring the error in case it already
finished) prevents that and makes this consistently pass for me.
Just pushing this out to get Green Dragon back online.
The search for the complete class definition can also produce entries
which are not of the expected type. This can happen for instance when
there is a function with the same name as the class we're looking up
(which means that the class needs to be disambiguated with the
struct/class tag in most contexts).
Previously we were just picking the first Decl that the lookup returned,
which later caused crashes or assertion failures if it was not of the
correct type. This patch changes that to search for an entry of the
correct type.
Differential Revision: https://reviews.llvm.org/D85904
There are two implementations for `TypeSystemMap::GetTypeSystemForLanguage`
which are both identical beside one taking a `Module` and one taking a `Target`
(and then passing that argument to the `TypeSystem::CreateInstance` function).
This merges both implementations into one function with a lambda that wraps the
different calls to `TypeSystem::CreateInstance`.
Reviewed By: #lldb, JDevlieghere
Differential Revision: https://reviews.llvm.org/D82537
This is relanding D81001. The patch originally failed as on newer editline
versions it seems CC_REFRESH will move the cursor to the start of the line via
\r and then back to the original position. On older editline versions like
the one used by default on macOS, CC_REFRESH doesn't move the cursor at all.
As the patch changed the way we handle tab completion (previously we did
REDISPLAY but now we're doing CC_REFRESH), this caused a few completion tests
to receive this unexpected cursor movement in the output stream.
This patch updates those tests to also accept output that contains the specific
cursor movement commands (\r and then \x1b[XC). lldbpexpect.py received an
utility method for generating the cursor movement escape sequence.
Original summary:
I implemented autosuggestion if there is one possible suggestion.
I set the keybinds for every character. When a character is typed, Editline::TypedCharacter is called.
Then, autosuggestion part is displayed in gray, and you can actually input by typing C-k.
Editline::Autosuggest is a function for finding completion, and it is like Editline::TabCommand now, but I will add more features to it.
Testing does not work well in my environment, so I can't confirm that it goes well, sorry. I am dealing with it now.
Reviewed By: teemperor, JDevlieghere, #lldb
Differential Revision: https://reviews.llvm.org/D81001
The function had very complicated signature, because it was trying to
avoid making unnecessary copies of the Scalar object. However, this
class is not hot enough to worry about these kinds of optimizations. My
making copies unconditionally, we can simplify the function and all of
its call sites.
Differential Revision: https://reviews.llvm.org/D85906
When LLDB sees only one possible completion for an input, it will add a trailing
space to the completion to signal that to the user. If the current argument is
quoted, that also means LLDB needs to add the trailing quote to finish the
current argument first.
In case the user is in a function with only one local variable and is currently
editing an empty line in the multiline expression editor, then we are in the
unique situation where we can have a unique completion for an empty input line.
(In a normal LLDB session this would never occur as empty input would just list
all the possible commands).
In this special situation our check if the current argument needs to receive a
trailing quote will crash LLDB as there is no current argument and the
completion code just unconditionally tries to access the current argument. This
just adds the missing check if we even have a current argument before we check
if we need to add a terminating quote character.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D85903
- Print the replay invocation.
- Keep the reproducer around.
- Return the "opposite" exit code so we don't have to rely on FileCheck
to fail the test when the expected exit code is non-zero.
When bit-field data was stored in a Scalar in ValueObjectChild during UpdateValue()
it was extracting the bit-field value. Later on in lldb_private::DumpDataExtractor(…)
we were again attempting to extract the bit-field. Which would then not obtain the
correct value. This will remove the extra extraction in UpdateValue().
We hit this specific case when values are passed in registers, which we could only
reproduce in an optimized build.
Differential Revision: https://reviews.llvm.org/D85376
Some of the test methods were already skipped because of an unexpected
packet. The test started failing after it was expanded. Skip the whole
test with reproducers so we don't have to add the decorator for every
method.
After moving python.swig and lua.swig into their respective
subdirectories, the relative paths in these files were out of date. This
fixes that and ensures the appropriate include paths are set in the SWIG
invocation.
Differential revision: https://reviews.llvm.org/D85859
Apparently when the strings are created, the `'\n'` is converted to the
platform's natural new line indicator, which is CR+LF on Windows. But
upon reading back with `sscanf`, the CRs caused a matching failure.
This patch configures LLDB.framework to build as a flat unversioned
framework on non-macOS Darwin targets, which have never supported the
macOS framework layout.
This patch also renames the 'IOS' cmake variable to 'APPLE_EMBEDDED' to
reflect the fact that lldb is built for several different kinds of embedded
Darwin targets, not just iOS.
Differential Revision: https://reviews.llvm.org/D85770
This reverts commit 246afe0cd1. This broke
the following tests on Linux it seems:
lldb-api :: commands/expression/multiline-completion/TestMultilineCompletion.py
lldb-api :: iohandler/completion/TestIOHandlerCompletion.py
I implemented autosuggestion if there is one possible suggestion.
I set the keybinds for every character. When a character is typed, Editline::TypedCharacter is called.
Then, autosuggestion part is displayed in gray, and you can actually input by typing C-k.
Editline::Autosuggest is a function for finding completion, and it is like Editline::TabCommand now, but I will add more features to it.
Testing does not work well in my environment, so I can't confirm that it goes well, sorry. I am dealing with it now.
Reviewed By: teemperor, JDevlieghere, #lldb
Differential Revision: https://reviews.llvm.org/D81001
expect_expr currently can't verify the children of the result SBValue.
This patch adds the ability to check them. The idea is to have a CheckValue
class where one can specify what attributes of a SBValue should be checked.
Beside the properties we already check for (summary, type, etc.) this also
has a list of children which is again just a list of CheckValue object (which
can also have children of their own).
The main motivation is to make checking the children no longer based
on error-prone substring checks that allow tests to pass just because
for example the error message contains the expected substrings by accident.
I also expect that we can just have a variant of `expect_expr` for LLDB's
expression paths (aka 'frame var') feature.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D83792
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
When loading a PE/COFF target, the associated PDB file often wasn't
found. The executable module contains a path for the associated PDB
file, but people often debug from a different directory than the one
their build system uses. (This is especially common in post-mortem
and cross platform debugging.)
Suppose the COFF executable being debugged is `~/proj/foo.exe`, but
it was built elsewhere and refers to `D:\remote\build\env\foobar.pdb`,
LLDB wouldn't find it.
With this change, if no file exists at the PDB path, LLDB will look
in the executable directory for a PDB file that matches the name of
the one it expected (e.g., `~/proj/foobar.pdb`). If found, the PDB
is subject to the same matching criteria (GUIDs and age) as would
have been used had it been in the original location.
This same-directory-as-the-binary rule is commonly used by debuggers
on Windows.
Differential Review: https://reviews.llvm.org/D84815
The current code fails when the first stderr line doesn't match the
given regex to parse the PID. This patch changes the code to read the
first 10 lines before giving up. It also adds tracing for the simctl
commands.
Separate the CMake logic for Lua and Python to clearly distinguish
between code specific to either scripting language and the code shared
by both.
What this patch does is:
- Move Python specific code into the bindings/python subdirectory.
- Move the Lua specific code into the bindings/lua subdirectory.
- Add the _python suffix to Python specific functions/targets.
- Fix a dependency issue that would check the binding instead of
whether the scripting language is enabled.
Note that this patch also changes where the bindings are generated,
which might affect downstream projects that check them in.
Differential revision: https://reviews.llvm.org/D85708
These definitions are needed by any file which uses gtest. Previously we
were adding them in the add_unittest function, but over time we've
accumulated libraries (which don't go through add_unittest) building on
gtest and this has resulted in proliferation of the definitions.
Making this a part of the library interface enables them to be managed
centrally. This follows a patch for -Wno-suggest-override (D84554) which
took a similar approach.
Differential Revision: https://reviews.llvm.org/D84748
Like the other type sugar removed by RemoveWrappingTypes, SubstTemplateTypeParm
is just pure sugar that should be ignored. If we don't ignore it (as we do now),
LLDB will fail to read values from record fields that have a
SubstTemplateTypeParm type.
Only way to produce such a type in LLDB is to either use the `import-std-module`
setting to get a template into the expression parser or just create your own
template directly in the expression parser which is what we do in the test.
Reviewed By: jarin
Differential Revision: https://reviews.llvm.org/D85132
1. Added a common completion WatchPointIDs to complete with a list of the IDs of the current watchpoints;
2. Applied the completion to these commands: watchpoint delete/enable/disable/modify/ignore;
3. Added a correlated test case.
Reviewed By: teemperor
Differential Revision: https://reviews.llvm.org/D84104
1. Added a common completion completing with a list of the threads of the current process;
2. Apply the common completion above to these commands: thread
continue/info/exception/select/step-in/step-inst/step-inst-over/step-out/step-over/step-script
3. Correlated test case test_common_completion_thread_index.
Reviewed By: teemperor
Differential Revision: https://reviews.llvm.org/D84088
1. Added a common completion StopHookIDs to provide completion with a list of stop hook ids;
2. Applied the common completion to commands: `target stop-hook delete/enable/disable';
3. Added an related test case.
Reviewed By: teemperor
Differential Revision: https://reviews.llvm.org/D84123
1. Added a common completion ModuleUUIDs to provide a list of the UUIDs of modules for completion;
2. Added a new enumeration item eArgTypeModuleUUID to CommandArgumentType which is set as the option argument type of OptionGroupUUID;
3. Applied the module UUID completion to the argument of the type eArgTypeModuleUUID in lldb/source/Interpreter/CommandObject.cpp;
4. Added an related test case in lldb/test/API/functionalities/completion/TestCompletion.py.
Commands frame select and thread backtrace -s can be completed in the same way.
Moved the dedicated completion of frame select into a common completion and
apply it to the both commands, along with the test modified.
Dedicated completion for the command `target modules search-paths insert` with a test case.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D83309
1. Added a new common completion TypeLanguages to provide a list of supporting languages;
2. Bound the completion to eArgTypeLanguage;
3. Added a related test case.
Dedicated completion for the command `thread plan discard` with a corresponding
test case.
Reviewed By: teemperor
Differential Revision: https://reviews.llvm.org/D83234
No one is calling this function it seems and according to
https://bugs.llvm.org/show_bug.cgi?id=47088 this can leak memory, so let's just
remove it:
Quote from the bug report:
> Before return on line 146, the memory allocated on line 130 is not freed.
Reviewed By: amccarth
Differential Revision: https://reviews.llvm.org/D85633
1.Added a new common completion DisassemblyFlavors;
2. Bound DisassemblyFlavors to argument of type eArgTypeDisassemblyFlavor in
CommandObject.cpp;
3. Added a related test case.
1. Applied the common completion `eVariablePathCompletion` to command
`watchpoint set variable`;
2. Added a related test case.
Reviewed By: teemperor, JDevlieghere
Differential Revision: https://reviews.llvm.org/D84177
1. Applied the common completion `eDiskFileCompletion` to the first argument of
the command `platform target-install`.
2. Added a related test case.
Reviewed By: teemperor
Differential Revision: https://reviews.llvm.org/D84179
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
We've been seeing this failure on green dragon when the system is
under high load. Unfortunately this is outside of LLDB's control.
Differential Revision: https://reviews.llvm.org/D85542
This patch stores the --apple-sdk argument in the dotest configuration.
When it's set, use it instead of the triple to determine the current
platform.
Differential revision: https://reviews.llvm.org/D85537
The implementation of these classes was copied & pasted from the
iPhone simulator plugin with only a handful of configuration
parameters substituted. This patch moves the redundant implementations
into the base class PlatformAppleSimulator.
Differential Revision: https://reviews.llvm.org/D85243
with how it is done for a lean binary
In particular this affects how target create --arch is handled — it
allowed us to override the deployment target (a useful feature for the
expression evaluator), but the fat binary case didn't.
rdar://problem/66024437
Differential Revision: https://reviews.llvm.org/D85049
(cherry picked from commit 470bdd3caaab0b6e0ffed4da304244be40b78668)
The code in ObjectFileMachO didn't disambiguate between ios and
ios-simulator object files for Mach-O objects using the legacy
ambiguous LC_VERSION_MIN load commands. This used to not matter before
taught ArchSpec that ios and ios-simulator are no longer compatible.
rdar://problem/66545307
Differential Revision: https://reviews.llvm.org/D85358
In order to be able to run the debugserver tests against the Rosetta
debugserver, detect the Rosetta run configuration and return the
system Rosetta debugserver.
wattr_get is a macro, and the documentation states:
"The parameter opts is reserved for future use,
applications must supply a null pointer."
In practice, passing a variable there is harmless, except
that it is unused inside the macro, which causes unused
variable warnings.
The various places where
GNU ld allows sections after a non-SHF_ALLOC section to be covered by PT_LOAD
(PR37607) and assigns addresses to non-SHF_ALLOC output sections (similar to
SHF_ALLOC NOBITS sections. The location counter is not advanced).
This patch tries to fix PR37607 (remove a special case in
`Writer<ELFT>::createPhdrs`). To make the created PT_LOAD meaningful, we cannot
reset dot to 0 for a middle non-SHF_ALLOC output section. This results in
removal of two special cases in LinkerScript::assignOffsets. Non-SHF_ALLOC
non-orphan sections can have non-zero addresses like in GNU ld.
The zero address rule for non-SHF_ALLOC sections is weakened to apply to orphan
only. This results in a special case in createSection and findOrphanPos, respectively.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D85100
Jonas Devlieghere