Commit Graph

1963 Commits

Author SHA1 Message Date
Walter Erquinigo 32bacb7410 [lldb][intel-pt] Remove old plugin
Now that LLDB proper has built-in support for intel-pt traces, we can remove the old plugin written by Intel. It has less features and it's hard to work with.

As a test, I ran "ninja lldbIntelFeatures" and it worked.

Differential Revision: https://reviews.llvm.org/D102866
2021-05-27 12:16:22 -07:00
Raphael Isemann 76e47d4887 [lldb][NFC] Use C++ versions of the deprecated C standard library headers
The C headers are deprecated so as requested in D102845, this is replacing them
all with their (not deprecated) C++ equivalent.

Reviewed By: shafik

Differential Revision: https://reviews.llvm.org/D103084
2021-05-26 12:46:12 +02:00
kuperxu 8dd106028b [debugserver] Add platform cache support to improve performance.
The dyld SPI used by debugserver (_dyld_process_info_create) has become
much slower in macOS BigSur 11.3 causing a significant performance
regression when attaching. This commit mitigates that by caching the
result when calling the SPI to compute the platform.

Differential revision: https://reviews.llvm.org/D102833
2021-05-20 19:10:46 -07:00
Jason Molenda afee09751d [NFC] Add GetInferiorAddrSize method, unify code to compute
MachProcess.mm has a sequence to get the address size in
the inferior in three places; and I'm about to add a fourth
in a future patch.  Not a fan.
2021-05-13 00:47:58 -07:00
Jason Molenda 0c443e92d3 Add some warnings when debugserver is running in translation
A debugserver launched x86_64 cannot control an arm64/arm64e
process on an Apple Silicon system.  Warn when this situation
has happened and return an error for the most common case of
attach.  I think there will be refinements to this in the
future, but start out by making it easy to spot the problem
when it happens.

rdar://76630595
2021-05-12 22:18:24 -07:00
Brad Smith 3a62d4fde8 Fix typo, arvm7 -> armv7 2021-05-05 00:56:44 -04:00
Jonas Devlieghere 2d5d720df0 [debugserver] Include LLDB_VERSION_SUFFIX in debugserver version
The lack of a dot before the suffix is intentional, as the suffix itself
includes a dot or dash.

Differential revision: https://reviews.llvm.org/D101655
2021-05-03 15:05:32 -07:00
Jonas Devlieghere b535459d0a [debugserver] Use add_lldb_library instead of add_library
Use add_lldb_library to ensure debugserver inherits the defines set by
llvm and lldb.

Differential revision: https://reviews.llvm.org/D101596
2021-04-29 22:09:10 -07:00
Walter Erquinigo 1141ba677e [lldb-vscode] Follow up of D99989 - store some strings more safely
As a follow up of https://reviews.llvm.org/D99989#inline-953343, I'm now
storing std::string instead of char *. I know it might never break as char *,
but if it does, chasing that bug might be dauting.
Besides, I'm also checking of the strings gotten through the SB API are
null or not.
2021-04-29 18:37:44 -07:00
Michał Górny 6c37984eba [lldb] [gdb-remote server] Introduce new stop reasons for fork and vfork
Introduce three new stop reasons for fork, vfork and vforkdone events.
This includes server support for serializing fork/vfork events into
gdb-remote protocol.  The stop infos for the two base events take a pair
of PID and TID for the newly forked process.

Differential Revision: https://reviews.llvm.org/D100196
2021-04-24 11:08:33 +02:00
Benjamin Kramer edc869cb57 [lldb-vscode] Use a DenseMap to pacify overly aggressive linters
Some linters get rather upset upon seeing
`std::unordered_map<const char*`, because it looks like a map of
strings but isn't. lldb uses interned strings so this is not a problem.
DenseMap is a better data structure for this anyways, so use that
instead.
2021-04-22 13:07:39 +02:00
Walter Erquinigo 875654f897 Fix VSCode/TestOptions.test
Found by https://lab.llvm.org/buildbot/#/builders/96/builds/6936
2021-04-21 15:46:26 -07:00
Walter Erquinigo c4a83c4e69 Fix TestVSCode_runInTerminal
It failed in https://lab.llvm.org/buildbot/#/builders/68/builds/10912

And it was caused due to https://reviews.llvm.org/rG64f47c1e58a1
2021-04-21 15:20:47 -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 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
Fangrui Song cdae6d7711 [lldb] Fix one leak in reproducer
Use a variable of static storage duration to reference an intentionally
leaked variable. A static data area is in the GC-set of various leak
checkers.

This fixes 3 `check-lldb-shell` tests in a `-DLLVM_USE_SANITIZER={Leaks,Address}` build,
e.g. `test/Shell/Reproducer/TestHomeDir.test`

