Commit Graph

5100 Commits

Author SHA1 Message Date
Adrian Prantl 017d7a9e14 Rename human-readable name for DW_LANG_Mips_Assembler
The Mips in DW_LANG_Mips_Assembler is a vendor name not an
architecture name and in lack of a proper generic DW_LANG_assembler,
some assemblers emit DWARF using this tag. Due to a warning I recently
introduced users will now be greeted with

  This version of LLDB has no plugin for the mipsassem language. Inspection of frame variables will be limited.

By renaming this to just "Assembler" this error message will make more sense.

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

rdar://77214764
2021-05-12 19:13:58 -07:00
Michał Górny b6c0edb979 [lldb] [Process/elf-core] Fix reading FPRs from FreeBSD/i386 cores
The FreeBSD coredumps from i386 systems contain only FSAVE-style
NT_FPREGSET.  Since we do not really support reading that kind of data
anymore, just use NT_X86_XSTATE to get FXSAVE-style data when available.

Differential Revision: https://reviews.llvm.org/D101086
2021-05-12 11:51:37 +02:00
Jim Ingham 10c309ad81 Removing test...
Actually, I don't think this test is going to be stable enough
to be worthwhile.  Let me see if I can think of a better way to
test this.
2021-05-11 18:27:37 -07:00
Jim Ingham 0f2eb7e6e5 This test is failing on Linux, skip while I investigate.
The gdb-remote tests are a bit artificial, depending on
Python threading, and sleeps.  So I'm not 100% surprised it doesn't
work straight up on another XSsystem.
2021-05-11 18:13:56 -07:00
Jim Ingham 9558b602b2 Add an "interrupt timeout" to Process, and pipe that through the
ProcessGDBRemote plugin layers.

Also fix a bug where if we tried to interrupt, but the ReadPacket
wakeup timer woke us up just after the timeout, we would break out
the switch, but then since we immediately check if the response is
empty & fail if it is, we could end up actually only giving a
small interval to the interrupt.

Differential Revision: https://reviews.llvm.org/D102085
2021-05-11 11:57:08 -07:00
Jim Ingham 72ba78c29e When SendContinuePacketAndWaitForResponse returns eStateInvalid, don't fetch more packets.
This looks like just an oversight in the AsyncThread function.  It gets a result of
eStateInvalid, and then marks the process as exited, but doesn't set "done" to true,
so we go to fetch another event.  That is not safe, since you don't know when that
extra packet is going to arrive.  If it arrives while you are tearing down the
process, the internal-state-thread might try to handle it when the process in not
in a good state.

Rather than put more effort into checking all the shutdown paths to make sure this
extra packet doesn't cause problems, just don't fetch it.  We weren't going to do
anything useful with it anyway.

The main part of the patch is setting "done = true" when we get the eStateInvalid.
I also added a check at the beginning of the while(done) loop to prevent another error
from getting us to fetch packets for an exited process.

I added a test case to ensure that if an Interrupt fails, we call the process
exited.  I can't test exactly the error I'm fixing, there's no good way to know
that the stop reply for the failed interrupt wasn't fetched.  But at least this
asserts that the overall behavior is correct.

Differential Revision: https://reviews.llvm.org/D101933
2021-05-06 14:11:42 -07:00
Raphael Isemann 3026f75ed0 [lldb][NFC] Make assert in TestStaticVariables more expressive 2021-05-06 16:00:24 +02:00
Med Ismail Bennani 9775582e34 [lldb/Test] Disable testBreakpointByLineAndColumnNearestCode on Windows
Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2021-05-05 06:04:08 +00:00
Med Ismail Bennani 35ecfda01c [lldb/Symbol] Fix column breakpoint `move_to_nearest_code` match
This patch fixes the column symbol resolution when creating a breakpoint
with the `move_to_nearest_code` flag set.

In order to achieve this, the patch adds column information handling in
the `LineTable`'s `LineEntry` finder. After experimenting a little, it
turns out the most natural approach in case of an inaccurate column match,
is to move backward and match the previous `LineEntry` rather than going
forward like we do with simple line breakpoints.

The patch also reflows the function to reduce code duplication.

Finally, it updates the `BreakpointResolver` heuristic to align it with
the `LineTable` method.

