Commit Graph

1996 Commits

Author SHA1 Message Date
Michał Górny ec2d0ded1b [lldb] Remove "0x" prefix from hex values in dirty-pages
Remove the redudant "0x" prefix in the "dirty-pages" key of
qMemoryRegionInfo packet.  The client accepts hex values both with
and without the prefix.

Differential Revision: https://reviews.llvm.org/D110510
2021-10-11 21:04:11 +02:00
Michał Górny 9da2fa277e [lldb] Move StringConvert inside debugserver
The StringConvert API is no longer used anywhere but in debugserver.
Since debugserver does not use LLVM API, we cannot replace it with
llvm::to_integer() and llvm::to_float() there.  Let's just move
the sources into debugserver.

Differential Revision: https://reviews.llvm.org/D110478
2021-09-27 14:32:42 +02:00
Michał Górny 3a6ba36751 [lldb] Convert misc. StringConvert uses
Replace misc. StringConvert uses with llvm::to_integer()
and llvm::to_float(), except for cases where further refactoring is
planned.  The purpose of this change is to eliminate the StringConvert
API that is duplicate to LLVM, and less correct in behavior at the same
time.

Differential Revision: https://reviews.llvm.org/D110447
2021-09-25 14:19:19 +02:00
Michał Górny 5f1c8d8a43 [lldb] [Host] Refactor Socket::DecodeHostAndPort() to use LLVM API
Refactor Socket::DecodeHostAndPort() to use LLVM API over redundant
LLDB API.  In particular, this means llvm::Regex, llvm::Error return
type and llvm::to_integer().

While at it, change the port type from int32_t to uint16_t.  The method
never returns any value outside this range, and using the correct type
allows us to rely on getAsInteger()'s implicit overflow check.

Differential Revision: https://reviews.llvm.org/D110391
2021-09-24 14:58:02 +02:00
Michał Górny c1af84ceaf Revert "[lldb] [Host] Refactor Socket::DecodeHostAndPort() to use LLVM API"
This reverts commit a6daf99228.  It causes
buildbot regressions, I'll investigate.
2021-09-24 13:33:51 +02:00
Michał Górny a6daf99228 [lldb] [Host] Refactor Socket::DecodeHostAndPort() to use LLVM API
Refactor Socket::DecodeHostAndPort() to use LLVM API over redundant
LLDB API.  In particular, this means llvm::Regex, llvm::Error return
type and llvm::to_integer().

While at it, change the port type from int32_t to uint16_t.  The method
never returns any value outside this range, and using the correct type
allows us to rely on getAsInteger()'s implicit overflow check.

Differential Revision: https://reviews.llvm.org/D110391
2021-09-24 13:24:58 +02:00
Ted Woodward 17589538aa [lldb-vscode] Fix focus thread when previous thread exits
The thread that Visual Studio Code displays on a stop is called the focus thread. When the previous focus thread exits and we stop in a new thread, lldb-vscode does not tell vscode to set the new thread as the focus thread, so it selects the first thread in the thread list.

This patch changes lldb-vscode to tell vscode that the new thread is the focus thread. It also includes a test that verifies the DAP stop message for this case contains the correct values.

Reviewed By: clayborg, wallace

Differential Revision: https://reviews.llvm.org/D109633
2021-09-15 18:09:32 -05:00
Jason Molenda 766afbc804 Don't re-define constants that are now in compact_unwind_encoding.h. 2021-09-09 17:01:43 -07:00
Raphael Isemann bbcb4d6bc0 Revert "[lldb server] Tidy up LLDB server return codes and associated tests"
This reverts commit e387c8c413. The
TestErrorMessages.test is failing on the Linux bots.
2021-09-02 15:27:39 +02:00
Sebastian Schwartz e387c8c413 [lldb server] Tidy up LLDB server return codes and associated tests
This diff modifies the LLDB server return codes to more accurately reflect usage
error paths. Specifically we always propagate the return codes from the main
entrypoints into GDB remote LLDB server, and platform LLDB server. This way, the
top-level caller of LLDB server will be able to correctly check whether the
executable exited with or without an error.

We additionally modify and extend the associated shell unit tests to expect
nonzero return codes on error conditions.

Test Plan:
LLDB tests pass:

```
ninja check-lldb
```

Reviewed By: teemperor

Differential Revision: https://reviews.llvm.org/D108351
2021-09-02 11:16:37 +02:00
Jason Molenda 2b30fc2ff3 Fix two bugs with stack corefiles patch, restrict test built debugserver
These two tests, TestSkinnyCorefile.py and TestStackCorefile.py,
require a new debugserver on darwin systems to run correctly; for now,
skip them if the system debugserver is in use.  There's no easy way to
test if the debugserver being used supports either of these memory
region info features. For end users, the fallback will be a full
corefile and that's not the worst thing, but for the tests it is a
problem.
2021-08-11 17:19:31 -07:00
Jason Molenda 8c31efeed6 Add the ability to process save-core stack-memory-only corefiles
Add a field to the qMemoryRegionInfo packet where the remote stub
can describe the type of memory -- heap, stack.  Keep track of
memory regions that are stack memory in lldb.  Add a new "--style
stack" to process save-core to request that only stack memory be
included in the corefile.

