When running in an ipv6-only environment where `AF_INET` sockets are not available, many lldb tests (mostly gdb remote tests) fail because things like `127.0.0.1` don't work there.
Use `localhost` instead of `127.0.0.1` whenever possible, or include a fallback of creating `AF_INET6` sockets when `AF_INET` fails.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D87333
Rather than relaying on CMake to substitute the full path to the lldb
source root, use the value set in config.lldb_src_root. This makes it
slightly easier to write a custom lit.site.cfg.py.
The destructor must be defined in the implementation class so that it
can be called, as Vedant Kumar pointed out in:
'''
What were your thoughts, re:
+class Trace : public PluginInterface {
+public:
+ ~Trace() override = default;
Does this need to be `virtual ~Trace() = ...`?
Otherwise, when a std::shared_ptr<Trace> is destroyed, the
destructor for the derived TraceIntelPT instance won't run.
'''
The `macos-setup-codesign.sh` script has been in place for over two years. If there are no known issues, it's a good time to drop the manual steps from the docs.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D88257
This reverts commit f775fe5964.
I fixed a return type error in the original patch that was causing a test failure.
Also added a REQUIRES: python to the shell test so we'll skip this for
people who build lldb w/o Python.
Also added another test for the error printing.
Configuring the variable in CMake isn't enought, because the build mode
can't be resolved until execution time, which requires the build mode to
be substituted by lit.
Add the flag in ProcessMachCore::DoLoadCore that stops additional
searches for the binaries when we have an LC_NOTE identifying the
firmware/standalone binary as the correct one & we have loaded it
successfully.
This enables support for writing LLDB documentation in markdown in
addition to reStructured text. We already had documentation written in
markdown (StructuredDataPlugins and DarwinLog) which will now also be
available on the website.
With the recent patches to the ASTImporter that improve template type importing
(D87444), most of the import-std-module tests can now finally import the
type of the STL container they are testing. This patch removes most of the casts
that were added to simplify types to something the ASTImporter can import
(for example, std::vector<int>::size_type was casted to `size_t` until now).
Also adds the missing tests that require referencing the container type (for
example simply printing the whole container) as here we couldn't use a casting
workaround.
The only casts that remain are in the forward_list tests that reference
the iterator and the stack test. Both tests are still failing to import the
respective container type correctly (or crash while trying to import).
Usually when we enter a SWIG wrapper function from Python, SWIG automatically
adds a `Py_BEGIN_ALLOW_THREADS`/`Py_END_ALLOW_THREADS` around the call to the SB
API C++ function. This will ensure that Python's GIL is released when we enter
LLDB and locked again when we return to the wrapper code.
D51569 changed this behaviour but only for the generated `__str__` wrappers. The
added `nothreadallow` disables the injection of the GIL release/re-acquire code
and the GIL is now kept locked when entering LLDB and is expected to be still
locked when returning from the LLDB implementation. The main reason for that was
that back when D51569 landed the wrapper itself created a Python string. These
days it just creates a std::string and SWIG itself takes care of getting the GIL
and creating the Python string from the std::string, so that workaround isn't
necessary anymore.
This patch just removes `nothreadallow` so that our `__str__` functions now
behave like all other wrapper functions in that they release the GIL when
calling into the SB API implementation.
The motivation here is actually to work around another potential bug in LLDB.
When one calls into the LLDB SB API while holding the GIL and that call causes
LLDB to interpret some Python script via `ScriptInterpreterPython`, then the GIL
will be unlocked when the control flow returns from the SB API. In the case of
the `__str__` wrapper this would cause that the next call to a Python function
requiring the GIL would fail (as SWIG will not try to reacquire the GIL as it
isn't aware that LLDB removed it).
The reason for this unexpected GIL release seems to be a workaround for recent
Python versions:
```
// The only case we should go further and acquire the GIL: it is unlocked.
if (PyGILState_Check())
return;
```
The early-exit here causes `InitializePythonRAII::m_was_already_initialized` to
be always false and that causes that `InitializePythonRAII`'s destructor always
directly unlocks the GIL via `PyEval_SaveThread`. I'm investigating how to
properly fix this bug in a follow up patch, but for now this straightforward
patch seems to be enough to unblock my other patches (and it also has the
benefit of removing this workaround).
The test for this is just a simple test for `std::deque` which has a synthetic
child provider implemented as a Python script. Inspecting the deque object will
cause `expect_expr` to create a string error message by calling
`str(deque_object)`. Printing the ValueObject causes the Python script for the
synthetic children to execute which then triggers the bug described above where
the GIL ends up being unlocked.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D88302
RegInfoBasedABI::GetRegisterInfoByName was failing because mips/mips64 ABIs
don't use ConstString in their register info array.
Reviewed By: #lldb, teemperor
Differential Revision: https://reviews.llvm.org/D88375
When a Mach-O corefile has an LC_NOTE "main bin spec" for a
standalone binary / firmware, with only a UUID and no load
address, try to locate the binary and dSYM by UUID and if
found, load it at offset 0 for the user.
Add a test case that tests a firmware/standalone corefile
with both the "kern ver str" and "main bin spec" LC_NOTEs.
<rdar://problem/68193804>
Differential Revision: https://reviews.llvm.org/D88282
Every call to the protected SBAddress constructor and the SetAddress
method takes the address of a valid object which means we might as well
pass it as a const reference instead of a pointer and drop the null
check.
Differential revision: https://reviews.llvm.org/D88249
Recently https://reviews.llvm.org/D88103 introduced a nice API for
converting a JSON object into C++ types, which include nice error
messaging.
I'm using that new functioniality to perform the parsing in a much more
elegant way. As a result, the code looks simpler and more maintainable,
as we aren't parsing anymore individual fields manually.
I updated the test cases accordingly.
Differential Revision: https://reviews.llvm.org/D88264
The OS version field is generally not very helpful for non-Darwin
targets. On Linux, it identifies the kernel version which moves
out-of-sync with the userspace. On Windows, this field actually ends up
corresponding to the Visual Studio toolset version instead of the OS
version. Consider non-Darwin targets without an OS version to be fully
specified.
Differential Revision: https://reviews.llvm.org/D88181
Reviewed By: Jonas Devlieghere, Dave Lee
Translating between JSON objects and C++ strutctures is common.
From experience in clangd, fromJSON/ObjectMapper work well and save a lot of
code, but aren't adopted elsewhere at least partly due to total lack of error
reporting beyond "ok"/"bad".
The recently-added error model should be rich enough for most applications.
It requires tracking the path within the root object and reporting local
errors at appropriate places.
To do this, we exploit the fact that the call graph of recursive
parse functions mirror the structure of the JSON itself.
The current path is represented as a linked list of segments, each of which is
on the stack as a parameter. Concretely, fromJSON now looks like:
bool fromJSON(const Value&, T&, Path);
Beyond the signature change, this is reasonably unobtrusive: building
the path segments is mostly handled by ObjectMapper and the vector<T> fromJSON.
However the root caller of fromJSON must now create a Root object to
store the errors, which is a little clunky.
I've added high-level parse<T>(StringRef) -> Expected<T>, but it's not
general enough to be the primary interface I think (at least, not usable in
clangd).
All existing users (mostly just clangd) are updated in this patch,
making this change backwards-compatible is a bit hairy.
Differential Revision: https://reviews.llvm.org/D88103
The minidump-sysroot test I added in commit 20f84257 compares two paths
using a string comparison. This causes the Windows buildbot to fail
because of mismatched forward slashes and backslashes. Use
os.path.normcase to normalize before comparing.
Add an optimal thread strategy to execute specified amount of tasks.
This strategy should prevent us from creating too many threads if we
occasionaly have an unexpectedly small amount of tasks.
Differential Revision: https://reviews.llvm.org/D87765
When the various methods of locating the module in GetRemoteSharedModule
fail, make sure we pass the original module spec to the bail-out call to
the provided resolver function.
Also make sure we consistently use the resolved module spec from the
various success paths.
Thanks to what appears to have been an accidentally inverted condition
(commit 85967fa applied the new condition to a path where GetModuleSpec
returns false, but should have applied it when GetModuleSpec returns
true), without this fix we only pass the original module spec in the
fallback if the original spec has no uuid (or has a uuid that somehow
matches the resolved module's uuid despite the call to GetModuleSpec
failing). This manifested as a bug when processing a minidump file with
a user-provided sysroot, since in that case the resolver call was being
applied to resolved_module_spec (despite resolution failing), which did
not have the path of its file_spec set.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D88099
Clang has some type sugar that only serves as a way to preserve the way a user
has typed a certain type in the source code. These types are currently not
unwrapped when we query the type name for a Clang type, which means that this
type sugar actually influences what formatters are picked for a certain type.
Currently if a user decides to reference a type by doing `::GlobalDecl Var = 3;`,
the type formatter for `GlobalDecl` will not be used (as the type sugar
around the type gives it the name `::GlobalDecl`. The same goes for other ways
to spell out a type such as `auto` etc.
With this patch most of this type sugar gets stripped when the full type name is
calculated. Typedefs are not getting desugared as that seems counterproductive.
I also don't desugar atomic types as that's technically not type sugar.
Reviewed By: jarin
Differential Revision: https://reviews.llvm.org/D87481
There was a little thinko which meant when stopped in a frame with
debug information but whose CU didn't have any global variables we
report:
no debug info for frame <N>
This patch fixes that error message to say the intended:
no global variables in current compile unit
<rdar://problem/69086361>
This is the first in a series of patches that will adds a new processor trace plug-in to LLDB.
The idea for this first patch to to add the plug-in interface with simple commands for the trace files that can "load" and "dump" the trace information. We can test the functionality and ensure people are happy with the way things are done and how things are organized before moving on to adding more functionality.
Processor trace information can be view in a few different ways:
- post mortem where a trace is saved off that can be viewed later in the debugger
- gathered while a process is running and allow the user to step back in time (with no variables, memory or registers) to see how each thread arrived at where it is currently stopped.
This patch attempts to start with the first solution of loading a trace file after the fact. The idea is that we will use a JSON file to load the trace information. JSON allows us to specify information about the trace like:
- plug-in name in LLDB
- path to trace file
- shared library load information so we can re-create a target and symbolicate the information in the trace
- any other info that the trace plug-in will need to be able to successfully parse the trace information
- cpu type
- version info
- ???
A new "trace" command was added at the top level of the LLDB commmands:
- "trace load"
- "trace dump"
I did this because if we load trace information we don't need to have a process and we might end up creating a new target for the trace information that will become active. If anyone has any input on where this would be better suited, please let me know. Walter Erquinigo will end up filling in the Intel PT specific plug-in so that it works and is tested once we can agree that the direction of this patch is the correct one, so please feel free to chime in with ideas on comments!
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D85705
A few fixes while trying to figure out why tests are being skipped for arsenm:
- We check `$compiler -v`, but `-v` is `--verbose`, not `--version`. Use the long flag name.
- We check all lines matching `version ...`, but we should exit early for the first version string we see (which should be the main one). I'm not sure if this is the issue, but perhaps this is causing some users to skip some tests if another "version ..." is showing up later.
- Having `\.` in a python string is triggering pylint warnings, because it should be escaped as a regex string, e.g. `r'\.' However, `.` in a character class does not need to be escaped, as it matches only a literal `.` in that context.
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D88051
When we fixed ImportDeclContext(...) in D71378 to make sure we complete each
FieldDecl of a RecordDecl when we are importing the definition we missed the
case where a FeildDecl was an ArrayType whose ElementType is a record.
This fix was motivated by a codegen crash during LLDB expression parsing. Since
we were not importing the definition we were crashing during layout which
required all the records be defined.
Differential Revision: https://reviews.llvm.org/D86660
Update the some examples in the help string for `breakpoint command add`.
Python breakpoint commands have different output than what's shown in the help string.
Notes:
* Removed an example containing an inner function, as it seems more about a Python technique than about `command script add`
* Updated `print x` to `print(x)` to be python 2/3 agnostic
Differential Revision: https://reviews.llvm.org/D87807
This patch makes the include_directories, file_names and opcodes fields
of the line table optional. This helps us simplify some tests.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D87878
Previously, there was a little ambiguity about whether IsInlined should
return true for an inlined lexical block, since technically the lexical
block would not represent an inlined function (it'd just be contained
within one).
Edit suggested by Jim Ingham.
Previously when <addr> in "memory region <addr>" didn't
parse correctly, we'd print an error then also ask lldb-server
for a region containing LLDB_INVALID_ADDRESS.
(lldb) memory region not_an_address
error: invalid address argument "not_an_address"...
error: Server returned invalid range
Only send the command to lldb-server if the address
parsed correctly.
(lldb) memory region not_an_address
error: invalid address argument "not_an_address"...
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D87694
Register the `faulthandler` module so we can see what lldb tests are doing when they misbehave (e.g. run under a test runner that sets a timeout). This will print a stack trace for the following signals:
- `SIGSEGV`, `SIGFPE`, `SIGABRT`, `SIGBUS`, and `SIGILL` (via `faulthandler.enable()`)
- `SIGTERM` (via `faulthandler.register(SIGTERM)`) [This is what our test runners sends when it times out].
The only signal we currently handle is `SIGINT` (via `unittest2.signals.installHandler()`) so there should be no overlap added by this patch.
Because this import is not available until python3, and the `register()` method is not available on Windows, this is enabled defensively.
This should have absolutely no effect when tests are passing (or even normally failing), but can be observed by running this while ninja is running:
```
kill -s SIGTERM $(ps aux | grep dotest.py | head -1 | awk '{print $2}')
```
Reviewed By: JDevlieghere
Differential Revision: https://reviews.llvm.org/D87637
Perform all error handling in ReadCode()
Add :help text describing “< path”, add extra line before Commands
Differential Revision: https://reviews.llvm.org/D87640
Since "generic type" has a precise meaning in some languages, reword the docstring of `CompilerType` to avoid ambiguity.
Differential Revision: https://reviews.llvm.org/D87633
Code was added that used llvm error checking to parse .debug_aranges, but the error check after parsing the DWARFDebugArangesSet was reversed and was causing no error to be returned with no valid address ranges being actually used. This meant we always would fall back onto creating out own address ranges by parsing the compile unit's ranges. This was causing problems for cases where the DW_TAG_compile_unit had a single address range by using a DW_AT_low_pc and DW_AT_high_pc attribute pair (not using a DW_AT_ranges attribute), but the .debug_aranges had correct split ranges. In this case we would end up using the single range for the compile unit that encompassed all of the ranges from the .debug_aranges section and would cause address resolving issues in LLDB where address lookups would fail for certain addresses.
Differential Revision: https://reviews.llvm.org/D87626
Make it possible to run the script command with a different language
than currently selected.
$ ./bin/lldb -l python
(lldb) script -l lua
>>> io.stdout:write("Hello, World!\n")
Hello, World!
When passing the language option and a raw command, you need to separate
the flag from the script code with --.
$ ./bin/lldb -l python
(lldb) script -l lua -- io.stdout:write("Hello, World!\n")
Hello, World!
Differential revision: https://reviews.llvm.org/D86996
qemu calls the "fp" and "lr" registers via their generic names
(x29/x30). This mismatch manifested itself as not being able to unwind
or display values of some local variables.
In MinGW world, UNIX like lib prefix is preferred for the libraries.
This patch adjusts CMake files to do that.
Differential Revision: https://reviews.llvm.org/D87517
On macOS Big Sur the class descriptor contains the NSKVONotifying_
prefix. This is covered by TestDataFormatterObjCKVO.
Differential revision: https://reviews.llvm.org/D87545
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.
Jordan Rupprecht