rdar://73218201

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

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2021-05-05 05:07:50 +00:00
Walter Erquinigo ade59d5309 [trace] Dedup different source lines when dumping instructions + refactor
When dumping the traced instructions in a for loop, like this one

  4:  for (int a = 0; a < n; a++)
  5:    do something;

there might be multiple LineEntry objects for line 4, but with different address ranges. This was causing the dump command to dump something like this:

```
  a.out`main + 11 at main.cpp:4
    [1] 0x0000000000400518    movl   $0x0, -0x8(%rbp)
    [2] 0x000000000040051f    jmp    0x400529                  ; <+28> at main.cpp:4
  a.out`main + 28 at main.cpp:4
    [3] 0x0000000000400529    cmpl   $0x3, -0x8(%rbp)
    [4] 0x000000000040052d    jle    0x400521                  ; <+20> at main.cpp:5
```

which is confusing, as main.cpp:4 appears twice consecutively.

This diff fixes that issue by making the line entry comparison strictly about the line, column and file name. Before it was also comparing the address ranges, which we don't need because our output is strictly about what the user sees in the source.

Besides, I've noticed that the logic that traverses instructions and calculates symbols and disassemblies had too much coupling, and made my changes harder to implement, so I decided to decouple it. Now there are two methods for iterating over the instruction of a trace. The existing one does it on raw load addresses, but the one provides a SymbolContext and an InstructionSP, and does the calculations efficiently (not as efficient as possible for now though), so the caller doesn't need to care about these details. I think I'll be using that iterator to reconstruct the call stacks.

I was able to fix a test with this change.

Differential Revision: https://reviews.llvm.org/D100740
2021-05-04 19:40:52 -07:00
Muhammad Omair Javaid 69a3269250 Support AArch64 PAC elf-core register read
This adds support for reading AArch64 Pointer Authentication regset
from elf-core file. Also includes a test-case for the same. Furthermore
there is also a slight refactoring of RegisterContextPOSIXCore_arm64
members and constructor. linux-aarch64-pac.core file is generated using
lldb/test/API/functionalities/postmortem/elf-core/main.c with following
clang arguments:
-march=armv8.5-a -mbranch-protection=pac-ret+leaf -nostdlib -static -g

Reviewed By: DavidSpickett

Differential Revision: https://reviews.llvm.org/D99941
2021-05-03 16:04:47 +05:00
David Spickett f31e390453 [lldb][AArch64] Don't check for VmFlags in smaps files
AArch64 kernel builds default to having /smaps and
the "VmFlags" line was added in 3.8. Long before MTE
was supported.

So we can assume that if you're AArch64 with MTE,
you can run this test.

The previous method of checking had a race condition
where the process we read smaps for, could finish before
we get to read the file.

I explored some alternatives but in the end I think
it's fine to just assume we have what we need.

Reviewed By: omjavaid

Differential Revision: https://reviews.llvm.org/D100493
2021-04-29 09:30:14 +01:00
Adrian Prantl 711a473cd9 Update testcase for D101333. 2021-04-27 13:24:24 -07:00
Adrian Prantl 25bf137b1e Also display the underlying error message when displaying a fixit
When the user running LLDB with default settings sees the fixit
notification it means that the auto-applied fixit didn't work. This
patch shows the underlying error message instead of just the fixit to
make it easier to understand what the error in the expression was.

Differential Revision: https://reviews.llvm.org/D101333
2021-04-27 10:40:42 -07:00
Michał Górny ca7824c2a8 [lldb] [gdb-remote] Report QPassSignals and qXfer via extensions API
Remove hardcoded platform list for QPassSignals, qXfer:auxv:read
and qXfer:libraries-svr4:read and instead query the process plugin
via the GetSupportedExtensions() API.

Differential Revision: https://reviews.llvm.org/D101241
2021-04-27 19:34:00 +02:00
Raphael Isemann a0c735e29a [lldb] Skip TestPointerToMemberTypeDependingOnParentSize on Windows and GCC
The test added in D100977 is failing to compile on these platforms. This seems
to be caused by GCC, MSVC and Clang@Windows rejecting the code because
`ToLayout` isn't complete when pointer_to_member_member is declared (even though
that seems to be valid code).