Differential Revision: https://reviews.llvm.org/D107625
2021-08-11 13:37:31 -07:00
Nico Weber e71fdc1acf [lldb] Stop referencing "host_lib" in cmake files
It hasn't had an effect since https://reviews.llvm.org/rG7b968969db.

No behavior change.

Differential Revision: https://reviews.llvm.org/D107446
2021-08-05 22:18:37 +02:00
Nico Weber 11565320fd [lldb] Remove a few unused .exports files
They used to be referenced from the .xcodeproj files, but those are long gone.

No behavior change.

Differential Revision: https://reviews.llvm.org/D107444
2021-08-05 22:17:00 +02:00
Jeffrey Tan b9139acb85 Fix expression evaluation result expansion in lldb-vscode
VScode now sends a "scopes" DAP request immediately after any expression evaluation.
This scopes request would clear and invalidate any non-scoped expandable variables in g_vsc.variables, causing later "variables" request to return empty result.
The symptom is that any expandable variables in VScode watch window/debug console UI to return empty content.

This diff fixes this issue by only clearing the expandable variables at process continue time. To achieve this, we have to repopulate all scoped variables
during context switch for each "scopes" request without clearing global expandable variables.
So the PR puts the scoped variables into its own locals/globals/registers; and all expandable variables into separate "expandableVariables" list.
Also, instead of using the variable index for "variableReference", it generates a new variableReference id each time as the key of "expandableVariables".

As a further new feature, this PR adds a new "expandablePermanentVariables" which has the lifetime of debug session. Any expandable variables from debug console
are added into this list. This enables users to snapshot expanable old variable in debug console and compare with new variables if desire.

Reviewed By: clayborg

Differential Revision: https://reviews.llvm.org/D105166
2021-08-03 15:24:44 -07:00
Nico Weber bf3383501f [lldb] Get rid of HAVE_SYS_TYPES_H
LLVM includes this header unconditionally on all platforms
(including Windows), so this define should no longer be necessary.

No behavior change.

Differential Revision: https://reviews.llvm.org/D107338
2021-08-03 22:14:56 +02:00
Jason Molenda b2e25572d2 Remove the DarwinLog functionality from debguserver
Remove the DarwinLog and qStructuredDataPlugins support
from debugserver.  The DarwinLog plugin was never debugged
fully and made reliable, and the underlying private APIs
it uses have migrated since 2016 so none of them exist
any longer.

Differential Revision: https://reviews.llvm.org/D106324
rdar://75073283
2021-07-20 00:36:56 -07:00
Jonas Devlieghere b5a84e214d [debugserver] Un-conditionalize code guarded by macOS 10.10 checks
We've been requiring macOS 10.11 since 2018 so there's no point in
keeping code for 10.10 around.
2021-07-15 23:18:05 -07:00
Jan Kratochvil 72748488ad [lldb] Fix editline unicode on Linux
Based on:
  [lldb-dev] proposed change to remove conditional WCHAR support in libedit wrapper
  https://lists.llvm.org/pipermail/lldb-dev/2021-July/016961.html

There is already setlocale in lldb/source/Core/IOHandlerCursesGUI.cpp
but that does not apply for Editline GUI editing.

Unaware how to make automated test for this, it requires pty.

Reviewed By: teemperor

Differential Revision: https://reviews.llvm.org/D105779
2021-07-13 12:37:53 +02:00
Walter Erquinigo 8ea1a630d6 [vscode] fix ubsan problem in the progress event reporter
The error

UndefinedBehaviorSanitizer: undefined-behavior /Users/buildslave/jenkins/workspace/lldb-cmake-sanitized/llvm-project/lldb/tools/lldb-vscode/ProgressEvent.cpp:89:64 in

was found in https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake-sanitized/1910/consoleFull#-15641370498254eaf0-7326-4999-85b0-388101f2d404

It turns out that we were not setting m_event_type when initializatin
and update case. The fix is very simple.

Differential Revision: https://reviews.llvm.org/D105832
2021-07-12 13:22:25 -07:00
Muhammad Omair Javaid 0f32d0034c [LLDB] Silence warnings in cli-wrapper-mpxtable.cpp
cli-wrapper-mpxtable.cpp was emitting warnings from printfs of
uint64_t on 32 bit arm build. This patch makes affected printfs
in cli-wrapper-mpxtable.cpp portable accross targets variants.
2021-06-28 02:36:14 +00:00
Chris Bond 4d8156ef87 [lldb-vscode] Make extension contribute breakpoints use new package.json schema
See https://code.visualstudio.com/updates/v1_42#_implement-a-debug-adapter-inside-an-extension

Reviewed By: clayborg

