This patch marks TestCreateDuringInstructionStep.py as flakey for Linux.
This is failing randomly on arm/aarch64. I will monitor buildbot and
skip it if it fails again.
This fixes an unhandled signed integer overflow in AddWithCarry() by
using the llvm::checkedAdd() function. Thats to Vedant Kumar for the
suggestion!
<rdar://problem/60926115>
Differential Revision: https://reviews.llvm.org/D80955
This reverts commit fd0ab3b3eb.
The fix here is incorrect and the actual fault was an incorrect test Makefile.
To give some more background:
The original test for D80798 compiled three source files into either one
executable or one executable + 2 shared libraries, each being one different
test setup. If both the monolithic executable and the shared libraries
where compiled in the same directory, then Make would overwrite the .o files
of one test setup with the other. This caused that while -fPIC was passed
correctly to the test setup with the shared libraries, the compiler invocations
for the monolithic executable would later overwrite these object files (and
as only the test setup with the shared library used -fPIC, it appeared as if
the shared library object files didn't receive the -fPIC flag).
Thanks to Pavel for figuring this out.
Summary:
ClangExpressionSourceCode has different ways to wrap the user expression based on
which context the expression is executed in. For example, if we're in a C++ member
function we put the expression inside a fake member function of a fake class to make the
evaluation possible. Similar things are done for Objective-C instance/static methods.
There is also a default wrapping where we put the expression in a normal function
just to make it possible to execute it.
The way we currently define which kind of wrapping the expression needs is based on
the `wrapping_language` we keep passing to the ClangExpressionSourceCode
instance. We repurposed the language type enum for that variable to distinguish the
cases above with the following mapping:
* language = C_plus_plus -> member function wrapping
* language = ObjC -> instance/static method wrapping (`is_static` distinguished between those two).
* language = C -> normal function wrapping
* all other cases like C_plus_plus11, Haskell etc. make our class a no-op that does mostly nothing.
That mapping is currently not documented and just confusing as the `language`
is unrelated to the expression language (and in the ClangUserExpression we even pretend
that it *is* the actual language, but luckily never used it for anything). Some of the code
in ClangExpressionSourceCode is also obviously thinking that this is the actual language of
the expression as it checks for non-existent cases such as `ObjC_plus_plus` which is
not part of the mapping.
This patch makes a new enum to describe the four cases above (with instance/static Objective-C
methods now being their own case). It also make that enum just a member of
ClangExpressionSourceCode instead of having to pass the same value to the class repeatedly.
This gets also rid of all the switch-case-checks for 'unknown' language such as C_plus_plus11 as this
is no longer necessary.
Reviewers: labath, JDevlieghere
Reviewed By: labath
Subscribers: abidh
Differential Revision: https://reviews.llvm.org/D80793
Summary:
It seems that when we rewrite a few rules to only build a dylib (i.e., when DYLIB_ONLY is set),
the rule for setting the CFLAGS for the dylib's object file compilation will no longer work. From what I can
see this is because in DYLIB_ONLY mode we pretend to compile the main executable so
the DYLIB_OBJECTS scope is actually never used.
This patch makes `-fPIC` unstopped if DYLIB_ONLY is set so that -fPIC actually ends up in the
CFLAGS for the dylib object file compilation.
The test for this is D80798 which only compiles on Linux with this patch.
Reviewers: friss, labath
Reviewed By: friss
Subscribers: JDevlieghere
Differential Revision: https://reviews.llvm.org/D80789
Commit 0800529fe6 adds a runtime error which triggers when using
SBAddress properties that use the current process/target from a
non-interactive session. TestThreadPlanCommands.py was doing exactly
this and this patch fixes that by use GetLoadAddress instead.
Several SBAddress properties use the lldb.target or lldb.process
convenience variables which are only set under the interactive script
interpreter. Unfortunately, users have been using these properties in
Python script and commands. This patch raises a Python exception to
force users to use GetLoadAddress instead.
Differential revision: https://reviews.llvm.org/D80848
We are leaking forked processes on macOS because the cleanup function
was checking the existence of /proc/pid which does not exist on macOS.
I've changed the code to be platform agnostic.
Don't run tests that use undefined behavior sanitizer inside an
address-sanitized LLDB. The tests don't support that
configuration. Incidentally they were skipped on green dragon for a
different reason, so this hasn't come up there before.
Don't run tests that use thread sanitizer inside an address-sanitized
LLDB. The tests don't support that configuration. Incidentally they
were skipped on green dragon for a different reason, so this hasn't
come up there before.
One can have multiple simulator runtimes installed, supporting
various generations of OSs. The logic in TestAppleSimulatorOSType
might select a rnutime older than the one targeted by the current
tools, preventing the executable from running. This commit changes
the test to look for the most recent runtime available instead.
Summary:
On Android, this method gets called twice: first when establishing
a host-server connection, then when attaching to a process id.
Each call takes several seconds to finish (especially slower on Windows)
and eliminating the call for the typical case improves latency significantly.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D79586
Summary:
This patch adds two new arguments to the MakeInlineTest function. The
main motivation is a follow-up patch I'm preparing, but they seem
generally useful.
The first argument allows the user to specify the "build dictionary".
With this argument one can avoid the need to provide a custom Makefile
if all he needs is to override a couple of make variables. This hooks in
neatly into the existing dictionary support for non-inline tests.
The second argument specifies the name of the test. This could be used
to provide better names to the generated test classes, but it's mainly
useful in conjuction with the first argument: now that we can specify a
custom build dictionary, it may sometimes make sense to run the same
test twice with different build configurations. To achieve that, we need
to give the two tests different names, and this argument achieves that.
The usage of the arguments is demonstrated via TestBasicEntryValues.py.
Reviewers: vsk, JDevlieghere
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D80518
Summary:
Running `vsce package` to package lldb-vscode as an installable .vsix file errors with:
```
ERROR Invalid publisher name 'llvm.org'. Expected the identifier of a publisher, not its human-friendly name.
```
This patch fixes the publisher name and bumps a required dependency so that `vsce package` succeeds.
Reviewers: clayborg
Reviewed By: clayborg
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D80569
Jim pointed out that "every time somebody has touched the documentation
on startup files they have stated that we source the application one and
then the global one, even though in actual fact we’ve never done that."
Indeed, when we read the application specific .lldbinit file, the global
one is not read. This patch updates the man page to reflect that.
This adds a new target `check-lldb-reproducers` that replaces the old
`check-lldb-repro`. The latter would only run the shell tests, while
`check-lldb-reproducers` includes the API tests as well. The new target
will be used on GreenDragon.
It's still possible to run just the shell tests with reproducers,
although now that requires crafting the lit invocation yourself. The
parameters haven't changed and are the shame for the API and shell
tests:
--param lldb-run-with-repro=capture
--param lldb-run-with-repro=replay
This patch also updates the reproducer documentation.
This property is explicitly for use only in the interactive editor,
and NOT in commands. It's use worked until we got more careful about
not leaving lldb.target lying around in the script interpreter.
I also added a quick sniff test for the save_crashlog command.
<rdar://problem/60350620>
Differential Revision: https://reviews.llvm.org/D80680
After this patch all remaining tests should pass on macOS when replayed
from a reproducer.
To capture the reproducers:
./bin/llvm-lit ../llvm-project/lldb/test/ --param lldb-run-with-repro=capture
To replay the reproducers:
./bin/llvm-lit ../llvm-project/lldb/test/ --param lldb-run-with-repro=replay
The reproducer don't model timeouts so tests that rely on them end up
with unexpected packets during replay. Skip them until we can handle
this scenario.
Although it's not entirely clear to me why, this test was generating its
binary in the source directory instead of the build directory. This
patch fixes that following the same approach as other tests.
The purpose of the LLDB_RECORD_DUMMY macro is twofold: it is used in
functions that take arguments that we don't know how to serialize (e.g.
void*) and it's used by function where we want to avoid doing excessive
work because they can be called from a signal handler (e.g.
setTerminalWidth).
To support the latter case, I've disabled API logging form the Recorder
ctor used by the DUMMY macro. This ensures we don't allocate memory when
called from a signal handler.
Summary:
It turns out that the order in which we provide completions for expressions is
nondeterministic. This leads to confusing user experience and also breaks the
reproducer tests (as two LLDB tests can go out of sync due to the
non-determinism in the completion lists)
The reason for the non-determinism is that the CompletionConsumer informs us
about decls in the order in which it finds declarations in the lookup store of
the DeclContexts it visits (mainly this snippet in SemaLookup.cpp):
``` lang=c++
// Enumerate all of the results in this context.
for (DeclContextLookupResult R :
Load ? Ctx->lookups()
: Ctx->noload_lookups(/*PreserveInternalState=*/false)) {
[...]
```
This storage of the lookup is sorted by pointer values (see the hash of
`DeclarationName`) and can therefore be non-deterministic. The LLDB code
completion consumer that receives these calls originally expected that the order
of declarations is defined by Clang, but it seems the API expects the client to
provide an order to the completions.
This patch fixes the issue as follows:
* We sort the completions we get from Clang alphabetically and also by the
priority value we get from Clang (with priority value sorting having precedence
over the alphabetical sorting)
* We make all the functions/variables that touch a completion before the sorting
const-qualified. The idea is that this should prevent that we never have
observable side-effect from touching these declarations in a non-deterministic
order (e.g., we don't try to complete the type by accident).
This way we behave like the other parts of Clang which also sort the results by
some deterministic value (usually the name or something computed from a name,
e.g., edit distance to a given string).
We most likely also need to fix the Clang code to make the loop I listed above
deterministic to prevent these issues in the future (tracked in rdar://63442513
). This wouldn't replace the functionality provided in this patch though as we
would still need the priority and overall alphabetical sorting.
Note: I had to increase the lldb-vscode completion limit to 100 as the tests
look for strings that aren't in the first 50 results anymore due to variable
names starting with letters like 'v' (which are now always shown much further
down in the list due to the alphabetical sorting).
Fixes rdar://63200995
Reviewers: JDevlieghere, clayborg
Reviewed By: JDevlieghere
Subscribers: mgrang, abidh
Differential Revision: https://reviews.llvm.org/D80292
Summary: `CommandObject::CheckRequirements` requires cleaning up `m_exe_ctx`
between commands. Function `HandleOptionCompletion` returns without cleaning up
`m_exe_ctx` could cause assert failure in later `CheckRequirements`.
Reviewers: teemperor, JDevlieghere
Reviewed By: teemperor
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D80447
Summary:
For ObjCInterfaceDecls, LLDB iterates over the `methods` of the interface in FindExternalVisibleDeclsByName
since commit ef423a3ba5 .
However, when LLDB calls `oid->methods()` in that function, Clang will pull in all declarations in the current
DeclContext from the current ExternalASTSource (which is again, `ClangExternalASTSourceCallbacks`). The
reason for that is that `methods()` is just a wrapper for `decls()` which is supposed to provide a list of *all*
(both currently loaded and external) decls in the DeclContext.
However, `ClangExternalASTSourceCallbacks::FindExternalLexicalDecls` doesn't implement support for ObjCInterfaceDecl,
so we don't actually add any declarations and just mark the ObjCInterfaceDecl as having no ExternalLexicalStorage.
As LLDB uses the ExternalLexicalStorage to see if it can complete a type with the ExternalASTSource, this causes
that LLDB thinks our class can't be completed any further by the ExternalASTSource
and will from on no longer make any CompleteType/FindExternalLexicalDecls calls to that decl. This essentially
renders those types unusable in the expression parser as they will always be considered incomplete.
This patch just changes the call to `methods` (which is just a `decls()` wrapper), to some ad-hoc `noload_methods`
call which is wrapping `noload_decls()`. `noload_decls()` won't trigger any calls to the ExternalASTSource, so
this prevents that ExternalLexicalStorage will be set to false.
The test for this is just adding a method to an ObjC interface. Before this patch, this unset the ExternalLexicalStorage
flag and put the interface into the state described above.
In a normal user session this situation was triggered by setting a breakpoint in a method of some ObjC class. This
caused LLDB to create the MethodDecl for that specific method and put it into the the ObjCInterfaceDecl.
Also `ObjCLanguageRuntime::LookupInCompleteClassCache` needs to be unable to resolve the type do
an actual definition when the breakpoint is set (I'm not sure how exactly this can happen, but we just
found no Type instance that had the `TypePayloadClang::IsCompleteObjCClass` flag set in its payload in
the situation where this happens. This however doesn't seem to be a regression as logic wasn't changed
from what I can see).
The module-ownership.mm test had to be changed as the only reason why the ObjC interface in that test had
it's ExternalLexicalStorage flag set to false was because of this unintended side effect. What actually happens
in the test is that ExternalLexicalStorage is first set to false in `DWARFASTParserClang::CompleteTypeFromDWARF`
when we try to complete the `SomeClass` interface, but is then the flag is set back to true once we add
the last ivar of `SomeClass` (see `SetMemberOwningModule` in `TypeSystemClang.cpp` which is called
when we add the ivar). I'll fix the code for that in a follow-up patch.
I think some of the code here needs some rethinking. LLDB and Clang shouldn't infer anything about the ExternalASTSource
and its ability to complete the current type form the `ExternalLexicalStorage` flag. We probably should
also actually provide any declarations when we get asked for the lexical decls of an ObjCInterfaceDecl. But both of those
changes are bigger (and most likely would cause us to eagerly complete more types), so those will be follow up patches
and this patch just brings us back to the state before commit ef423a3ba5 .
Fixes rdar://63584164
Reviewers: aprantl, friss, shafik
Reviewed By: aprantl, shafik
Subscribers: arphaman, abidh, JDevlieghere
Differential Revision: https://reviews.llvm.org/D80556
Summary:
Objective-C names are stored in m_demangled, not in m_mangled. The
method in the condition will never return true.
Differential Revision: https://reviews.llvm.org/D79823
Summary:
A struct argument can be passed-by-value to a callee via a pointer to a
temporary stack copy. Add support for emitting an entry value DBG_VALUE
when an indirect parameter DBG_VALUE becomes unavailable. This is done
by omitting DW_OP_stack_value from the entry value expression, to make
the expression describe the location of an object.
rdar://63373691
Reviewers: djtodoro, aprantl, dstenb
Subscribers: hiraditya, lldb-commits, llvm-commits
Tags: #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D80345
Don't run tests that use address sanitizer inside an address-sanitized
LLDB. The tests don't support that configuration. Incidentally they
were skipped on green dragon for a different reason, so this hasn't
come up there before.
Many tests use (commented out) print statement for debugging the test
itself. This patch adds a new trace method to lldbtest to reuse the
existing tracing infrastructure and replace these print statements.
Differential revision: https://reviews.llvm.org/D80448
The llvm DWARFExpression dump is nearly identical, but better -- for
example it does print a spurious space after zero-argument expressions.
Some parts of our code (variable locations) have been already switched
to llvm-based expression dumping. This switches the remainder: unwind
plans and some unit tests.
Summary:
This is an attempt to fix https://bugs.llvm.org/show_bug.cgi?id=45988,
where SBValue::GetNumChildren returns 2, but SBValue::GetChildAtIndex(1) returns
an invalid value sentinel.
The root cause of this seems to be that GetNumChildren can return the number of
children of a wrong value. In particular, for pointers GetNumChildren just
recursively calls itself on the pointee type, so it effectively walks chains of
pointers. This is different from the logic of GetChildAtIndex, which only
recurses if pointee.IsAggregateType() returns true (IsAggregateType is false for
pointers and references), so it never follows chain of pointers.
This patch aims to make GetNumChildren (more) consistent with GetChildAtIndex by
only recursively calling GetNumChildren for aggregate types.
Ideally, GetNumChildren and GetChildAtIndex would share the code that decides
which pointers/references are followed, but that is a bit more invasive change.
Reviewers: teemperor, jingham, clayborg
Reviewed By: teemperor, clayborg
Subscribers: clayborg, labath, shafik, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D80254
Muhammad Omair Javaid