This also reverts the test changes in the lazy-loading test from D100977 as
that failed for the same reason.
2021-04-26 18:55:54 +02:00
Jonas Devlieghere 7d850db6b6 [lldb] Don't use ::fork or ::vfork on watchOS or tvOS
Update lldb-server to not use fork or vfork on watchOS and tvOS as these
functions are explicitly marked unavailable there.

llvm-project/lldb/test/API/tools/lldb-server/main.cpp:304:11:
error: 'fork' is unavailable: not available on watchOS
      if (fork() == 0)
          ^
WatchSimulator6.2.sdk/usr/include/unistd.h:447:8: note: 'fork' has been
explicitly marked unavailable here
pid_t    fork(void) __WATCHOS_PROHIBITED __TVOS_PROHIBITED;
         ^
llvm-project/lldb/test/API/tools/lldb-server/main.cpp:307:11:
error: 'vfork' is unavailable: not available on watchOS
      if (vfork() == 0)
          ^
WatchSimulator6.2.sdk/usr/include/unistd.h:602:8: note: 'vfork' has been
explicitly marked unavailable here
pid_t    vfork(void) __WATCHOS_PROHIBITED __TVOS_PROHIBITED;
         ^
2021-04-26 09:31:35 -07:00
Emre Kultursay e439a463a3 [lldb] Use forward type in pointer-to-member
This change is similar in spirit to the change at:
https://reviews.llvm.org/rG34c697c85e9d0af11a72ac4df5578aac94a627b3

It fixes the problem where the layout of a type was being accessed
while its base classes were not populated yet; which caused an
incorrect layout to be produced and cached.

This fixes PR50054

Reviewed By: teemperor

Differential Revision: https://reviews.llvm.org/D100977
2021-04-26 15:23:58 +02:00
Michał Górny bbae0c1f7b [lldb] [llgs] Support owning and detaching extra processes
Add a NativeDelegate API to pass new processes (forks) to LLGS,
and support detaching them via the 'D' packet.  A 'D' packet without
a specific PID detaches all processes, otherwise it detaches either
the specified subprocess or the main process, depending on the passed
PID.

Differential Revision: https://reviews.llvm.org/D100191
2021-04-24 11:08:33 +02:00
Michał Górny 312257688e [lldb] [Process] Introduce protocol extension support API
Introduce a NativeProcessProtocol API for indicating support for
protocol extensions and enabling them.  LLGS calls
GetSupportedExtensions() method on the process factory to determine
which extensions are supported by the plugin.  If the future is both
supported by the plugin and reported as supported by the client, LLGS
enables it and reports to the client as supported by the server.

The extension is enabled on the process instance by calling
SetEnabledExtensions() method.  This is done after qSupported exchange
(if the debugger is attached to any process), as well as after launching
or attaching to a new inferior.

The patch adds 'fork' extension corresponding to 'fork-events+'
qSupported feature and 'vfork' extension for 'vfork-events+'.  Both
features rely on 'multiprocess+' being supported as well.

Differential Revision: https://reviews.llvm.org/D100153
2021-04-24 11:08:33 +02:00
Jonas Devlieghere 91d3f73937 [lldb] Update register state parsing for JSON crashlogs
- The register encoding state in the JSON crashlog format changes.
   Update the parser accordingly.
 - Print the register state when printing the symbolicated thread.
2021-04-22 16:40:59 -07:00
Adrian Prantl 007158ac42 Skip unreliable LLDB tests when running under asan 2021-04-22 11:55:43 -07:00
Jonas Devlieghere a62cbd9a02 [lldb] Include thread name in crashlog.py output
Update the JSON parser to include the thread name in the Thread object.

rdar://76677320
2021-04-22 11:38:53 -07:00
Raphael Isemann d616a6bd10 [lldb] Fix that the expression commands --top-level flag overwrites --allow-jit false
The `--allow-jit` flag allows the user to force the IR interpreter to run the
provided expression.

The `--top-level` flag parses and injects the code as if its in the top level
scope of a source file.

