Commit Graph

4603 Commits

Author SHA1 Message Date
Jonas Devlieghere 3a538de653 [lldb] Make UBSan tests remote ready
Add missing call to registerSanitizerLibrariesWithTarget.
2020-08-05 18:31:43 -07:00
Jonas Devlieghere 927afdffbb [lldb] Skip test_launch_simple on Windows
Because stdio manipulation unsupported on Windows.
2020-08-05 15:38:07 -07:00
Jonas Devlieghere 31137b87ef [lldb] Skip TestProcessConnect when running remotely
This test doesn't make much sense when already running remotely.
2020-08-05 15:27:34 -07:00
Jonas Devlieghere df46f174db [lldb] Modify the `skipIfRemote` decorator so we can skip all PExpect tests.
This patch modifies the skipIfRemote decorator so it can apply to a
whole class, which allows us to skip all PExpect tests as a whole.

Differential revision: https://reviews.llvm.org/D85365
2020-08-05 15:27:34 -07:00
Jordan Rupprecht fcb0d8163a [lldb/test] Use realpath consistently for test root file paths.
LLDB tests assume that tests are in the test tree (the `LLDB_TEST_SRC` env variable, configured by `dotest.py`).
If this assertion doesn't hold, tests fail in strange ways. An early place this goes wrong is in `compute_mydir` which does a simple length-based substring to get the relative path. Later, we use that path to chdir to. If the test file and test tree don't agree in realpath-ness (and therefore length), this will be a cryptic error of chdir-ing to a directory that does not exist.

The actual discrepency is that the places we look for `use_lldb_suite.py` don't use a realpath, but `dotest.py` does (see initialization of `configuration.testdirs`).

It doesn't particularly matter whether we use realpath or abspath to canonicalize things, but many places end up with implicit dependencies on the canonicalized pwd being a realpath, so make them realpath consistently. Also, in the `compute_mydir` method mentioned, raise an error if the path types don't agree.

Reviewed By: JDevlieghere

Differential Revision: https://reviews.llvm.org/D85258
2020-08-05 11:35:37 -07:00
Jonas Devlieghere 249a1d4f1b [lldb] Add an option to inherit TCC permissions from parent.
Add an option that allows the user to decide to not make the inferior is
responsible for its own TCC permissions. If you don't make the inferior
responsible, it inherits the permissions of its parent. The motivation
is the scenario of running the LLDB test suite from an external hard
drive. If the inferior is responsible, every test needs to be granted
access to the external volume. When the permissions are inherited,
approval needs to be granted only once.

Differential revision: https://reviews.llvm.org/D85237
2020-08-05 10:08:28 -07:00
Jonas Devlieghere 882d8e60dd [lldb] Make SBTarget::LaunchSimple start form the target's LaunchInfo
Currently SBTarget::LaunchSimple creates a new LaunchInfo which means it
ignores any target properties that have been set. Instead, it should
start from the target's LaunchInfo and populated the specified fields.

Differential revision: https://reviews.llvm.org/D85235
2020-08-05 10:08:28 -07:00
Luboš Luňák 188187f062 [lldb] expect TestGuiBasicDebug.py failure on aarch64
http://lab.llvm.org:8011/builders/lldb-aarch64-ubuntu/builds/7287/steps/test/logs/stdio
fails, and the output suggests that gui 'finish' (='thread step-out') is broken
on aarch64.
2020-08-05 12:21:05 +02:00
Luboš Luňák db828aba55 [lldb][gui] add a test for 'b' (toggle breakpoint)
Differential Revision: https://reviews.llvm.org/D85107
2020-08-05 09:51:13 +02:00
Luboš Luňák c7be982c83 [lldb][gui] move TestGuiBasicDebug.py to lldb/test and update it
Between the time it was created and it was pushed upstream,
99451b4453 has moved the existing
gui gui tests to lldb/test, so move this one too.
And update it to contain TestGuiBasic.py changes since the time
when it was based on that test.

Differential Revision: https://reviews.llvm.org/D85106
2020-08-05 09:51:13 +02:00
Fred Riss 4c9ed3ed3d [lldb/testsuite] Skip 'frame diagnose' tests based on architecture
AFAICS, the feature only works on x86, skipping the tests has nothing to
do with the target being iOS or remote.
2020-08-04 17:45:55 -07:00
Adrian Prantl 7e9bab6ad5 Fix debugserver's qProcessInfo reporting of maccatalyst binaries
This patch is similar in spirit to https://reviews.llvm.org/D84480,
but does the maccatalyst/macosx disambiguation. I also took the
opportunity to factor out the gdb-remote packet log scanning used by
several testcases into lldbutil functions.

rdar://problem/66059257

Differential Revision: https://reviews.llvm.org/D84576
2020-08-04 16:42:14 -07:00
Jonas Devlieghere e8b7edafc3 [lldb/Test] Add @skipIfRemote decorator to TestProcessList.py
lldb-platform contains a very minimal support for the qfProcessInfo
packet, only allowing the simplest query to get most of the testsuite
running, and returning very little information about the matched
processes.
2020-08-04 14:40:07 -07:00
Jonas Devlieghere ba3d84d82b [lldb/Test] Skip tests that try to get the remote environment
We don't support getting the remote environment. The gdb remote protocol
has no packet for that.
2020-08-04 14:01:57 -07:00
Jonas Devlieghere bb33f925a6 [lldb/Test] Add missing stdio.h includes
Fixes error: implicit declaration of function 'printf' is invalid in C99
[-Werror,-Wimplicit-function-declaration]
2020-08-04 13:08:14 -07:00
Jan Kratochvil e6c2c9a7d1 [lldb] [test] Fix DW_TAG_GNU_call_site-DW_AT_low_pc.s relocation
I have made the DW_FORM_ref4 relative. One could also use relocated
DW_FORM_ref_addr instead.

Tested with:
        echo 'void f(){}'|clang -o 1.o -c -Wall -g -x c -;./bin/clang -o 1 1.o ../llvm-monorepo/lldb/test/Shell/SymbolFile/DWARF/DW_TAG_GNU_call_site-DW_AT_low_pc.s;./bin/lldb --no-lldbinit ./1 -o r -o 'p p' -o exit
2020-08-02 22:41:02 +02:00
Luboš Luňák 77d5a63c19 [lldb] report an error if a CLI option lacks an argument
Differential Revision: https://reviews.llvm.org/D84955
2020-07-31 22:02:40 +02:00
Jonas Devlieghere 162e9f72ac [lldb/Test] Reduce code duplication by importing subprocess globally
Import the subprocess module once instead of doing it inline which is
error prone and leads to needless code duplication.
2020-07-31 10:56:13 -07:00
Jonas Devlieghere 3bb48898bc [lldb/Test] Use self.assertIn in TestGdbRemoteTargetXmlPacket
On the ARM buildbot the returned architecture is `armv8l` while
getArchitecture() just returns `arm`.
2020-07-30 11:48:35 -07:00
Jordan Rupprecht be198e03eb [lldb][test] Move registers-target-xml-reading target to the correct test location.
This test was added in D74217 (and the `.categories` file later added in ccf1c30cde) around the same time I moved the test tree from `lldb/packages/Python/lldbsuite/test` to `lldb/test/API` (D71151). Since this got lost in the move, it isn't running. (I introduced an intentional syntax error, and `ninja check-lldb` passes).

I moved it to the correct location, and now it runs and passes -- locally, at least -- as `ninja check-lldb-api-tools-lldb-server-registers-target-xml-reading`.
2020-07-30 10:28:32 -07:00
Jonas Devlieghere 6587ff77ea [lldb] Fix llvm-lit in standalone builds
LLVM's make_paths_relative uses Python3_EXECUTABLE which isn't set in
standalone LLDB builds.
2020-07-29 15:38:40 -07:00
Tatyana Krasnukha ebaa8b1c60 [lldb] Don't use hardware index to determine whether a breakpoint site is hardware
Most process plugins (if not all) don't set hardware index for breakpoints. They even
are not able to determine this index.

This patch makes StoppointLocation::IsHardware pure virtual and lets BreakpointSite
override it using more accurate BreakpointSite::Type.

It also adds assertions to be sure that a breakpoint site is hardware when this is required.

Differential Revision: https://reviews.llvm.org/D84257
2020-07-29 21:27:24 +03:00
Tatyana Krasnukha b352e62fea [lldb] Make process plugins check whether a hardware breakpoint is required
Remove @skipIfWindows as process should report the error correctly on Windows now.

Differential Revision: https://reviews.llvm.org/D84255
2020-07-29 21:27:23 +03:00
Tatyana Krasnukha f7ec3e3be7 [lldb] Skip overlapping hardware and external breakpoints when writing memory
This fixes the assertion `assert(intersects);` in the Process::WriteMemory function.

Differential Revision: https://reviews.llvm.org/D84254
2020-07-29 21:27:23 +03:00
Tatyana Krasnukha c114352edf [lldb/test] Put hardware breakpoint tests together, NFC
Create a common base class for them to re-use supports_hw_breakpoints function in decorators.

Differential Revision: https://reviews.llvm.org/D84311
2020-07-29 21:20:04 +03:00
Jonas Devlieghere 4add853647 [lldb] Improve platform handling in CreateTargetInternal
Currently, `target create` has no --platform option. However,
TargetList::CreateTargetInternal which is called under the hood, will
return an error when either no platform or multiple matching platforms
are found, saying that a platform should be specified with --platform.

This patch adds the platform option, but that doesn't solve either of
these errors.

 - If more than one platform matches, specifying the platform isn't
   going to fix that. The current code will only look at the
   architecture instead. I've updated the error message to ask the user
   to specify an architecture.

 - If no architecture is found, specifying a new one via platform isn't
   going to change that either because we already try to find one that
   matches the given architecture.

Differential revision: https://reviews.llvm.org/D84809
2020-07-29 10:30:20 -07:00
Amy Huang 394db22595 Revert "Switch to using -debug-info-kind=constructor as default (from =limited)"
This reverts commit 227db86a1b.

Causing debug info errors in google3 LTO builds; also causes a
debuginfo-test failure.
2020-07-28 11:23:59 -07:00
Pavel Labath 1956cf1042 [lldb/DWARF] Don't treat class declarations with children as definitions
Summary:
This effectively reverts r188124, which added code to handle
(DW_AT_)declarations of structures with some kinds of children as
definitions. The commit message claims this is a workaround for some
kind of debug info produced by gcc. However, it does not go into
specifics, so it's hard to reproduce or verify that this is indeed still a
problem.

Having this code is definitely a problem though, because it mistakenly
declares incomplete dwarf declarations to be complete. Both clang (with
-flimit-debug-info) and gcc (by default) generate DW_AT_declarations of
structs with children. This happens when full debug info for a class is
not emitted in a given compile unit (e.g. because of vtable homing), but
the class has inline methods which are used in the given compile unit.
In that case, the compilers emit a DW_AT_declaration of a class, but
add a DW_TAG_subprogram child to it to describe the inlined instance of
the method.

