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.
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
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
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
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: 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.
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.
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
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
"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.
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
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
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
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.
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.
Summary:
Using a BreakpointList corrupts the breakpoints' IDs because
BreakpointList::Add sets the ID, so use a vector instead, and
update the signature to return the vector wrapped in an
llvm::Expected which can propagate any error from the inner
call to StringIsBreakpointName.
Note that, despite the similar name, SBTarget::FindBreakpointsByName
doesn't suffer the same problem, because it uses a SBBreakpointList,
which is more like a BreakpointIDList than a BreakpointList under the
covers.
Add a check to TestBreakpointNames that, without this fix, notices the
ID getting mutated and fails.
Reviewers: jingham, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70907