Both flags just change the ExecutionPolicy of the expression:
* `--allow-jit true` -> doesn't change anything (its the default)
* `--allow-jit false` -> ExecutionPolicyNever
* `--top-level` -> ExecutionPolicyTopLevel

Passing `--allow-jit false` and `--top-level` currently causes the `--top-level`
to silently overwrite the ExecutionPolicy value that was set by `--allow-jit
false`. There isn't any ExecutionPolicy value that says "top-level but only
interpret", so I would say we reject this combination of flags until someone
finds time to refactor top-level feature out of the ExecutionPolicy enum.

The SBExpressionOptions suffer from a similar symptom as `SetTopLevel` and
`SetAllowJIT` just silently disable each other. But those functions don't have
any error handling, so not a lot we can do about this in the meantime.

Reviewed By: labath, kastiglione

Differential Revision: https://reviews.llvm.org/D91780
2021-04-22 18:51:03 +02:00
Raphael Isemann d2223c7a49 [lldb] XFAIL TestStoppedInStaticMemberFunction on Windows
It seems we can't find the symbols of static members on Windows? The bug is not
 relevant to what this test is actually testing so let's just XFAIL it.
2021-04-22 13:46:27 +02:00
Raphael Isemann 00764c36ed [lldb] Add support for evaluating expressions in static member functions
At the moment the expression parser doesn't support evaluating expressions in
static member functions and just pretends the expression is evaluated within a
non-member function. This causes that all static members are inaccessible when
doing unqualified name lookup.

This patch adds support for evaluating in static member functions. It
essentially just does the same setup as what LLDB is already doing for
non-static member functions (i.e., wrapping the expression in a fake member
function) with the difference that we now mark the wrapping function as static
(to prevent access to non-static members).

Reviewed By: shafik, jarin