Even though the class tag has some children, it definitely does not
contain enough information to construct a full class definition (most
notably, it lacks any members). Keeping the class as incomplete allows
us to search for a real definition in other modules, helping the
-flimit-debug-info flow. And in case the definition is not found we can
display a error message saying that, instead of just showing an empty
struct.

Reviewers: clayborg, aprantl, JDevlieghere, shafik

Subscribers: lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D83302
2020-07-27 12:58:22 +02:00
Yifan Shen 2c1bea88a5 Add Debug Info Size to Symbol Status
If a module has debug info, the size of debug symbol will be displayed after the Symbols Loaded Message for each module in the VScode modules view.{F12335461}

Reviewed By: wallace, clayborg

Differential Revision: https://reviews.llvm.org/D83731
2020-07-24 13:30:04 -07:00
Walter Erquinigo 313b60742a Revert "Add Debug Info Size to Symbol Status"
This reverts commit 986e3af53b.

It incorrectly deleted clang/tools/clang-format/git-clang-format
2020-07-24 13:28:29 -07:00
Yifan Shen 986e3af53b Add Debug Info Size to Symbol Status
Summary: If a module has debug info, the size of debug symbol will be displayed after the Symbols Loaded Message for each module in the VScode modules view.{F12335461}

Reviewers: wallace, clayborg

Reviewed By: wallace, clayborg

Subscribers: cfe-commits, aprantl, lldb-commits

Tags: #lldb, #clang

Differential Revision: https://reviews.llvm.org/D83731
2020-07-24 13:26:06 -07:00
shafik 0db2934b0f [ASTImporter] Modify ImportDefiniton for ObjCInterfaceDecl so that we always the ImportDeclContext one we start the definition
Once we start the definition of an ObjCInterfaceDecl we won't attempt to ImportDeclContext
later on. Unlike RecordDecl case which uses DefinitionCompleter to force completeDefinition
we don't seem to have a similar mechanism for ObjCInterfaceDecl.

This fix was needed due to a bug we see in LLDB expression parsing where an initial expression
cause an ObjCInterfaceDecl to be defined and subsequent expressions during import do not call
ImportDeclContext and we can end up in a situation where ivars are imported out of order and not all ivars are imported.

Differential Revision: https://reviews.llvm.org/D83972
2020-07-24 13:15:08 -07:00
Adrian Prantl 58d84eb534 debugserver: Support ios simulator load command disambiguation in qProcessInfo
This patch basically moves the disambiguation code from a place where
it was complicated to implement straight to where the load command is
parsed, which has the neat side affect of actually supporting all call
sites!

rdar://problem/66011909

Differential Revision: https://reviews.llvm.org/D84480
2020-07-24 09:49:16 -07:00
Fred Riss 22c16360dd [lldb/ObjectFileMachO] Correctly account for resolver symbols
Summary:
The resolver addresses stored in the dyld trie are relative to the base
of the __TEXT segment. This is usually 0 in a dylib, so this was never
noticed, but it is not 0 for most dylibs integrated in the shared cache.
As we started using the shared cache images recently as symbol source,
this causes LLDB to fail to resolve symbols which go through a runtime
resolver.

Reviewers: jasonmolenda, jingham

Subscribers: lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D84083
2020-07-24 09:19:17 -07:00
Raphael Isemann 5477fbc294 [lldb] Make deleting frame recognizers actually work
Summary:

Frame recognizers are stored alongside a flag that indicates whether they were
deleted by the user. If the flag is set, they are supposed to be ignored by the
rest of the frame recognizer code. 'frame recognizer delete' is supposed to set
that flag. 'frame recognizer clear' however actually deletes all frame
recognizers (so, it doesn't set the flag but directly deletes them from the
list).

The current implementation of this concept is pretty broken. `frame recognizer
delete` sets the flag, but it somehow thinks that the recognizer id is an index
in the recognizer list. That's not true as it's actually just a member of each
recognizer entry. So it actually just sets the `deleted` flag for a random other
recognizer. The tests for the recognizer still pass as `frame recognizer list`
is also broken and just completely ignored the `deleted` flag and lists all
recognizers. Also `frame recognizer delete` just ignores if it can't actually
delete a recognizer if the id is invalid.

I think we can simplify this whole thing by just actually deleting recognizers
instead of making sure all code is actually respecting the `deleted` flag. I
assume the intention of this was to make sure that all recognizers are getting
unique ids over the course of an LLDB session, but as `clear` is actually
deleting them and we keep recycling ids, that didn't really work to begin with.

This patch deletes the `deleted` flag and just actually deletes the stored
recognizer. Also adds the missing error message in case it find a recognizer
with a given id.

Reviewers: mib

Reviewed By: mib

Subscribers: abidh, JDevlieghere

Differential Revision: https://reviews.llvm.org/D84404
2020-07-23 17:43:37 +02:00
Pavel Labath 9cdd68e7c1 Recommit "[lldb/API] Overwrite variables with SBLaunchInfo::SetEnvironment(append=true)"
The patch was reverted 27d52cd86a because of failures in
TestWeakSymbols.py. These have now been addressed in D83552.

The original commit message was:
This function was documented to overwrite entries with D76111, which was
adding a couple of similar functions. However, this function (unlike the
functions added in that patch) was/is not actually overwriting variables
-- any pre-existing variables would get ignored.

This behavior does not seem to be intentional. In fact, before the refactor in
D41359, this function could introduce duplicate entries, which could
have very surprising effects both inside lldb and on other applications
(some applications would take the first value, some the second one; in
lldb, attempting to unset a variable could make the second variable
become active, etc.).

Overwriting seems to be the most reasonable behavior here, so change the
code to match documentation.

Differential Revision: https://reviews.llvm.org/D83306
2020-07-23 14:17:57 +02:00
Med Ismail Bennani e605994bb3 [lldb/test] Fix TestHistoryRecall failure (NFC)
This patch fixes a test failure in TestHistoryRecall caused by the move
of the `history` subcommand to the `session` command.

This change was introduced by commit 85fbb08fa2.

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2020-07-23 13:27:12 +02:00
Med Ismail Bennani 85fbb08fa2 [lldb/interpreter] Move the history subcommand to session (NFCI)
This patch moves the `history` subcommand from the `command` to `session`
command. I think it makes more sense to have it there because as the `command`
usage suggests, it should be used to manage custom LLDB commands.

However, `history` is essentially tied to a debugging session and holds
all the commands (not specifically custom ones).

This also makes it more discoverable by adding an alias for it (mimicking
the shell builtin).

Differential Revision: https://reviews.llvm.org/D84307

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2020-07-23 13:05:45 +02:00
Jonas Devlieghere 8acaceb14c [lldb] Fix LLDB_DEFAULT_TEST_ARCH for standalone builds
LLVM_TARGET_ARCH is not exported by LLVM so we can't use it from
standalone builds. Default to the architecture in LLVM_HOST_TRIPLE when
no LLDB_DEFAULT_TEST_ARCH was specified.
2020-07-22 17:04:42 -07:00
Benson Li c9d5a3058f [lldb] add printing of stdout compile errors to lldbsuite
Summary: Add printing of the output of stdout during compile errors, in
addition to stderr output.

Reviewed By: labath

Differential Revision: https://reviews.llvm.org/D83425
2020-07-22 16:38:20 +02:00
Med Ismail Bennani 5bb742b10d [lldb/interpreter] Add ability to save lldb session to a file
This patch introduce a new feature that allows the users to save their
debugging session's transcript (commands + outputs) to a file.

It differs from the reproducers since it doesn't require to capture a
session preemptively and replay the reproducer file in lldb.
The user can choose the save its session manually using the session save
command or automatically by setting the interpreter.save-session-on-quit
on their init file.

To do so, the patch adds a Stream object to the CommandInterpreter that
will hold the input command from the IOHandler and the CommandReturnObject
output and error. This way, that stream object accumulates passively all
the interactions throughout the session and will save them to disk on demand.

The user can specify a file path where the session's transcript will be
saved. However, it is optional, and when it is not provided, lldb will
create a temporary file name according to the session date and time.

rdar://63347792

Differential Revision: https://reviews.llvm.org/D82155

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2020-07-22 11:43:16 +02:00
Pavel Labath 5f4c850e7b [lldb/test] Do a better job at setting (DY)LD_LIBRARY_PATH
Summary:
registerSharedLibrariesWithTarget was setting the library path
environment variable to the process build directory, but the function is
also accepting libraries in other directories (in which case they won't
be found automatically).

This patch makes the function set the path variable correctly for these
libraries too. This enables us to remove the code for setting the path
variable in TestWeakSymbols.py, which was working only accidentally --
it was relying on the fact that
  launch_info.SetEnvironmentEntries(..., append=True)
would not overwrite the path variable it has set, but that is going to
change with D83306.

Reviewers: davide, jingham

Subscribers: lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D83552
2020-07-22 11:37:02 +02:00
Vedant Kumar 46334dfc3b [lldb/test] Skip test in TestBitfieldIvars.py instead of xfailing it
The test triggers an ASan exception, causing job failures on the
sanitizer bot.

As suggested by Shafik.
2020-07-21 11:29:09 -07:00
Jonas Devlieghere 1c9cc094d0 [lldb] Fix typo that went unnoticed on my case insensitive FS 2020-07-21 09:13:26 -07:00
Jonas Devlieghere 9f8d481d68 [lldb/Reproducers] Don't recursively record everything in the CWD
RecordInterestingDirectory was added to collect dSYM bundles and their
content. For the current working directory we only want the directory to
be part of the VFS, not necessarily its contents. This patch renames the
current method to RecordInterestingDirectoryRecursively and adds a new
one that's not recursive.
2020-07-21 09:02:38 -07:00
Muhammad Omair Javaid 510e37c88c Revert "Revert "AArch64 SVE register infos and core file support""
This reverts commit d9920e0199.
2020-07-21 14:31:47 +05:00
Jim Ingham bc0a9a17a4 Add an option (-y) to "break set" and "source list" that uses the same
file:line:column form that we use to print out locations.  Since we
print them this way it makes sense we also accept that form.

Differential Revision: https://reviews.llvm.org/D83975
2020-07-20 17:40:36 -07:00
shafik a54c42df9a Fix how we handle bit-fields for Objective-C when creating an AST
Currently expressions dealing with bit-fields in Objective-C objects is pretty broken. When generating debug-info for Objective-C bit-fields DW_AT_data_bit_offset has a different meaning than it does to C and C++.
When we parse the DWARF we validate bit offsets for C and C++ correctly but not for ObjC. For ObjC in some cases we end up incorrectly flagging an error and we don't generate further bit-fields in the AST.
Later on when we do a name lookup we don't find the ObjCIvarDecl in the ObjCInterfaceDecl in some cases since we never added it and then we don't go to the runtime to obtain the offset.

