Commit Graph

24017 Commits

Author SHA1 Message Date
Fangrui Song ce5e21868c [lldb] Fix build after found_decls was removed by 1f40d60a3b 2020-12-01 19:14:35 -08:00
Muhammad Omair Javaid fa7fabb644 [LLDB] Rename duplicate TestAlignAsBaseClass.py
lldb-dotest breaks due to duplicate TestAlignAsBaseClass.py. I have
renamed later version to TestAlignAsBaseClassNonTemplateParam.py.
2020-12-02 07:31:29 +05:00
David Blaikie 615f63e149 Revert "[FastISel] Flush local value map on ever instruction" and dependent patches
This reverts commit cf1c774d6a.

This change caused several regressions in the gdb test suite - at least
a sample of which was due to line zero instructions making breakpoints
un-lined. I think they're worth investigating/understanding more (&
possibly addressing) before moving forward with this change.

Revert "[FastISel] NFC: Clean up unnecessary bookkeeping"
This reverts commit 3fd39d3694.

Revert "[FastISel] NFC: Remove obsolete -fast-isel-sink-local-values option"
This reverts commit a474657e30.

Revert "Remove static function unused after cf1c774."
This reverts commit dc35368ccf.

Revert "[lldb] Fix TestThreadStepOut.py after "Flush local value map on every instruction""
This reverts commit 53a14a47ee.
2020-12-01 14:26:23 -08:00
Michał Górny e1f613ce3c [lldb] [test] Reenable two passing tests on FreeBSD
[Reenable TestReproducerAttach and TestThreadSpecificBpPlusCondition
on FreeBSD -- both seem to pass correctly now.
2020-12-01 23:25:45 +01:00
Muhammad Omair Javaid 78cb4562fa Make offset field optional in RegisterInfo packet for Arm64
This patch carries forward our aim to remove offset field from qRegisterInfo
packets and XML register description. I have created a new function which
returns if offset fields are dynamic meaning client can calculate offset on
its own based on register number sequence and register size. For now this
function only returns true for NativeRegisterContextLinux_arm64 but we can
test this for other architectures and make it standard later.

As a consequence we do not send offset field from lldb-server (arm64 for now)
while other stubs dont have an offset field so it wont effect them for now.
On the client side we have replaced previous offset calculation algorithm
with a new scheme, where we sort all primary registers in increasing
order of remote regnum and then calculate offset incrementally.

This committ also includes a test to verify all of above functionality
on Arm64.

Reviewed By: labath

Differential Revision: https://reviews.llvm.org/D91241
2020-12-02 03:19:43 +05:00
Muhammad Omair Javaid 26b8ea2e37 RegisterInfoPOSIX_arm64 remove unused bytes from g/G packet
This came up while putting together our new strategy to create g/G packets
in compliance with GDB RSP protocol where register offsets are calculated in
increasing order of register numbers without any unused spacing.

RegisterInfoPOSIX_arm64::GPR size was being calculated after alignment
correction to 8 bytes which meant there was a 4 bytes unused space between
last gpr (cpsr) and first vector register V. We have put LLVM_PACKED_START
decorator on RegisterInfoPOSIX_arm64::GPR to make sure single byte
alignment is enforced. Moreover we are now doing to use arm64 user_pt_regs
struct defined in ptrace.h for accessing ptrace user registers.

Reviewed By: labath

Differential Revision: https://reviews.llvm.org/D92063
2020-12-02 03:19:39 +05:00
Raphael Isemann 64f04629aa [lldb][NFC] Modernize and cleanup TestClassTemplateParameterPack
* Un-inline the test.
* Use expect_expr everywhere and also check all involved types.
* Clang-format the test sources.
* Explain what we're actually testing with the 'C' and 'D' templates.
* Split out the non-template-parameter-pack part of the test into its own small test.
2020-12-01 15:53:40 +01:00
Jonas Devlieghere 173bb3c2eb [lldb] Refactor GetDeviceSupportDirectoryNames and GetPlatformName (NFC)
Both functions are effectively returning a single string literal. Change
the interface to return a llvm::StringRef instead of populating a vector
of std::strings or returning a std::string respectively.
2020-11-30 19:37:12 -08:00
Jonas Devlieghere 1b9f214efc [lldb] Give TestDefaultTemplateArgs a unique class name
Multiple tests cannot share the same test class name.
2020-11-30 14:41:35 -08:00
Raphael Isemann e0e7bbeb54 [lldb] Always include template arguments that have their default value in the internal type name
Our type formatters/summaries match on the internal type name we generate in LLDB for Clang types.

These names were generated using Clang's default printing policy. However Clang's
default printing policy got tweaked over the last month to make the generated type
names more readable (by for example excluding inline/anonymous namespaces and
removing template arguments that have their default value). This broke the formatter
system where LLDB's matching logic now no longer can format certain types as
the new type names generated by Clang's default printing policy no longer match
the type names that LLDB/the user specified.

I already introduced LLDB's own type printing policy and fixed the inline/anonymous
namespaces in da121fff11 (just to get the
test suite passing again).

This patch is restoring the old type printing behaviour where always include the template
arguments in the internal type name (even if they match the default args). This should get
template type formatters/summaries working again in the rare situation where we do
know template default arguments within LLDB. This can only happen when either having
a template that was parsed in the expression parser or when we get type information from a C++ module.

The Clang change that removed defaulted template arguments from Clang's printing policy was
e7f3e2103c

Reviewed By: labath

Differential Revision: https://reviews.llvm.org/D92311
2020-11-30 16:40:50 +01:00
Pedro Tammela a0d7406ae8 [LLDB/Lua] add support for one-liner breakpoint callback
These callbacks are set using the following:
   breakpoint command add -s lua -o "print('hello world!')"

The user supplied script is executed as:
   function (frame, bp_loc, ...)
      <body>
   end

So the local variables 'frame', 'bp_loc' and vararg are all accessible.
Any global variables declared will persist in the Lua interpreter.
A user should never hold 'frame' and 'bp_loc' in a global variable as
these userdatas are context dependent.

Differential Revision: https://reviews.llvm.org/D91508
2020-11-30 14:12:26 +00:00
Muhammad Omair Javaid 4e8aeb97ca Send SVE vg register in custom expedited registerset
This patch ovverides GetExpeditedRegisterSet for
NativeRegisterContextLinux_arm64 to send vector granule register in
expedited register set if SVE mode is selected.

Reviewed By: labath

Differential Revision: https://reviews.llvm.org/D82855
2020-11-30 17:34:19 +05:00
Muhammad Omair Javaid b69c09bf43 Support custom expedited register set in gdb-remote
This patch adds capability to introduce a custom expedited register set
in gdb remote. Currently we send register set 0 as expedited register set
but for the case of AArch64 SVE we intend to send additional information
about SVE registers size/offset configuration which can be calculated
from vg register. Therefore we will expedited Vg register in case of
AArch64 is in SVE mode to speedup register configuration calculations.

Reviewed By: labath

Differential Revision: https://reviews.llvm.org/D82853
2020-11-30 17:34:19 +05:00
David Spickett a7f8d96b16 [lldb] Use llvm::Optional for port in LaunchGDBServer
Previously we used UINT16_MAX to mean no port/no specifc
port. This leads to confusion because 65535 is a valid
port number.

Instead use an optional. If you want a specific port call
LaunchGDBServer as normal, otherwise pass an empty optional
and it will be set to the port that gets chosen.
(or left empty in the case where we fail to find a port)

Reviewed By: labath

Differential Revision: https://reviews.llvm.org/D92035
2020-11-30 11:20:39 +00:00
David Spickett 98e87f76d0 [lldb] Error when there are no ports to launch a gdbserver on
Previously if you did:
$ lldb-server platform --server <...> --min-gdbserver-port 12346
--max-gdbserver-port 12347
(meaning only use port 12346 for gdbservers)

Then tried to launch two gdbservers on the same connection,
the second one would return port 65535. Which is a real port
number but it actually means lldb-server didn't find one it was
allowed to use.

send packet: $qLaunchGDBServer;<...>
read packet: $pid:1919;port:12346;#c0
<...>
send packet: $qLaunchGDBServer;<...>
read packet: $pid:1927;port:65535;#c7

This situation should be an error even if port 65535 does happen
to be available on the current machine.

To fix this make PortMap it's own class within
GDBRemoteCommunicationServerPlatform.

This almost the same as the old typedef but for
GetNextAvailablePort() returning an llvm::Expected.
This means we have to handle not finding a port,
by returning an error packet.

Also add unit tests for this new PortMap class.

Reviewed By: labath

Differential Revision: https://reviews.llvm.org/D91634
2020-11-30 10:19:14 +00:00
Pavel Labath b6e04ac5aa [lldb/test] Avoid the socket "pump" thread
A separate thread is not necessary, as we can do its work on the main
thread, while waiting for the packet to arrive. This makes the code
easier to understand and debug (other simplifications are possible too,
but I'll leave that for separate patches). The new implementation also
avoids busy waiting.
2020-11-30 09:07:45 +01:00
Raphael Isemann 3f6c856bb5 [ASTImporter] Import the default argument of TemplateTypeParmDecl
The test case isn't using the AST matchers for all checks as there doesn't seem to be support for
matching TemplateTypeParmDecl default arguments. Otherwise this is simply importing the
default arguments.

Also updates several LLDB tests that now as intended omit the default template
arguments of several std templates.

Reviewed By: martong

Differential Revision: https://reviews.llvm.org/D92103
2020-11-26 18:01:30 +01:00
Raphael Isemann 53a14a47ee [lldb] Fix TestThreadStepOut.py after "Flush local value map on every instruction"
After cf1c774d6a, Clang seems to generate code
that is more similar to icc/Clang, so we can use the same line numbers for
all compilers in this test.
2020-11-26 09:43:47 +01:00
Richard Smith 3fb0879867 Refactor and simplify class scope name lookup.
This is partly in preparation for an upcoming change that can change the
order in which DeclContext lookup results are presented.

In passing, fix some obvious errors where name lookup's notion of a
"static member function" missed static member function templates, and
where its notion of "same set of declarations" was confused by the same
declarations appearing in a different order.
2020-11-25 16:25:33 -08:00
Paul Robinson cf1c774d6a [FastISel] Flush local value map on ever instruction
Local values are constants or addresses that can't be folded into
the instruction that uses them. FastISel materializes these in a
"local value" area that always dominates the current insertion
point, to try to avoid materializing these values more than once
(per block).

https://reviews.llvm.org/D43093 added code to sink these local
value instructions to their first use, which has two beneficial
effects. One, it is likely to avoid some unnecessary spills and
reloads; two, it allows us to attach the debug location of the
user to the local value instruction. The latter effect can
improve the debugging experience for debuggers with a "set next
statement" feature, such as the Visual Studio debugger and PS4
debugger, because instructions to set up constants for a given
statement will be associated with the appropriate source line.

There are also some constants (primarily addresses) that could be
produced by no-op casts or GEP instructions; the main difference
from "local value" instructions is that these are values from
separate IR instructions, and therefore could have multiple users
across multiple basic blocks. D43093 avoided sinking these, even
though they were emitted to the same "local value" area as the
other instructions. The patch comment for D43093 states:

  Local values may also be used by no-op casts, which adds the
  register to the RegFixups table. Without reversing the RegFixups
  map direction, we don't have enough information to sink these
  instructions.

This patch undoes most of D43093, and instead flushes the local
value map after(*) every IR instruction, using that instruction's
debug location. This avoids sometimes incorrect locations used
previously, and emits instructions in a more natural order.

This does mean materialized values are not re-used across IR
instruction boundaries; however, only about 5% of those values
were reused in an experimental self-build of clang.

(*) Actually, just prior to the next instruction. It seems like
it would be cleaner the other way, but I was having trouble
getting that to work.

Differential Revision: https://reviews.llvm.org/D91734
2020-11-25 13:05:00 -05:00
Muhammad Omair Javaid 2bd4540f38 [LLDB] Fix typo in RegisterContextPOSIXProcessMonitor_arm64
This patch fixes a minor typo in RegisterContextPOSIXProcessMonitor_arm64
constructor where memset target was wrongly specified as m_fpr instead of
m_gpr_arm64.
2020-11-24 07:09:00 +05:00
Jonas Devlieghere b20f3cc5b5 [lldb] Add platform select to TestProcessConnect.py
Extend TestProcessConnect to cover the scenario fixed by
6c0cd5676e. This replaces
command-process-connect.test which would fail if port 4321
was open.
2020-11-23 18:02:00 -08:00
Jordan Rupprecht 5b8e4a1102 [lldb/test] Remove flaky `process connect` test.
This test is flaky because it assumes port 4321 is not already open on a machine.
2020-11-23 12:49:50 -08:00
Michał Górny a8f6f4e873 [lldb] [test] Restore Windows-skip on 'process connect' tests 2020-11-23 14:27:32 +01:00
Michał Górny 18e4272a4f [lldb] Prevent 'process connect' from using local-only plugins
Add a 'can_connect' parameter to Process plugin initialization, and use
it to filter plugins to these capable of remote connections.  This is
used to prevent 'process connect' from picking up a plugin that can only
be used locally, e.g. the legacy FreeBSD plugin.

Differential Revision: https://reviews.llvm.org/D91810
2020-11-23 09:48:55 +01:00
Michał Górny 8018e7b447 [lldb] [Process/FreeBSDRemote] Fix regset names and related tests
Restore Linux-alike regset names for AVX/MPX registers
as TestLldbGdbServer seems to depend on them.  At the same time, fix
TestRegisters to be aware that they are not available on FreeBSD
and NetBSD, at least until we figure out a better way of reporting
unsupported register sets.

Differential Revision: https://reviews.llvm.org/D91923
2020-11-23 09:28:20 +01:00
Michał Górny 9367b57dad [lldb] [test] Fix qRegisterInfo lldb-server tests to handle missing registers
Fix qRegisterInfo tests to handle Exx error response when querying
registers that are not supported on the platform in question.  This
is how FreeBSD and NetBSD platforms reporting missing registers right
now, and there certainly is value from verifying the remaining
registers.

This change fixes the test for FreeBSD but NetBSD has other regressions
that still need to be researched.

Differential Revision: https://reviews.llvm.org/D91922
2020-11-23 09:26:23 +01:00
Michał Górny 8f2f9a82e2 [lldb] [Process/Utility] Declare register overlaps between ST and MM
Explicitly declare register overlaps/invalidation between ST(i) and MMi
registers.

Differential Revision: https://reviews.llvm.org/D91728
2020-11-23 09:23:14 +01:00
Michał Górny 7b7c372e3f [lldb] [Process/FreeBSD] Add missing 'override' kws to POSIXStopInfo
Differential Revision: https://reviews.llvm.org/D91934
2020-11-23 09:22:41 +01:00
Michał Górny 8aea95f3cb [lldb] Reland "Use translated full ftag values"
Translate between abridged and full ftag values in order to expose
the latter in the gdb-remote protocol while the former are used by
FXSAVE/XSAVE...  This matches the gdb behavior.

The Shell/Register tests now rely on the new behavior, and therefore
are run on non-Darwin systems only.  The Python (API) test relies
on the legacy behavior, and is run on Darwin only.

Differential Revision: https://reviews.llvm.org/D91504
2020-11-21 17:11:38 +01:00
Nathan Lanza 33c79f76af Revert "[lldb] add a missing dependency on intrinsics_gen"
This reverts commit 137ff73317.

This belongs in Apple's Swift fork since this is a direct fix for
unified Swift + llvm + lldb builds.
2020-11-20 16:02:16 -05:00
Dave Lee dbcc69217a [lldb] Add examples and reword source-map help string
Update the help string for `target.source-map` to remove the use of the word
"duple" and to add examples. Additionally I rewrote parts with the goal of
making the description more concrete.

rdar://68736012

Differential Revision: https://reviews.llvm.org/D91742
2020-11-20 10:01:36 -08:00
Raphael Isemann ffb3fd8f18 Partially revert '[MachO] Update embedded part of ObjectFileMachO for Mangled API change'
Commit f3aa9e36d9 fixed the embedded OS
build by removing all passed args for `GetName`/`GetDemangledName`. The motivation
for this was that these arguments were apparently removed in
commit 22b044877d. However, only `GetName`'s language
argument was removed but the mangling preference argument was *not* removed
(and unfortunately had a default argument). So when that commit removed all
the args it didn't just fix the build but it also changed all the mangling
preferences to 'demangled' for all `GetName` calls.

Also some `GetName` calls were outside the TARGET_OS_EMBEDDED ifdef, so
this change ended up breaking the following tests on macOS:

  lldb-api :: lang/objc/objc-static-method-stripped/TestObjCStaticMethodStripped.py
  lldb-api :: lang/objc/objc-super/TestObjCSuper.py

From what I can see f3aa9e36d9 removed 12 ePreferMangled args and this patch
re-adds 12 args with roughly the same line numbers, so this *should* restore the
old behaviour and also keep the embedded build working. On the other hand,
ObjectFileMachO::ParseSymtab is a very successful attempt at writing
the longest possible function within LLVM, so this fix is partly based
on the engineering principle known as "hoping for the best".
2020-11-20 13:31:36 +01:00
David Spickett 32541685b2 [lldb][AArch64/Linux] Show memory tagged memory regions
This extends the "memory region" command to
show tagged regions on AArch64 Linux when the MTE
extension is enabled.

(lldb) memory region the_page
[0x0000fffff7ff8000-0x0000fffff7ff9000) rw-
memory tagging: enabled

This is done by adding an optional "flags" field to
the qMemoryRegion packet. The only supported flag is
"mt" but this can be extended.

This "mt" flag is read from /proc/{pid}/smaps on Linux,
other platforms will leave out the "flags" field.

Where this "mt" flag is received "memory region" will
show that it is enabled. If it is not or the target
doesn't support memory tagging, the line is not shown.
(since majority of the time tagging will not be enabled)

Testing is added for the existing /proc/{pid}/maps
parsing and the new smaps parsing.
Minidump parsing has been updated where needed,
though it only uses maps not smaps.

Target specific tests can be run with QEMU and I have
added MTE flags to the existing helper scripts.

Reviewed By: labath

Differential Revision: https://reviews.llvm.org/D87442
2020-11-20 11:21:59 +00:00
Michał Górny f0e2c5131e [lldb] [test/Register] XFAIL x86-fp-write on Darwin 2020-11-20 09:43:08 +01:00
Michał Górny 3a230101fe Revert "[LLDB] Fixing lldb/test/Shell/Register/x86-fp-write.test"
The problem is not specific to arch but to the whole Darwin platform.

Reverts: 0fd04337a1
2020-11-20 09:42:13 +01:00
shafik 0fd04337a1 [LLDB] Fixing lldb/test/Shell/Register/x86-fp-write.test
D91497 changed lldb/test/Shell/Register/x86-fp-write.test and added target-x86_64 to the REQUIRES clause.
It looks this test does not pass on this platform so removing it since it one of tests failing on the
green dragon build bot.
2020-11-19 16:29:28 -08:00
Raphael Isemann c77aefb0ff [lldb] Fix another Python2/3 string<->bytes type error in patch-crashlog.py 2020-11-19 19:24:40 +01:00
Raphael Isemann 47b7138b48 [lldb] Fix incorrect error handling in GDBRemoteCommunicationClient::SendGetSupportedTraceType
GDBRemoteCommunicationClient::SendGetSupportedTraceType is checking whether the
response is `!response.IsNormalResponse()` and infers from that that it is an error response.
However, it could be either "unsupported" or "error". If we get an unsupported response,
the code then tries to generate an llvm::Expected from the non-error response which then asserts.

Debugserver doesn't implement `jLLDBTraceSupportedType`, so we get an unsupported response
whenever this function is called on macOS.

This fixes the TestAproposWithProcess on macOS (where the `apropos` command will query
the CommandObjectTraceStart which then sends the trace type query package).

Reviewed By: wallace, shafik

Differential Revision: https://reviews.llvm.org/D91801
2020-11-19 19:14:04 +01:00
Raphael Isemann b7a09de10f [lldb][NFC] Add a FIXME for ClangASTSource::FindExternalLexicalDecls's unused 'decls' parameter 2020-11-19 17:15:14 +01:00
Raphael Isemann a703998e66 [lldb] Remove legacy casts from TestStackFromStdModule
We can handle all the types in the expression evaluator now without casting.
On Linux, we have a system header declaration that is still causing issues, so
I'm skipping the test there until I get around to fix this.
2020-11-19 17:07:12 +01:00
Mikhail Goncharov 193a9b374e Revert "[lldb] Use translated full ftag values"
This reverts commit c43abf0436.

Test commands/register/register/register_command/TestRegisters.py fails.
Buildbot http://lab.llvm.org:8011/#/changes/4149
2020-11-19 15:24:59 +01:00
Michał Górny c43abf0436 [lldb] Use translated full ftag values
Translate between abridged and full ftag values in order to expose
the latter in the gdb-remote protocol while the former are used by
FXSAVE/XSAVE...  This matches the gdb behavior.

Differential Revision: https://reviews.llvm.org/D91504
2020-11-19 13:23:12 +01:00
Michał Górny d8ff269f67 [lldb] Add explicit 64-bit fip/fdp registers on x86_64
The FXSAVE/XSAVE data can have two different layouts on x86_64.  When
called as FXSAVE/XSAVE..., the Instruction Pointer and Address Pointer
registers are reported using a 16-bit segment identifier and a 32-bit
offset.  When called as FXSAVE64/XSAVE64..., they are reported using
a complete 64-bit offsets instead.

LLDB has historically followed GDB and unconditionally used to assume
the 32-bit layout, with the slight modification of possibly
using a 32-bit segment register (i.e. extending the register into
the reserved 16 upper bits).  When the underlying operating system used
FXSAVE64/XSAVE64..., the pointer was split into two halves,
with the upper half repored as the segment registers.  While
reconstructing the full address was possible on the user end (and e.g.
the FPU register tests did that), it certainly was not the most
convenient option.

Introduce a two additional 'fip' and 'fdp' registers that overlap
with 'fiseg'/'fioff' and 'foseg'/'foff' respectively, and report
the complete 64-bit address.

Differential Revision: https://reviews.llvm.org/D91497
2020-11-19 13:23:12 +01:00
Walter Erquinigo fb19f11ef4 [trace][intel-pt] Scaffold the 'thread trace start | stop' commands
Depends on D90490.

The stop command is simple and invokes the new method Trace::StopTracingThread(thread).

On the other hand, the start command works by delegating its implementation to a CommandObject provided by the Trace plugin. This is necessary because each trace plugin needs different options for this command. There's even the chance that a Trace plugin can't support live tracing, but instead supports offline decoding and analysis, which means that "thread trace dump instructions" works but "thread trace start" doest. Because of this and a few other reasons, it's better to have each plugin provide this implementation.

Besides, I'm using the GetSupportedTraceType method introduced in D90490 to quickly infer what's the trace plug-in that works for the current process.

As an implementation note, I moved CommandObjectIterateOverThreads to its header so that I can use it from the IntelPT plugin. Besides, the actual start and stop logic for intel-pt is not part of this diff.

Reviewed By: clayborg

Differential Revision: https://reviews.llvm.org/D90729
2020-11-18 18:24:36 -08:00
Jonas Devlieghere f3aa9e36d9 [MachO] Update embedded part of ObjectFileMachO for Mangled API change
Mangled::GetName and Mangled::GetDemangledName no longer take any
arguments.
2020-11-18 14:47:31 -08:00
Raphael Isemann ccd9091d4a [lldb][NFC] Don't let Process inherit from UserID
I noticed that Process is inheriting from UserID to store its PID value. This patch
replaces this with a dedicated field in the Process class. This is NFC, but has some
small effects on the code using Process:
* `GetID()` now returns a `lldb::pid_t` like all other process code instead of `lldb::user_id_t`. Both are typedefs for `uint64_t`, so no change in behaviour.
* The equality operators defined for UserID no longer accept Process instances.
* Removes the inherited method `Process::Clear()` which didn't actually clear anything beside the PID value.

We maybe should also remove the getters/setters to `S/GetPID` or something like that. I can update all the code for that
in a follow-up NFC commit.

Reviewed By: labath

Differential Revision: https://reviews.llvm.org/D91699
2020-11-18 14:33:48 +01:00
David Spickett 50f12ade2d [lldb] Fix a couple of remote llgs tests
init_llgs_test no longer takes an argument
but these two were not updated.

Also fix some mistakes in TestAutoInstallMainExecutable
to get it passing again.

Reviewed By: JDevlieghere, labath

Differential Revision: https://reviews.llvm.org/D91612
2020-11-18 11:36:45 +00:00
Michał Górny 97a2eac3a9 [lldb] [test] Un-XFAIL tests on freebsd/i386
Restrict i386-specific XFAIL on a few tests to non-FreeBSD systems,
as they pass on FreeBSD.

Differential Revision: https://reviews.llvm.org/D91645
2020-11-18 12:09:11 +01:00
Michał Górny b48ace051c [lldb] [test] Un-XFAIL TestMultipleDebuggers.py
This test is flaky, and for the time being we do not mark them as XFAIL.
2020-11-18 12:09:04 +01:00
Michał Górny 5a75512eba [lldb] [test] Mark command-process-connect.test XFAIL
We are still investigating why 'process connect' does not work while
'gdb-remote' does.

Signed-off-by: Michał Górny <mgorny@moritz.systems>
2020-11-18 12:08:59 +01:00
Michał Górny 3e1f1b406e [lldb] [test] Pass -mmmx to x86-gp-write test explicitly
Pass -mmmx explicitly to fix build failure with FreeBSD's clang on i386.

Differential Revision: https://reviews.llvm.org/D91578
2020-11-18 12:08:24 +01:00
Raphael Isemann 2fa38fa9a6 [lldb] Python3 byte<->string issue in patch-crashlog.py 2020-11-18 09:58:02 +01:00
Alessandro Arzilli 27012c0f75 [debugserver] Add option to propagate SIGSEGV to target process
Adds a command line option that makes debugserver propagate the SIGSEGV
signal to the target process.

Motivation: I'm one of the maintainers of Delve [1] a debugger for Go.
We use debugserver as our backend on macOS and one of the most often
reported bugs is that, on macOS, we don't propagate SIGSEGV back to the
target process [2]. Sometimes some programs will actually cause a
SIGSEGV, by design, and then handle it. Those programs can not be
debugged at all.

Since catching signals isn't very important for a Go debugger I'd much
rather have a command line option in debugserver that causes it to let
SIGSEGV go directly to the target process.

[1] https://github.com/go-delve/delve/
[2] https://github.com/go-delve/delve/issues/852

Differential revision: https://reviews.llvm.org/D89315
2020-11-17 09:27:52 -08:00
Muhammad Omair Javaid 661e4040ac [LLDB] Fix SVE reginfo for sequential offset in g packet
This moves in the direction of our effort to synchronize register descriptions
between LLDB and GDB xml description. We want to able to send registers in a
way that their offset fields can be re-constructed based on register sizes
in the increasing order of register number.

In context to Arm64 SVE, FPCR and FPSR are same registers in FPU regset and
SVE regset. Previously FPSR/FPCR offset was set at the end of SVE data
because Linux ptrace data placed FPCR and FPSR at the end of SVE register set.

Considering interoperability with other stubs like QEMU and that g packets
should generate register data in increasing order of register numbers. We
have to move FPCR/FPSR offset up to its original location according to
register numbering scheme of ARM64 registers with SVE registers included.

Reviewed By: labath

Differential Revision: https://reviews.llvm.org/D90741
2020-11-17 17:18:34 +05:00
Muhammad Omair Javaid fcca6fe93f [LLDB] Update SVE Z reg info to remove invalidate regs
In our recent discussion we are aiming to make LLDB registers exchange minimum
possible information in qRegisterInfo or XMl register descriptions.
For SVE registers, Z registers are catagorized as primary registers and should
not have any infomration about any pseudo registers. All pseudo registers
should have the information on which primary register they belong to.
This patch removes invalidate_regs list from Z registers and will mitigate its
impact on SVE resize patch in a follow up update.

Reviewed By: labath

Differential Revision: https://reviews.llvm.org/D91057
2020-11-17 17:14:44 +05:00
Jonas Devlieghere a4d1e60910 [crashlog] Improve patch-crashlog.py script
Compute the real addresses and offsets for the json crashlog test.
2020-11-16 23:27:40 -08:00
Jonas Devlieghere c7cbf32f57 [crashlog] Implement parser for JSON encoded crashlogs
Add a parser for JSON crashlogs. The CrashLogParser now defers to either
the JSONCrashLogParser or the TextCrashLogParser. It first tries to
interpret the input as JSON, and if that fails falling back to the
textual parser.

Differential revision: https://reviews.llvm.org/D91130
2020-11-16 13:50:37 -08:00
Aaron Ballman fa72ce346c Another speculative fix for lldb related to ConstexprSpecKind 2020-11-16 14:39:34 -05:00
Aaron Ballman 1941d9651c Speculatively fix the lldb build
Pick up the changes from 41b65f166b.
2020-11-16 14:23:04 -05:00
Raphael Isemann 618f11ba0b [lldb] Skip TestCppKeywordsAsCIdentifiers on Windows
Somehow static_assert is a keyword with C on Windows (maybe the Windows
default is C11?). Skipping the test for now.
2020-11-16 18:41:04 +01:00
Raphael Isemann a8350ce79d [lldb] Add support for using variables with C++ keywords names in non-C++ expressions
LLDB is currently always activating C++ when parsing expressions as LLDB itself
is using C++ features when creating the final AST that will be codegen'd
(specifically, references to variables, namespaces and using declarations are
used).

This is causing problems for users that have variables in non-C++ programs (e.g.
plain C or Objective-C) that have names which are keywords in C++. Expressions
referencing those variables fail to parse as LLDB's Clang parser thinks those
identifiers are C++ keywords and not identifiers that may belong to a
declaration.

We can't just disable C++ in the expression parser for those situations as
replacing the functionality of the injected C++ code isn't trivial. So this
patch is just disabling most keywords that are exclusive to C++ in LLDB's Clang
parser when we are in a non-C++ expression. There are a few keywords we can't
disable for now:

* `using` as that's currently used in some situations to inject variables into the expression function.
* `__null` as that's used by LLDB to define `NULL`/`Nil`/`nil`.

Getting rid of these last two keywords is possible but is a large enough change
that this will be handled in follow up patches.

Note that this only changes the keyword status of those tokens but this patch
does not remove any C++ functionality from the expression parser. The type
system still follows C++ rules and so does the rest of the expression parser.

There is another small change that gives the hardcoded macro definitions in LLDB
a higher precedence than the macros imported from the Objective-C modules. The
reason for this is that the Objective-C modules in LLDB are actually parsed in
Objective-C++ mode and they end up providing the C++ definitions of certain
system macros (like `NULL` being defined as `nullptr`). So we have to move the
LLDB definition forward and surround the definition from the module with an
`#ifdef` to make sure that we use the correct LLDB definition that doesn't
reference C++ keywords. Or to give an example, this is how the expression source
code changes:

Before:
```
 #define NULL (nullptr) // injected module definition
 #ifndef NULL
 #define NULL (__null) // hardcoded LLDB definition
 #endif
```

After:
```
 #ifndef NULL
 #define NULL (__null) // hardcoded LLDB definition
 #endif
 #ifndef NULL
 #define NULL (nullptr) // injected module definition
 #endif
```

Fixes rdar://10356912

Reviewed By: shafik

Differential Revision: https://reviews.llvm.org/D82770
2020-11-16 16:04:44 +01:00
Michał Górny b9734c6b44 [lldb] [Process/FreeBSDRemote] Optimize regset pointer logic
Create a helper GetOffsetRegSetData() method to get pointer
to the regset data accounting for the necessary offset.  Establish
the offsets in the constructor and store them in the structure.  This
avoids having to add new Get*Offset() methods and combines some common
code.

Differential Revision: https://reviews.llvm.org/D91411
2020-11-16 13:03:02 +01:00
Michał Górny 68ca01eb50 [lldb] [Process/FreeBSDRemote] Modernize and simplify YMM logic
Eliminate the remaining swith-case code for register getters,
and migrate YMM registers to regset-oriented model.  Since these
registers are recombined from XMM and YMM_Hi128 XSAVE blocks, while LLDB
gdb-server protocol transmits YMM registers whole, the offset-based
model will not work here.  Nevertheless, some improvement was possible.

Replace generic 'XSaveRegSet' along with sub-sets for XSAVE components
with 'YMMRegSet' (and more regsets in the future as further components
are implemented).  Create a helper GetYMMSplitReg() method that obtains
pointers to the appropriate XMM and YMM_Hi128 blocks to reduce code
duplication.

Differential Revision: https://reviews.llvm.org/D91293
2020-11-16 13:03:01 +01:00
Michał Górny 6adb55877c [lldb] [Process/FreeBSDRemote] Access debug registers via offsets
Use offset-based method to access x86 debug registers.  This also
involves adding a test for the correctness of these offsets, and making
GetDR() method of NativeRegisterContextWatchpoint_x86 public to avoid
duplicate code.

Differential Revision: https://reviews.llvm.org/D91268
2020-11-16 13:03:01 +01:00
Michał Górny e520487bf4 [lldb] [Process/FreeBSDRemote] Access FPR via RegisterInfo offsets
Use offset-based method to access base x87 FPU registers, using offsets
relative to the position of 'struct FPR', as determined by the location
of first register in it (fctrl).  Change m_fpr to use a fixed-size array
matching FXSAVE size (512 bytes).  Add unit tests for verifying
RegisterInfo offsets and sizes against the FXSAVE layout.

Differential Revision: https://reviews.llvm.org/D91248
2020-11-16 13:03:01 +01:00
Michał Górny 58abbf821c [lldb] [Process/FreeBSDRemote] Access GPR via reginfo offsets
Read and write registers from m_gpr using offsets from RegisterInfo
rather than explicit switch-case.  This eliminates a lot of redundant
code, and avoids mistakes such as type mismatches seen recently (wrt
segment registers).  The same logic will be extended to other register
sets in the future.

Make m_gpr an uint8_t std::array to ease accesses.  Ideally, we could
avoid including <machine/reg.h> entirely in the future and instead
get the correct GPR size from Utility/RegisterContextFreeBSD_* somehow.

While at it, modify register set logic to use an explicit enum with
llvm::Optional<>, making the code cleaner and at the same time enabling
compiler warnings for unhandled sets.

Since now we're fully relying on 'struct GPR' defined
in Utility/RegisterContextFreeBSD_* being entirely in sync with
the system structure, add unit tests to verify the field offsets
and sizes.

Differential Revision: https://reviews.llvm.org/D91216
2020-11-16 12:19:37 +01:00
Jonas Devlieghere 875be9f454 [lldb] Mark command-process-connect as unsupported on Windows
Windows doesn't support remote connections.
2020-11-13 20:02:05 -08:00
Jonas Devlieghere 6c0cd5676e [lldb] Make `process connect` behave the same in sync and async mode.
I think the check for whether the process is connected is totally bogus
in the first place, but on the off-chance that's it's not, we should
behave the same in synchronous and asynchronous mode.
2020-11-13 17:39:30 -08:00
Jim Ingham 5a4b2e1541 The AssertRecognizer used the module from a frames SC without checking it was non-null.
I only have a crash report for this.  I could reproduce it with a slightly older
lldb by running an expression that called pthread_kill, but we started making modules
for our expression JIT code, so that no longer triggers the bug.  I can't think of another
good way to test it but the fix is obvious.
2020-11-13 11:41:32 -08:00
Jonas Devlieghere e5a82b4594 [lldb] Fix SymbolFile/PDB/udt-layout.test
Update the test for 406ad18748
2020-11-13 09:30:40 -08:00
Raphael Isemann dc848a0888 [lldb][NFC] Fix flaky TestForwardDeclFromStdModule test
"[lldb/DataFormatters] Display null C++ pointers as nullptr" added an assumption
that the member we check for is always a nullptr, but it is actually never
initialized. That causes the test to randomly fail due to the pointer having
some random value that isn't 0.
2020-11-13 11:40:51 +01:00
Jason Molenda 92b036dea2 debugserver should advance pc past builtin_debugtrap insn
On x86_64, when you hit a __builtin_debugtrap instruction, you
can continue past this in the debugger.  This patch has debugserver
recognize the specific instruction used for __builtin_debugtrap
and advance the pc past it, so that the user can continue execution
once they've hit one of these.

In the patch discussion, we were in agreement that it would be better
to have this knowledge up in lldb instead of depending on each
stub rewriting the pc behind the debugger's back, but that's a
larger scale change for another day.

<rdar://problem/65521634>
Differential revision: https://reviews.llvm.org/D91238
2020-11-12 23:31:14 -08:00
Jonas Devlieghere 406ad18748 [lldb/DataFormatters] Display null C++ pointers as nullptr
Display null pointer as `nullptr`, `nil` and `NULL` for C++,
Objective-C/Objective-C++ and C respectively. The original motivation
for this patch was to display a null std::string pointer as nullptr
instead of "", but the fix seemed generic enough to be done for all
summary providers.

Differential revision: https://reviews.llvm.org/D77153
2020-11-12 15:24:06 -08:00
shafik bae9aedb34 [LLDB] Fix handling of bit-fields in a union
When parsing DWARF and laying out bit-fields we don't properly take into account when they are in a union, they will all have a zero offset.

Differential Revision: https://reviews.llvm.org/D91118
2020-11-12 14:09:27 -08:00
Raphael Isemann d4b08ccb87 [lldb] Replace TestAbortExitCode with a debugserver specific test
When I added TestAbortExitCode I actually planned this to be a generic test for the
exit code functionality on POSIX systems. However due to all the different test setups we
can have I don't think this worked out. Right now the test had to be made so permissive
that it pretty much can't fail.

Just to summarize, we would need to support the following situations:
1. ToT debugserver (on macOS)
2. lldb-server (on other platforms)
3. Any old debugserver version when using the system debugserver (on macOS)

This patch is removing TestAbortExitCode and adds a ToT debugserver specific test
that checks the patch that motivated the whole exit code testing. There is already
an exit-code test for lldb-server from what I can see and 3) is pretty much untestable
as we don't know anything about the system debugserver.

Reviewed By: kastiglione

Differential Revision: https://reviews.llvm.org/D89305
2020-11-12 17:33:21 +01:00
Raphael Isemann d85cc03c9c [lldb] Add expect_var_path to test variable path results
This adds `expect_var_path` to test variable paths so we no longer have to
use `frame var` and find substrs in the command output. The behaviour
is identical with `expect_expr` (and it also uses the same checking backend),
but it instead calls `GetValueForVariablePath` to evaluate the string as a variable
path.

Also rewrites a few of the tests that previously used `frame variable` to use
`expect_var_path`.

Reviewed By: labath

Differential Revision: https://reviews.llvm.org/D90450
2020-11-12 16:14:48 +01:00
Raphael Isemann b4b836563a [lldb][NFC] Move OptionDefinition from lldb-private-types.h to its own Utility header
Also moves the curious isprint8 function (which was used to check whether we have a
valid short option) into the struct and documents it.
2020-11-12 15:30:26 +01:00
Michał Górny f37834c7dc [lldb] [test] Add a minimal test for x86 dbreg reading
Add a test verifying that after the 'watchpoint' command, new values
of x86 debug registers can be read back correctly.  The primary purpose
of this test is to catch broken DRn reading and help debugging it.

Differential Revision: https://reviews.llvm.org/D91264
2020-11-12 14:09:03 +01:00
Michał Górny a8bfee2a35 [lldb] [Process/Utility] Fix DR offsets for FreeBSD
Fix Debug Register offsets to be specified relatively to UserArea
on FreeBSD/amd64 and FreeBSD/i386, and add them to UserArea on i386.
This fixes overlapping GPRs and DRs in gdb-remote protocol, making it
impossible to correctly get and set debug registers from the LLDB
client.

Differential Revision: https://reviews.llvm.org/D91254
2020-11-12 14:09:03 +01:00
Raphael Isemann 1115d1d083 Revert "Generalize regex matching std::string variants to compensate for recent"
This reverts commit 856fd98a17. The type formatters
use inline namespaces to find the formatter that fits the type ABI, so they
can't just ignore the inline namespaces.

The failing tests should be fixed by da121fff11 .
2020-11-12 14:01:22 +01:00
Raphael Isemann da121fff11 [lldb] Introduce a LLDB printing policy for Clang type names that suppressed inline namespaces
Commit 5f12f4ff90 made suppressing inline namespaces
when printing typenames default to true. As we're using the inline namespaces
in LLDB to construct internal type names (which need internal namespaces in them
to, for example, differentiate libc++'s std::__1::string from the std::string
from libstdc++), this broke most of the type formatting logic.
2020-11-12 14:00:33 +01:00
Richard Smith 856fd98a17 Generalize regex matching std::string variants to compensate for recent
improvements to Clang's type printing.
2020-11-11 17:55:47 -08:00
Dave Lee 0783ad9e6a [lldb] Switch expect to runCmd in TestRecursiveTypes (NFC)
Following discussion in D91193, a change made in D88792 was not quite right.
This restores the message argument, and switches from `expect` to `runCmd`.

Differential Revision: https://reviews.llvm.org/D91206
2020-11-11 16:17:38 -08:00
Walter Erquinigo d2f18e6b1e Fix 21555fff4d
Buildbot failed on Windows
http://lab.llvm.org:8011/#/builders/83/builds/693

Error: On Windows, std::future can't hold an Expected, as it doesn't have a default
constructor.

Solution: Use std::future<bool> instead of std::future<Expected<T>>
2020-11-11 12:30:24 -08:00
Vedant Kumar fc8c1ea9af [lldb/test] Add missing decorators import 2020-11-11 10:48:27 -08:00
Vedant Kumar b7c06dcb73 [ThreadPlan] Add a test for `thread step-in -r`, NFC (reapply)
Adds test coverage for ThreadPlanStepInRange::SetAvoidRegexp, but
disables the test on Windows.

See:
http://lab.llvm.org:8080/coverage/coverage-reports/coverage/Users/buildslave/jenkins/workspace/coverage/llvm-project/lldb/source/Target/ThreadPlanStepInRange.cpp.html#L309

Differential Revision: https://reviews.llvm.org/D91220
2020-11-11 10:43:38 -08:00
Walter Erquinigo 21555fff4d [intel-pt][trace] Implement a "get supported trace type" packet
Depends on D89283.

The goal of this packet (jTraceGetSupportedType) is to be able to query the gdb-server for the tracing technology that can work for the current debuggeer, which can make the user experience simpler but allowing the user to simply type

  thread trace start

to start tracing the current thread without even telling the debugger to use "intel-pt", for example. Similarly, `thread trace start [args...]` would accept args beloging to the working trace type.

Also, if the user typed

  help thread trace start

We could directly show the help information of the trace type that is supported for the target, or mention instead that no tracing is supported, if that's the case.

I added some simple tests, besides, when I ran this on my machine with intel-pt support, I got

  $ process plugin packet send "jTraceSupportedType"
    packet: jTraceSupportedType
  response: {"description":"Intel Processor Trace","pluginName":"intel-pt"}

On a machine without intel-pt support, I got

  $ process plugin packet send "jTraceSupportedType"
    packet: jTraceSupportedType
  response: E00;

Reviewed By: clayborg, labath

Differential Revision: https://reviews.llvm.org/D90490
2020-11-11 10:35:58 -08:00
Stella Stamenova d9624f4448 Revert "[ThreadPlan] Add a test for `thread step-in -r`, NFC"
This reverts commit ae3640e386.

The new test is failing on the Windows LLDB buildbot.
2020-11-11 09:09:43 -08:00
Raphael Isemann 66ae40ebfb [lldb][test] Remove not_remote_testsuite_ready in favor of skipIfRemote decorator
Those two decorators have identical behaviour. This removes
`not_remote_testsuite_ready` as `skipIfRemote` seems more consistent with the
other decorator names we have

Reviewed By: JDevlieghere

Differential Revision: https://reviews.llvm.org/D89376
2020-11-11 09:14:54 +01:00
Vedant Kumar 9922dded47 [test] Delete redundant lldbutil import, NFC 2020-11-10 16:37:47 -08:00
Vedant Kumar ae3640e386 [ThreadPlan] Add a test for `thread step-in -r`, NFC
Adds test coverage for ThreadPlanStepInRange::SetAvoidRegexp.

See:
http://lab.llvm.org:8080/coverage/coverage-reports/coverage/Users/buildslave/jenkins/workspace/coverage/llvm-project/lldb/source/Target/ThreadPlanStepInRange.cpp.html#L309

Differential Revision: https://reviews.llvm.org/D91220
2020-11-10 16:37:47 -08:00
Vedant Kumar 04cd6c6217 [ThreadPlan] Delete unused ThreadPlanStepInRange code, NFC 2020-11-10 16:15:03 -08:00
Vedant Kumar 34d56b05fd [ThreadPlan] Reflow docs to fit the 80 column limit, NFC 2020-11-10 16:14:52 -08:00
Vedant Kumar ba21376883 [Command] Fix accidental word concatenation in Options.td
Split up words that appear to have been accidentally concatenated.

This looks to be exhaustive: to find these in vim, use:

/\v[^ ]"\n +"[^ ]
2020-11-10 16:13:39 -08:00
Michał Górny f21e704d4a [lldb] [Process/NetBSD] Copy the recent improvements from FreeBSD
Copy the recent improvements from the FreeBSDRemote plugin, notably:

- moving event reporting setup into SetupTrace() helper

- adding more debug info into SIGTRAP handling

- handling user-generated (and unknown) SIGTRAP events

- adding missing error handling to the generic signal handler

- fixing attaching to processes

- switching watchpoint helpers to use llvm::Error

- minor style and formatting changes

This fixes a number of tests, mostly related to fixed attaching.

Differential Revision: https://reviews.llvm.org/D91167
2020-11-10 20:20:44 +01:00
Raphael Isemann 7211604220 [lldb][NFC] Add lldb-server to the shell tests disallow list
This prevents that one can write a test that referenced lldb-server (instead
of %lldb-server). Addresses review feedback from D91155.
2020-11-10 18:48:28 +01:00
Jonas Devlieghere 8da14fb76c [lldb] Propagate llvm::Error to report_fatal_error
Instead of having a custom error message, propagate the llvm::Error from
SystemInitializerCommon. I didn't realize we had this overload until
Pavel mentioned it in D90987 today.
2020-11-10 08:19:47 -08:00
Pavel Labath 4edb7e34f8 [lldb/DWARF] Fix sizes of DW_OP_const[1248][us] and DW_OP_litN results
Dwarf says (Section 2.5.1.1. of DWARF v5) that these operations should
push "generic" (pointer-sized) values. This was not the case for
DW_OP_const operations (which were pushing values based on the size of
arguments), nor DW_OP_litN (which were always pushing 64-bit values).

The practical effect of this that were were unable to display the values
of variables if the size of the DW_OP_const opcode was smaller than the
value of the variable it was describing. This would happen because we
would store this (small) result into a buffer and then would not be able
to read sufficient data out of it (in Value::GetValueAsData). Gcc emits
debug info like this.

Other (more subtle) effects are also possible.

The same fix should be applied to DW_OP_const[us] (leb128 versions), but
I'm not doing that right now, because that would cause us to display
wrong (truncated) values of variables on 32-bit targets (pr48087).

Differential Revision: https://reviews.llvm.org/D90840
2020-11-10 16:10:08 +01:00
Raphael Isemann 9b0578d546 [lldb] Reinstate TestGdbserverPort.test
This test was deleted by accident in the great lldb-mi removal:
37fed66402
2020-11-10 15:51:15 +01:00
Raphael Isemann c50faf5c9d [lldb] Fix TestErrorMessages test on standalone builds by adding lldb-server substitution
It seems that TestErrorMessages.test is failing on the standalone + Xcode builds
as lldb-server executable can't be found by lit's default PATH search. I assume
invoking lldb-server via a lit substitution gets this working again as
everything else is working, so that's what this patch is doing.

I had to add the lldb-server substitution as the test seems lldb-server specific
and we don't want it to default to debugserver on Darwin.

Using a substitution also seems in general like a good idea so that the commands
lit is printing on failure are using the full path to lldb-server and can be
re-run in a terminal.

Reviewed By: labath

Differential Revision: https://reviews.llvm.org/D91155
2020-11-10 15:26:19 +01:00
Michał Górny 4c54399b7e [lldb] [Process/FreeBSDRemote] Explicitly copy dbregs to new threads
Explicitly copy dbregs to new threads to ensure that watchpoints
are propagated properly.  Fixes the test failure due to apparent kernel
race between reporting a new thread and resuming main thread execution
that makes implicit inheritance of dbregs unreliable.  By copying them
explicitly, we ensure that the new thread correctly respects watchpoints
that were set after the thread was created but before it was reported.

The code is copied from the NetBSD plugin and modernized to use
llvm::Error.

Differential Revision: https://reviews.llvm.org/D91032
2020-11-10 14:18:03 +01:00
Michał Górny 194c5accb2 [lldb] [Process/FreeBSDRemote] Correct DS/ES/FS/GS register sizes
Fix DS/ES/FS/GS register sizes in getter/setter for FreeBSD.  Apparently
only CS and SS registers are specified as 64/32-bit in LLDB, while
the others are specified as 16-bit.  This fixes the failing
StandardStartupTest.TestStopReplyContainsThreadPcs lldb-server unittest.

Differential Revision: https://reviews.llvm.org/D91076
2020-11-10 14:18:03 +01:00
Michał Górny e637602e7a [lldb] [Process/FreeBSDRemote] Fix handling user-generated SIGTRAP
Update the SIGTRAP handler to account for the possibility of SIGTRAP
being generated by the user, i.e. not having any specific debugging
event associated with it, as well as receiving unknown SIGTRAPs.  These
instances of SIGTRAP are passed to the regular signal handler.

Differential Revision: https://reviews.llvm.org/D91007
2020-11-10 14:18:03 +01:00
Michał Górny 311cca8bbf [lldb] [test] Rename '.categories' to 'categories'
Make category-specifying files visible.  There is really no good reason
to keep them hidden, and having them visible increases the chances
that someone will actually spot them.

Differential Revision: https://reviews.llvm.org/D91065
2020-11-10 12:02:38 +01:00
Michał Górny a852cf66ea [lldb] [test] Skip ObjC-based tests via 'objc' category
Replace the plethora of ObjC-implied 'skipUnlessDarwin' decorators
with marking tests as 'objc' category (whenever missing), and skip all
ObjC tests on non-Darwin platforms.  I have used '.categories' file
wherever it was present already or all (>1) tests were relying on ObjC,
and explicit add_test_categories() where there was only one test.

Differential Revision: https://reviews.llvm.org/D91056
2020-11-10 12:02:38 +01:00
Stefan Gränitz 203b4774b8 [lldb][ObjectFile] Relocate sections for in-memory objects (e.g. received via JITLoaderGDB)
Part 2 of a fix for JITed code debugging. This has been a regression from 5.0 to 6.0 and it's still reproducible on current master: https://bugs.llvm.org/show_bug.cgi?id=36209 Part 1 was D61611 a while ago.

The in-memory object files we obtain from JITLoaderGDB are not yet relocated. It looks like this used to happen on the LLDB side and my guess is that it broke with D38142. (However, it's hard to tell because the whole thing was broken already due to the bug in part 1.) The patch moved relocation resolution to a later point in time and didn't apply it to in-memory objects. I am not aware of any reason why we wouldn't resolve relocations per-se, so I made it unconditional here. On Debian, it fixes the bug for me and all tests in `check-lldb` are still fine.

Reviewed By: labath

Differential Revision: https://reviews.llvm.org/D90769
2020-11-10 11:37:53 +01:00
Jonas Devlieghere 0ca90eb335 [lldb] Don't use ::exit but instead return from the driver loop (NFC)
This fixes a reproducer test failure that was caused by the undefined
order in which global destructors run. More concretely, the static
instance of the RealFileSystem had been destroyed before we finalized
the reproducer, which uses it to copy files into the reproducer. By
exiting normally, we call SBDebugger::Terminate and finalize the
reproducer before any static dtors are run.
2020-11-09 16:47:30 -08:00
Jonas Devlieghere 6ac12b5b6c [lldb] Destory the debugger in the Driver dtor (NFC) 2020-11-09 16:47:30 -08:00
Jonas Devlieghere b2fa3b922e [lldb] Make GetSelectedOrDummyTarget return the target by reference (NFC)
Return references from GetDummyTarget and GetSelectedOrDummyTarget. This
matches how the APIs are already used in practice.
2020-11-09 15:42:27 -08:00
Michał Górny ed3ac6c110 [lldb] [Process/NetBSD] Correct DS/ES/FS/GS register sizes
Fix DS/ES/FS/GS register sizes in getter/setter for NetBSD.  Apparently
only CS and SS registers are specified as 64/32-bit in LLDB, while
the others are specified as 16-bit.

Differential Revision: https://reviews.llvm.org/D91090
2020-11-09 22:14:58 +01:00
António Afonso d7be9a4647 Revert "Check if debug line sequences are starting after the first code segment"
This reverts commit 265a38fbc5.
2020-11-09 11:45:35 -08:00
António Afonso a9dcd15f50 Revert "Ignores functions that have a range starting outside of a code section"
This reverts commit df30bc0168.
2020-11-09 09:07:48 -08:00
Jonas Devlieghere b31d787949 [lldb] Avoid confusing reproducer crashes when initialization failed
During active replay, the ::Initialize call is replayed like any other
SB API call and the return value is ignored. Since we can't intercept
this, we terminate here before the uninitialized debugger inevitably
crashes.

Differential revision: https://reviews.llvm.org/D90987
2020-11-09 08:50:10 -08:00
António Afonso df30bc0168 Ignores functions that have a range starting outside of a code section
This is a similar patch to https://reviews.llvm.org/D87172. Greg said we should also do it for functions.

Reviewed By: clayborg, labath

Differential Revision: https://reviews.llvm.org/D87173
2020-11-09 08:26:08 -08:00
António Afonso 265a38fbc5 Check if debug line sequences are starting after the first code segment
I found a few cases where entries in the debug_line for a specific line of code have invalid entries (the address is outside of a code section or no section at all) and also valid entries. When this happens lldb might not set the breakpoint because the first line entry it will find in the line table might be the invalid one and since it's range is "invalid" no location is resolved. To get around this I changed the way we parse the line sequences to ignore those starting at an address under the first code segment.
Greg suggested to implement it this way so we don't need to check all sections for every line sequence.

Reviewed By: clayborg

Differential Revision: https://reviews.llvm.org/D87172
2020-11-09 08:26:00 -08:00
Georgii Rymar 57f87977f5 [LLDB][test] - Update one more test after the yaml2obj change.
I've missed this one.
2020-11-09 14:56:07 +03:00
Michał Górny bc125665c5 [lldb] [Host/freebsd] Set Arg0 for 'platform process list -v'
Same fix as in NetBSD (a6712889f5).

Differential Revision: https://reviews.llvm.org/D91026
2020-11-09 12:09:12 +01:00
Michał Górny 2384c4f971 Revert "[lldb] [Host/freebsd] Set Arg0 for 'platform process list -v'"
Accidentally referenced the wrong diff.

This reverts commit fce8e75889.
2020-11-09 12:09:12 +01:00
Georgii Rymar 62e3b2ec1d [lldb][test] - Update test cases after yaml2obj change.
The format of program header descriptions was changed by D90458.
2020-11-09 13:53:40 +03:00
Michał Górny afcdd43bf7 [llvm] [Support] Fix segv if argv0 is null in getMainExecutable()
When LLDB Python bindings are used and stack backtraces are enabled
for logging, getMainExecutable() is called with argv0 being null.
This caused the fallback function getprogpath() (used on FreeBSD, NetBSD
and Linux) to segfault.  Make it handle null executable name gracefully.

Differential Revision: https://reviews.llvm.org/D91012
2020-11-09 11:35:11 +01:00
Michał Górny fce8e75889 [lldb] [Host/freebsd] Set Arg0 for 'platform process list -v'
Same fix as in NetBSD (a6712889f5).

Differential Revision: https://reviews.llvm.org/D91012
2020-11-09 11:35:11 +01:00
Michał Górny 7e2ef84fe7 [lldb] [test] Extend watchpoint test to wait for thread to start
TestWatchpointMultipleThreads currently accounts for two scenarios:
setting the watchpoint before a new thread starts (presumably, verifying
that it will be propagated to the new thread) and setting it after
the thread starts (presumably, verifying that a new watchpoint is set
on all threads).  However, the latter test currently assumes that
the thread will be reported to the debugger before the breakpoint is
hit.  This is not the case on FreeBSD and NetBSD.

On NetBSD, new threads do not inherit debug registers from their parent
threads.  Instead, LLDB copies them manually after the new thread is
reported.  Since the thread is actually reported after the second
breakpoint location, both tests effectively check the same behavior
(i.e. watchpoint being set before the new thread is reported).

On FreeBSD, new threads inherit debug registers and we seem to hit
an interesting race condition.  While the thread is reported after
the breakpoint is hit, the kernel seems to construct it and copy
the debug register before that happens.  As a result, setting
the watchpoint at the second breakpoint location modifies the debug
registers of the first thread after they have been copied to the second
thread but before the debugger is aware of it.  Therefore,
the watchpoint is not propagated to the second thread and the test
fails.

Extend the test to cover all three possible scenarios: setting
watchpoint before the thread is lanched, after it is launched but before
it is guaranteed to have started and after it has actually started.  Add
a second barrier to account for the last case.  This should ensure that
the second assumption (i.e. that the watchpoint is set on all currently
known threads) is actually tested on FreeBSD and NetBSD.

Differential Revision: https://reviews.llvm.org/D91030
2020-11-09 11:35:11 +01:00
Michał Górny 9e1409aa1e [lldb] [Process/FreeBSDRemote] Handle exec() from inferior
Differential Revision: https://reviews.llvm.org/D90938
2020-11-09 11:35:11 +01:00
Jan Kratochvil 24f07531a3 [lldb] Fix DW_AT_decl_file from DW_AT_specification from a different CU
This would be reproducible in future DWZ category of the testsuite as:
  Failed Tests (1):
    lldb-api :: python_api/symbol-context/two-files/TestSymbolContextTwoFiles.py

Differential Revision: https://reviews.llvm.org/D91014
2020-11-09 10:52:48 +01:00
Michał Górny 93c9110c98 [lldb] [test] Use skipUnlessDarwin for tests specific to Darwin
Use skipUnlessDarwin decorator for tests that are specific to Darwin,
instead of skipIf... for all other platforms.  This should make it clear
that these tests are not supposed to work elsewhere.  It will also make
these tests stop repeatedly popping up while I look for tests that could
be fixed on the platform in question.

Differential Revision: https://reviews.llvm.org/D91003
2020-11-07 19:26:42 +01:00
Michał Górny 1ba9cedd0a [lldb] [test] Un-skip one of TestRaise signals on fbsd 2020-11-07 19:26:42 +01:00
Richard Howell 137ff73317 [lldb] add a missing dependency on intrinsics_gen
Sometimes builds will fail with errors like:

```
In file included from /build/external/llvm-project/lldb/source/Symbol/SwiftASTContext.cpp:52:
In file included from /build/external/swift/include/swift/IRGen/Linking.h:22:
In file included from /build/external/swift/include/swift/SIL/SILFunction.h:24:
In file included from /build/external/swift/include/swift/SIL/SILBasicBlock.h:23:
In file included from /build/external/swift/include/swift/SIL/SILInstruction.h:21:
In file included from /build/external/swift/include/swift/AST/Builtins.h:24:
**/build/external/llvm-project/llvm/include/llvm/IR/Attributes.h:74:14: fatal error: 'llvm/IR/Attributes.inc' file not found**
**^~~~~~~~~~~~~~~~~~~~~~~~**
```
This change ensures the `Attributes.inc` file is generated before building `SwiftASTContext.cpp`.

Differential Revision: https://reviews.llvm.org/D90857
2020-11-06 13:15:08 -05:00
Michał Górny 1a8d52820f [lldb] [test] Avoid double negation in llgs/debugserver logic
Use positive logic (i.e. llgs_platform/debugserver_platform) for
indicating which platforms use the particular server variant.
Deduplicate the lists — it is rather expected that none of the platforms
using LLGS would use debugserver.

Differential Revision: https://reviews.llvm.org/D90875
2020-11-06 14:34:12 +01:00
Walter Erquinigo cfd96f057b [trace][intel-pt] Implement the basic decoding functionality
Depends on D89408.

This diff finally implements trace decoding!

The current interface is

  $ trace load /path/to/trace/session/file.json
  $ thread trace dump instructions

  thread #1: tid = 3842849, total instructions = 22
    [ 0] 0x40052d
    [ 1] 0x40052d
    ...
    [19] 0x400521

  $ # simply enter, which is a repeat command
    [20] 0x40052d
    [21] 0x400529
    ...

This doesn't do any disassembly, which will be done in the next diff.

Changes:
- Added an IntelPTDecoder class, that is a wrapper for libipt, which is the actual library that performs the decoding.
- Added TraceThreadDecoder class that decodes traces and memoizes the result to avoid repeating the decoding step.
- Added a DecodedThread class, which represents the output from decoding and that for the time being only stores the list of reconstructed instructions. Later it'll contain the function call hierarchy, which will enable reconstructing backtraces.
- Added basic APIs for accessing the trace in Trace.h:
  - GetInstructionCount, which counts the number of instructions traced for a given thread
  - IsTraceFailed, which returns an Error if decoding a thread failed
  - ForEachInstruction, which iterates on the instructions traced for a given thread, concealing the internal storage of threads, as plug-ins can decide to generate the instructions on the fly or to store them all in a vector, like I do.
- DumpTraceInstructions was updated to print the instructions or show an error message if decoding was impossible.
- Tests included

Differential Revision: https://reviews.llvm.org/D89283
2020-11-05 18:38:03 -08:00
Jonas Devlieghere 99a99c29c6 [lldb] Remove Crashlog/interactive.test
This test requires running under the Python we built against (which is
easy) and setting up the PYTHONPATH (which is not worth it for this
simple test).
2020-11-05 17:10:52 -08:00
Vedant Kumar 65d15fefe3 [TargetList] Delete the destructor
AFAICT, ~TargetList simply implements the default destructor, plus some
locking.

The history is murky, so I'm not sure why we do this locking. Perhaps,
at some point, it was possible to delete the same TargetList instance
from two different threads, setting up a race. If that were true, then
the locking would protect against the race.

Since TargetList is uniquely owned by Debugger (m_target_list), no such
race is possible today.

Testing: check-lldb

Differential Revision: https://reviews.llvm.org/D90895
2020-11-05 16:56:37 -08:00
Vedant Kumar 16e5a347e7 [TargetList] Simplify dummy target creation
Factor out dummy target creation from CreateTargetInternal.

This makes it impossible for dummy target creation to accidentally fail
due to too-strict checking in one of the CreateTargetInternal overloads.

Testing: check-lldb

rdar://70630655

Differential Revision: https://reviews.llvm.org/D90872
2020-11-05 16:04:02 -08:00
Pedro Tammela ca17571051 [LLDB-lua] modify Lua's 'print' to respect 'io.stdout'
This patch changes the implementation of Lua's `print()` function to
respect `io.stdout`.

The original implementation uses `lua_writestring()` internally, which is
hardcoded to `stdout`.

Reviewed By: JDevlieghere

Differential Revision: https://reviews.llvm.org/D90787
2020-11-05 21:23:20 +00:00
Michał Górny 40140e122f [lldb] [Process/FreeBSDRemote] Remove thread name caching
Remove the thread name caching code.  It does not handle the possibility
of thread name changing between requests, therefore breaking
TestGdbRemoteThreadName.  While technically we could cache the results
and reset the cache on resuming process, the gain from doing that
does not seem worth the effort.

Differential Revision: https://reviews.llvm.org/D90863
2020-11-05 20:45:34 +01:00
Michał Górny b643deb03f [lldb] [test] Fix TestGdbRemoteThreadName code on FreeBSD
Fix TestGdbRemoteThreadName to call ::pthread_setname_np instead
of ::pthread_set_name_np on FreeBSD.  While technically both names
are correct, the former is preferable because of compatibility
with Linux.  Furthermore, the latter requires `#include <pthread_np.h>`
that was missing causing the test to fail to compile.

Differential Revision: https://reviews.llvm.org/D90862
2020-11-05 20:45:34 +01:00
Michał Górny 2c2eb5e670 [lldb] Enable FreeBSDRemote plugin by default and update test status
The new FreeBSDRemote plugin has reached feature parity on i386
and amd64 targets.  Use it by default on these architectures, while
allowing the use of the legacy plugin via FREEBSD_LEGACY_PLUGIN envvar.

Revisit the method of switching plugins.  Apparently, the return value
of PlatformFreeBSD::CanDebugProcess() is what really decides whether
the legacy or the new plugin is used.

Update the test status.  Reenable the tests that were previously
disabled on FreeBSD and do not cause hangs or are irrelevant to FreeBSD.
Mark all tests that fail reliably as expectedFailure.  For now, tests
that are flaky (i.e. produce unstable results) are left enabled
and cause unpredictable test failures.

Differential Revision: https://reviews.llvm.org/D90757
2020-11-05 17:49:46 +01:00
Michał Górny 6ba2c2bf90 [lldb] [test/Shell] Simplify -pthread condition
Pass -pthread on all systems except for Darwin and Windows.
Suggested by Pavel Labath.
2020-11-05 17:49:20 +01:00
Raphael Isemann 79d16764dd [lldb][NFC] Fix compiler warnings after removal of eValueTypeVector
5d64574301 removes this enum value and now
all the switch statements that previously relied on handling this in the
'default' branch are causes compiler warnings due to redundant default cases.

This just removes the now unreachable code in there.
2020-11-05 17:17:33 +01:00
Raphael Isemann b9b5f12bd4 [lldb] Set the default architecture also in buildDefault
In D89056 the default value for architecture was moved to `build` so that
all called functions see the same architecture value. It seems there are a
few functions that call buildDefault directly (and not via build), so
on some test configurations that set a custom arch value the architecture
value is no longer available.

This just adds the architecture code from build to buildDefault to get
the bots green again while I'm looking for a better solution.
2020-11-05 16:32:05 +01:00
Raphael Isemann 26a8e8502b [lldb] Add Apple simulator platforms to lldbplatform.py
This just adds the simulator platforms to the lldbplatform enumerations
and the respective test decorator.

The platform names for the simulator are just the SDK names since D85537, so
that's why we are not using LLDB's usual platform names here (e.g., SDK =
"iphonesimulator" vs LLDB platform ="ios-simulator").

Also removes the duplicate platform enumaration in lldbplatformutil.py.

Reviewed By: JDevlieghere

Differential Revision: https://reviews.llvm.org/D89694
2020-11-05 15:34:42 +01:00
Raphael Isemann d68ebea767 Reland [lldb] Explicitly use the configuration architecture when building test executables
This originally broke the TestQuoting which explicitly called buildDefault
instead of calling build() and marking the test as no_debug_info_test.
TestQuoting has been rewritten by now and is using `build`, so this should now
pass on all platforms.

Original summary:

The Darwin builder currently assumes in `getArchCFlags` that the passed `arch`
value is an actual string it can string.join with vendor/os/version/env strings:

```
   triple = '-'.join([arch, vendor, os, version, env])
```

However this is not true for most tests as we just pass down the `arch=None`
default value from `TestBase.build`. This causes that if we actually end up in
this function we just error out when concatenating `None` with the other actual
strings of vendor/os/version/env. What we should do instead is check that if
there is no test-specific architecture that we fall back to the configuration's
architecture value.

It seems we already worked around this in `builder.getArchSpec` by explicitly
falling back to the architecture specified in the configuration.

This patch just moves this fallback logic to the top `build` function so that it
affects all functions called from `TestBase.build`.

Reviewed By: JDevlieghere

Differential Revision: https://reviews.llvm.org/D89056
2020-11-05 15:13:48 +01:00
Raphael Isemann 239f488fd6 [lldb] Skip TestChangeProcessGroup on watchOS/tvOS
`fork` is marked as `__WATCHOS_PROHIBITED __TVOS_PROHIBITED` so the test source
which is calling fork will never compile on watchOS/tvOS. This just adds the
skip decorator for these platforms.

Reviewed By: mib

Differential Revision: https://reviews.llvm.org/D89695
2020-11-05 15:11:30 +01:00
Raphael Isemann 2f84b59a4c [lldb] Also Catch invalid calls to TestPExpectTest's expect()
This is a follow up to D88792 which found an issue in a call to PExpectTest's
expect function that allows passing a string to the `substrs` parameter. However
this issue was found by just grepping and TestPExpect's expect function is still
accepting a single string as a value to `substrs`.

This patch adds the same sanity check that D88792 added to the PExpectTest's
implementation of `expect` and also adds a small test for it.

Reviewed By: kastiglione, JDevlieghere

Differential Revision: https://reviews.llvm.org/D89302
2020-11-05 14:08:46 +01:00
Jonas Devlieghere c29c24be63 [crashlog] Pass the debugger around instead of relying on lldb.debugger
The lldb.debugger et al convenience variables are only available from
the interactive script interpreter. In all other scenarios, they are
None (since fc1fd6bf9f) before that they
were default initialized.

The crashlog script was hacking around that by setting the lldb.debugger
to a newly created debugger instance when running outside of the script
interpreter, which works fine until lldb creates a script interpreter
instance under the hood and clears the variables. This was resulting in
an AttributeError when invoking the script directly (from outside of
lldb):

  AttributeError: 'NoneType' object has no attribute 'GetSourceManager'

This patch fixes that by passing around the debugger instance.

rdar://64775776

Differential revision: https://reviews.llvm.org/D90706
2020-11-04 12:51:26 -08:00
Pavel Labath 586c375fa3 [lldb] Remove [US]IntValueIsValidForSize from CommandObjectMemory
Use llvm::is(U)IntN (MathExtras.h) instead.
2020-11-04 16:28:10 +01:00
Pavel Labath e2d24d91c2 [lldb/Utility] Delete Scalar::[US]IntValueIsValidForSize
It's unused, and the same functionality is available in llvm (is(U)IntN
in MathExtras.h).
2020-11-04 16:28:10 +01:00
Pavel Labath ac6799d25a [lldb] Improve RegisterValue::GetScalarValue
Using Scalar::SetValueFromData, we make the code simpler, handle
big-endian systems properly, _and_ avoid type aliasing issues.
2020-11-04 14:53:06 +01:00
Pavel Labath 5d64574301 [lldb] Delete Value::Vector class
This class and it's surroundings contain a lot of shady code, but as far
as I can tell all of that code is unreachable (there is no code actually
setting the value to eValueTypeVector).

According to history this class was introduced in 2012 in
r167033/0665a0f09. At that time, the code seemed to serve some purpose,
and it had two entry points (in Value::SetContext and
ClangExpressionDeclMap::LookupDecl). The first entry point was deleted
in D17897 and the second one in r179842/44342735.

The stated purpose of the patch introducing this class was to fix
TestRegisters.py, and "expr $xmm0" in particular. Both of these things
function perfectly well these days without this class.
2020-11-04 10:21:56 +01:00
Jordan Rupprecht 33945cdd62 [NFC] Fix call to lldb RegisterValue constructor 2020-11-03 13:24:06 -08:00