It's not up to YAML to validate the semantics of the GDB remote packet
struct. This is especially wrong here as there's nothing that says that
the amount of bytes transmitted matches the packet payload size.
There is no clang::Action anymore so our forward decl for it and the obsolete pointer in the
ASTStructExtractor can both go (that code anyway didn't do anything).
Currently, there is no option to delete all the watchpoint without LLDB
asking for a confirmation. Besides making the watchpoint delete command
homogeneous with the breakpoint delete command, this option could also
become handy to trigger automated watchpoint deletion i.e. using
breakpoint actions.
rdar://42560586
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Use a status message to convey whether an optional dependency was found
or not. With the auto-detection code it's not longer as simple as
checking the CMake cache.
The current FOUND_VAR for FindLibEdit is libedit_FOUND but wasn't set by
find_package_handle_standard_args. However this isn't valid for the
package name.
The argument for FOUND_VAR is "libedit_FOUND", but only "LibEdit_FOUND" and
"LIBEDIT_FOUND" are valid names.
This fixes all the variables set by FindLibEdit to match the desired
naming scheme.
PYTHON_LIBRARIES is the canonical variable set by FindPythonLibs while
PYTHON_LIBRARY is an implementation detail. This replaces the uses of
the latter with the former.
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 restores 68a235d07f,
e6c7ed6d21. The problem with the windows
bot is a need for clearing the cache.
This reverts commit 68a235d07f.
This commit broke the clang-x64-windows-msvc build bot and a follow-up
commit did not fix it. Reverting to fix the bot.
Summary:
We currently don't set access specifiers for function template declarations. This seems to be fine
as long as the function template is not declared inside any record in which case Clang asserts
with the following once we try to query it's access:
```
Assertion failed: (Access != AS_none && "Access specifier is AS_none inside a record decl"), function AccessDeclContextSanity,
```
This patch just marks these function template declarations as public to make Clang happy.
Reviewers: shafik, teemperor
Reviewed By: teemperor
Subscribers: JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71909
LLDB frequently converts QualType to CompilerType. This is currently done like this:
result = CompilerType(this, qual_type_var.getAsOpaquePtr())
There are a few shortcomings in this current approach:
1. CompilerType's constructor takes a void* pointer so it isn't type safe.
2. We can't add any sanity checks to the CompilerType constructor (e.g. that the type
actually belongs to the passed ClangASTContext) without expanding the TypeSystem API.
3. The logic for converting QualType->CompilerType is spread out over all of LLDB so
changing it is difficult (e.g., what if we want to just pass the type ptr and not the
1type_ptr | qual_flags1 to CompilerType).
This patch adds a `ClangASTContext::GetType` function similar to the other GetTypeForDecl
functions that does this conversion in a type safe way.
It also adds a sanity check for Tag-based types that the type actually belongs to the
current ClangASTContext (Types don't seem to know their ASTContext, so we have to
workaround by looking at the decl for the underlying TagDecl. This doesn't cover all types
we construct but it's better than no sanity check).
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.
Now that we are building the python bindings on Windows once more, the
extended testsuite is running. Mark a few failing tests and skip a few
tests which hang. This should at least bring the bot back to green
without reverting the Python changes which are an improvement for the
build system and enable another ~35% of the test suite which was
previously disabled.
CompilerType has no virtual functions and no statements in its constructors,
so we can simplify this code. This also allows Clang to emit unused variable warnings
for CompilerType, so I also removed one unused variable that otherwise causes -Werror
builds to fail.
These functions need a ClangASTContext instance that we would otherwise
recalculate by calling GetASTContext (which is no longer necessary with
this patch).
We try to build a CompilerType from the persistent decls so we need
a ClangASTContext. With this patch the ClangPersistentVariables store
the associated ClangASTContext of the persistent decls (which is
always the scratch ClangASTContext) and no longer call GetASTContext
to map back from clang::ASTContext to ClangASTContext.
Instead of returning NamedDecls and then calling GetASTContext
to find back the ClangASTContext we used can just implement the
FindDecl variant that returns CompilerDecls (and implement the
other function by throwing away the ClangASTContext part of the
compiler decl).
This patch adds skipif decorator to TestWatchLocationWithWatchSet.py.
Decorator will trigger for aarch64-linux as this test passes randomly
causing buildbot failure.
The enumeration EntryType is used as a bit field of DebugMacroEntry:
```
EntryType m_type : 3
```
Since underlying type of enumeration is implementation-dependent, a signed integer is
converted to the 3-bit value by some compilers (MSVC).
That's why a DebugMacroEntry instance that was created with EntryType value > 3 (END_FILE or INDIRECT)
contains incorrect negative value in its m_type data-member.
This code actually needs a ClangASTContext but instead takes a
clang::ASTContext and then retrieves the original ClangASTContext
via the global map of ClangASTContexts. Let's change it so
that it takes a ClangASTContext which is simpler and faster.
GetASTContext is really expensive to call as it makes use of the global
mapping from ASTContext to ClangASTContext. This replaces all calls where
we already have the ClangASTContext around and don't need to call
GetASTContext again.
m_scratch_ast_source_up is only used by ClangASTContextForExpressions so it
should also be declared only in that class. Also make all other members of
ClangASTContext private and move the initialization code for ClangASTContextForExpressions
into the constructor.
ClangExternalASTSourceCommon's purpose is to store a map from
Decl*/Type* to ClangASTMetadata. Usually this data is accessed
via the ClangASTContext interface which then grabs the
current ExternalASTSource of its ASTContext, tries to cast it
to ClangExternalASTSourceCommon and then accesses the metadata
map. If the casting fails the setter does nothing and the getter
returns a nullptr as if there was no known metadata for a type/decl.
This system breaks as soon as any non-LLDB ExternalASTSource is added via
a multiplexer to our existing ExternalASTSource (in which case we suddenly
loose all out metadata as the casting always fails with an ExternalASTSource
that is not inheriting from ClangExternalASTSourceCommon).
This patch moves the metadata map to the ClangASTContext. This gets
rid of all the fragile casting, the requirement that every ExternalASTSource in
LLDB has to inherit from ClangExternalASTSourceCommon and simplifies
the metadata implementation to a simple map lookup. As ClangExternalASTSourceCommon
had no other purpose than storing metadata, this patch deletes this class
and replaces all uses with clang::ExternalASTSource.
No other code changes in this commit beside the AppleObjCDeclVendor which
was the only code that did not use the ClangASTContext interface but directly
accessed the ClangExternalASTSourceCommon.
Because this is a macro, previous values of `find_package` persist
between calls. This means that if it is set to TRUE on any run, all
subsequent runs will have find_package set to TRUE regardles of whether
or not they should be.
The test was being skipped on the Windwos bot because it requires Python
which was silently disabled because of a configuration issue. Now that
the test runs, this fails as expected.
This function is not very useful, as it's forcing a materialization of
the returned DIEs, and calling it is not substantially simpler than just
iterating over the DIEs manually. Delete it, and rewrite the single
caller.
This bit of code is trying to strip everything up to the first colon
from all debug info paths, as dwarf2 recommends this syntax for storing
the compilation host name. However, this code was too eager, and it
ended up stripping the entire compilation directory, if it did not
contain a forward slash (or a "x:\").
Normally this does not matter, as all absolute paths will contain one of
these patterns, but this does not have to be the case in case the debug
info is produced by "clang -fdebug-compilation-dir", which can end up
producing a relative compilation directory with no slashes (this is one
of the techniques for producing "relocatable" debug info).
This class is only used by the ClangASTContext so we might as well
simplify this whole logic by just passing a ClangASTContext instead
of a list of callbacks and a void* pointer. If we ever need this
to support other classes then we can define some interface that
ClangASTContext implements but for now this isn't needed.
I also removed any code for m_callback_find_by_name as this was
always a nullptr in LLDB and removed all overriden implementations
that just redefined the default no-op implementation that the
ExternalASTSource provides.
Also removed the assert.h workarounds.
This adds a check that the ClangASTContext actually fits to the
DeclContext that we want to create a CompilerDeclContext for. If
the ClangASTContext (and its associated ASTContext) does not fit
to the DeclContext (that is, the DeclContext wasn't created by the
ASTContext), all computations using this malformed CompilerDeclContext
will yield unpredictable results.
Also fixes the only place that actually hits this assert which is the
construction of a CompilerDeclContext in ClangExpressionDeclMap
where we pass an unrelated ASTContext instead of the ASTContext
of the current expression.
I had to revert my previous change to DWARFASTParserClangTests.cpp
back to using the unsafe direct construction of CompilerDeclContext
as this assert won't work if the DeclContext we pass isn't a valid
DeclContext in the first place.
Summary:
This code is handling debug info paths starting with /proc/self/cwd,
which is one of the mechanisms people use to obtain "relocatable" debug
info (the idea being that one starts the debugger with an appropriate
cwd and things "just work").
Instead of resolving the symlinks inside DWARFUnit, we can do the same
thing more elegantly by hooking into the existing Module path remapping
code. Since llvm::DWARFUnit does not support any similar functionality,
doing things this way is also a step towards unifying llvm and lldb
dwarf parsers.
Reviewers: JDevlieghere, aprantl, clayborg, jdoerfert
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71770
These two functions are just calling their equivalent function
in ASTContext and implicitly convert the result to a
DeclContext* (a parent class of TranslationUnitDecl). This leads
to the absurd situation that we had to cast the result of
GetTranslationUnitDecl to a TranslationUnitDecl*. The only reason
we did this implicit conversion to the parent class
was that the void* conversion for the CompilerDeclContext constructor
was sound (which otherwise would receive a Decl* pointer when
called with a TranslationUnitDecl*).
Now that the CompilerDeclContext constructor is type safe we can
properly implement these functions by actually returning the
right type. Also deletes the static inconvenience method that was
not used anywhere.
Summary:
Many of our tests need to initialize certain subsystems/plugins of LLDB such as
`FileSystem` or `HostInfo` by calling their static `Initialize` functions before the
test starts and then calling `::Terminate` after the test is done (in reverse order).
This adds a lot of error-prone boilerplate code to our testing code.
This patch adds a RAII called SubsystemRAII that ensures that we always call
::Initialize and then call ::Terminate after the test is done (and that the Terminate
calls are always in the reverse order of the ::Initialize calls). It also gets rid of
all of the boilerplate that we had for these calls.
Per-fixture initialization is still not very nice with this approach as it would
require some kind of static unique_ptr that gets manually assigned/reseted
from the gtest SetUpTestCase/TearDownTestCase functions. Because of that
I changed all per-fixture setup to now do per-test setup which can be done
by just having the SubsystemRAII as a member of the test fixture. This change doesn't
influence our normal test runtime as LIT anyway runs each test case separately
(and the Initialize/Terminate calls are anyway not very expensive). It will however
make running all tests in a single executable slightly slower.
Reviewers: labath, JDevlieghere, martong, espindola, shafik
Reviewed By: labath
Subscribers: mgorny, rnkovacs, emaste, MaskRay, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71630
The CompilerDeclContext constructor takes a void* pointer which
means that all callers of this constructor need to first explicitly
convert all pointers to clang::DeclContext*. This causes that we
for example can't just pass a TranslationUnitDecl* to the constructor without
first casting it to its parent class (as it inherits from both
Decl and DeclContext so the void* pointer is actually a Decl*).
This patch introduces a utility function in the ClangASTContext
which gets rid of the requirement to cast all pointers to
clang::DeclContext. Also moves all constructor calls to use this
function instead which is NFC (beside the change in
DWARFASTParserClangTests.cpp).
The `-r` option for `command script import` is there for legacy
compatibility, however the can_reload flag is always set to true. This
patch removes the flag and any code that relies on it being false.
The behaviour of `PYTHON_HOME` can be emulated by setting
`Python3_EXECUTABLE` to the absolute path instead of the custom variable
now that we can find the python interpreter.
Require a newer CMake on Windows to use the Python3 support that is
packaged in CMake. This version is able to check both 32-bit and 64-bit
versions and will setup everything properly without the user needing to
specify PYTHON_HOME. This enables building lldb's python bindings on
Windows under Azure's CI again.
Previously, SWIG was only a hard dependency if python bindings were
enabled.
Since bf03e17c57, scripts/CMakeLists.txt
is included unconditionally, while that file adds the hard dependency
on SWIG.
Instead, only include that file if either python or lua bindings are
enabled.
This ensures that watchpoint command honors the scripting language
passed with `-s`. Currently the argument ignores the actual language and
only uses it to differentiate between lldb and script commands.
- Fix enum entry order.
- Fix missing enum case in CommandObjectBreakpointCommand.
- Add Lua entry to swtich in LanguageToString and simplify the code.
This ensures that breakpoint command honors the scripting language
passed with `-s`. Currently the argument ignores the actual language and
only uses it to differentiate between lldb and script commands.
Rather than holding on to one script interpreter, it should be possible
to request a script interpreter for a specific scripting language. The
GetScriptInterpreter method now takes an optional scripting language
argument.
(NFC)
Don't create a new lua state on every operation. Share a single state
across the lifetime of the script interpreter. Add simple locking to
prevent two threads from modifying the state concurrently.
ClangASTContext::getASTContext() currently returns a ptr but we have an assert there since a
while that the ASTContext is not a nullptr. This causes that we still have a lot of code
that is doing nullptr checks on the result of getASTContext() which is all unreachable code.
This patch changes the return value to a reference to make it clear this can't be a nullptr
and deletes all the nullptr checks.
Their naming is misleading as they only return the
ClangASTContext-owned variables. For ClangASTContext instances constructed
for a given clang::ASTContext they silently generated duplicated instances
(e.g., a second IdentifierTable) that were essentially unusable.
This removes all these getters as they are anyway not very useful in comparison
to just calling the clang::ASTContext getters. The initialization
code has been moved to the CreateASTContext initialization method so that all
code for making our own clang::ASTContext is in one place.
D71372 introduced: `Unwind/thread-step-out-ret-addr-check.test` failing on
Fedora 30 Linux x86_64.
[lldb] Add additional validation on return address in 'thread step-out'
https://reviews.llvm.org/D71372
One problem is the underscored `_nonstandard_stub` in the `.s` file but not in
the LLDB command:
(lldb) breakpoint set -n nonstandard_stub
Breakpoint 1: no locations (pending).
WARNING: Unable to resolve breakpoint to any actual locations.
(lldb) process launch
Process 21919 exited with status = 0 (0x00000000)
Process 21919 launched: '/home/jkratoch/redhat/llvm-monorepo-clangassert/tools/lldb/test/Unwind/Output/thread-step-out-ret-addr-check.test.tmp' (x86_64)
(lldb) thread step-out
error: invalid thread
(lldb) _
Another problem is that Fedora Linux has executable stack by default and all
programs indicate non-executable stack by `PT_GNU_STACK`, after fixing the
underscore I was getting:
(lldb) thread step-out
Process 22294 exited with status = 0 (0x00000000)
(lldb) _
A different approach was tried as:
[lldb] Refactor thread-step-out-ret-addr-check test to use .data instead of stack variable
https://reviews.llvm.org/D71789
Differential revision: https://reviews.llvm.org/D71784
echo -e '#include <unistd.h>\nint main(void){\nsync();return 0;}'|./bin/clang -g -x c -;./bin/lldb -o 'file ./a.out' -o 'b main' -o r -o 'p (void)sync()'
Actual:
error: Expression can't be run, because there is no JIT compiled function
Expected:
<nothing, sync() has been executed>
This patch has been checked by:
D71707: clang-tidy: new bugprone-pointer-cast-widening
https://reviews.llvm.org/D71707
Casting from 32-bit `void *` to `uint64_t` requires an intermediate `uintptr_t` cast otherwise the pointer gets sign-extended:
echo -e '#include <stdio.h>\n#include <stdint.h>\nint main(void){void *p=(void *)0x80000000;unsigned long long ull=(unsigned long long)p;unsigned long long ull2=(unsigned long
long)(uintptr_t)p;printf("p=%p ull=0x%llx ull2=0x%llx\\n",p,ull,ull2);return 0;}'|gcc -Wall -m32 -x c -;./a.out
<stdin>: In function ‘main’:
<stdin>:3:66: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
p=0x80000000 ull=0xffffffff80000000 ull2=0x80000000
With debug output:
Actual:
IRMemoryMap::WriteMemory (0xb6ff8640, 0xffffffffb6f82158, 0x112) went to [0xb6ff8640..0xb6ff86b3)
Code can be run in the target.
Found function, has local address 0xffffffffb6f84000 and remote address 0xffffffffffffffff
Couldn't disassemble function : Couldn't find code range for function _Z12$__lldb_exprPv
Sections:
[0xb6f84000+0x3c]->0xb6ff9020 (alignment 4, section ID 0, name .text)
...
HandleCommand, command did not succeed
error: Expression can't be run, because there is no JIT compiled function
Expected:
IRMemoryMap::WriteMemory (0xb6ff8640, 0xb6faa15c, 0x128) went to [0xb6ff8640..0xb6ff86c3)
IRExecutionUnit::GetRemoteAddressForLocal() found 0xb6fac000 in [0xb6fac000..0xb6fac040], and returned 0xb6ff9020 from [0xb6ff9020..0xb6ff9060].
Code can be run in the target.
Found function, has local address 0xb6fac000 and remote address 0xb6ff9020
Function's code range is [0xb6ff9020+0x40]
...
Function data has contents:
0xb6ff9020: 10 4c 2d e9 08 b0 8d e2 08 d0 4d e2 00 40 a0 e1
...
Function disassembly:
0xb6ff9020: 0xe92d4c10 push {r4, r10, r11, lr}
Differential revision: https://reviews.llvm.org/D71498
> A macro is executed as if the macro body were pasted in place of the
> calling statement. This has the consequence that a return() in a macro
> body does not just terminate execution of the macro
After converting from a function() to a macro(), the return() became
invalid. This modifies the control flow to elude the return.
Recently there has been some discussion about how we deal with optional
dependencies in LLDB. The approach in LLVM is to make things work out of
the box. If the dependency isn't there, we move on silently.
That's not true for LLDB. Unless you explicitly disable the dependency
with LLDB_ENABLE_*, you'll get a configuration-time error. The
historical reason for this is that LLDB's dependencies have a much
broader impact, think about Python for example which is required to run
the test suite.
The current approach can be frustrating from a user experience
perspective. Sometimes you just want to ensure LLDB builds with a change
in clang.
This patch changes the optional dependencies (with the exception of
Python) to a new scheme. The LLDB_ENABLE_* now takes three values: On,
Off or Auto, with the latter being the default. On and Off behave the
same as today, forcing the dependency to be enabled or disabled. If the
dependency is set to On but is not found, it results in a configuration
time warning. For Auto we detect if the dependency is there and either
enable or disable it depending on whether it's found.
Differential revision: https://reviews.llvm.org/D71306
PS: The reason Python isn't included yet is because it's so pervasive
that I plan on doing that in a separate patch.
Recently there has been some discussion about how we deal with optional
dependencies in LLDB. The approach in LLVM is to make things work out of
the box. If the dependency isn't there, we move on silently.
That's not true for LLDB. Unless you explicitly disable the dependency
with LLDB_ENABLE_*, you'll get a configuration-time error. The
historical reason for this is that LLDB's dependencies have a much
broader impact, think about Python for example which is required to run
the test suite.
The current approach can be frustrating from a user experience
perspective. Sometimes you just want to ensure LLDB builds with a change
in clang.
This patch changes the optional dependencies (with the exception of
Python) to a new scheme. The LLDB_ENABLE_* now takes three values: On,
Off or Auto, with the latter being the default. On and Off behave the
same as today, forcing the dependency to be enabled or disabled. If the
dependency is set to On but is not found, it results in a configuration
time warning. For Auto we detect if the dependency is there and either
enable or disable it depending on whether it's found.
Differential revision: https://reviews.llvm.org/D71306
PS: The reason Python isn't included yet is because it's so pervasive
that I plan on doing that in a separate patch.
This is a purely cosmetic change that is NFC in terms of the binary
output. I bugs me that I called the attribute DW_AT_LLVM_isysroot
since the "i" is an artifact of GCC command line option syntax
(-isysroot is in the category of -i options) and doesn't carry any
useful information otherwise.
This attribute only appears in Clang module debug info.
Differential Revision: https://reviews.llvm.org/D71722
This implements a very elementary Lua script interpreter. It supports
running a single command as well as running interactively. It uses
editline if available. It's still missing a bunch of stuff though. Some
things that I intentionally ingored for now are that I/O isn't properly
hooked up (so every print goes to stdout) and the non-editline support
which is not handling a bunch of corner cases. The latter is a matter of
reusing existing code in the Python interpreter.
Discussion on the mailing list:
http://lists.llvm.org/pipermail/lldb-dev/2019-December/015812.html
Differential revision: https://reviews.llvm.org/D71234
Previously, if the current function had a nonstandard stack layout/ABI, and had a valid
data pointer in the location where the return address is usually located, data corruption
would occur when the breakpoint was written. This could lead to an incorrectly reported
crash or silent corruption of the program's state. Now, if the above check fails, the command safely aborts.
Differential Revision: https://reviews.llvm.org/D71372
TracingStarted gets called in the Thread constructor, which means you can't
call a virtual method of the class. So delay setting up the m_register_values
till you need them. NFC as lldb just crashes if you don't do this.
The thread tracing is an only occasionally useful feature, and it only sort
of works. I'm not adding tests etc. at this point, I'm just poking at it a
bit. If I get it working better I'll write tests and so forth.
We already pass a Decl here and the additional ASTContext needs to
match the Decl. We might as well just pass the Decl and then extract
the ASTContext from that.
In some environments (typically, buildbots), this variable may not be
available. This can cause tests to behave differently.
Explicitly set the variable to "vt100" to ensure consistent test
behavior. It should not matter that we do not inherit the process TERM
variable, as the child process runs in a new virtual terminal anyway.
Summary:
HostInfo's state isn't actually fully rested after calling ::Terminate. Currently we only reset the
values of all the `HostInfoBaseFields` but not all the variables with static storage that
keep track of whether the fields need to be initialised. This breaks random unit tests as running
them twice (or running multiple test instances in one run) will cause that the second time
we ask HostInfo for any information we get the default value back for any field.
This patch moves all the once_flag's into the `HostInfoBaseFields` so that they also get reseted
by ::Terminate and removes all the `success` bools. We should also rewrite half this code but
I would prefer if my tests aren't broken over the holidays so let's just put some duct tape on it
for now.
Reviewers: labath
Reviewed By: labath
Subscribers: abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71748
Summary:
Fixes PR41237 - SIGSEGV on call expression evaluation when debugging clang
When linking multiple compilation units that define the same functions,
the functions is merged but their debug info is not. This ignores debug
info entries for functions in a non-executable sections; those are
functions that were definitely dropped by the linker.
Reviewers: spyffe, clayborg, jasonmolenda
Reviewed By: clayborg
Subscribers: labath, aprantl, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71487
This fix was motivated by a crashes in expression parsing during code generation in which we had a RecordDecl that had incomplete FieldDecl. During code generation when computing the layout for the RecordDecl we crash because we have several incomplete FieldDecl.
This fixes the issue by assuring that during ImportDefinition(...) for a RecordDecl we also import the definitions for each FieldDecl.
Differential Revision: https://reviews.llvm.org/D71378
The "none" script interpreter does not depend on Python so it doesn't
make sense to have it withing the if-block. The only goal seems to be to
have a slightly different error for when there's no script interpreter,
but as per the comment this doesn't make sense for more than one
scripting language. I think the existing error is perfectly clear, so I
just removed this altogether.
This error message didn't specify which file was malformed, so
there's some hunting-around required if it comes up. We have the
filename; include it in the error message.
Create a new test for lldb launched without a script interpreter and
move it under a new `ScriptInterpreter` directory. Also move
crashlog.test there for consistency.
Remove the hack that populates the cpsr register in the gpr struct by
writing past the end of the array. This was tripping up ASan.
Patch by: Reva Cuthbertson
This adds a unit test for looking up persistent declarations in the scratch AST
context. Also adds the `GetPersistentDecl` hook to the ClangExpressionDeclMap
that this unit test can emulate looking up persistent variables without having
a lldb_private::Target.
The ClangExpressionDeclMap should be testable from a unit test. This is currently
impossible as they have both dependencies on Target/ExecutionContext from their
constructor. This patch allows constructing these classes without an active Target
and adds the missing tests for running without a target that we can do at least
a basic lookup test without crashing.
Summary:
As discussed on the mailing list [1] we have to make a decision for how to proceed with the modern-type-lookup.
This patch removes modern-type-lookup from LLDB. This just removes all the code behind the modern-type-lookup
setting but it does *not* remove any code from Clang (i.e., the ExternalASTMerger and the clang-import-test stay around
for now).
The motivation for this is that I don't think that the current approach of implementing modern-type-lookup
will work out. Especially creating a completely new lookup system behind some setting that is never turned on by anyone
and then one day make one big switch to the new system seems wrong. It doesn't fit into the way LLVM is developed and has
so far made the transition work much more complicated than it has to be.
A lot of the benefits that were supposed to come with the modern-type-lookup are related to having a better organization
in the way types move across LLDB and having less dependencies on unrelated LLDB code. By just looking at the current code (mostly
the ClangASTImporter) I think we can reach the same goals by just incrementally cleaning up, documenting, refactoring
and actually testing the existing code we have.
[1] http://lists.llvm.org/pipermail/lldb-dev/2019-December/015831.html
Reviewers: shafik, martong
Subscribers: rnkovacs, christof, arphaman, JDevlieghere, usaxena95, lldb-commits, friss
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71562
Those functions have the same semantics beside some small optimization of not creating
a new empty ASTContextMetadataSP value in the metadata map. We never actually hit this
optimization according to test coverage so let's just call GetDeclOrigin instead.
Summary:
D69991 introduced `__attribute__((objc_direct))` that allows directly calling methods without message passing.
This patch adds support for calling methods with this attribute to LLDB's expression evaluator.
The patch can be summarised in that LLDB just adds the same attribute to our module AST when we find a
method with `__attribute__((objc_direct))` in our debug information.
Reviewers: aprantl, shafik
Reviewed By: shafik
Subscribers: JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71196
If you don't do this you end up running arbitrary code with
only one thread allowed to run, which can cause deadlocks.
<rdar://problem/56422478>
Differential Revision: https://reviews.llvm.org/D71440
If you set LLDB_TABLEGEN_EXE in a CMake cache file or in the CMake
invocation line, your setting isn't respected. Setting up the tablegen
for the host will overwrite the value that we set LLDB_TABLEGEN_EXE to,
which defeats the whole point of setting it in the first place.
The overloads that don't take a CompilerType serve no purpose as we
always have a CompilerType in the scope where we call them. Instead
just call the overload that takes a CompilerType and delete the
now unused other overloaded methods.
Summary:
These types were handled in some places, but not others. This resulted
in (for example) not being able to display members of structs whose
types were defined using these constructs.
Using getLocallyUnqualifiedSingleStepDesugaredType for these types is
not fully equivalent, as it will only desugar them if the types are not
instantiation-dependent, whereas previously we did that unconditionally.
It's not clear to me which behavior is correct here, but the test suite
does not seem to care either way.
Reviewers: teemperor, shafik
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71405
Changing metadata of a ClangASTContext currently requires to include
the unrelated ClangExternalASTSourceCommon.h header because it actually defines
the ClangASTMetadata class.
This also removes the dependency from ClangASTImporter to ClangExternalASTSourceCommon.
Summary: This removes most of unnecessary includes in the `source/Commands` directory. This was generated by IWYU and a script that fixed all the bogus reports from IWYU. Patch is tested on Linux and macOS.
Reviewers: JDevlieghere
Reviewed By: JDevlieghere
Subscribers: krytarowski, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71489
We have several pointer->pointer mappings in the ClangASTImporter implemented using
STL data structures. This moves these variables to the appropriate LLVM data structures
that are intended for mapping pointers.
Summary:
Currently we do our RTTI check for ClangExternalASTSourceCommon by using this global map of
ClangExternalASTSourceCommon where every instance is registering and deregistering itself
on creation/destruction. Then we can do the RTTI check by looking up in this map from ClangASTContext.
This patch removes this whole thing and just adds LLVM-style RTTI support to ClangExternalASTSourceCommon
which is possible with D71397.
Reviewers: labath, aprantl
Reviewed By: labath
Subscribers: JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71398
Summary:
Right now, NSException::GetSummary() has the following output:
"name: $exception_name - reason: $exception_reason"
It would be better to simplify the output by removing the name and only
showing the exception's reason. This way, annotations would look nicer in
the editor, and would be a shorter summary in the Variables Inspector.
Accessing the exception's name can still be done by expanding the
NSException object in the Variables Inspector.
rdar://54770115
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71311
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Summary:
A lot of our tests copied the setUp code from our TestSampleTest.py:
```
def setUp(self):
# Call super's setUp().
TestBase.setUp(self)
```
This code does nothing unless we actually do any setUp work in there, so let's remove all these method definitions.
Reviewers: labath, JDevlieghere
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71454
Summary:
A lot of tests do this trick but the vast majority of them don't even call `print()`.
Most of this patch was generated by a script that just looks at all the files and deletes the line if there is no `print (` or `print(` anywhere else in the file.
I checked the remaining tests manually and deleted the import if we never call print (but instead do stuff like `expr print(...)` and similar false-positives).
I also corrected the additional empty lines after the import in the files that I manually edited.
Reviewers: JDevlieghere, labath, jfb
Reviewed By: labath
Subscribers: dexonsmith, wuzish, nemanjai, kbarton, christof, arphaman, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71452
Summary:
LLDB associates additional information with Types and Declarations which it calls ClangASTMetadata.
ClangASTMetadata is stored by the ClangASTSourceCommon which is implemented by having a large map of
`void *` keys to associated `ClangASTMetadata` values. To make this whole mechanism even unsafer
we also decided to use `clang::Decl *` as one of pointers we throw in there (beside `clang::Type *`).
The Decl class hierarchy uses multiple inheritance which means that not all pointers have the
same address when they are implicitly converted to pointers of their parent classes. For example
`clang::Decl *` and `clang::DeclContext *` won't end up being the same address when they
are implicitly converted from one of the many Decl-subclasses that inherit from both.
As we use the addresses as the keys in our Metadata map, this means that any implicit type
conversions to parent classes (or anything else that changes the addresses) will break our metadata tracking
in obscure ways.
Just to illustrate how broken this whole mechanism currently is:
```lang=cpp
// m_ast is our ClangASTContext. Let's double check that from GetTranslationUnitDecl
// in ClangASTContext and ASTContext return the same thing (one method just calls the other).
assert(m_ast->GetTranslationUnitDecl() == m_ast->getASTContext()->getTranslationUnitDecl());
// Ok, both methods have the same TU*. Let's store metadata with the result of one method call.
m_ast->SetMetadataAsUserID(m_ast->GetTranslationUnitDecl(), 1234U);
// Retrieve the same Metadata for the TU by using the TU* from the other method... which fails?
EXPECT_EQ(m_ast->GetMetadata(m_ast->getASTContext()->getTranslationUnitDecl())->GetUserID(), 1234U);
// Turns out that getTranslationUnitDecl one time returns a TranslationUnitDecl* but the other time
// we return one of the parent classes of TranslationUnitDecl (DeclContext).
```
This patch splits up the `void *` API into two where one does the `clang::Type *` tracking and one the `clang::Decl *` mapping.
Type and Decl are disjoint class hierarchies so there is no implicit conversion possible that could influence
the address values.
I had to change the storing of `clang::QualType` opaque pointers to their `clang::Type *` equivalents as
opaque pointers are already `void *` pointers to begin with. We don't seem to ever set any qualifier in any of these
QualTypes to this conversion should be NFC.
Reviewers: labath, shafik, aprantl
Reviewed By: labath
Subscribers: JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71409
At least one lldb bot still uses this cmake variable instead of
LLDB_ENABLE_CURSES. Add code to set the default value of the "enable"
variable based on the old value of the "disable" setting.
This should bring those bots back up, until we can update the master to
use the new setting.
Target doesn't really need to know about ClangASTContext more than any
other TypeSystem. We can create a method ClangASTContext::GetScratch for
anything who needs a ClangASTContext specifically instead of just a
generic TypeSystem.
The initialization was accidentally lost in https://reviews.llvm.org/D71310, causing a ubsan failure:
/Users/buildslave/jenkins/workspace/lldb-cmake-sanitized/llvm-project/lldb/include/lldb/DataFormatters/TypeCategory.h:278:35: runtime error: load of value 190, which is not a valid value for type 'bool'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /Users/buildslave/jenkins/workspace/lldb-cmake-sanitized/llvm-project/lldb/include/lldb/DataFormatters/TypeCategory.h:278:35 in
http://lab.llvm.org:8080/green/view/LLDB/job/lldb-cmake-sanitized/621/consoleText
Summary:
Add `function.mangled-name` key for FormatEntity to show the mangled
function names in backtraces.
rdar://54088244
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71237
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
This renames LLDB_CONFIG_TERMIOS_SUPPORTED to LLDB_ENABLE_TERMIOS. It
now also uses cmakedefine01 to keep things consistent with out other
optional dependencies. But more importantly it won't silently fail when
you forget to include Config.h.
Summary: Not once have I looked at these numbers in a log and considered them useful. Also this should not have been implemented via an unguarded list of globals.
Reviewers: martong, shafik
Reviewed By: shafik
Subscribers: rnkovacs, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71336
Summary:
This enables us to display the contents of atomic structs. Calling the
removal of _Atomic "desugaring" is not fully correct as it does more
than remove sugar, but it is the right thing to do for most of the
things that we care about. We can change this back once we decide to
support atomic types more comprehensively.
Reviewers: teemperor, shafik
Subscribers: jfb, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71262
Centralize the logic to determine what libraries to link against for
curses in the CMake file where it is actually being used. Use
target_include_directories instead of include_directories.
Summary: The test logic for running libc++ tests only looks to see if `/usr/include/c++/v1` exists. This adds a fallback for including libc++ tests as long as `$(CC) -stdlib=libc++` works.
Reviewers: labath, EricWF
Subscribers: ldionne, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71319
I don't think this test case can be handled correctly on AAPCS64.
The ABI says that the caller passes the address of the return object
in x8. x8 is a caller-spilled (aka "volatile") register, and the
function is not required to preserve x8 or to copy the address back
into x8 on function exit like the SysV x86_64 ABI does with rax.
(from aapcs64: "there is no requirement for the callee to preserve the
value stored in x8")
From my quick reading of ABISysV_arm64, I worry that it may actually be
using the value in x8 at function exit, assuming it still has the
address of the return object -
if (is_return_value) {
// We are assuming we are decoding this immediately after returning from
// a function call and that the address of the structure is in x8
reg_info = reg_ctx->GetRegisterInfoByName("x8", 0);
This will work on trivial test programs / examples, but if the function
does another function call, or overwrites x8 as a scratch register, lldb
will provide incorrect values to the user.
ABIMacOSX_arm64 doesn't do this, but it also doesn't flag the value
as unavailable so we're providing incorrect values to the user all
the time. I expect my fix will be to make ABIMacOSX_arm64 flag
the return value as unretrievable, unless I've misread the ABI.
This is a half-implemented feature that as far as we can tell was
never used by anything since its original inclusion in 2014. This
patch removes it to make remaining the code easier to understand.
Differential Revision: https://reviews.llvm.org/D71310
HasMetadata checks if our metadata map knows the given object. GetMetadata
also does this check and then does another search to actually retrieve
the value. This can all just be one lookup.
Summary:
This adds support for DWARF5 location lists which are specified
indirectly, via an index into the debug_loclists offset table. This
includes parsing the DW_AT_loclists_base attribute which determines the
location of this offset table, and support for new form DW_FORM_loclistx
which is used in conjuction with DW_AT_location to refer to the location
lists in this way.
The code uses the llvm class to parse the offset information, and I've
also tried to structure it similarly to how the relevant llvm
functionality works.
Reviewers: JDevlieghere, aprantl, clayborg
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71268
of depending on it being set in the environment. Fred's change
from October assumed that SDKROOT was set in the environment
so that 'xcrun --show-sdk-path' would print the path. If it
was passed in as a Makefile variable, it wouldn't be set in
the environment and xcrun --show-sdk-path would always show the
macOS SDK path. When running the lldb testsuite against an ios
device via lit, this seems to be the case.
This refactoring makes the lookup caching easier to reason about. This
has no observable effect although it does slightly change what is
being cached.
- Before this patch a negative lookup in the LanguageCategory would be
cached, but a positive wouldn't.
- After this patch LanguageCategory lookups aren't cached by
FormatManager, period. (LanguageCategory has its own FormatCache for this!)
Differential Revision: https://reviews.llvm.org/D71289
The cache in FormatCache uses only a type name as key. The hardcoded
formats, synthetic children, etc inspect an entire ValueObject to
determine their eligibility, which isn't modelled in the cache. This
leads to bugs such as the one in this patch (where two similarly named
types in different files have different hardcoded summary
providers). The problem is exaggerated in the Swift language plugin
due to the language's dynamic nature.
rdar://problem/57756763
Differential Revision: https://reviews.llvm.org/D71233
As suggested by Pavel in a code review:
> Can we replace this (and maybe python too, while at it) with a
> Host/Config.h entry? A global definition means that one has to
> recompile everything when these change in any way, whereas in
> practice only a handful of files need this..
Differential revision: https://reviews.llvm.org/D71280
When running the test suite with always capture on, a handful of tests
are failing because they have multiple targets and therefore multiple
GDB remote connections. The current reproducer infrastructure is capable
of dealing with that.
This patch reworks the GDB remote provider to support multiple GDB
remote connections, similar to how the reproducers support shadowing
multiple command interpreter inputs. The provider now keeps a list of
packet recorders which deal with a single GDB remote connection. During
replay we rely on the order of creation to match the number of packets
to the GDB remote connection.
Differential revision: https://reviews.llvm.org/D71105
This is a preparatory patch for an upcoming bugfix.
FormatManager and friends have four identical implementations of many
accessor functions to deal with the four types of shared pointers in
the FormatCache. This patch replaces these implementations with
templates. While this patch drastically reduces the amount of source
code and its maintainablity, it doesn't actually improve code
size. I'd argue, this is still an improvement.
rdar://problem/57756763
Differential Revision: https://reviews.llvm.org/D71231
Summary:
Our Editline implementation in LLDB supports using the wchar interface of Editline which
should improve handling of unicode input when using Editline. At the moment we essentially
just ignore unicode input and echo the escaped unicode code point (`\U1234`) to the command line
(which we then also incorrectly treat as multiple characters, so console navigation is also broken afterwards).
This patch just adds the include to the host config file which already contains the LLDB_EDITLINE_USE_WCHAR
define to enable the Editline support (we just never included it in the file before). With this we now actually
echo back unicode characters on macOS and we no longer ignore unicode input. On Linux this doesn't
seem to improve the echoing back of characters but at least it fixes that we ignore unicode input.
Reviewers: labath
Reviewed By: labath
Subscribers: JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71251
Summary:
A *lot* of ClangASTContext functions contained repetitive code for
"desugaring" certain kinds of clang types. This patch creates a utility
function for performing this task.
Right now it handles four types (auto, elaborated, paren and typedef),
as these are the types that were handled everywhere. There are probably
other kinds of types that could/should be added here too (TypeOf,
decltype, ...), but I'm leaving that for a separate patch as doing that
would not be NFC (though I'm pretty sure that adding them will not hurt,
and it may in fact fix some bugs).
In another patch I'd like to add "atomic" type to this list to properly
display atomic structs.
Since sometimes one may want to handle a certain kind of type specially
(right now we have code which does that with typedefs), the Desugar
function takes a "mask" argument, which can supress desugaring of
certain kinds of types.
Reviewers: teemperor, shafik
Subscribers: jfb, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71212
If not set, the address byte size was implied to be the one of the
host process.
This allows reverting the functional change from 31087b2ae9154, since
now PECOFF does the same as ELF and MachO wrt setting both byte order
and address size on m_data within ParseHeader.
Differential Revision: https://reviews.llvm.org/D71108
"The debug adapter supports the delayed loading of parts of the stack,
which requires that both the 'startFrame' and 'levels' arguments and the
'totalFrames' result of the 'StackTrace' request are supported."
Lack of this field makes VSCode incorrectly display stack traces information
D71034
This test was accidentally passing on non-darwin OS because it was
explicitly setting the CFLAGS make variable. This meant that (in the
default config) it was building with absolutely no debug info, and so
setting a breakpoint on a stripped symbol failed, because there was
really no trace of it remaining. In other configurations, we were
generating the debug info (-gsplit-dwarf implies -g) and the test failed
because we did not treat the zeroed out debug info address specially.
The test was also xfailed in pretty much every non-standard
configuration.
This patch fixes the makefile to avoid messing with CFLAGS (use
CFLAGS_EXTRAS instead). This causes it to fail in all configurations
(except darwin), and so I replace the various decorators with a simple
os!=darwin check.
Guard the Python type map in SBTarget by the SWIGPYTHON define to
ensures the rest of the interface can be reused for other languages
supported by SWIG.
Summary:
This patch deletes the lldb location list parser and teaches the
DWARFExpression class to use the parser in llvm instead. I have
centralized all the places doing the parsing into a single
GetLocationExpression function.
In theory the the actual location list parsing should be covered by llvm
tests, and this glue code by our existing location list tests, but since
we don't have that many location list tests, I've tried to extend the
coverage a bit by adding some explicit dwarf5 loclist handling and a
test of the dumping code.
For DWARF4 location lists this should be NFC (modulo small differences
in error handling which should only show up on invalid inputs). In case
of DWARF5, this fixes various missing bits of functionality, most
notably, the lack of support for DW_LLE_offset_pair.
Reviewers: JDevlieghere, aprantl, clayborg
Subscribers: lldb-commits, dblaikie
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71003
Summary:
Lldb support base address selection entries in location lists was broken
for a long time. This wasn't noticed until llvm started producing these
kinds of entries more frequently with r374600.
In r374769, I made a quick patch which added sufficient support for them
to get the test suite to pass. However, I did not fully understand how
this code operates, and so the fix was not complete. Specifically, what
was lacking was the ability to handle modules which were not loaded at
their preferred load address (for instance, due to ASLR).
Now that I better understand how this code works, I've come to the
conclusion that the current setup does not provide enough information
to correctly process these entries. In the current setup the location
lists were parameterized by two addresses:
- the distance of the function start from the start of the compile unit.
The purpose of this was to make the location ranges relative to the
start of the function.
- the actual address where the function was loaded at. With this the
function-start-relative ranges can be translated to actual memory
locations.
The reason for the two values, instead of just one (the load bias) is (I
think) MachO, where the debug info in the object files will appear to be
relative to the address zero, but the actual code it refers to
can be moved and reordered by the linker. This means that the location
lists need to be "linked" to reflect the locations in the actual linked
file.
These two bits of information were enough to correctly process location
lists which do not contain base address selection entries (and so all
entries are relative to the CU base). However, they don't work with
them because, in theory two base address can be completely unrelated (as
can happen for instace with hot/cold function splitting, where the
linker can reorder the two pars arbitrarily).
To fix that, I split the first parameter into two:
- the compile unit base address
- the function start address, as is known in the object file
The new algorithm becomes:
- the location lists are processed as they were meant to be processed.
The CU base address is used as the initial base address value. Base
address selection entries can set a new base.
- the difference between the "file" and "load" function start addresses
is used to compute the load bias. This value is added to the final
ranges to get the actual memory location.
This algorithm is correct for non-MachO debug info, as there the
location lists correctly describe the code in the final executable, and
the dynamic linker can just move the entire module, not pieces of it. It
will also be correct for MachO if the static linker preserves relative
positions of the various parts of the location lists -- I don't know
whether it actually does that, but judging by the lack of base address
selection support in dsymutil and lldb, this isn't something that has
come up in the past.
I add a test case which simulates the ASLR scenario and demonstrates
that base address selection entries now work correctly here.
Reviewers: JDevlieghere, aprantl, clayborg
Subscribers: dblaikie, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70532
Summary:
This patch adds support for atomic types (DW_TAG_atomic_type) to LLDB. It's mostly just filling out all the switch-statements that didn't implement Atomic case with the usual boilerplate.
Thanks Pavel for writing the test case.
Reviewers: labath, aprantl, shafik
Reviewed By: labath
Subscribers: jfb, abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71183
Summary:
One of the ways we try to make LLDB faster is by only creating the Clang declarations (and loading the associated types)
when we actually need them for something. For example an evaluated expression might need to load types to
type check and codegen the expression.
Currently this mechanism isn't really tested, so we currently have no way to know how many Clang nodes we load and
when we load them. In general there seems to be some confusion when and why certain Clang nodes are created.
As we are about to make some changes to the code which is creating Clang AST nodes we probably should have
a test that at least checks that the current behaviour doesn't change. It also serves as some kind of documentation
on the current behaviour.
The test in this patch is just evaluating some expressions and checks which Clang nodes are created due to this in the
module AST. The check happens by looking at the AST dump of the current module and then scanning it for the
declarations we are looking for.
I'm aware that there are things missing in this test (inheritance, template parameters, non-expression evaluation commands)
but I'll expand it in follow up patches.
Also this test found two potential bugs in LLDB which are documented near the respective asserts in the test:
1. LLDB seems to always load all types of local variables even when we don't reference them in the expression. We had patches
that tried to prevent this but it seems that didn't work as well as it should have (even though we don't complete these
types).
2. We always seem to complete the first field of any record we run into. This has the funny side effect that LLDB is faster when
all classes in a project have an arbitrary `char unused;` as their first member. We probably want to fix this.
Reviewers: shafik
Subscribers: abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71056
Use type elaborated spellings for the parameter to avoid the ambiguity
between `llvm` and `lldb_private` names. This is needed for building
with Visual Studio.
Summary:
This patch simplifies register accesses in NativeRegisterContextLinux_arm64
and also adds some bare minimum caching to avoid multiple calls to ptrace
during a stop.
Linux ptrace returns data in the form of structures containing GPR/FPR data.
This means that one single call is enough to read all GPRs or FPRs. We do
that once per stop and keep reading from or writing to the buffer that we
have in NativeRegisterContextLinux_arm64 class. Before a resume or detach we
write all buffers back.
This is tested on aarch64 thunder x1 with Ubuntu 18.04. Also tested
regressions on x86_64.
Reviewers: labath, clayborg
Reviewed By: labath
Subscribers: kristof.beyls, lldb-commits
Differential Revision: https://reviews.llvm.org/D69371
Summary:
When creating a test with `lldbinline.MakeInlineTest()`, the reported `inspect.getfile(test.__class__)` is `lldbtest.pyc`, meaning any `.categories` file will be ineffective for those tests. Check for the test_filename first, which inline tests will set.
Additionally, raise an error with the starting dir if `.categories` is not found. This makes the problem more obvious when it occurs: when the test is separated from the test framework tree.
Reviewers: labath, JDevlieghere
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71099
In DWARF5 DW_AT_low_pc (and DW_AT_entry_pc, and possibly others) can use
DW_FORM_addrx to refer to the address indirectly. This means we need to
have processed the DW_AT_addr_base attribute before we can do anything
with these.
Since we were processing the unit attributes serially, this created a
problem in cases where the DW_AT_addr_base comes after DW_AT_low_pc --
we would end up computing the wrong unit base address, which also
corrupted any values which later depended on that (for instance range
lists). Clang currently always emits DW_AT_addr_base last.
The fix is simple -- process DW_AT_addr_base first, regardless of its
position in the attribute list.
the value of DW_AT_rnglists_base of the skeleton unit is for that unit
alone (e.g. used in DW_AT_ranges of the unit DIE) and should not apply
to the split unit.
The split unit has a hardcoded range list base value -- we should
initialize range list code whenever we detect a nonempty
debug_rnglists.dwo section.
Summary:
This was causing problems on linux, where we'd end up calling the
deleting destructor instead of a regular one (because they have the same
demangled name), making a lot of mischief in the process.
The only place where this was necessary (according to the test suite, at
least) was to call a base structor instead of a complete one, but this
is now handled in a more targeted fashion.
TestCallOverriddenMethod is now re-enabled as it now passes reliably.
Reviewers: teemperor, JDevlieghere
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70722
I was working on SearchFilter.cpp and felt it a bit too complex in some cases in terms of nesting and logic flow.
Reviewers: teemperor, JDevlieghere
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71022
This replaces `include $(LEVEL)/Makefile.rules` with `include Makefile.rules`.
The lldb test driver already passes the include path when running make, and specifically looking for "../../Makefile.rules" forces the test to be in a specific location.
Removing this hardcoded relative path will make it possible to move this test as-is.
GetMaxU64Bitfield(...) uses the ul suffix but we require a 64 bit unsigned integer and ul could be 32 bit. So this replacing it with a explicit cast and refactors the code around it to use an early exit.
Differential Revision: https://reviews.llvm.org/D70992
Summary:
Yet another step on the long road towards getting rid of lldb's Stream class.
We probably should just make this some kind of member of Address/AddressRange, but it seems quite often we just push
in random integers in there and this is just about getting rid of Stream and not improving arbitrary APIs.
I had to rename another `DumpAddress` function in FormatEntity that is dumping the content of an address to make Clang happy.
Reviewers: labath
Reviewed By: labath
Subscribers: JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71052
Summary:
Our rnglist support was working only for the trivial cases (one CU),
because we only ever parsed one contribution out of the debug_rnglists
section. This means we were never able to resolve range lists for the
second and subsequent units (DW_FORM_sec_offset references came out
blang, and DW_FORM_rnglistx references always used the ranges lists from
the first unit).
Since both llvm and lldb rnglist parsers are sufficiently
self-contained, and operate similarly, we can fix this problem by
switching to the llvm parser instead. Besides the changes which are due
to variations in the interface, the main thing is that now the range
list object is a member of the DWARFUnit, instead of the entire symbol
file. This ensures that each unit can get it's own private set of range
list indices, and is consistent with how llvm's DWARFUnit does it
(overall, I've tried to structure the code the same way as the llvm
version).
I've also added a test case for the two unit scenario.
Reviewers: JDevlieghere, aprantl, clayborg
Subscribers: dblaikie, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71021
Summary:
This patch adds code which will substitute references to the full object
constructors/destructors with their base object versions.
Like all substitutions in this category, this operation is not really
sound, but doing this in a more precise way allows us to get rid of a
much larger hack -- matching function according to their demangled
names, which effectively does the same thing, but also much more.
This is a (very late) follow-up to D54074.
Background: clang has an optimization which can eliminate full object
structors completely, if they are found to be equivalent to their base
object versions. It does this because it assumes they can be regenerated
on demand in the compile unit that needs them (e.g., because they are
declared inline). However, this doesn't work for the debugging scenario,
where we don't have the structor bodies available -- we pretend all
constructors are defined out-of-line as far as clang is concerned. This
causes clang to emit references to the (nonexisting) full object
structors during expression evaluation.
Fun fact: This is not a problem on darwin, because the relevant
optimization is disabled to work around a linker bug.
Reviewers: teemperor, JDevlieghere
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70721
Summary:
Lldb's "format-independent" debug info made use of the fact that DWARF
(<=4) did not use the file index zero, and reused the support file index
zero for storing the compile unit name.
While this provided some convenience for DWARF<=4, it meant that the PDB
plugin needed to artificially remap file indices in order to free up
index 0. Furthermore, DWARF v5 make file index 0 legal, which meant that
similar remapping would be needed in the dwarf plugin too.
What this patch does instead is remove the requirement of having the
compile unit name in the index 0. It is not that useful since the name
can always be fetched from the CompileUnit object. Remapping code in the
pdb plugin(s) has been removed or simplified.
DWARF plugin has started inserting an empty FileSpec at index 0 to
ensure the indices keep matching up (in case of DWARF<=4). For DWARF5,
we insert the file 0 from the line table.
I add a test to ensure we can correctly lookup line table entries
referencing file 0, and in particular the case where the file 0 is also
duplicated in another file entry, as this is how clang produces line
tables in some circumstances (see pr44170). Though this is probably a
bug in clang, this is not forbidden by DWARF, and lldb already has
support for that in some (but not all) cases -- this adds a test for the
code path which was not fixed in this patch.
Reviewers: clayborg, JDevlieghere, jdoerfert
Subscribers: aprantl, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70954
Summary:
This patch fixes a bug where when target triple created from elf information
is arm-*-linux-eabihf and platform triple is armv8l-*-linux-gnueabihf. Merging
both triple results in armv8l--unknown-unknown.
This happens because we order a triple update while calling CoreUpdated and
CoreUpdated creates a new triple with no vendor or environment information.
Making sure we do not update triple and just update to more specific core
fixes the issue.
Reviewers: labath, jasonmolenda, clayborg
Reviewed By: jasonmolenda
Subscribers: jankratochvil, kristof.beyls, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70155
options class. This value was hanging around so for instance if you made a scripted breakpoint
resolver, then went to set another breakpoint, it would still think you had passed in a class
name and the breakpoint wouldn't do what you expected.
Make it possible to override reproducer capture with the
LLDB_CAPTURE_REPRODUCER environment variable.
The goal of this change is twofold.
(1) I want to be able to enable capturing reproducers during regular
test runs, both locally and on the bots. To do so I need a way to
force capture. I cannot do this through the Python API, because
reproducer capture must be enabled *before* the debugger
initialized, which happens automatically when doing `import lldb`.
(2) I want to provide an escape hatch for when reproducers are enabled
by default. Downstream we have reproducer capture enabled by default
in the driver.
This patch solves both problems by overriding the reproducer mode based
on the environment variable. Acceptable values are 0/1 and ON/OFF.
Jonas Devlieghere