This will fix how we handle bit-fields for the Objective-C case and add tests to verify this fix but also to documents areas that still don't work and will be addressed in follow-up PRs.

Note: we can never correctly calculate offsets statically because of how Objective-C deals with the fragile base class issue. Which means the runtime may need to shift fields over.

Differential Revision: https://reviews.llvm.org/D83433
2020-07-20 16:12:29 -07:00
Martin Storsjö f07ddbc9c4 [LLDB] [COFF] Fix handling of symbols with more than one aux symbol
Differential Revision: https://reviews.llvm.org/D84070
2020-07-20 22:42:28 +03:00
Jonas Devlieghere f8df2e1a19 [lldb/Reproducers] Always record the current working directory
Setting the current working directory in the VFS will fail if the given
path doesn't exist in the YAML mapping or on disk.
2020-07-20 11:54:11 -07:00
Muhammad Omair Javaid d9920e0199 Revert "AArch64 SVE register infos and core file support"
This reverts commit 7e017de0ad.
2020-07-20 17:37:17 +05:00
Muhammad Omair Javaid 7e017de0ad AArch64 SVE register infos and core file support
Summary:
This patch adds support for AArch64 SVE register infos description and
core file register access.

AArch64 SVE is a an optional extension of Arm v8.3-a architecture. It
has introduced 32 new vector registers Z, 16 predicate P registers and FFR
predicate register. These registers have fixed names but can dynamically
be configured to different size based on underlying OS configuration.

This patch adds register info struct that describes SVE register infos and
also provides RegisterContextPOSIXCore_arm64 routines to access SVE registers.

This patch also introduces a mechanism to configure SVE register sizes and
offsets at startup before exchanging register information across gdb-remote.

TestLinuxCore.py has been updated to include testing of SVE core files.

Reviewers: labath, clayborg, jankratochvil, jasonmolenda, rengolin

Reviewed By: labath

Subscribers: tschuett, kristof.beyls, danielkiss, lldb-commits

Differential Revision: https://reviews.llvm.org/D77047
2020-07-20 17:21:16 +05:00
Jonas Devlieghere 0fbbf3a98c [lldb] Unify sleep and time outs in GDB remote testcases
Reduce sleep and time outs in GDB remote testcases to one default value
for each. Stop passing these values around and always use the default
instead.

Differential revision: https://reviews.llvm.org/D83904
2020-07-17 11:03:16 -07:00
Pavel Labath f3fab392f5 [lldb/DWARF] Don't get confused by line sequences with tombstone values
Summary:
With D81784, lld has started debug info resolving relocations to
garbage-collected symbols as -1 (instead of relocation addend). For an
unaware consumer this generated sequences which seemingly wrap the
address space -- their first entry was 0xfffff, but all other entries
were low numbers.

Lldb stores line sequences concatenated into one large vector, sorted by
the first entry, and searched with std::lower_bound. This resulted in
the low-value entries being placed at the end of the vector, which
utterly confused the lower_bound algorithm, and caused it to not find a
match. (Previously, these sequences would be at the start of the vector,
and normally would contain addresses that are far smaller than any real
address we want to look up, so std::lower_bound was fine.)

This patch makes lldb ignore these kinds of sequences completely. It
does that by changing the construction algorithm from iterating over the
rows (as parsed by llvm), to iterating over the sequences. This is
important because the llvm parsed performs validity checks when
constructing the sequence array, whereas the row array contains raw
data.

Reviewers: JDevlieghere, MaskRay

Differential Revision: https://reviews.llvm.org/D83957
2020-07-17 11:51:52 +02:00
Raphael Isemann 1b7c9eae6d [lldb] Store StackFrameRecognizers in the target instead of a global list
Summary:

Currently the frame recognizers are stored in a global list (the list in the
StackFrameRecognizersManagerImpl singleton to be precise). All commands and
plugins that modify the list are just modifying that global list of recognizers
which is shared by all Target and Debugger instances.

This is clearly against the idea of LLDB being usable as a library and it also
leads to some very obscure errors as now multiple tests are sharing the used
frame recognizers. For example D83400 is currently failing as it reorders some
test_ functions which permanently changes the frame recognizers of all
debuggers/targets. As all frame recognizers are also initialized in a 'once'
guard, it's also impossible to every restore back the original frame recognizers
once they are deleted in a process.

This patch just moves the frame recognizers into the current target. This seems
the way everyone assumes the system works as for example the assert frame
recognizers is using the current target to find the function/so-name to look for
(which only works if the recognizers are stored in the target).

Reviewers: jingham, mib

Reviewed By: jingham, mib

Subscribers: MrHate, JDevlieghere

Differential Revision: https://reviews.llvm.org/D83757
2020-07-17 09:26:27 +02:00
Raphael Isemann 16926115ed [lldb] Only set the executable module for a target once
Summary:

When we try to find the executable module for our target we don't check
if we already have an executable module set. This causes that when debugging
a program that dlopens another executable, LLDB will take that other executable
as the new executable of the target (which causes that future launches of the
target will launch the dlopen'd executable instead of the original executable).

This just adds a check that we only set the executable when we haven't already
found one.

Fixes rdar://63443099

Reviewers: jasonmolenda, jingham, teemperor

Reviewed By: jasonmolenda, teemperor

Subscribers: jingham, JDevlieghere

Differential Revision: https://reviews.llvm.org/D80724
2020-07-17 08:35:38 +02:00
Jonas Devlieghere 2f99059aa0 [lldb/Test] Skip TestMacABImacOSFramework.py with reproducers
This test is hitting https://bugs.python.org/issue22393 which results in
the lit multiprocessing pool deadlocking and the reproducer job timing
out on GreenDragon.
2020-07-16 15:50:35 -07:00
serge-sans-paille 515bc8c155 Harmonize Python shebang
Differential Revision: https://reviews.llvm.org/D83857
2020-07-16 21:53:45 +02:00
Jaroslav Sevcik 93ec6cd684 [lldb] Desugar template specializations
Template specializations are not handled in many of the
TypeSystemClang methods. For example, GetNumChildren does not handle
the TemplateSpecialization type class, so template specializations
always look like empty objects.

This patch just desugars template specializations in the existing
RemoveWrappingTypes desugaring helper.

Differential Revision: https://reviews.llvm.org/D83858
2020-07-16 09:01:01 +02:00
Jonas Devlieghere c14e11b0bb [lldb/Test] Skip async process connect tests with reproducers
Reproducers only support synchronous mode.
2020-07-15 15:39:44 -07:00
Muhammad Omair Javaid 3c22996129 [LLDB] Disable lldb-vscode test_terminate_commands test on Arm
Summary:
test_terminate_commands is flaky on LLDB Arm buildbot as well. It was already
being skipped for aarch64. I am going to mark it skipped for Arm too.

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D81978
2020-07-16 03:33:52 +05:00
Jordan Rupprecht cf3f100fcb [lldb][test] Prevent infinite loop while looking for use_lldb_suite_root.py.
Several scripts (two copies of use_lldb_suite.py, and an __init__.py) look for use_lldb_suite_root.py by checking parent directories. If for some reason it doesn't exist, it keeps checking parent directories until it finds it.

However, this only breaks when the parent directory is None, but at least on Linux, dirname('/') == '/', so this will never be None.

This changes the lookup to stop if the dirname(lldb_root) is unchanged. This was previously fixed in 67f6d842fa, but only in one copy of this script.

Additionally, this makes the failure mode more visible -- if the root is not found, it complains loudly instead of silently failing, and having later modules that need lldb_root fail.

Differential Revision: https://reviews.llvm.org/D83840
2020-07-15 09:16:30 -07:00
Jonas Devlieghere 700dd17399 [lldb/Test] Remove support for forking a subprocess from the test suite.
Remove the forkSubprocess method and its bookkeeping.
TestCreateAfterAttach is the only test using the fork method and I'm not
convinced it adds enough to warrant the maintenance. Pavel suggested the
same thing in D83815.
2020-07-15 08:57:54 -07:00
Raphael Isemann 9c1c6a3fcc Revert "[lldb] Use the basename of the Python test for the log name instead of the class name"
This reverts commit 29aab9b5c7.

It seems on Windows the file name is just always "lldbsuite.test.lldbtest" for
all tests and that breaks pretty much everything. Reverting until we have
a better solution.
2020-07-15 16:26:37 +02:00
Raphael Isemann 10fd550d30 [lldb] Make expect_expr fall back to the dummy target if no target is selected
Summary:

Currently expect_expr will not run the expression if no target is selected. This
patch changes this behavior so that expect_expr will instead fall back to the
dummy target similar to what the `expression` command is doing. This way we
don't have to compile an empty executable to be able to use `expect_expr` (which
is a waste of resources for tests that just test generic type system features).

As a test I modernized the TestTypeOfDeclTypeExpr into a Python test +
expect_expr (as it relied on the dummy target fallback of the expression
command).

Reviewers: labath, JDevlieghere

Reviewed By: labath

Subscribers: abidh

Differential Revision: https://reviews.llvm.org/D83388
2020-07-15 13:56:00 +02:00
Raphael Isemann 29aab9b5c7 [lldb] Use the basename of the Python test for the log name instead of the class name
Summary:

From what I know we already have the restriction that every test in the test
suite needs to have a unique file name as that's used for generating the unique
build directory for a test. It seems there is also a restriction that every test
case class in the test suite needs to have a unique name as that's used to
generate the unique log file name for the test run.

This changes the log file format to use the basename of the test file instead so
that we only have to keep worrying about the 'unique file name' restriction from
now on.

This came up because I started naming the test classes "TestCase" (as repeating
the file name in the test class seems like redudant information that just makes
renaming tests a pain).

Reviewers: labath, JDevlieghere

Reviewed By: labath

Subscribers: mgorny, abidh

Differential Revision: https://reviews.llvm.org/D83767
2020-07-15 13:54:43 +02:00
Raphael Isemann 001c78de35 [lldb][formatters] Add support for printing NSConstantDate and fix distantPast value
Summary:

Certain `NSDate` constructors return a special `NSConstantDate` class which
currently ends up being unformatted as it's not in the list of supported classes
for the NSDate formatter. This patch adds that class to the supported class list
so LLDB produces a summary for it.

One of these special constructors is `[NSDate distantPast]` which returns the
date for `0001-01-01 00:00:00 UTC`. LLDB has a special case for formatting this
date but for some reason we did hardcode the wrong summary string in that
special case. Maybe the summary string was correct back when the code was
written but it isn't correct anymore (`distantPast` isn't actually defined to be
a special date but just some 'a guaranteed temporal boundary.' so maybe someone
changed the value in the last 10 years).

If someone else is wondering why we even have this special case for
`distantPast` but not for the future. The reason seems to be that our date
formatting for really old dates is off by 24 hours. So for example, adding one
second to `distantPast` will cause LLDB to print `0000-12-30 00:00:01 UTC`
(which is 24 hours behind the expected result). So to make our code appear to be
correct it seems we just hardcoded the most common NSDate result from that time
span. I'll replace that logic with a generic solution in a probably more
invasive follow up patch.