Differential Revision: https://reviews.llvm.org/D100806
2021-04-19 19:39:10 -07:00
Jason Molenda 9d4415d01d Don't refer to allocation map entry after deallocating it
debugserver's MachTask::DeallocateMemory when removing an
allocate entry from our map (in resposne to an '_m' packet),
copy the size from the entry before removing it from the
map and then using the iterator to fix an ASAN error on
the bots when running TestGdbRemoteMemoryAllocation.py

rdar://76595998
2021-04-15 20:16:38 -07:00
Walter Erquinigo cc88d301a0 [lldb-vscode] Reduce chattiness of progress events
Progress events internally have a completed count and a total count, which can mean that for a job with 20000 total counts, then there will be 20000 events fired. Sending all these events to the IDE can break it. For example, debugging a huge binary resulted in around 50 million messages, which rendered the IDE useless, as it was spending all of its resources simply parsing messages and updating the UI.

A way to fix this is to send unique percentage updates, which are at most 100 per job, which is not much. I was able to debug that big target and confirm that only unique percentage notifications are sent. I can't write a test for this because the current test is flaky. I'll figure out later how to make the test reliable, but fixing this will unblock us from deploy a new version of lldb-vscode.

Differential Revision: https://reviews.llvm.org/D100443
2021-04-14 13:00:01 -07:00
Jonas Devlieghere e825effe9b [lldb] Build debugserver 2-way fat on AS
When compiling for arm, build debugserver 2 way fat with an arm64 and
arm64e slice. You can only debug arm64e processes using an arm64e
debugserver.
2021-04-13 19:55:13 -07:00
Jonas Devlieghere ae8a5c6852 [debugserver] Use class member initialization for RNBContext
Address Shafik Yaghmour's post commit code review feedback.
2021-04-13 10:39:27 -07:00
Jonas Devlieghere 8a5af9e284 [debugserver] Fix unintialized member variable
Caught by ubsan (__ubsan_handle_load_invalid_value_abort) when running
the unit tests.
2021-04-13 09:46:59 -07:00
Abhina Sreeskantharajan 82b3e28e83 [SystemZ][z/OS][Windows] Add new OF_TextWithCRLF flag and use this flag instead of OF_Text
Problem:
On SystemZ we need to open text files in text mode. On Windows, files opened in text mode adds a CRLF '\r\n' which may not be desirable.

Solution:
This patch adds two new flags

  - OF_CRLF which indicates that CRLF translation is used.
  - OF_TextWithCRLF = OF_Text | OF_CRLF indicates that the file is text and uses CRLF translation.

Developers should now use either the OF_Text or OF_TextWithCRLF for text files and OF_None for binary files. If the developer doesn't want carriage returns on Windows, they should use OF_Text, if they do want carriage returns on Windows, they should use OF_TextWithCRLF.

So this is the behaviour per platform with my patch:

z/OS:
OF_None: open in binary mode
OF_Text : open in text mode
OF_TextWithCRLF: open in text mode

Windows:
OF_None: open file with no carriage return
OF_Text: open file with no carriage return
OF_TextWithCRLF: open file with carriage return

The Major change is in llvm/lib/Support/Windows/Path.inc to only set text mode if the OF_CRLF is set.
```
  if (Flags & OF_CRLF)
    CrtOpenFlags |= _O_TEXT;
```

These following files are the ones that still use OF_Text which I left unchanged. I modified all these except raw_ostream.cpp in recent patches so I know these were previously in Binary mode on Windows.
./llvm/lib/Support/raw_ostream.cpp
./llvm/lib/TableGen/Main.cpp
./llvm/tools/dsymutil/DwarfLinkerForBinary.cpp
./llvm/unittests/Support/Path.cpp
./clang/lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp
./clang/lib/Frontend/CompilerInstance.cpp
./clang/lib/Driver/Driver.cpp
./clang/lib/Driver/ToolChains/Clang.cpp

Reviewed By: MaskRay

Differential Revision: https://reviews.llvm.org/D99426
2021-04-06 07:23:31 -04:00
Jonas Devlieghere b7e2c2acb8 [lldb-vscode] Use LLVM's ScopeExit to ensure we always terminate the debugger
Make sure we always terminate the debugger by using a RAII object.

Differential revision: https://reviews.llvm.org/D99702
2021-03-31 21:41:59 -07:00
Jonas Devlieghere 54c3c2e828 [lldb-vscode] Consistently use return EXIT_SUCCESS and EXIT_FAILURE (NFC)
Consistently use return with EXIT_SUCCESS or EXIT_FAILURE instead of
mix-and-matching return, exit 0, 1 etc.

Differential revision: https://reviews.llvm.org/D99701
2021-03-31 21:41:59 -07:00
Walter Erquinigo 0b69756110 [trace][intel-pt] Implement trace start and trace stop
This implements the interactive trace start and stop methods.