Differential Revision: https://reviews.llvm.org/D81550
2021-04-22 12:14:31 +02:00
Jonas Devlieghere 39ea3ceda3 [lldb] Disable TestSimulatorPlatform.py because it's causing a SIGHUP
Ever since Dave Zarzycki's patch to sort test start times based on prior
test timing data (https://reviews.llvm.org/D98179) the test suite aborts
with a SIGHUP. I don't believe his patch is to blame, but rather
uncovers an preexisting issue by making test runs more deterministic.

I was able to narrow down the issue to TestSimulatorPlatform.py. The
issue also manifests itself on the standalone bot on GreenDragon [1].
This patch disables the test until we can figure this out.

[1] http://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake-standalone/

rdar://76995109
2021-04-21 20:00:51 -07:00
Walter Erquinigo c9a0754b44 [lldb-vscode] Distinguish shadowed variables in the scopes request
VSCode doesn't render multiple variables with the same name in the variables view. It only renders one of them. This is a situation that happens often when there are shadowed variables.
The nodejs debugger solves this by adding a number suffix to the variable, e.g. "x", "x2", "x3" are the different x variables in nested blocks.

In this patch I'm doing something similar, but the suffix is " @ <file_name:line>), e.g. "x @ main.cpp:17", "x @ main.cpp:21". The fallback would be an address if the source and line information is not present, which should be rare.

This fix is only needed for globals and locals. Children of variables don't suffer of this problem.

When there are shadowed variables
{F16182150}

Without shadowed variables
{F16182152}

Modifying these variables through the UI works

Reviewed By: clayborg

Differential Revision: https://reviews.llvm.org/D99989
2021-04-21 15:09:39 -07:00
Walter Erquinigo 64f47c1e58 [lldb-vscode] redirect stderr/stdout to the IDE's console
In certain occasions times, like when LLDB is initializing and
evaluating the .lldbinit files, it tries to print to stderr and stdout
directly. This confuses the IDE with malformed data, as it talks to
lldb-vscode using stdin and stdout following the JSON RPC protocol. This
ends up terminating the debug session with the user unaware of what's
going on. There might be other situations in which this can happen, and
they will be harder to debug than the .lldbinit case.

After several discussions with @clayborg, @yinghuitan and @aadsm, we
realized that the best course of action is to simply redirect stdout and
stderr to the console, without modifying LLDB itself. This will prove to
be resilient to future bugs or features.

I made the simplest possible redirection logic I could come up with. It
only works for POSIX, and to make it work with Windows should be merely
changing pipe and dup2 for the windows equivalents like _pipe and _dup2.
Sadly I don't have a Windows machine, so I'll do it later once my office
reopens, or maybe someone else can do it.

I'm intentionally not adding a stop-redirecting logic, as I don't see it
useful for the lldb-vscode case (why would we want to do that, really?).

I added a test.

Note: this is a simpler version of D80659. I first tried to implement a
RIIA version of it, but it was problematic to manage the state of the
thread and reverting the redirection came with some non trivial
complexities, like what to do with unflushed data after the debug
session has finished on the IDE's side.
2021-04-21 14:48:48 -07:00
Walter Erquinigo 12a2507646 Fix TestVSCode_launch test
Broken in https://lab.llvm.org/buildbot/#/builders/96/builds/6933

We don't really need to run this test on arm, but would be worth fixing
it later.
2021-04-21 14:33:34 -07:00
Walter Erquinigo 79fbbeb412 [lldb-vscode] Add postRunCommands
This diff ass postRunCommands, which are the counterpart of the preRunCommands. TThey will be executed right after the target is launched or attached correctly, which means that the targets can assume that the target is running.

Differential Revision: https://reviews.llvm.org/D100340
2021-04-21 13:51:30 -07:00
Jonas Devlieghere 5d1c43f333 [lldb] Use the compiler from the SDK in simulator tests
Use the clang compiler from the SDK to build the simulator test programs
to ensure we pick up the correct libc++.
2021-04-21 13:22:58 -07:00
Michał Górny e414ede2cd [lldb] [test/Register] Initial tests for regsets in core dumps
Add initial tests for reading register sets from core dumps.  This
includes a C++ program to write registers and dump core, resulting core
dumps for Linux, FreeBSD and NetBSD, and the tests to verify them.

The tests are split into generic part, verifying user-specified register
values, and coredump-specific tests that verify memory addresses that
differ for every dump.

At this moment, all platforms support GPRs and FPRs up to XMM for amd64
target.  The i386 target does not work on NetBSD at all, and is missing
FPRs entirely on FreeBSD.

Differential Revision: https://reviews.llvm.org/D91963
2021-04-21 19:41:09 +02:00
Pavel Labath 55ee541653 [lldb/test] Clean up TestThreadSpecificBpPlusCondition inferior
The test had a race that could cause two threads to end up with the same
"thread local" value. I believe this would not cause the test to fail,
but it could cause it to succeed even when the functionality is broken.

The new implementation removes this uncertainty, and removes a lot of
cruft left over from the time this test was written using pthreads.
2021-04-21 17:37:30 +02:00
Pavel Labath 953f580b90 [lldb/test] Modernize lldb-server test inferior
Avoid c string manipulation by introducing a StringRef-like
consume_front operation.
2021-04-21 17:02:41 +02:00
Pavel Labath cd64273f5e [lldb/ELF] Fix IDs of synthetic eh_frame symbols
The code used the total number of symbols to create a symbol ID for the
synthetic symbols. This is not correct because the IDs of real symbols
can be higher than their total number, as we do not add all symbols (and
in particular, we never add symbol zero, which is not a real symbol).

This meant we could have symbols with duplicate IDs, which caused
problems if some relocations were referring to the duplicated IDs. This
was the cause of the failure of the test D97786.

This patch fixes the code to use the ID of the highest (last) symbol
instead.
2021-04-21 11:24:43 +02:00
Jonas Devlieghere eff4f65afb [lldb] Simplify check for nill value in breakpoint_function_callback.test 2021-04-20 21:53:30 -07:00
Jonas Devlieghere cc68799056 [lldb] Stop unsetting LLDB_DEBUGSERVER_PATH from TestLaunchProcessPosixSpawn
We no longer need this after Pavel's change to automatically find debug
servers to test. (3ca7b2d)
2021-04-19 12:28:22 -07:00
Jonas Devlieghere a7712091ea [lldb] Update breakpoint_function_callback.test for different error message
Adjust for the Lua error message printed by Lua 5.4.3.
2021-04-19 12:23:23 -07:00
Caroline Tice 3dc24bc31e [LLDB] Re-land: Use path relative to binary for finding .dwo files.
DWARF allows .dwo file paths to be relative rather than absolute. When
they are relative, DWARF uses DW_AT_comp_dir to find the .dwo
file. DW_AT_comp_dir can also be relative, making the entire search
patch for the .dwo file relative. In this case, LLDB currently
searches relative to its current working directory, i.e. the directory
from which the debugger was launched. This is not right, as the
compiler, which generated the relative paths, can have no idea where
the debugger will be launched. The correct thing is to search relative
to the location of the executable binary. That is what this patch
does.

Differential Revision: https://reviews.llvm.org/D97786
2021-04-16 11:12:39 -07:00
Caroline Tice 042668d092 Revert "[LLDB] Use path relative to binary for finding .dwo files."
This reverts commit b241f3cb29.

Test case is breaking windows builder.
2021-04-15 17:17:44 -07:00
Caroline Tice b241f3cb29 [LLDB] Use path relative to binary for finding .dwo files.
DWARF allows .dwo file paths to be relative rather than absolute. When
they are relative, DWARF uses DW_AT_comp_dir to find the .dwo
file. DW_AT_comp_dir can also be relative, making the entire search
patch for the .dwo file relative. In this case, LLDB currently
searches relative to its current working directory, i.e. the directory
from which the debugger was launched. This is not right, as the
compiler, which generated the relative paths, can have no idea where
the debugger will be launched. The correct thing is to search relative
to the location of the executable binary. That is what this patch
does.

Differential Revision: https://reviews.llvm.org/D97786
2021-04-15 14:43:47 -07:00
Jonas Devlieghere a749bd7639 [lldb] Add addressing_bits to KNOWN_HOST_INFO_KEYS and sort the list
This fixes TestGdbRemoteHostInfo on Apple Silicon.
2021-04-14 14:15:17 -07:00
Pavel Labath ded660495f [lldb/test] Remove the "expect_captures" feature of lldb-server tests
This functionality is used exactly once, and it is trivial to implement
it differently (capture into two distinct variables, and compare for
equality afterwards).
2021-04-14 21:08:55 +02:00
David Spickett 6cdc2239db [lldb][AArch64] Simplify MTE memory region test
By checking for cpu and toolchain features ahead
of time we don't need the custom return codes.

Reviewed By: omjavaid

Differential Revision: https://reviews.llvm.org/D97684
2021-04-14 11:50:45 +01:00
Jonas Devlieghere accb095512 [lldb] Disable TestClangModulesUpdate.py because it's flaky
The test is failing intermittently on GreenDragon.

rdar://76540904
2021-04-13 20:37:17 -07:00
Pavel Labath 872b1da6ad [lldb/test] s/add_no_ack_remote_stream/do_handshake
These two functions are doing the same thing, only one of them is
sending the packets immediately and the other "queues" them to be sent
later. The first one is better as in case of errors, the backtrace will
point straight to the place that caused them.

Modify the first method to avoid duplication, and ten standardize on it.
2021-04-13 17:10:32 +02:00
David Spickett 29a4d7813c [lldb][AArch64] Only run MTE memory region test if we have MTE
This test is flakey because it tries to read the proc/smaps
file of the first lldb-server process it finds. This process
can finish before we finish doing that.

http://lab.llvm.org:8011/#/builders/96/builds/6634/steps/6/logs/stdio

For now limit this to MTE targets which basically means
QEMU via lldb-dotest, which doesn't have this issue.

I'll fix the race condition shortly.
2021-04-13 15:40:38 +01:00
Pavel Labath 14b9f320fe [lldb] Remote @debugserver_test from TestAppleSimulatorOSType
The annotation is now (since the introduction of @apple_simulator_test)
redundant, and the test could theoretically run on lldb-server too (if
it supported darwin hosts).
2021-04-13 16:09:50 +02:00
David Spickett f152472af5 [lldb] Require x86 for various NativePDB, Breakpad and Minidump tests
These tests fail if you build without the x86 llvm backend.
Either because they use an x86 triple or try to backtrace which
requires some x86 knowledge to see all frames.

Reviewed By: labath

Differential Revision: https://reviews.llvm.org/D100194
2021-04-13 12:51:48 +00:00