I also took the freedom to replace the magic value `-63114076800` with some
constant + documentation. I heard there are some people that don't know from the
top of their head that there are 63114076800 seconds between 1. Jan 0001 and 1.
January 2001 in whatever calendar system NSDate is using.

Reviewers: mib, davide

Reviewed By: mib

Subscribers: JDevlieghere

Differential Revision: https://reviews.llvm.org/D83217
2020-07-15 10:28:10 +02:00
Jonas Devlieghere 984e12ab48 [lldb/Test] Create reproducer dir if necessary
Create the reproducer directory under the build root if it doesn't
exists. The reproducer will only create the top level directory.
2020-07-14 16:17:53 -07:00
Jonas Devlieghere c6e8bf7287 [lldb/Test] Skip TestProcessConnect.py on Windows
Remote connections are not supported on Windows.
2020-07-14 14:07:06 -07:00
Jonas Devlieghere 4aafc479f2 [lldb/Test] Always set the cleanupSubprocesses tear down hook
Always clean up subprocesses on tear down instead of relying on the
caller to do so. This is not only less error prone but also means the
tests can be more concise.

Differential revision: https://reviews.llvm.org/D83787
2020-07-14 14:05:56 -07:00
Jonas Devlieghere f5f15acebb [lldb/Test] Skip TestProcessConnect.py on Windows
Skip TestProcessConnect.py on Windows and Android (the same platforms as
TestPlatformProcessConnect.py) and mark it as a NO_DEBUG_INFO test so we
don't run all the variants.
2020-07-14 10:12:40 -07:00
Jonas Devlieghere 706cccb889 [lldb] Make `process connect` blocking in synchronous mode.
In synchronous mode, the process connect command and its aliases should
wait for the stop event before claiming the command is complete.
Currently, the stop event is always handled asynchronously by the
debugger.

The implementation takes the same approach as Process::ResumeSynchronous
which hijacks the event and handles it on the current thread. Similarly,
after this patch, the stop event is part of the command return object,
which is the property used by the test case.

Differential revision: https://reviews.llvm.org/D83728
2020-07-14 08:45:34 -07:00
Walter Erquinigo 869d05fb3e [lldb-vscode] Fix TestVSCode_module
This test was added in https://reviews.llvm.org/D82477 and needs to wait a little bit before fetching some information.
2020-07-13 18:02:37 -07:00
Walter Erquinigo 77c9aafc5d Retry ""[lldb-vscode] Fix TestVSCode_module""
Original commit c60216db15.

The test can only run on Darwin because of how it was setup, so I'm
enforcing that.

Summary:

Test Plan:

Reviewers:

Subscribers:

Tasks:

Tags:
2020-07-13 14:12:03 -07:00
Jonas Devlieghere 8ee225744f [lldb/Test] Fix missing yaml2obj in Xcode standalone build.
Rather than trying to find the yaml2obj from dotest we should pass it in
like we do for dsymutil and FileCheck.
2020-07-10 21:34:56 -07:00
Walter Erquinigo c60216db15 Revert "[lldb-vscode] Fix TestVSCode_module"
This reverts commit 881af6eb00.

Revert "[lldb-vscode] Add Compile Unit List to Modules View"
This reverts commit 03ef61033f.

Revert "[lldb-vscode] Add Support for Module Event"
This reverts commit f7f8015975.

The debian buildbot has reported issues with the modules test.
http://lab.llvm.org:8011/builders/lldb-x86_64-debian/builds/13767/steps/test/logs/stdio

Reverting it for now.
2020-07-10 17:07:07 -07:00
Walter Erquinigo 881af6eb00 [lldb-vscode] Fix TestVSCode_module
For some reason this works on the original author's machine, but not on my. So I'm using a safer approach of using an unstripped dynamic library to place breakpoints on. The author was placing a breakpoint on the main symbol of a stripped library and for some reason it worked on their machine, but it shouldn't have...

Offender diff: D82477
2020-07-10 16:50:59 -07:00
Yifan Shen 03ef61033f [lldb-vscode] Add Compile Unit List to Modules View
Summary: User can expand and check compile unit list for the modules that have debug info.

Reviewers: wallace, clayborg

Reviewed By: clayborg

Subscribers: aprantl, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D83072
2020-07-10 16:50:59 -07:00
Yifan Shen f7f8015975 [lldb-vscode] Add Support for Module Event
Summary:
Whenever a module is created, removed or changed, lldb-vscode is now sending an event that can be interpreted by the IDE so that modules can be rendered in the IDE, like the tree view in this screenshot

{F12229758}

Reviewers: wallace, clayborg, kusmour, aadsm

Reviewed By: clayborg

Subscribers: cfe-commits, labath, lldb-commits

Tags: #lldb, #clang

Differential Revision: https://reviews.llvm.org/D82477
2020-07-10 16:50:59 -07:00
Amy Huang 227db86a1b Switch to using -debug-info-kind=constructor as default (from =limited)
Summary:
-debug-info-kind=constructor reduces the amount of class debug info that
is emitted; this patch switches to using this as the default.

Constructor homing emits the complete type info for a class only when the
constructor is emitted, so it is expected that there will be some classes that
are not defined in the debug info anymore because they are never constructed,
and we shouldn't need debug info for these classes.

I compared the PDB files for clang, and there are 273 class types that are defined with `=limited`
but not with `=constructor` (out of ~60,000 total class types).
We've looked at a number of the types that are no longer defined with =constructor. The vast
majority of cases are something like class A is used as a parameter in a member function of
some other class B, which is emitted. But the function that uses class A is never called, and class A
is never constructed, and therefore isn't emitted in the debug info.

Bug: https://bugs.llvm.org/show_bug.cgi?id=46537

Subscribers: aprantl, cfe-commits, lldb-commits

Tags: #clang, #lldb

Differential Revision: https://reviews.llvm.org/D79147
2020-07-09 15:26:46 -07:00
Jonas Devlieghere 10aa9e19fa [LLDB/Reproducers] Add flag to avoid installing the signal handler.
There are bugs where you don't want the signal handler to trigger, most
notably when that will cause another crash. Examples of this are lldb
running out of memory or a bug in the reproducer generation code. This
adds an escape hatch trough a (developer oriented) flag to not install
the signal handler.

rdar://problem/65149595

Differential revision: https://reviews.llvm.org/D83496
2020-07-09 11:50:45 -07:00
Jonas Devlieghere 84557c18b3 [lldb/Reproducers] Rename developer-oriented reproducer flags.
This is a preparatory rename of the developer facing reproducer flags.

reproducer-skip-version-check -> reproducer-no-version-check
reproducer-auto-generate      -> reproducer-generate-on-quit
2020-07-09 11:50:45 -07:00
Adrian Prantl 15149e4064 Fix debugserver reporting of deployment target
This patch fixes debugserver incorrectly returning the SDK version
instead of the minimum deployment target version.

rdar://problem/65001691

Differential Revision: https://reviews.llvm.org/D83443
2020-07-08 17:21:43 -07:00
Davide Italiano 27d52cd86a Revert "[lldb/API] Overwrite variables with SBLaunchInfo::SetEnvironment(append=true)"
This reverts commit 695b33a569 beacuse
it broke the macOS bot.
2020-07-08 13:09:24 -07:00
shafik 63b0f8c788 [RecordLayout] Fix ItaniumRecordLayoutBuilder so that is grabs the correct bases class offsets from the external source
Currently the ItaniumRecordLayoutBuilder when laying out base classes has the virtual
and non-virtual bases mixed up when pulling the base class layouts from the external source.

This came up in an LLDB bug where on arm64 because of differences in how it deals with
tail padding would layout the bases differently without the correct layout from the
external source (LLDB). This would result in some fields being off by 4 bytes.

Differential Revision: https://reviews.llvm.org/D83008
2020-07-08 10:07:15 -07:00
Pavel Labath 695b33a569 [lldb/API] Overwrite variables with SBLaunchInfo::SetEnvironment(append=true)
Summary:
This function was documented to overwrite entries with D76111, which was
adding a couple of similar functions. However, this function (unlike the
functions added in that patch) was/is not actually overwriting variables
-- any pre-existing variables would get ignored.

This behavior does not seem to be intentional. In fact, before the refactor in
D41359, this function could introduce duplicate entries, which could
have very surprising effects both inside lldb and on other applications
(some applications would take the first value, some the second one; in
lldb, attempting to unset a variable could make the second variable
become active, etc.).

Overwriting seems to be the most reasonable behavior here, so change the
code to match documentation.

Reviewers: clayborg, wallace, jingham

Subscribers: lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D83306
2020-07-08 13:35:31 +02:00
Raphael Isemann e9f943429c [lldb] Skip TestIOHandlerResizeNoEditline on Windows
It seems opening the empty file and trying use that file object as an input
stream doesn't work on Windows. Skipping it for now.
2020-07-08 11:45:38 +02:00
Muhammad Omair Javaid 1f780c997c [LLDB] Disable flaky lldb-vscode tests on arm
Summary:
These two tests are flaky on lldb Arm buildbot as well. They are already
being skipped for aarch64. I am going to mark them skipped for Arm.

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D81978
2020-07-08 07:07:10 +05:00
Med Ismail Bennani 7177e63fb5 [lldb/Core] Fix crash in ValueObject::CreateChildAtIndex
The patch fixes a crash in ValueObject::CreateChildAtIndex caused by a
null pointer dereferencing. This is a corner case that is happening when
trying to dereference a variable with an incomplete type, and this same
variable doesn't have a synthetic value to get the child ValueObject.

If this happens, lldb will now return a null pointer that will results
in an error message.

rdar://65181171

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2020-07-07 20:37:13 +02:00
Raphael Isemann de0175d04b [lldb] Make TestIOHandlerResizeNoEditline pass with Python 2
io.BytesIO seems to produce a stream in Python 2 which isn't recognized
as a file object in the SWIG API, so this test fails for Python 2 (and I assume
also an old SWIG version needs to be involved).

Instead just open an empty input file which is a file object in all Python
versions to make this test pass everywhere.
2020-07-07 13:54:14 +02:00
Raphael Isemann 5814255e1a [lldb] Always round down in NSDate's formatter to match NSDate's builtin format
Summary:

When printing an NSDate (for example with `NSLog` or `po`) the seconds value is
always rounded down. LLDB's own formatter however isn't following that behaviour
which leads to situations where the formatted result is sometimes one second
off. For example:

```
(lldb) p [NSDate dateWithTimeIntervalSince1970:0.1]
(__NSTaggedDate *) $1 = [...] 1970-01-01 00:00:01 UTC
(lldb) po [NSDate dateWithTimeIntervalSince1970:0.1]
1970-01-01 00:00:00 +0000

(lldb) p [NSDate dateWithTimeIntervalSince1970:0.6]
(__NSTaggedDate *) $4 =[...] 1970-01-01 00:00:01 UTC
(lldb) po [NSDate dateWithTimeIntervalSince1970:0.6]
1970-01-01 00:00:00 +0000
```