This diff ended up being much larger than I anticipated because, by doing it, I found that I had implemented in the beginning many things in a non optimal way. In any case, the code is much better now.

There's a lot of boilerplate code due to the gdb-remote protocol, but the main changes are:

- New tracing packets: jLLDBTraceStop, jLLDBTraceStart, jLLDBTraceGetBinaryData. The gdb-remote packet definitions are quite comprehensive.
- Implementation of the "process trace start|stop" and "thread trace start|stop" commands.
- Implementaiton of an API in Trace.h to interact with live traces.
- Created an IntelPTDecoder for live threads, that use the debugger's stop id as checkpoint for its internal cache.
- Added a functionality to stop the process in case "process tracing" is enabled and a new thread can't traced.
- Added tests

I have some ideas to unify the code paths for post mortem and live threads, but I'll do that in another diff.

Differential Revision: https://reviews.llvm.org/D91679
2021-03-30 17:31:37 -07:00
Jonas Devlieghere 984e2f440a [lldb] Prints error using WithColor::error in lldb-platform 2021-03-29 15:45:33 -07:00
Jonas Devlieghere 047cbfe2bb [lldb] Print stack trace when lldb-vscode crashes
Print LLVM's pretty stack trace when lldb-vscode crashes. Also removes
the unnecessary call to PrintStackTraceOnErrorSignal in lldb-server as
it's already part of InitLLVM.

Differential revision: https://reviews.llvm.org/D99535
2021-03-29 14:20:59 -07:00
Greg Clayton e122877f10 Add a progress class that can track long running operations in LLDB.
LLDB can often appear deadlocked to users that use IDEs when it is indexing DWARF, or parsing symbol tables. These long running operations can make a debug session appear to be doing nothing even though a lot of work is going on inside LLDB. This patch adds a public API to allow clients to listen to debugger events that report progress and will allow UI to create an activity window or display that can show users what is going on and keep them informed of expensive operations that are going on inside LLDB.

Differential Revision: https://reviews.llvm.org/D97739
2021-03-24 12:58:13 -07:00
Shafik Yaghmour ec00502b9f [NFC][LLDB] Removing extra semicolons to silence -Wc++98-compat-extra-semi diagnostics 2021-03-23 14:32:36 -07:00
Jonas Devlieghere e089b5e9e1 [lldb] Call os_log_fault on lldb_assert
Call `os_log_fault` when an lldb assert fails. We piggyback off
`LLVM_SUPPORT_XCODE_SIGNPOSTS`, which also depends on `os_log`, to avoid
having to introduce another CMake check and corresponding define.

This patch also adds a small test using lldb-test that verifies we abort
with a "regular" assertion when asserts are enabled.

Differential revision: https://reviews.llvm.org/D98987
2021-03-19 14:23:50 -07:00
Walter Erquinigo 34885bffdf [lldb-vscode] Handle request_evaluate's context attribute
Summary:
The request "evaluate" supports a "context" attribute, which is sent by VSCode. The attribute is defined here https://microsoft.github.io/debug-adapter-protocol/specification#Requests_Evaluate

The "clipboard" context is not yet supported by lldb-vscode, so we can forget about it for now. The 'repl' (i.e. Debug Console) and 'watch' (i.e. Watch Expression) contexts must use the expression parser in case the frame's variable path is not enough, as the user expects these expressions to never fail. On the other hand, the 'hover' expression is invoked whenever the user hovers on any keyword on the UI and the user is fine with the expression not being fully resolved, as they know that the 'repl' case is the fallback they can rely on.

Given that the 'hover' expression is invoked many many times without the user noticing it due to it being triggered by the mouse, I'm making it use only the frame's variable path functionality and not the expression parser. This should speed up tremendously the responsiveness of a debug session when the user only sets source breakpoints and inspect local variables, as the entire debug info is not needed to be parsed.

Regarding tests, I've tried to be as comprehensive as possible considering a multi-file project. Fortunately, the results from the "hover" case are enough most of the times.

Differential Revision: https://reviews.llvm.org/D98656
2021-03-15 15:09:23 -07:00
Jonas Devlieghere 3dcbfa27d4 [debugserver] Fix more compiler warnings on arm64
This fixes the following two warnings in code that's only compiled on
arm64:

 - warning: cast from 'const void *' to 'unsigned char *' drops const
   qualifier [-Wcast-qual]
 - warning: embedding a directive within macro arguments has undefined
   behavior [-Wembedded-directive]
2021-03-03 23:12:12 -08:00
Jonas Devlieghere 011a8e218e [debugserver] Fix logic to extract app bundle from file path
Fix the logic to find the app bundle in a path by correctly accounting
for paths containing multiple occurrences of `.app`. The new logic will
correctly extract `com.app.Foo.app` from `com.app.Foo.app/com.app.Foo`.