Differential Revision: https://reviews.llvm.org/D104882
2021-06-25 18:21:26 +02:00
serge-sans-paille f7b1fa6f5e [NFC] remove unreferenced function ResolveIPV4HostName
Differential Revision: https://reviews.llvm.org/D104856
2021-06-25 13:45:11 +02:00
Fangrui Song f1e2d5851b [OptTable] Rename PrintHelp to printHelp
To be consistent with other member functions and match the coding standard.
2021-06-24 14:47:03 -07:00
Walter Erquinigo bff2b9adbc Retry of [lldb-vscode] only report long running progress events
This time adding a check that should prevent the crash found in
https://lab.llvm.org/buildbot/#/builders/68/builds/14182/steps/6/logs/stdio

Differential Revision: https://reviews.llvm.org/D101128
2021-06-21 20:33:09 -07:00
Walter Erquinigo f84615a5a5 Revert "[lldb-vscode] only report long running progress events"
This reverts commit 610d474cfd.

lldb-vscode is crashing.
2021-06-21 19:42:34 -07:00
Walter Erquinigo 610d474cfd [lldb-vscode] only report long running progress events
When the number of shared libs is massive, there could be hundreds of
thousands of short lived progress events sent to the IDE, which makes it
irresponsive while it's processing all this data. As these small jobs
take less than a second to process, the user doesn't even see them,
because the IDE only display the progress of long operations. So it's
better not to send these events.

I'm fixing that by sending only the events that are taking longer than 5
seconds to process.
In a specific run, I got the number of events from ~500k to 100, because
there was only 1 big lib to parse.

I've tried this on several small and massive targets, and it seems to
work fine.

Differential Revision: https://reviews.llvm.org/D101128
2021-06-21 19:35:05 -07:00
Greg Clayton 4181bfe688 Clarify the "env" launch configuration setting.
A few users recently were trying to set environment values when using lldb-vscode and were unsure of the format of the "env" launch configuration setting. Clarify the exact format as when users add the "env" launch config setting, they can see this help string in the IDE.

Differential Revision: https://reviews.llvm.org/D104578
2021-06-21 16:11:16 -07:00
Walter Erquinigo 28d9fd00d4 Revert "[lldb-vscode] attempt to fix flakiness"
Revert "[lldb-vscode] only report long running progress events"

This reverts commit f2c009dbcf.
This reverts commit aa4685c0fb.
2021-06-21 10:53:49 -07:00
Jason Molenda 9ea6dd5cfa Add a corefile style option to process save-core; skinny corefiles
Add a new feature to process save-core on Darwin systems -- for
lldb to create a user process corefile with only the dirty (modified
memory) pages included.  All of the binaries that were used in the
corefile are assumed to still exist on the system for the duration
of the use of the corefile.  A new --style option to process save-core
is added, so a full corefile can be requested if portability across
systems, or across time, is needed for this corefile.

debugserver can now identify the dirty pages in a memory region
when queried with qMemoryRegionInfo, and the size of vm pages is
given in qHostInfo.

Create a new "all image infos" LC_NOTE for Mach-O which allows us
to describe all of the binaries that were loaded in the process --
load address, UUID, file path, segment load addresses, and optionally
whether code from the binary was executing on any thread.  The old
"read dyld_all_image_infos and then the in-memory Mach-O load
commands to get segment load addresses" no longer works when we
only have dirty memory.

rdar://69670807
Differential Revision: https://reviews.llvm.org/D88387
2021-06-20 12:26:54 -07:00
Walter Erquinigo f2c009dbcf [lldb-vscode] attempt to fix flakiness
There are many tests failing intermittently for lldb-vscode after
https://reviews.llvm.org/rGaa4685c0fb3aab5acb90be5fd3eb5ba8bf1e3211. I'm
unsure if this actually the culprit, so I'm softly removing that feature
to see if that fixes the issue.
2021-06-18 10:12:46 -07:00
Walter Erquinigo aa4685c0fb [lldb-vscode] only report long running progress events
When the number of shared libs is massive, there could be hundreds of
thousands of short lived progress events sent to the IDE, which makes it
irresponsive while it's processing all this data. As these small jobs
take less than a second to process, the user doesn't even see them,
because the IDE only display the progress of long operations. So it's
better not to send these events.

I'm fixing that by sending only the events that are taking longer than 5
seconds to process.
In a specific run, I got the number of events from ~500k to 100, because
there was only 1 big lib to parse.

I've tried this on several small and massive targets, and it seems to
work fine.

Differential Revision: https://reviews.llvm.org/D101128
2021-06-17 12:01:27 -07:00
Ayush Sahay 5ef5177145 [lldb-vscode] Synchronize calls to SendTerminatedEvent
If an inferior exits prior to the processing of a disconnect request,
then the threads executing EventThreadFunction and request_discontinue
respectively may call SendTerminatedEvent simultaneously, in turn,
testing and/or setting g_vsc.sent_terminated_event without any
synchronization. In case the thread executing EventThreadFunction sets
it before the thread executing request_discontinue has had a chance to
test it, the latter would move ahead to issue a response to the
disconnect request. Said response may be dispatched ahead of the
terminated event compelling the client to terminate the debug session
without consuming any console output that might've been generated by
the execution of terminateCommands.

Reviewed By: clayborg, wallace

Differential Revision: https://reviews.llvm.org/D103609
2021-06-11 21:37:19 +05:30
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