This patch just always rounds down the seconds value we get from the NSDate
object.

Fixes rdar://65084800

Reviewers: mib, davide

Reviewed By: mib

Subscribers: JDevlieghere

Differential Revision: https://reviews.llvm.org/D83221
2020-07-06 16:59:37 +02:00
Pavel Labath b65d4b23f6 [lldb/DWARF] Look for complete array element definitions in other modules
This applies the same logic we have for incomplete class bases and
members to array element types.
2020-07-06 10:09:13 +02:00
Pavel Labath b3b952873f [lldb/DWARF] Look for complete member definitions in other modules
With -flimit-debug-info, we can have a definition of a class, but no
definition for some of its members. This extends the same logic we were
using for incomplete base classes to cover incomplete members too.

Test forward-declarations.s is removed as it is no longer applicable --
we don't warn anymore when encountering incomplete members as they could
be completed elsewhere. New checks added to TestLimitDebugInfo cover the
handling of incomplete members more thoroughly.
2020-07-03 16:50:49 +02:00
Pavel Labath b725142c8d [lldb] Fix type conversion in the Scalar getters
Summary:
The Scalar class claims to follow the C type conversion rules. This is
true for the Promote function, but it is not true for the implicit
conversions done in the getter methods.

These functions had a subtle bug: when extending the type, they used the
signedness of the *target* type in order to determine whether to do
sign-extension or zero-extension. This is not how things work in C,
which uses the signedness of the *source* type. I.e., C does
(sign-)extension before it does signed->unsigned conversion, and not the
other way around.

This means that: (unsigned long)(int)-1
      is equal to (unsigned long)0xffffffffffffffff
      and not (unsigned long)0x00000000ffffffff

Unsurprisingly, we have accumulated code which depended on this
inconsistent behavior. It mainly manifested itself as code calling
"ULongLong/SLongLong" as a way to get the value of the Scalar object in
a primitive type that is "large enough". Previously, the ULongLong
conversion did not do sign-extension, but now it does.

This patch makes the Scalar getters consistent with the declared
semantics, and fixes the couple of call sites that were using it
incorrectly.

Reviewers: teemperor, JDevlieghere

Subscribers: lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D82772
2020-07-02 18:02:57 +02:00
Pavel Labath c1f1db8502 [lldb] Add a host-independent test for handling -flimit-debug-info
This complements the existing TestLimitDebugInfo.py, which tests this
scenario more comprehensively, but is not able to run on all hosts.
Specifically, it's hard to trigger this code from windows because clang
tries hard to ensure that debug info for types marked with
__declspec(dllexport) is emitted even under -flimit-debug-info (and
dllexport is needed to use a type across shared libraries).

This assembly-based test serves two purposes:
- it tests that -flimit-debug-info code path works for windows binaries
  (even though the aforementioned feature means its less likely to be
  used there)
- it gives basic test coverage for the -flimit-debug-info handling code
  when running the test suite on windows hosts.
2020-07-02 15:51:20 +02:00
Pavel Labath d6343e607a [lldb] Skip TestLimitDebugInfo on windows
The test does not work on windows, because clang will emit full type
information for __declspec(dllexport) types even under
-flimit-debug-info. __declspec(dllexport) is needed to be able to use
the type across shared library boundaries on windows, which makes this a
pretty good heuristic, but defeats the purpose of this test.

I am going to create (in another patch) an basic assembly test, so that
the relevant code gets at least some coverage on windows hosts.

This also reverts commit 1276855f2b, which
added the __declspec annotations -- they are not necessary anymore, and
they needlessly complicate the test.
2020-07-02 14:34:33 +02:00
Fred Riss c9f251aa6f [lldb/build.py] Always pass an SDK to the compiler on Darwin
On macOS 11, system libraries which are part of the shared cache
are not present on the filesystem anymore. This causes issues
with build.py, because it fails to link binaries with libSystem
or libc++.

The real issue is that build.py was not passing an SDK to the
compiler. The script accepts an argument for the SDK, but it
is currently unused. This patch just threads the SDK through
to the compile and link steps and this fixes a bunch of Shell
test failures on very recent macOS builds.
2020-07-01 20:27:38 -07:00
Adrian Prantl 116b103373 Revert "Revert "Improve the detection of iOS/tvOS/watchOS simulator binaries in""
This reverts commit 98c3a38a19.
2020-07-01 11:06:15 -07:00
Jonas Devlieghere 98c3a38a19 Revert "Improve the detection of iOS/tvOS/watchOS simulator binaries in"
This reverts commit 0da0437b2a to unbreak
the following tests:

lldb-api.tools/lldb-server.TestAppleSimulatorOSType.py
lldb-api.tools/lldb-server.TestGdbRemoteAttach.py
lldb-api.tools/lldb-server.TestGdbRemoteProcessInfo.py
lldb-api.tools/lldb-server.TestGdbRemoteRegisterState.py
lldb-api.tools/lldb-server.TestGdbRemoteThreadsInStopReply.py
lldb-api.tools/lldb-server.TestLldbGdbServer.py
2020-07-01 10:46:19 -07:00
Raphael Isemann 9010cef2af [lldb] Replace StringConvert with llvm::to_integer when parsing integer values in CommandObjects
Summary:

This replaces the current use of LLDB's own `StringConvert` with LLVM's
`to_integer` which has a less error-prone API and doesn't use special 'error
values' to designate parsing problems.

Where needed I also added missing error handling code that prints a parsing
error instead of continuing with the error value returned from `StringConvert`
(which either gave a cryptic error message or just took the error value
performed an incorrect action with it. For example, `frame recognizer delete -1`
just deleted the frame recognizer at index 0).

Reviewers: #lldb, labath

Reviewed By: labath

Subscribers: labath, abidh, JDevlieghere

Differential Revision: https://reviews.llvm.org/D82297
2020-07-01 17:19:31 +02:00
Pavel Labath 1276855f2b [lldb] Attempt to fix TestLimitDebugInfo on windows
The test fails due to link errors. I believe this change should fix
that.
2020-07-01 16:56:56 +02:00
Pavel Labath a03dc8c9fa [lldb] Add basic -flimit-debug-info support to expression evaluator
Summary:
This patch adds support for evaluation of expressions referring to types
which were compiled in -flimit-debug-info (a.k.a -fno-standalone-debug)
in clang. In this mode it's possible that the debug information needed
to fully describe a c++ type is not present in a single shared library
-- for example debug info for a base class or a member of a type can
only be found in another shared library.  This situation is not
currently handled well within lldb as we are limited to searching within
a single shared library (lldb_private::Module) when searching for the
definition of these types.

The way that this patch gets around this limitation is by doing the
search at a later stage -- during the construction of the expression ast
context. This works by having the parser (currently SymbolFileDWARF, but
a similar approach is probably needed for PDBs too) mark a type as
"forcefully completed". What this means is that the parser has marked
the type as "complete" in the module ast context (as this is necessary
to e.g. derive classes from it), but its definition is not really there.
This is done via a new field on the ClangASTMetadata struct.

Later, when we are importing such a type into the expression ast, we
check this flag. If the flag is set, we try to find a better definition
for the type in other shared libraries. We do this by initiating a
new lookup for the "forcefully completed" classes, which then imports the
type from a module with a full definition.

This patch only implements this handling for base classes, but other
cases (members, array element types, etc.). The changes for that should
be fairly simple and mostly revolve around marking these types as
"forcefully completed" at an approriate time -- the importing logic is
generic already.

Another aspect, which is also not handled by this patch is viewing these
types via the "frame variable" command. This does not use the AST
importer and so it will need to handle these types on its own -- that
will be the subject of another patch.

Differential Revision: https://reviews.llvm.org/D81561
2020-07-01 14:50:14 +02:00
Med Ismail Bennani f70cad2612
[lldb/api] Improve error reporting in SBBreakpoint::AddName (NFCI)
This patch improves the error reporting for SBBreakpoint::AddName by
adding a new method `SBBreakpoint::AddNameWithErrorHandling` that returns
a SBError instead of a boolean.

This way, if the breakpoint naming failed in the backend, the client
(i.e. Xcode), will be able to report the reason of that failure to the
user.

rdar://64765461

Differential Revision: https://reviews.llvm.org/D82879

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2020-07-01 12:45:05 +02:00
Med Ismail Bennani a61f62a7b6 Revert "[lldb/api] Improve error reporting in SBBreakpoint::AddName (NFCI)"
This reverts commit 56bb1d1755.
2020-07-01 12:41:32 +02:00
Med Ismail Bennani 56bb1d1755 [lldb/api] Improve error reporting in SBBreakpoint::AddName (NFCI)
This patch improves the error reporting for SBBreakpoint::AddName by
adding a new method `SBBreakpoint::AddNameWithErrorHandling` that returns
a SBError instead of a boolean.

This way, if the breakpoint naming failed in the backend, the client
(i.e. Xcode), will be able to report the reason of that failure to the
user.

rdar://64765461

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2020-07-01 12:37:00 +02:00
Davide Italiano 983a4b520e Skip arm-(fp|gp)-read.test on Darwin.
Our assembler doesn't seem to grok floating point literals.

<rdar://problem/64951608>
2020-06-30 12:53:20 -07:00
Davide Italiano 4f1f253ce5 [TestReturnValue] Skip based on architecutre, not platform. 2020-06-30 12:48:23 -07:00
Jonas Devlieghere 66d9c0d4fc [lldb/Test] Skip TestIOHandlerResizeNoEditline with reproducers 2020-06-30 11:40:17 -07:00
Adrian Prantl 0da0437b2a Improve the detection of iOS/tvOS/watchOS simulator binaries in
debugserver and lldb

This patch improves the heuristics for correctly identifying simulator binaries on Darwin and adds support for simulators running on Apple Silicon.

rdar://problem/64046344

Differential Revision: https://reviews.llvm.org/D82616
2020-06-30 11:22:03 -07:00
Jonas Devlieghere 69b2d9f42f [lldb/Test] Skip recognizer tests when Python is disabled
The `frame recognizer` command only exists when Python scripting is
enabled. Therefore the test should be made conditional on Python.
Without it, the test fails with "'frame recognizer' is not a known
command."
2020-06-30 08:59:44 -07:00
Pavel Labath 35674976f0 [lldb/Test] Introduce "assertSuccess"
Summary:
A lot of our tests do 'self.assertTrue(error.Success()'. The problem
with that is that when this fails, it produces a completely useless
error message (False is not True) and the most important piece of
information -- the actual error message -- is completely hidden.

Sometimes we mitigate that by including the error message in the "msg"
argument, but this has two additional problems:
- as the msg argument is evaluated unconditionally, one needs to be
  careful to not trigger an exception when the operation was actually
  successful.
