Commit Graph

2062 Commits

Author SHA1 Message Date
Chelsea Cassanova 5451c4b4fb
[lldb/fuzzer] Moving target fuzzer into separate subdirectory
Moving lldb-target-fuzzer into its own subdirectory for better
organization and modularity.

Differential revision: https://reviews.llvm.org/D126507
2022-05-26 17:05:14 -07:00
Jeffrey Tan a1d490319a Fix lldb-vscode frame test failure
Previous patch (https://reviews.llvm.org/D126013) added a new "optimized"
attribute to DAP stack frame this caused some tests, like
lldb-vscode/coreFile/TestVSCode_coreFile.py
to fail because the tests explicitly check for all attributes.

To fix the test failure I decided to remove this attribute.

Differential Revision: https://reviews.llvm.org/D126225
2022-05-23 14:04:37 -07:00
Jeffrey Tan 0fe220a331 Show error message for optimized variables
This fixes an issue that optimized variable error message is not shown to end
users in lldb-vscode.

Differential Revision: https://reviews.llvm.org/D126014
2022-05-23 10:04:58 -07:00
Jeffrey Tan 46c1f77e16 Add [opt] suffix to optimized stack frame in lldb-vscode
To help user identify optimized code This diff adds a "[opt]" suffix to
optimized stack frames in lldb-vscode. This provides consistent experience
as command line lldb.

It also adds a new "optimized" attribute to DAP stack frame object so that
it is easy to identify from telemetry than parsing trailing "[opt]".

Differential Revision: https://reviews.llvm.org/D126013
2022-05-23 10:03:13 -07:00
Jonas Devlieghere a1cf154dd4
[lldb] Set correct register number for cpsr (GENERIC_REGNUM_FLAGS)
Report the correct register number (GENERIC_REGNUM_FLAGS) for cpsr. This
fixes TestLldbGdbServer.py on Apple Silicon.

Differential revision: https://reviews.llvm.org/D126076
2022-05-20 09:36:58 -07:00
Jim Ingham bff4673b41 Add a darwin platform setting to specify which exceptions debugserver
should not receive as exceptions (some will get converted to BSD
signals instead).  This is really the only stable way to ensure that
a Mach exception gets converted to it's equivalent BSD signal.  For
programs that rely on BSD signal handlers, this has to happen or you
can't even get the program to invoke the signal handler when under
the debugger.

This builds on a previous solution to this problem which required you
start debugserver with the -U flag.  This was not very discoverable
and required lldb be the one to launch debugserver, which is not always
the case.

Differential Revision: https://reviews.llvm.org/D125434
2022-05-18 10:16:11 -07:00
Walter Erquinigo be738c9d1c [lldb-vscode] Fix data race in lldb-vscode when running with ThreadSanitizer
This patch fixes https://github.com/llvm/llvm-project/issues/54768. A ProgressEventReporter creates a dedicated thread that keeps checking whether there are new events that need to be sent to IDE as long as m_thread_should_exit is true. When the VSCode instance is destructed, it will set m_thread_should_exit to false, which caused a data race because at the same time its ProgressEventReporter is reading this value to determine whether it should quit. This fix simply uses mutex to ensure they cannot read and write this value at the same time.

Committed on behalf of PRESIDENT810

Reviewed By: clayborg, wallace

Differential Revision: https://reviews.llvm.org/D125073
2022-05-17 09:11:45 -07:00
Greg Clayton 91d5bfdb79 Add "indexedVariables" to variables with lots of children.
Prior to this fix if we have a really large array or collection class, we would end up always creating all of the child variables for an array or collection class. If the number of children was very high this can cause delays when expanding variables. By adding the "indexedVariables" to variables with lots of children, we can keep good performance in the variables view at all times. This patch will add the "indexedVariables" key/value pair to any "Variable" JSON dictionairies when we have an array of synthetic child provider that will create more than 100 children.

We have to be careful to not call "uint32_t SBValue::GetNumChildren()" on any lldb::SBValue that we use because it can cause a class, struct or union to complete the type in order to be able to properly tell us how many children it has and this can be expensive if you have a lot of variables. By default LLDB won't need to complete a type if we have variables that are classes, structs or unions unless the user expands the variable in the variable view. So we try to only get the GetNumChildren() when we have an array, as this is a cheap operation, or a synthetic child provider, most of which are for showing collections that typically fall into this category. We add a variable reference, which indicates that something can be expanded, when the function "bool SBValue::MightHaveChildren()" is true as this call doesn't need to complete the type in order to return true. This way if no one ever expands class variables, we don't need to complete the type.

Differential Revision: https://reviews.llvm.org/D125347
2022-05-11 16:17:57 -07:00
Alexandre Perez eb3136f022 Fix debugserver translation check
Currently, debugserver has a test to check if it was launched in
translation. The intent was to cover the case where an x86_64
debugserver attempts to control an arm64/arm64e process, returning
an error. However, this check also covers the case where users
are attaching to an x86_64 process, exiting out before attempting
to hand off control to the translated debugserver at
`/Library/Apple/usr/libexec/oah/debugserver`.

This diff delays the debugserver translation check until after
determining whether to hand off control to
`/Library/Apple/usr/libexec/oah/debugserver`. Only when the
process is not translated and thus has not been handed off do we
check if the debugserver is translated, erroring out in that case.

Reviewed By: jasonmolenda

Differential Revision: https://reviews.llvm.org/D124814
2022-05-05 11:31:23 -07:00
Jonas Devlieghere 763ff89c0e
[debugserver ] Un-conditionalize use of libcompression
Jason removed the include guards in 681f6c2f55. This patch removes the
corresponding CMake logic as well.

Differential revision: https://reviews.llvm.org/D123616
2022-04-13 14:36:25 -07:00
Jason Molenda 4d3cc27831 Correct debugserver to write xmm/ymm/zmm reg values
debugserver does not call thread_set_state when changing xmm/ymm/zmm
register values, so the register contents are never updated.  Fix
that.  Mark the shell tests which xfail'ed these tests on darwin systems
to xfail them when the system debugserver, they will pass when using
the in-tree debugserver.  When this makes it into the installed
system debugservers, we'll remove the xfails.

Differential Revision: https://reviews.llvm.org/D123269
rdar://91258333
rdar://31294382
2022-04-06 23:36:52 -07:00
Walter Erquinigo 9bcaf6ddfe [lldb-vscode] Implement stderr/stdout on win32 and redirect lldb log to VSCode
This patch implements stderr/stdout forwarding on windows.
This was previously not implemented in D99974.
I added separate callbacks so the output can be sent to the different channels VSCode provides (OutputType::Stdout, OutputType::Stderr, OutputType::Console).

This patch also passes a log callback handler to SBDebugger::Create to be able to see logging output when it is enabled.

Since the output is now redirect on early startup I removed the calls to SetOutputFileHandle/SetErrorFileHandle, which set them to /dev/null.

I send the output of stderr/stdout/lldb log to OutputType::Console

Reviewed By: wallace

Differential Revision: https://reviews.llvm.org/D123025
2022-04-05 11:54:03 -07:00
Jason Molenda 7ebcd8891a Add DumpBinaryEscaped method to JSONGenerator, avoid extra copy
All uses of JSONGenerator in debugserver would create a JSON text
dump of the object collection, then copy that string into a
binary-escaped string, then send it up to the lldb side or
make a compressed version and send that.

This adds a DumpBinaryEscaped method to JSONGenerator which
does the gdb remote serial protocol binary escaping directly,
and removes the need to pass over the string and have an
additional copy in memory.

Differential Revision: https://reviews.llvm.org/D122882
rdar://91117456
2022-04-04 14:14:02 -07:00
Jason Molenda c04fdfa17e Update callers to SendPacket with std::string's to not devolve to c-strs
Many callers of SendPacket() in RNBRemote.cpp have a local std::string
object, call c_str() on it to pass a c-string, which is then copied into
a std::string temporary object.

Also free JSONGenerator objects once we've formatted them into
ostringstream and don't need the objects any longer, to reduce max
memory use in debugserver.

Differential Revision: https://reviews.llvm.org/D122848
rdar://91117263
2022-03-31 23:46:44 -07:00
Shafik Yaghmour 24f9a2f53d [LLDB] Applying clang-tidy modernize-use-equals-default over LLDB
Applied modernize-use-equals-default clang-tidy check over LLDB.

This check is already present in the lldb/.clang-tidy config.

Differential Revision: https://reviews.llvm.org/D121844
2022-03-31 13:21:49 -07:00
Martin Storsjö a37cb5ece5 [lldb-vscode] Avoid a -Wunused-but-set-variable warning. NFC.
Differential Revision: https://reviews.llvm.org/D122710
2022-03-31 00:10:05 +03:00
Martin Storsjö bc13101cf9 [lldb] Fix building for mingw after changes to sigtstp_handler
Some signal handlers were set up within an !_MSC_VER condition,
i.e. omitted in MSVC builds but included in mingw builds. Previously
sigtstp_handler was defined in all builds, but since
4bcadd6686 / D120320 it's only
defined non platforms other than Windows.

Change the condition to !_WIN32 for consistency between the MSVC
and mingw builds, fixing the build for mingw.

Differential Revision: https://reviews.llvm.org/D122486
2022-03-26 22:32:53 +02:00
Jonas Devlieghere 8f7db763ef
[lldb] Conditionalize target_link_libraries on the target
Fixes "Cannot specify link libraries for target "lldb-target-fuzzer"
which is not built by this project." Normally that's taken care of by
add_llvm_fuzzer but we need target_link_libraries for liblldb and our
utility library.
2022-03-25 09:50:34 -07:00
Jonas Devlieghere 61efe14e21
[lldb] Add a fuzzer for target creation
This patch adds a generic fuzzer that interprets inputs as object files
and uses them to create a target in lldb. It is very similar to the
llvm-dwarfdump fuzzer which found a bunch of issues in libObject.

Differential revision: https://reviews.llvm.org/D122461
2022-03-25 09:34:00 -07:00
Pavel Labath 4bcadd6686 [lldb/driver] Fix SIGTSTP handling
Our SIGTSTP handler was working, but that was mostly accidental.

The reason it worked is because lldb is multithreaded for most of its
lifetime and the OS is reasonably fast at responding to signals. So,
what happened was that the kill(SIGTSTP) which we sent from inside the
handler was delivered to another thread while the handler was still set
to SIG_DFL (which then correctly put the entire process to sleep).

Sometimes it happened that the other thread got the second signal after
the first thread had already restored the handler, in which case the
signal handler would run again, and it would again attempt to send the
SIGTSTP signal back to itself.

Normally it didn't take many iterations for the signal to be delivered
quickly enough. However, if you were unlucky (or were playing around
with pexpect) you could get SIGTSTP while lldb was single-threaded, and
in that case, lldb would go into an endless loop because the second
SIGTSTP could only be handled on the main thread, and only after the
handler for the first signal returned (and re-installed itself). In that
situation the handler would keep re-sending the signal to itself.

This patch fixes the issue by implementing the handler the way it
supposed to be done:
- before sending the second SIGTSTP, we unblock the signal (it gets
  automatically blocked upon entering the handler)
- we use raise to send the signal, which makes sure it gets delivered to
  the thread which is running the handler

This also means we don't need the SIGCONT handler, as our TSTP handler
resumes right after the entire process is continued, and we can do the
required work there.

I also include a test case for the SIGTSTP flow. It uses pexpect, but it
includes a couple of extra twists. Specifically, I needed to create an
extra process on top of lldb, which will run lldb in a separate process
group and simulate the role of the shell. This is needed because SIGTSTP
is not effective on a session leader (the signal gets delivered, but it
does not cause a stop) -- normally there isn't anyone to notice the
stop.

Differential Revision: https://reviews.llvm.org/D120320
2022-03-09 14:31:17 +01:00
Greg Clayton 63e512100a Fix race condition when launching and attaching.
This is a modified version of a previous patch that was reverted: https://reviews.llvm.org/D119797
This version only waits for the process to stop when using "launchCommands" or "attachCommands"...

...and doesn't play with the async mode when doing normal launch/attach.

We discovered that when using "launchCommands" or "attachCommands" that there was an issue where these commands were not being run synchronously. There were further problems in this case where we would get thread events for the process that was just launched or attached before the IDE was ready, which is after "configurationDone" was sent to lldb-vscode.

This fix introduces the ability to wait for the process to stop after "launchCommands" or "attachCommands" are run to ensure that we have a stopped process point that is ready for the debug session to proceed. We spin up the thread that listens for process events before we start the launch or attach, but we don't want stop events being delivered through the DAP protocol until the "configurationDone" packet is received. We now always ignore the stop event with a stop ID of 1, which is the first stop. All normal launch and attach scenarios use the synchronous mode, and "launchCommands and "attachCommands" run an array of LLDB commands in async mode.

This should make our launch with "launchCommands" and attach with "attachCommands" avoid a race condition when the process is being launched or attached.

Differential Revision: https://reviews.llvm.org/D120755
2022-03-03 16:20:27 -08:00
Jonas Devlieghere 4212a57a54
[lldb] Remove reproducer_handler from the driver 2022-03-03 13:22:39 -08:00
Stephane Moore 0ff2905709 [lldb] Hyphenate Objective-C exception breakpoint labels ✍️
Objective-C is officially hyphenated:
https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/ObjectiveC/Introduction/introObjectiveC.html#//apple_ref/doc/uid/TP30001163

Reviewed By: mwyman, clayborg

Differential Revision: https://reviews.llvm.org/D113616
2022-03-01 15:02:44 -08:00
Jonas Devlieghere 4429cf146e
[Support] Allow the ability to change WithColor's auto detection function
WithColor has an "auto detection mode" which looks whether the
corresponding whether the corresponding cl::opt is enabled or not. While
this is great when opting into cl::opt, it's not so great for downstream
users of this utility, which might have their own competing options to
enable or disable colors. The WithColor constructor takes a color mode,
but the big benefit of the class are its static error and warning
helpers and default error handlers.

In order to allow users of this utility to enable or disable colors
globally, this patch adds the ability to specify a global auto detection
function. By default, the auto detection function behaves the way that
it does today. The benefit of this patch lies in that it can be
overwritten. In addition to a ability to change the auto detection
function, I've also made it possible to get your hands on the default
auto detection function, so you swap it back if if you so desire.

This patch allow downstream users (like LLDB) to globally disable colors
with its own command line flag.

Differential revision: https://reviews.llvm.org/D120593
2022-02-28 20:30:06 -08:00
Jonas Devlieghere 3a167c4a90
Revert "[Support] Allow the ability to change WithColor's auto detection function"
This reverts commit a83cf7a846 because it
breaks a bunch of build bots.
2022-02-28 15:32:15 -08:00
Jonas Devlieghere a83cf7a846
[Support] Allow the ability to change WithColor's auto detection function
WithColor has an "auto detection mode" which looks whether the
corresponding whether the corresponding cl::opt is enabled or not. While
this is great when opting into cl::opt, it's not so great for downstream
users of this utility, which might have their own competing options to
enable or disable colors. The WithColor constructor takes a color mode,
but the big benefit of the class are its static error and warning
helpers and default error handlers.

In order to allow users of this utility to enable or disable colors
globally, this patch adds the ability to specify a global auto detection
function. By default, the auto detection function behaves the way that
it does today. The benefit of this patch lies in that it can be
overwritten. In addition to a ability to change the auto detection
function, I've also made it possible to get your hands on the default
auto detection function, so you swap it back if if you so desire.

This patch allow downstream users (like LLDB) to globally disable colors
with its own command line flag.

Differential revision: https://reviews.llvm.org/D120593
2022-02-28 15:03:04 -08:00
Pavel Labath 6c99a3469d [lldb] Add support for a "global" lldbinit file
This patch adds introduces a new kind of an lldbinit file. Unlike the
lldbinit in the home directory (useful for customizing lldb to the needs
of a particular user), or the cwd lldbinit file (useful for
project-specific settings), this file can be used to customize an entire
lldb installation to a particular environment.

The feature is enabled at build time, by setting the
LLDB_GLOBAL_INIT_DIRECTORY variable to a path to a directory which
should contain an "lldbinit" file. Lldb will then load the file at
startup, if it exists, and if automatic init loading has not been
disabled. Relative paths will be resolved (at runtime) relative to the
location of the lldb library (liblldb or LLDB.framework).

The system-wide lldbinit file will be loaded first, before any
$HOME/.lldbinit and $CWD/.lldbinit files are processed, so that those
can override any system-wide settings.

More information can be found on the RFC thread at
<https://discourse.llvm.org/t/rfc-system-wide-lldbinit/59933>.

Differential Revision: https://reviews.llvm.org/D119831
2022-02-18 12:30:22 +01:00
Pavel Labath a59014b759 Revert "Fix race condition when launching and attaching."
It breaks TestVSCode_attach.py.

This reverts commit 9febd1e573 and
38054556a0.
2022-02-18 12:11:37 +01:00
Greg Clayton 9febd1e573 Fix race condition when launching and attaching.
We discovered that when using "launchCommands" or "attachCommands" that there was an issue where these commands were not being run synchronously. There were further problems in this case where we would get thread events for the process that was just launched or attached before the IDE was ready, which is after "configurationDone" was sent to lldb-vscode.

This fix introduces the ability to wait for the process to stop after the run or attach to ensure that we have a stopped process at the entry point that is ready for the debug session to proceed. This also allows us to run the normal launch or attach without needing to play with the async flag the debugger. We spin up the thread that listens for process events before we start the launch or attach, but we stop the first eStateStopped (with stop ID of zero) event from being delivered through the DAP protocol because the "configurationDone" request handler will deliver it manually as the IDE expects a stop after configuration done. The request_configurationDone will also only deliver the stop packet if the "stopOnEntry" is False in the launch configuration.

Also added a new "timeout" to the launch and attach launch configuration arguments that can be set and defaults to 30 seconds. Since we now poll to detect when the process is stopped, we need a timeout that can be changed in case certain workflows take longer that 30 seconds to attach. If the process is not stopped by the timeout, an error will be retured for the launch or attach.

Added a flag to the vscode.py protocol classes that detects and ensures that no "stopped" events are sent prior to "configurationDone" has been sent and will raise an error if it does happen.

This should make our launching and attaching more reliable and avoid some deadlocks that were being seen (https://reviews.llvm.org/D119548).

Differential Revision: https://reviews.llvm.org/D119797
2022-02-17 13:18:49 -08:00
Adrian Prantl ca7f06fcb6 add missing include 2022-02-17 09:02:29 -08:00
Pavel Labath c34698a811 [lldb] Rename Logging.h to LLDBLog.h and clean up includes
Most of our code was including Log.h even though that is not where the
"lldb" log channel is defined (Log.h defines the generic logging
infrastructure). This worked because Log.h included Logging.h, even
though it should.

After the recent refactor, it became impossible the two files include
each other in this direction (the opposite inclusion is needed), so this
patch removes the workaround that was put in place and cleans up all
files to include the right thing. It also renames the file to LLDBLog to
better reflect its purpose.
2022-02-03 14:47:01 +01:00
Pavel Labath a007a6d844 [lldb] Convert "LLDB" log channel to the new API 2022-02-02 14:13:08 +01:00
Pavel Labath 0f08db66db [lldb] Make logging machinery type-safe
This patch makes use of c++ type checking and scoped enums to make
logging statements shorter and harder to misuse.

Defines like LIBLLDB_LOG_PROCESS are replaces with LLDBLog::Process.
Because it now carries type information we do not need to worry about
matching a specific enum value with the right getter function -- the
compiler will now do that for us.

The main entry point for the logging machinery becomes the GetLog
(template) function, which will obtain the correct Log object based on
the enum type. It achieves this through another template function
(LogChannelFor<T>), which must be specialized for each type, and should
return the appropriate channel object.

This patch also removes the ability to log a message if multiple
categories are enabled simultaneously as it was unused and confusing.

This patch does not actually remove any of the existing interfaces. The
defines and log retrieval functions are left around as wrappers around
the new interfaces. They will be removed in follow-up patch.

Differential Revision: https://reviews.llvm.org/D117490
2022-01-25 12:13:49 +01:00
serge-sans-paille e9211e0393 Remove dependency from raw_ostream on <chrono>
The tryLockFor method from raw_fd_sotreamis the sole user of that
header, and it's not referenced in the mono repo. I still chose to keep
it (may be useful for downstream user) but added a transient type that's
forward declared to hold the duration parameter.

Notable changes:

- "llvm/Support/Duration.h" must be included in order to use tryLockFor.
- "llvm/Support/raw_ostream.h" no longer includes <chrono>

This sole change has an interesting impact on the number of processed
line, as measured by:

clang++ -E  -Iinclude -I../llvm/include ../llvm/lib/Support/*.cpp -std=c++14 -fno-rtti -fno-exceptions | wc -l

before: 7917500
after:  7835142

Discourse thread on the topic: https://llvm.discourse.group/t/include-what-you-use-include-cleanup/5831
2022-01-21 15:17:39 +01:00
Jonas Devlieghere f811cb82a6 [lldb] Revive lldb-instr
I revived lldb-instr to update the macros for D117712. I think the new
macros are simple enough that we add them by hand, but this tool can do
it automatically for you.

Differential revision: https://reviews.llvm.org/D117748
2022-01-20 18:06:14 -08:00
John Ericson df31ff1b29 [cmake] Make include(GNUInstallDirs) always below project(..)
Its defaulting logic must go after `project(..)` to work correctly,  but `project(..)` is often in a standalone condition making this
awkward, since the rest of the condition code may also need GNUInstallDirs.

The good thing is there are the various standalone booleans, which I had missed before. This makes splitting the conditional blocks less awkward.

Reviewed By: arichardson, phosek, beanz, ldionne, #libunwind, #libc, #libc_abi

Differential Revision: https://reviews.llvm.org/D117639
2022-01-20 18:59:17 +00:00
Pavel Labath b2a162e63b [lldb] Remove the requirement for windows clients to specify -DIMPORT_LIBLLDB
This macro was being used to select the proper import/export annotations
on SB classes. Non-windows clients do not have such requirements.

Instead introduce a new macro (LLDB_IN_LIBLLDB), which signals that
we're compiling liblldb itself (and should use dllexport). The default
(no macro) is to use dllimport. I've moved the macro definition to
SBDefines.h, since it only makes sense when building the API library.

Differential Revision: https://reviews.llvm.org/D117564
2022-01-19 12:49:47 +01:00
Jonas Devlieghere 4609e30f50 [lldb] Remove lldb-instr 2022-01-10 11:48:16 -08:00
Martin Storsjö 1919720fdd [lldb] [debugserver] Simplify handling of arch specific files
There are no duplicates among the include files, and all the
source files are wrapped in architecture ifdefs, so there's no harm
in including all of them, always.

This fixes builds if TARGET_TRIPLE is set to something else than the
build architecture.

This also allows building for multiple architectures at once by
setting CMAKE_OSX_ARCHITECTURES.

Differential Revision: https://reviews.llvm.org/D116625
2022-01-06 10:23:04 +02:00
Jonas Devlieghere 46a28a954e [lldb] Create a property to store the REPL language
Until the introduction of the C++ REPL, there was always a single REPL
language. Several places relied on this assumption through
repl_languages.GetSingularLanguage. Now that this is no longer the case,
we need a way to specify a selected/preferred REPL language. This patch
does that with the help of a debugger property, taking inspiration from
how we store the scripting language.

Differential revision: https://reviews.llvm.org/D116697
2022-01-05 15:03:46 -08:00
Jonas Devlieghere fa1260697e [lldb] Remove reproducer replay functionality
This is part of a bigger rework of the reproducer feature. See [1] for
more details.

[1] https://lists.llvm.org/pipermail/lldb-dev/2021-September/017045.html
2021-12-17 17:14:52 -08:00
Jonas Devlieghere 67bc243535 [lldb] Remove --reproducer-finalize and associated functionality
This is part of a bigger rework of the reproducer feature. See [1] for
more details.

[1] https://lists.llvm.org/pipermail/lldb-dev/2021-September/017045.html
2021-12-17 12:19:55 -08:00
Jonas Devlieghere ccf1469a4c [lldb] Make lldbVersion a full fledged library
Because of its dependency on clang (and potentially other compilers
downstream, such as swift) lldb_private::GetVersion already lives in its
own library called lldbBase. Despite that, its implementation was spread
across unrelated files. This patch improves things by introducing a
Version library with its own directory, header and implementation file.

The benefits of this patch include:

 - We can get rid of the ugly quoting macros.
 - Other parts of LLDB can read the version number from
   lldb/Version/Version.inc.
 - The implementation can be swapped out for tools like lldb-server than
   don't need to depend on clang at all.

Differential revision: https://reviews.llvm.org/D115211
2021-12-08 15:14:34 -08:00
Andy Yankovsky 0495301293 [lldb-vscode] Report supportsModulesRequest=true
The adapter does support `Modules` request, implemented in 39239f9.

Reviewed By: wallace

Differential Revision: https://reviews.llvm.org/D115033
2021-12-03 16:07:48 +01:00
Pavel Labath 165545c7a4 [lldb/gdb-remote] Ignore spurious ACK packets
Although I cannot find any mention of this in the specification, both
gdb and lldb agree on sending an initial + packet after establishing the
connection.

OTOH, gdbserver and lldb-server behavior is subtly different. While
lldb-server *expects* the initial ack, and drops the connection if it is
not received, gdbserver will just ignore a spurious ack at _any_ point
in the connection.

This patch changes lldb's behavior to match that of gdb. An ACK packet
is ignored at any point in the connection (except when expecting an ACK
packet, of course). This is inline with the "be strict in what you
generate, and lenient in what you accept" philosophy, and also enables
us to remove some special cases from the server code. I've extended the
same handling to NAK (-) packets, mainly because I don't see a reason to
treat them differently here.

(The background here is that we had a stub which was sending spurious
+ packets. This bug has since been fixed, but I think this change makes
sense nonetheless.)

Differential Revision: https://reviews.llvm.org/D114520
2021-11-25 12:34:08 +01:00
Levon Ter-Grigoryan f23b829a26 Fixed use of -o and -k in LLDB under Windows when statically compiled with vcruntime.
Right now if the LLDB is compiled under the windows with static vcruntime library, the -o and -k commands will not work.

The problem is that the LLDB create FILE* in lldb.exe and pass it to liblldb.dll which is an object from CRT.
Since the CRT is statically linked each of these module has its own copy of the CRT with it's own global state and the LLDB should not share CRT objects between them.

In this change I moved the logic of creating FILE* out of commands stream from Driver class to SBDebugger.
To do this I added new method: SBError SBDebugger::SetInputStream(SBStream &stream)

Command to build the LLDB:
cmake -G Ninja -DLLVM_ENABLE_PROJECTS="clang;lldb;libcxx"  -DLLVM_USE_CRT_RELEASE="MT" -DLLVM_USE_CRT_MINSIZEREL="MT" -DLLVM_USE_CRT_RELWITHDEBINFO="MT" -DP
YTHON_HOME:FILEPATH=C:/Python38 -DCMAKE_C_COMPILER:STRING=cl.exe -DCMAKE_CXX_COMPILER:STRING=cl.exe ../llvm

Command which will fail:
lldb.exe -o help

See discord discussion for more details: https://discord.com/channels/636084430946959380/636732809708306432/854629125398724628
This revision is for the further discussion.

Reviewed By: teemperor

Differential Revision: https://reviews.llvm.org/D104413
2021-11-24 16:17:08 +00:00
Jonas Devlieghere 18d883cc0a [debugserver] Remove varaible `ldb_set` which is set but not used.
Differential revision: https://reviews.llvm.org/D113598
2021-11-10 11:56:59 -08:00
Lawrence D'Anna bbef51eb43 [lldb] make it easier to find LLDB's python
It is surprisingly difficult to write a simple python script that
can reliably `import lldb` without failing, or crashing.   I'm
currently resorting to convolutions like this:

    def find_lldb(may_reexec=False):
		if prefix := os.environ.get('LLDB_PYTHON_PREFIX'):
			if os.path.realpath(prefix) != os.path.realpath(sys.prefix):
				raise Exception("cannot import lldb.\n"
					f"  sys.prefix should be: {prefix}\n"
					f"  but it is: {sys.prefix}")
		else:
			line1, line2 = subprocess.run(
				['lldb', '-x', '-b', '-o', 'script print(sys.prefix)'],
				encoding='utf8', stdout=subprocess.PIPE,
				check=True).stdout.strip().splitlines()
			assert line1.strip() == '(lldb) script print(sys.prefix)'
			prefix = line2.strip()
			os.environ['LLDB_PYTHON_PREFIX'] = prefix

		if sys.prefix != prefix:
			if not may_reexec:
				raise Exception(
					"cannot import lldb.\n" +
					f"  This python, at {sys.prefix}\n"
					f"  does not math LLDB's python at {prefix}")
			os.environ['LLDB_PYTHON_PREFIX'] = prefix
			python_exe = os.path.join(prefix, 'bin', 'python3')
			os.execl(python_exe, python_exe, *sys.argv)

		lldb_path = subprocess.run(['lldb', '-P'],
			check=True, stdout=subprocess.PIPE,
				encoding='utf8').stdout.strip()

		sys.path = [lldb_path] + sys.path

This patch aims to replace all that with:

  #!/usr/bin/env lldb-python
  import lldb
  ...

... by adding the following features:

* new command line option: --print-script-interpreter-info.  This
   prints language-specific information about the script interpreter
   in JSON format.

* new tool (unix only): lldb-python which finds python and exec's it.

Reviewed By: JDevlieghere

Differential Revision: https://reviews.llvm.org/D112973
2021-11-10 10:33:34 -08:00
Michał Górny 3f1372365a [lldb] Support gdbserver signals
GDB and LLDB use different signal models.  GDB uses a predefined set
of signal codes, and maps platform's signos to them.  On the other hand,
LLDB has historically simply passed native signos.

In order to improve compatibility between LLDB and gdbserver, the GDB
signal model should be used.  However, GDB does not provide a mapping
for all existing signals on Linux and unsupported signals are passed
as 'unknown'.  Limiting LLDB to this behavior could be considered
a regression.

To get the best of both worlds, use the LLDB signal model when talking
to lldb-server, and the GDB signal model otherwise.  For this purpose,
new versions of lldb-server indicate "native-signals+" via qSupported.
At the same time, we also detect older versions of lldb-server
via QThreadSuffixSupported for backwards compatibility.  If neither test
succeeds, we assume gdbserver or another implementation using GDB model.

Differential Revision: https://reviews.llvm.org/D108078
2021-11-10 09:38:55 +01:00
Andy Yankovsky dc8f0035ca [lldb-vscode] Add presentation hints for scopes
Scopes can have an optional hint for how to present this scope in the UI:
https://microsoft.github.io/debug-adapter-protocol/specification#Types_Scope

The IDEs can use the hint to present the data accordingly. For example,
Visual Studio has a separate Registers window, which is populated with the
data from the scope with `presentationHint: "registers"`.

Reviewed By: wallace

Differential Revision: https://reviews.llvm.org/D113400
2021-11-09 17:50:46 +01:00