rdar://74666208

Differential revision: https://reviews.llvm.org/D97441
2021-02-24 23:08:42 -08:00
António Afonso 878d82c4f2 Revert "[lldb-vscode] Emit the breakpoint changed event on location resolved"
This reverts commit 1f21d488bd.
2021-02-21 13:08:06 -08:00
António Afonso 1f21d488bd [lldb-vscode] Emit the breakpoint changed event on location resolved
VSCode was not being informed whenever a location had been resolved (after being initated as non-resolved), so even though it was actually resolved, the IDE would show a hollow dot (instead of a red dot) because it didn't know about the change.

Differential Revision: https://reviews.llvm.org/D96680
2021-02-21 09:46:29 -08:00
Pavel Labath 004a264f8c [lldb] Fix shared library directory computation on windows
Our code for locating the shared library directory works via dladdr (or
the windows equivalent) to locate the path of an address known to reside
in liblldb. This works great for C++ programs, but there's a catch.

When (lib)lldb is used from python (like in our test suite), this dladdr
call will return a path to the _lldb.so (or such) file in the python
directory. To compensate for this, we have code which attempts to
resolve this symlink, to ensure we get the canonical location. However,
here's the second catch.

On windows, this file is not a symlink (but a copy), so this logic
fails. Since most of our other paths are derived from the liblldb
location, all of these paths will be wrong, when running the test suite.
One effect of this was the failure to find lldb-server in D96202.

To fix this issue, I add some windows-specific code to locate the
liblldb directory. Since it cannot rely on symlinks, it works by
manually walking the directory tree -- essentially doing the opposite of
what we do when computing the python directory.

To avoid python leaking back into the host code, I implement this with
the help of a callback which can be passed to HostInfo::Initialize in
order to assist with the directory location. The callback lives inside
the python plugin.

I also strenghten the existing path test to ensure the returned path is
the right one.

Differential Revision: https://reviews.llvm.org/D96779
2021-02-18 15:37:52 +01:00
Jonas Devlieghere 71811048c0 [debugserver] Correctly pass argv[0] to execl
The execl function takes both the executable and argv[0].
2021-02-15 18:42:21 -08:00
Michał Górny bee4d6efe1 [lldb] Rename FreeBSDRemote to FreeBSD (NFC)
Differential Revision: https://reviews.llvm.org/D96557
2021-02-15 13:04:11 +01:00
Michał Górny cd44339856 [lldb] Remove the legacy FreeBSD plugin
The new FreeBSDRemote plugin has reached feature parity with the legacy
plugin, so we can finally remove the latter.  The new plugin will
be renamed to FreeBSD in a separate commit to avoid confusion.

Differential Revision: https://reviews.llvm.org/D96555
2021-02-15 13:04:11 +01:00
Jonas Devlieghere ac1242bce3 [debugserver] Fix more warnings in DNBArchImplARM64 2021-02-05 15:21:24 -08:00
Walter Erquinigo 36496cc299 [lldb-vscode] correctly use Windows macros
@mstorsjo found a mistake that I made when trying to fix some Windows
compilation errors encountered by @stella.stamenova.

I was incorrectly using the LLVM_ON_UNIX macro. In any case, proper use
of

  #if defined(_WIN32)

should be the actual fix.

Differential Revision: https://reviews.llvm.org/D96060
2021-02-04 11:03:33 -08:00
Jonas Devlieghere 5580fa10db [lldb] Fix debugserver-entitlements.plist path 2021-02-03 10:42:36 -08:00
Jonas Devlieghere 39047f6c2e [debugserver] Fix -Wmissing-field-initializers warnings on arm64 2021-02-02 10:29:09 -08:00
Jonas Devlieghere ec6815a72d [debugserver] Fix -Wsign-compare warnings on arm64 2021-02-02 10:23:57 -08:00
Jonas Devlieghere 9a62b7242a [debugserver] Fix -Wunused-function warnings on arm64 2021-02-02 10:20:11 -08:00
Jonas Devlieghere 870a58a758 [debugserver] Fix -Winconsistent-missing-override warnings on arm64 2021-02-02 09:41:18 -08:00
Martin Storsjö 11e74e512d [lldb] Remove a stray semicolon, fixing GCC warnings. NFC. 2021-02-01 13:45:07 +02:00
serge-sans-paille 27f2fe9163 Adapt lldb-instr to d47ee525f9 APi change 2021-01-29 10:58:40 +01:00
Walter Erquinigo 0bca9a7ce2 Fix lldb-vscode builds on Windows targeting POSIX
@stella.stamenova found out that lldb-vscode's Win32 macros were failing
when building on windows targetings POSIX platforms.

I'm changing these macros for LLVM_ON_UNIX, which should be more
accurate.
2021-01-28 09:36:13 -08:00