- it requires more typing, which means we often don't do it

assertSuccess solves these problems by taking the entire SBError object
as an argument. If the operation was unsuccessful, it can format a
reasonable error message itself. The function still accepts a "msg"
argument, which can include any additional context, but this context now
does not need to include the error message.

To demonstrate usage, I replace a number of existing assertTrue
assertions with the new function. As this process is not easily
automatable, I have just manually updated a representative sample. In
some cases, I did not update the code to use assertSuccess, but I went
for even higher-level assertion apis (runCmd, expect_expr), as these are
even shorter, and can produce even better failure messages.

Reviewers: teemperor, JDevlieghere

Subscribers: arphaman, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D82759
2020-06-30 15:41:03 +02:00
Gongyu Deng c37d25f0d1 [lldb] Tab completion for `frame recognizer delete`
Summary: Provided tab completion for command `frame recognizer delete`.

Reviewers: teemperor, JDevlieghere

Reviewed By: teemperor, JDevlieghere

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D81241
2020-06-30 13:50:14 +02:00
Gongyu Deng 80eb42281f [lldb] Tab completion for `frame select`
Summary: Provided the tab completion for command `frame select`.

Reviewers: teemperor, JDevlieghere

Reviewed By: teemperor

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D81177
2020-06-30 13:13:38 +02:00
Raphael Isemann 621f845679 [lldb] Modernize TestOperatorOverload.py asserts 2020-06-30 11:38:42 +02:00
Xing GUO fe08ab542b [DWARFYAML][debug_info] Replace 'InitialLength' with 'Format' and 'Length'.
'InitialLength' is replaced with 'Format' (DWARF32 by default) and 'Length' in this patch.
Besides, test cases for DWARFv4 and DWARFv5, DWARF32 and DWARF64 is
added.

Reviewed By: jhenderson

Differential Revision: https://reviews.llvm.org/D82622
2020-06-30 16:28:39 +08:00
Muhammad Omair Javaid 3936b753ba [LLDB] skip TestCreateDuringInstructionStep on aarch64/linux
TestCreateDuringInstructionStep have started failing again on
aarch64/linux after moving to new machine. I am going mark it skipped
for aarch64/linux.
2020-06-29 21:32:48 +05:00
Jonas Devlieghere 6292702d12 [lldb/Test] Skip TestVSCode_disconnect on Darwin
It's failing on the sanitized bot on GreenDragon.
2020-06-29 07:48:09 -07:00
Jonas Devlieghere b4180fe477 [lldb/Test] Disable eh-frame-augment-noop.test on macOS
The test fails on Darwin because a different Asynchronous UnwindPlan is
chosen:

  Asynchronous (not restricted to call-sites) UnwindPlan is 'assembly
  insn profiling'`

instead of what the test expects:

  Asynchronous (not restricted to call-sites) UnwindPlan is 'eh_frame
  CFI'
2020-06-26 15:59:59 -07:00
Raphael Isemann bb91520e4f [lldb] Re-add X-Fail for Windows to TestDollarInVariable
This got removed by accident in 048d11de43 when
the test was rewritten as a non-inline test.
2020-06-26 15:24:15 +02:00
Raphael Isemann 048d11de43 [lldb][NFC] Make TestDollarInVariable a non-inline test 2020-06-26 12:56:22 +02:00
Pavel Labath 5ed8765e2f [lldb/Unwind] Use eh_frame plan directly when it doesn't need to be augmented
Summary:
This fixes a bug in the logic for choosing the unwind plan. Based on the
comment in UnwindAssembly-x86, the intention was that a plan which
describes the function epilogue correctly does not need to be augmented
(and it should be used directly). However, the way this was implemented
(by returning false) meant that the higher level code
(FuncUnwinders::GetEHFrameAugmentedUnwindPlan) interpreted this as a
failure to produce _any_ plan and proceeded with other fallback options.
The fallback usually chosed for "asynchronous" plans was the
"instruction emulation" plan, which tended to fall over on certain
functions with multiple epilogues (that's a separate bug).

This patch simply changes the function to return true, which signals the
caller that the unmodified plan is ready to be used.

The attached test case demonstrates the case where we would previously
fall back to the instruction emulation plan, and unwind incorrectly --
the test asserts that the "augmented" eh_frame plan is used, and that
the unwind is correct.

Reviewers: jasonmolenda, jankratochvil

Subscribers: davide, echristo, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D82378
2020-06-26 11:46:47 +02:00
Davide Italiano c7eb06a880 [test] XFail TestStepNoDebug based on arch rather than OS 2020-06-25 16:23:59 -07:00
Davide Italiano 38135b2a7f [test] XFail TestSigtrampUnwind based on arch rather than OS 2020-06-25 16:22:52 -07:00
Davide Italiano 0df7be2344 [lldb/test] XFAIL TestHWBreakMultiThread on arch rather platform. 2020-06-25 16:21:23 -07:00
Davide Italiano d358ec4639 [lldb/test] Skip TestBreakpointThumbCodesection on arm64.
This test relies on thumb, which is a 32-bits feature only.
2020-06-25 16:20:27 -07:00
Raphael Isemann 4df7d852af [lldb][NFC] Use expect_expr in TestDollarInVariable 2020-06-25 19:07:55 +02:00
Jonas Devlieghere ed8184b781 [lldb/Lua] Redirect Lua stdout/stderr to the CommandReturnObject
Redirect the output of stdout and stderr to the CommandReturnObject for
one line commands.

Differential revision: https://reviews.llvm.org/D82412
2020-06-25 09:55:46 -07:00
Aleksandr Urakov 895529cfd8 [lldb][PDB] Constexpr static member values as AST literals
Summary:
When evaluating an expression referencing a constexpr static member variable, an
error is issued because the PDB does not specify a symbol with an address that
can be relocated against.

Rather than attempt to resolve the variable's value within the IR execution, the
values of all constants can be looked up and incorporated into the AST of the
record type as a literal, mirroring the original compiler AST.

This change applies to DIA and native PDB loaders.

Patch By: jackoalan

Reviewers: aleksandr.urakov, jasonmolenda, zturner, jdoerfert, teemperor

Reviewed By: aleksandr.urakov

Subscribers: sstefan1, lldb-commits, llvm-commits, #lldb

Tags: #lldb, #llvm

Differential Revision: https://reviews.llvm.org/D82160
2020-06-25 11:27:16 +03:00
Raphael Isemann cad79f73b6 [lldb][NFC] Use expect_expr in TestStructTypes.py 2020-06-24 22:12:17 +02:00
Walter Erquinigo d4ef569577 Disable a flaky lldb-vscode test on aarch64
Summary:
These tests isflaky only on this arch for some reason. It's testing important features and is not flaky on x86_64, so I'll investigate this arm issue separatedly.

A flaky run:
http://lab.llvm.org:8011/builders/lldb-aarch64-ubuntu/builds/5540/steps/test/logs/stdio

Diff that created those tests:
https://reviews.llvm.org/D81978
2020-06-24 11:09:21 -07:00
Walter Erquinigo 8e08422385 Disable flaky lldb-vscode tests on aarch64
Summary:
These two tests are flaky only on this arch for some reason. They are testing important features and are not flaky on x86_64, so I'll investigate this arm issue separatedly.

Some flaky runs:
http://lab.llvm.org:8011/builders/lldb-aarch64-ubuntu/builds/5517/steps/test/logs/stdio
http://lab.llvm.org:8011/builders/lldb-aarch64-ubuntu/builds/5527/steps/test/logs/stdio

Diff that created those tests:
https://reviews.llvm.org/D81978
2020-06-24 08:57:20 -07:00
Jonas Devlieghere 6507bc5621 [lldb/Test] Temporarily disable TestSimulatorPlatform.py 2020-06-23 22:41:01 -07:00
Walter Erquinigo 74ab1da028 Redo of Add terminateCommands to lldb-vscode protocol
Summary:
This redoes https://reviews.llvm.org/D79726 and fixes two things.
- The logic that determines whether to automatically disconnect during the tear down is not very dumb compared to the original implementation. Each test will determine whether to do that or not.
- The terminate commands and terminate event were being sent after the disconnect response was sent to the IDE. That was not good, as VSCode stops the debug session as soon as it receives a disconnect response. Now, the terminate event and terminateEvents are being executed before the disconnect response is sent. This ensures that any connection between the IDE and lldb-vscode is alive while the terminate commands are executed. Besides, it also allows displaying the output of the terminate commands on the debug console, as it's still alive.

Reviewers: clayborg, aadsm, kusmour, labath

Subscribers: lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D81978
2020-06-23 12:51:43 -07:00
Davide Italiano 33ece57241 Generalize TestFormattersBoolRefPtr to work on Apple Silicon. 2020-06-23 12:45:31 -07:00
Walter Erquinigo 0a9e7d0b6b [vscode] set default values for terminateDebuggee for the disconnect request
Summary:
Recently I've noticed that VSCode sometimes doesn't send the terminateDebuggee flag within the disconnectRequest,
even though lldb-vscode sets the terminateDebuggee capability correctly.
This has been causing that inferiors don't die after the debug session ends, and many users have reported issues because of this.

An easy way to mitigate this is to set better default values for the terminateDebuggee field in the disconnect request.
I'm assuming that for a launch request, the default will be true, and for attach it'll be false.

Reviewers: clayborg, labath, aadsm

Subscribers: lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D81200
2020-06-23 11:47:43 -07:00
Raphael Isemann d13c3e2f88 [lldb][NFC] Add some more tests for edge cases LLDB's builtin formatters
OSType with less than 8 bytes has special code that isn't tested yet.
The same for C-strings that don't have `const char *` type. Also we're now testing
escaping the ASCII escape sequence (\033).
2020-06-23 19:59:46 +02:00
Jonas Devlieghere fa1b4a96a0 [lldb/Lua] Use the debugger's output and error file for Lua's I/O library.
Add support for changing the stdout and stderr file in Lua's I/O library
and hook it up with the debugger's output and error file respectively
for the interactive Lua interpreter.

https://reviews.llvm.org/D82273
2020-06-23 09:05:51 -07:00
Jonas Devlieghere 1728dec255 [lldb/Lua] Recognize "quit" as a way to exit the script interpreter.
Add a way to quit the interactive script interpreter from a shell tests.
Currently, the only way (that I know) to exit the interactive Lua
interpreter is to send a EOF with CTRL-D. I noticed that the embedded
Python script interpreter accepts quit (while the regular python
interpreter doesn't). I've added a special case to the Lua interpreter
to do the same.

Differential revision: https://reviews.llvm.org/D82272
2020-06-22 09:27:12 -07:00
Raphael Isemann 79608371f1 [lldb][NFC] Add more test for builtin formats
Reland 90c1af106a . This changes the char format
tests which were printing the pointer value of the C-string instead of its
contents, so this test failed on other machines. Now they just print the
bytes in a uint128_t.

Original commit description:

The previous tests apparently missed a few code branches in DumpDataExtractor
code. Also renames the 'test_instruction' which had the same name as another
test (and Python therefore ignored the test entirely).
2020-06-22 15:13:41 +02:00
Eric Christopher 10b4354136 Temporarily Revert "[lldb][NFC] Add more test for builtin formats"
as it's failing on the debian buildbots:

http://lab.llvm.org:8011/builders/lldb-x86_64-debian/builds/12531

This reverts commit 90c1af106a.
2020-06-20 14:21:42 -07:00
Raphael Isemann 90c1af106a [lldb][NFC] Add more test for builtin formats
The previous tests apparently missed a few code branches in DumpDataExtractor
code. Also renames the 'test_instruction' which had the same name as another
test (and Python therefore ignored the test entirely).
2020-06-20 19:31:40 +02:00
Raphael Isemann ab888262b3 [lldb] Skip TestBuiltinFormats.py on arm for now 2020-06-20 11:22:44 +02:00
Jonas Devlieghere 8027f04a6d [lldb/Test] Disable TestBuiltinFormats.py on Windows
Disable the test to turn the Windows bot green again until Raphael has
time to investigate.
2020-06-19 22:41:29 -07:00
Jonas Devlieghere 7a9a341953 [lldb/Test] Temporarily skip watch simulator in TestSimulatorPlatform.py
The simulator doesn't launch on green-dragon-10.

rdar://problem/64552748
2020-06-19 22:41:29 -07:00
Raphael Isemann aa7cd42993 [lldb][NFC] Add test for builtin formats 2020-06-19 22:33:02 +02:00
Raphael Isemann be18df3d23 [lldb] Fix that SIGWINCH crashes IOHandlerEditline when we are not using the editline backend
Summary:
TerminalSizeChanged is called from our SIGWINCH signal handler but the
IOHandlerEditline currently doesn't check if we are actually using the real
editline backend. If we're not using the real editline backend, `m_editline_up`
won't be set and `IOHandlerEditline::TerminalSizeChanged` will access
the empty unique_ptr. In a real use case we don't use the editline backend
when we for example read input from a file. We also create some temporary
IOHandlerEditline's during LLDB startup it seems that are also treated
as non-interactive (apparently to read startup commands).

This patch just adds a nullptr check for`m_editline_up` as we do in the rest of
IOHandlerEditline.

Fixes rdar://problem/63921950

Reviewers: labath, friss

Reviewed By: friss

Subscribers: abidh, JDevlieghere

Differential Revision: https://reviews.llvm.org/D81729
2020-06-19 19:14:16 +02:00
Adrian Prantl 7e825abd57 Repair support for launching ios/tv/watch simulator binaries through platform
and delete a bunch (but not all) redundant code. If you compare the remaining implementations of Platform*Simulator.cpp, there is still an obvious leftover cleanup task.

Specifically, this patch

- removes SDK initialization from dotest (there is equivalent but more
  complete code in Makefile.rules)

- make Platform*Simulator inherit the generic implementation of
  PlatformAppleSimulator (more can be done here)

- simplify the platform logic in Makefile.rules

- replace the custom SDK finding logic in Platform*Simulator with XcodeSDK

- adds a test for each supported simulator

Differential Revision: https://reviews.llvm.org/D81980
2020-06-19 09:42:44 -07:00
Raphael Isemann 6331c7d0be [lldb] Disable complex tests on Windows
The tests fail to compile there:
```
complex/main.c:4:16: error: expected ';' at end of declaration
  float complex complex_float = -1.5f + -2.5f * I;
               ^
               ;
```
2020-06-19 18:40:08 +02:00
Raphael Isemann 85e7e3b1c9 [lldb] Fix TestComplexInt on ARM
On the buildbot long and int have the same size but long and long long don't,
so the bug where we find the first type by size will produce a different error.
Make the test dynamic based on int/long/long long size to fix the bot.
2020-06-19 17:47:16 +02:00
Raphael Isemann 3e66bd291f [lldb][NFC] Add test for C99 and GCC complex types
LLDB has a lot of code for supporting complex types but we don't have a single
test for it. This adds some basic tests and documents the found bugs.
2020-06-19 16:22:16 +02:00
Jonas Devlieghere 64c87a94ca [lldb/Test] Fix tests that rely on logfiles with reproducers.
Now that the log file is included in the reproducers, the path needs to
be remapped for the test to find the new file in the reproducer.
2020-06-17 10:09:06 -07:00
Muhammad Omair Javaid e29b31513f [lldb] Remove xfail aarch64/linux from TestBuiltinTrap.py
The underlying clang bug seems to have been fixed in and test is
consistently passing on aarch64-linux buildbot.
2020-06-17 15:48:59 +05:00
Jonas Devlieghere c151230533 [lldb/Test] Cleanup TestJITLoaderGDB and make it compatible with reproducers 2020-06-16 15:46:14 -07:00
Jonas Devlieghere c0f1dcf31e [lldb/Test] Pass the lldb_tool_dir when setting the lldb-repro substitutions
Otherwise LIT can't find the lldb-repro script in standalone builds.
2020-06-16 13:56:16 -07:00
Jonas Devlieghere 4dd3dfe8e3 [lldb/Python] Fix the infinitely looping Python prompt bug
Executing commands below will get you bombarded by a wall of Python
command prompts (>>> ).

$ echo 'foo' | ./bin/lldb -o script
$ cat /tmp/script
script
print("foo")
$ lldb --source /tmp/script

The issue is that our custom input reader doesn't handle EOF. According
to the Python documentation, file.readline always includes a trailing
newline character unless the file ends with an incomplete line. An empty
string signals EOF. This patch raises an EOFError when that happens.

[1] https://docs.python.org/2/library/stdtypes.html#file.readline

Differential revision: https://reviews.llvm.org/D81898
2020-06-16 11:05:19 -07:00
Xing GUO 8a2ff19272 [lldb][test] Trying to fix build bot after 0431e4bcb2 2020-06-13 23:53:13 +08:00
Raphael Isemann a8c755545b [lldb] Test creating persistent variables with $[digit] names 2020-06-12 16:12:33 +02:00
Raphael Isemann f52e4129a7 [lldb][NFC] Modernize TestPersistentVariables 2020-06-12 16:06:05 +02:00
Raphael Isemann 91728b9172 [lldb] Don't print IRForTarget errors directly to the console
Summary:

When we get an error back from IRForTarget we directly print that error to the
debugger output stream instead of putting it in the result object. The result
object only gets a vague "The expression could not be prepared to run in the
target" error message that doesn't actually tell the user what went wrong.

This patch just puts the IRForTarget errors into the status object that is
returned to the caller instead of directly printing it to the debugger. Also
updates one test that now can actually check for the error message it is
supposed to check for (instead of the default error which is all we had before).

Reviewers: JDevlieghere

Reviewed By: JDevlieghere

Differential Revision: https://reviews.llvm.org/D81654
2020-06-12 10:27:25 +02:00
Jonas Devlieghere 526e0c8d15 [lldb/Test] Fix ASan/TSan workaround for Xcode Python 3
The Python 3 interpreter in Xcode has a relative RPATH and dyld fails to
load it when we copy it into the build directory.

This patch adds an additional check that the copied binary can be
executed. If it doesn't, we assume we're dealing with the Xcode python
interpreter and return the path to the real executable. That is
sufficient for the sanitizers because only system binaries need to be
copied to work around SIP.

This patch also moves all that logic out of LLDBTest and into the lit
configuration so that it's executed only once per test run, instead of
once for every test. Although I didn't benchmark the difference this
should result in a mild speedup.

Differential revision: https://reviews.llvm.org/D81696
2020-06-11 19:36:42 -07:00
Jonas Devlieghere 8d8ec55035 [lldb/Test] Unify DYLD_INSERT_LIBRARIES solution for ASan and TSan
Add the same fix for loading the sanitizer runtime for TSan as we
currently have for ASan and unify the code with a helper function.
2020-06-11 16:04:46 -07:00
Ilya Bukonkin 3b43f00629 [lldb] Check if thread was suspended during previous stop added.
Encountered the following situation: Let we started thread T1 and it hit
breakpoint on B1 location. We suspended T1 and continued the process.
Then we started thread T2 which hit for example the same location B1.
This time in a breakpoint callback we decided not to stop returning
false.

Expected result: process continues (as if T2 did not hit breakpoint) its
workflow with T1 still suspended. Actual result: process do stops (as if
T2 callback returned true).

Solution: We need invalidate StopInfo for threads that was previously
suspended just because something that is already inactive can not be the
reason of stop. Thread::GetPrivateStopInfo() may be appropriate place to
do it, because it gets called (through Thread::GetStopInfo()) every time
before process reports stop and user gets chance to change
m_resume_state again i.e if we see m_resume_state == eStateSuspended
it definitely means it was set during previous stop and it also means
this thread can not be stopped again (cos' it was frozen during
previous stop).

Differential revision: https://reviews.llvm.org/D80112
2020-06-11 15:02:46 -07:00
Jonas Devlieghere 351823fbf1 [lldb/Test] Add 'std-module' category and skip them with reproducers
These tests are flaky on the reproducer bot. I suspect it has something
to do with the module cache. Skipping the whole category while I
investigate the issue.
2020-06-10 14:59:05 -07:00
Pavel Labath 42229b6de7 [lldb] XFAIL TestForwardDeclaration.test_debug_names on windows
Before 539b47c9 this test was not actually using the debug_names section
because the -gdwarf added by Makefile.rules on windows overrode the
-gdwarf-5 flag from CFLAGS_EXTRAS. Now that -gdwarf-5 is respected, the
test is failing.
2020-06-10 17:09:51 +02:00
Jonas Devlieghere 7dd86c9e7c [lldb/Reproducers] Skip test_remove_placeholder_add_real_module with reproducers
Modules are not orphaned and it finds the existing module with the same
UUID from test_partial_uuid_match.
2020-06-09 16:17:53 -07:00
Jaroslav Sevcik fac5d05eb7 [lldb] Fix and enable Windows minidump tests
SBFileSpec.fullpath always uses the forward slash to join the directory with the
base name. This causes mismatches when comparing Windows paths with backslashes
in two of the minidump tests. To get around that we just compare the directory
names separately from the filenames.

Reviewed By: labath

Differential Revision: https://reviews.llvm.org/D81465
2020-06-09 20:03:44 +00:00
Jonas Devlieghere de019b88dd [lldb/Interpreter] Support color in CommandReturnObject
Color the error: and warning: part of the CommandReturnObject output,
similar to how an error is printed from the driver when colors are
enabled.

Differential revision: https://reviews.llvm.org/D81058
2020-06-09 10:45:45 -07:00
Raphael Isemann 70a21887f7 [lldb] Test compatibility between a class type from a member function expr and its original version 2020-06-09 15:48:00 +02:00
Jan Kratochvil 4515d35f5c [lldb] Fix DW_TAG_GNU_call_site-DW_AT_low_pc as produced by GCC
D80519 <https://reviews.llvm.org/D80519>
added support for `DW_TAG_GNU_call_site` but
Bug 45886 <https://bugs.llvm.org/show_bug.cgi?id=45886>
found one case did not work.

There is:

  0x000000b1:     DW_TAG_GNU_call_site
                    DW_AT_low_pc  (0x000000000040111e)
                    DW_AT_abstract_origin (0x000000cc "a")
  ...
  0x000000cc:   DW_TAG_subprogram
                  DW_AT_name      ("a")
                  DW_AT_prototyped        (true)
                  DW_AT_low_pc    (0x0000000000401109)
                  ^^^^^^^^^^^^ - here it did overwrite the 'low_pc' variable containing value 0x40111e we wanted
                  DW_AT_high_pc   (0x0000000000401114)
                  DW_AT_frame_base        (DW_OP_call_frame_cfa)
                  DW_AT_GNU_all_call_sites        (true)

DW_TAG_GNU_call_site attributes order as produced by GCC:
0x000000b1:     DW_TAG_GNU_call_site
                  DW_AT_low_pc  (0x000000000040111e)
                  DW_AT_abstract_origin (0x000000cc "a")

clang produces the attributes in opposite order:
0x00000064:     DW_TAG_GNU_call_site
                  DW_AT_abstract_origin (0x0000002a "a")
                  DW_AT_low_pc  (0x0000000000401146)

Differential Revision: https://reviews.llvm.org/D81334
2020-06-09 13:41:41 +02:00
Pavel Labath 731fee8b42 [lldb] Fail evaluation of DWARF expressions with unknown opcodes
Previously, we were simply ignoring them and continuing the evaluation.
This behavior does not seem useful, because the resulting value will
most likely be completely bogus.
2020-06-08 15:52:28 +02:00
Pavel Labath 0081149f96 [lldb/DWARF] Fix PC value for artificial tail call frames for the "GNU" case
Summary:
The way that the support for the GNU dialect of tail call frames was
implemented in D80519 meant that the were reporting very bogus PC values
which pointed into the middle of an instruction: the -1 trick is
necessary for the address to resolve to the right function, but we
should still be reporting a more realistic PC value -- I say "realistic"
and not "real", because it's very debatable what should be the correct
PC value for frames like this.

This patch achieves that my moving the -1 from SymbolFileDWARF into the
stack frame computation code. The idea is that SymbolFileDWARF will
merely report whether it has provided an address of the instruction
after the tail call, or the address of the call instruction itself. The
StackFrameList machinery uses this information to set the "behaves like
frame zero" property of the artificial frames (the main thing this flag
does is it controls the -1 subtraction when looking up the function
address).

This required a moderate refactor of the CallEdge class, because it was
implicitly assuming that edges pointing after the call were real calls
and those pointing the the call insn were tail calls. The class now
carries this information explicitly -- it carries three mostly
independent pieces of information:
- an address of interest in the caller
- a bit saying whether this address points to the call insn or after it
- whether this is a tail call

Reviewers: vsk, dblaikie

Subscribers: aprantl, mgrang, lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D81010
2020-06-08 14:44:36 +02:00
Jaroslav Sevcik 6143874f73 [lldb] Disable remove-add module test on Windows
This disables the test introduced by
1beffc1888
on Windows.

Reviewed By: labath

Differential Revision: https://reviews.llvm.org/D81363
2020-06-08 08:21:07 +00:00
Jaroslav Sevcik 1beffc1888 Support build-ids of other sizes than 16 in UUID::SetFromStringRef
SBTarget::AddModule currently handles the UUID parameter in a very
weird way: UUIDs with more than 16 bytes are trimmed to 16 bytes. On
the other hand, shorter-than-16-bytes UUIDs are completely ignored. In
this patch, we change the parsing code to handle UUIDs of arbitrary
size.

To support arbitrary size UUIDs in SBTarget::AddModule, this patch
changes UUID::SetFromStringRef to parse UUIDs of arbitrary length. We
subtly change the semantics of SetFromStringRef - SetFromStringRef now
only succeeds if the entire input is consumed to prevent some
prefix-parsing confusion. This is up for discussion, but I believe
this is more consistent - we always return false for invalid UUIDs
rather than sometimes truncating to a valid prefix. Also, all the
call-sites except the API and interpreter seem to expect to consume
the entire input.

This also adds tests for adding existing modules 4-, 16-, and 20-byte
build-ids. Finally, we took the liberty of testing the minidump
scenario we care about - removing placeholder module from minidump and
replacing it with the real module.

Reviewed By: labath, friss

Differential Revision: https://reviews.llvm.org/D80755
2020-06-07 10:03:41 +00:00
Jan Kratochvil 8fc1e307f9 [lldb] [nfc] Fix comment in testcase DW_TAG_variable-DW_AT_const_value.s 2020-06-06 23:31:30 +02:00
Jim Ingham a976a7fcae Disable this test for Windows.
The printf expression crashes with the message:

Attempted to dereference an invalid pointer

Someone who knows more about Windows should suggest how to fix this.
2020-06-04 10:51:01 -07:00
Jan Kratochvil 476f520a0b [lldb] Fix SLEB128 decoding
Bug 46181 shows SLEB128 0xED9A924C00011151 decoded as 0xffffffff80011151.
        LLDB show a wrong value for function argument
        https://bugs.llvm.org/show_bug.cgi?id=46181

Differential Revision: https://reviews.llvm.org/D81119
2020-06-04 19:41:24 +02:00
Gongyu Deng 2e8f304f5e [lldb] tab completion for `command script delete'
Summary: Added the tab completion for `command script delete`.

Reviewers: teemperor, JDevlieghere

Reviewed By: teemperor

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D80775
2020-06-04 10:19:03 +02:00
Jim Ingham f4d4273265 Add a test for preserving state on the non-expr thread across expression evaluation.
There may be another test that tests this but I couldn't find one.
2020-06-03 14:30:35 -07:00
Vedant Kumar 4699a7e230 [lldb/StringPrinter] Support strings with invalid utf8 sub-sequences
Support printing strings which contain invalid utf8 sub-sequences, e.g.
strings like "hello world \xfe", instead of bailing out with "Summary
Unavailable".

I took the opportunity here to delete some hand-rolled utf8 -> utf32
conversion code and replace it with calls into llvm's Support library.

rdar://61554346
2020-06-03 12:24:23 -07:00
Muhammad Omair Javaid 884aaf7f64 [LLDB] skip TestCreateDuringInstructionStep on arm/linux
There are sporadic failures in this test on arm. I am marking it
skipped as labath suggested flaky decorators no longer work.
2020-06-03 16:18:41 +05:00
Pavel Labath de04375ac5 [lldb] Skip tests exercising DW_OP_GNU_entry_value with dsymutil
It seems that this opcode needs explicit support in dsymutil. Disable
these tests until that is implemented.
2020-06-02 18:31:15 +02:00
Pavel Labath bddd288826 [lldb/DWARF] Add support for pre-standard GNU call site attributes
Summary:
The code changes are very straight-forward -- just handle both DW_AT_GNU
and DW_AT_call versions of all tags and attributes. There is just one
small gotcha: in the GNU version, DW_AT_low_pc was used both for the
"return pc" and the "call pc" values, depending on whether the tag was
describing a tail call, while the official scheme uses different
attributes for the two things.

Reviewers: vsk, dblaikie

Subscribers: lldb-commits

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D80519
2020-06-02 12:57:51 +02:00
Muhammad Omair Javaid cbfae97ca8 [LLDB] Mark TestCreateDuringInstructionStep as flaky on Linux
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.
2020-06-02 14:08:28 +05:00
Jonas Devlieghere 382f6d37a1 [lldb/Test] Add test for man page and lldb --help output 2020-06-01 13:04:45 -07:00
Jonas Devlieghere 2388a096e7 [lldb/Test] use GetLoadAddress from scripted thread plan
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.
2020-05-29 23:04:08 -07:00
Jonas Devlieghere 0800529fe6 [lldb/Bindings] Raise exception when using properties that rely on lldb.target
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
2020-05-29 22:11:21 -07:00
Fred Riss 977f00123a [lldb/test] Fix TestAppleSimulatorOSType when multiple runtimes are installed
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.
2020-05-29 08:30:04 -07:00
Pavel Labath 2c22c14735 [lldb] Make "inline" tests more configurable
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
2020-05-29 11:36:11 +02:00
Jonas Devlieghere b950c261d9 [lldb/Reproducers] Add top-level-target check-lldb-reproducers
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.
2020-05-28 10:48:16 -07:00
Jim Ingham 723a1caa37 Fix the crashlog.py script's use of the load_address property.
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
2020-05-28 09:55:40 -07:00
Jonas Devlieghere e5bb542362 [lldb/Test] Import all decorators.
Fixes "NameError: name 'skipIfReproducer' is not defined".
2020-05-27 21:13:08 -07:00
Jonas Devlieghere 5238b80058 [lldb/Reproducers] Skip or fix the remaining tests.
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
2020-05-27 21:02:36 -07:00
Jonas Devlieghere f9bea9bc4a [lldb/Reproducers] Skip & add FIXME to tests failing with unexpected packet.
Add skip decorator to tests failing with an unexpected packet during
passive replay.
2020-05-27 13:52:48 -07:00
Jonas Devlieghere 5f97a540ad [lldb/Reproducers] Differentiate active and passive replay unexpected packet. 2020-05-27 13:52:38 -07:00
Jonas Devlieghere c30c2368c7 [lldb/Reproducers] Skip tests relying on timeouts
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.
2020-05-27 12:08:41 -07:00
Jonas Devlieghere fe9d8442e0 [lldb/Test] Generate YAML binary in build directory
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.
2020-05-27 12:08:41 -07:00
Raphael Isemann 74a51753a6 [lldb] Make order of completions for expressions deterministic and sorted by Clang's priority values.
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
2020-05-27 19:22:01 +02:00
Gongyu Deng 763bc23057 [lldb] Tab completion for process plugin name
Summary:

1. Added tab completion to `process launch -p`, `process attach -P`, `process
connect -p`;

2. Bound the plugin name common completion as the default completion for
`eArgTypePlugin` arguments.

Reviewers: teemperor, JDevlieghere

Tags: #lldb

Differential Revision: https://reviews.llvm.org/D79929
2020-05-27 14:11:16 +02:00
Raphael Isemann 019bd6485c [lldb] Don't complete ObjCInterfaceDecls in ClangExternalASTSourceCallbacks::FindExternalVisibleDeclsByName
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
2020-05-27 12:39:24 +02:00
Jonas Devlieghere e724db0375 [lldb/Test] Modify TestSymbolTable.py for reproducers
Work around global module caching during reproducer replay. See inline
comment for the details.
2020-05-26 17:07:41 -07:00