2018-08-17 01:59:38 +08:00
|
|
|
if ( CMAKE_SYSTEM_NAME MATCHES "Windows" OR CMAKE_SYSTEM_NAME MATCHES "NetBSD" )
|
|
|
|
|
list(APPEND extra_libs lldbHost)
|
|
|
|
|
endif ()
|
|
|
|
|
|
|
|
|
|
if (HAVE_LIBPTHREAD)
|
|
|
|
|
list(APPEND extra_libs pthread)
|
|
|
|
|
endif ()
|
|
|
|
|
|
2019-11-16 01:46:27 +08:00
|
|
|
|
|
|
|
|
if(APPLE)
|
|
|
|
|
configure_file(
|
|
|
|
|
${CMAKE_CURRENT_SOURCE_DIR}/lldb-vscode-Info.plist.in
|
|
|
|
|
${CMAKE_CURRENT_BINARY_DIR}/lldb-vscode-Info.plist
|
|
|
|
|
)
|
|
|
|
|
# Inline info plist in binary (use target_link_options for this as soon as CMake 3.13 is available)
|
|
|
|
|
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -Wl,-sectcreate,__TEXT,__info_plist,${CMAKE_CURRENT_BINARY_DIR}/lldb-vscode-Info.plist")
|
|
|
|
|
endif()
|
|
|
|
|
|
2018-08-17 01:59:38 +08:00
|
|
|
# We need to include the llvm components we depend on manually, as liblldb does
|
|
|
|
|
# not re-export those.
|
|
|
|
|
set(LLVM_LINK_COMPONENTS Support)
|
2020-02-22 00:13:05 +08:00
|
|
|
set(LLVM_TARGET_DEFINITIONS Options.td)
|
|
|
|
|
tablegen(LLVM Options.inc -gen-opt-parser-defs)
|
|
|
|
|
add_public_tablegen_target(LLDBVSCodeOptionsTableGen)
|
2018-08-17 01:59:38 +08:00
|
|
|
add_lldb_tool(lldb-vscode
|
|
|
|
|
lldb-vscode.cpp
|
|
|
|
|
BreakpointBase.cpp
|
|
|
|
|
ExceptionBreakpoint.cpp
|
[vscode] Improve runInTerminal and support linux
Depends on D93874.
runInTerminal was using --wait-for, but it was some problems because it uses process polling looking for a single instance of the debuggee:
- it gets to know of the target late, which renders breakpoints in the main function almost impossible
- polling might fail if there are already other processes with the same name
- polling might also fail on some linux machine, as it's implemented with the ps command, and the ps command's args and output are not standard everywhere
As a better way to implement this so that it works well on Darwin and Linux, I'm using now the following process:
- lldb-vscode notices the runInTerminal, so it spawns lldb-vscode with a special flag --launch-target <target>. This flags tells lldb-vscode to wait to be attached and then it execs the target program. I'm using lldb-vscode itself to do this, because it makes finding the launcher program easier. Also no CMAKE INSTALL scripts are needed.
- Besides this, the debugger creates a temporary FIFO file where the launcher program will write its pid to. That way the debugger will be sure of which program to attach.
- Once attach happend, the debugger creates a second temporary file to notify the launcher program that it has been attached, so that it can then exec. I'm using this instead of using a signal or a similar mechanism because I don't want the launcher program to wait indefinitely to be attached in case the debugger crashed. That would pollute the process list with a lot of hanging processes. Instead, I'm setting a 20 seconds timeout (that's an overkill) and the launcher program seeks in intervals the second tepmorary file.
Some notes:
- I preferred not to use sockets because it requires a lot of code and I only need a pid. It would also require a lot of code when windows support is implemented.
- I didn't add Windows support, as I don't have a windows machine, but adding support for it should be easy, as the FIFO file can be implemented with a named pipe, which is standard on Windows and works pretty much the same way.
The existing test which didn't pass on Linux, now passes.
Differential Revision: https://reviews.llvm.org/D93951
2020-12-29 04:00:47 +08:00
|
|
|
FifoFiles.cpp
|
2018-08-17 01:59:38 +08:00
|
|
|
FunctionBreakpoint.cpp
|
2019-03-08 05:23:21 +08:00
|
|
|
IOStream.cpp
|
2018-08-17 01:59:38 +08:00
|
|
|
JSONUtils.cpp
|
|
|
|
|
LLDBUtils.cpp
|
[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-22 05:20:17 +08:00
|
|
|
OutputRedirector.cpp
|
2021-04-14 12:45:03 +08:00
|
|
|
ProgressEvent.cpp
|
[vscode] Improve runInTerminal and support linux
Depends on D93874.
runInTerminal was using --wait-for, but it was some problems because it uses process polling looking for a single instance of the debuggee:
- it gets to know of the target late, which renders breakpoints in the main function almost impossible
- polling might fail if there are already other processes with the same name
- polling might also fail on some linux machine, as it's implemented with the ps command, and the ps command's args and output are not standard everywhere
As a better way to implement this so that it works well on Darwin and Linux, I'm using now the following process:
- lldb-vscode notices the runInTerminal, so it spawns lldb-vscode with a special flag --launch-target <target>. This flags tells lldb-vscode to wait to be attached and then it execs the target program. I'm using lldb-vscode itself to do this, because it makes finding the launcher program easier. Also no CMAKE INSTALL scripts are needed.
- Besides this, the debugger creates a temporary FIFO file where the launcher program will write its pid to. That way the debugger will be sure of which program to attach.
- Once attach happend, the debugger creates a second temporary file to notify the launcher program that it has been attached, so that it can then exec. I'm using this instead of using a signal or a similar mechanism because I don't want the launcher program to wait indefinitely to be attached in case the debugger crashed. That would pollute the process list with a lot of hanging processes. Instead, I'm setting a 20 seconds timeout (that's an overkill) and the launcher program seeks in intervals the second tepmorary file.
Some notes:
- I preferred not to use sockets because it requires a lot of code and I only need a pid. It would also require a lot of code when windows support is implemented.
- I didn't add Windows support, as I don't have a windows machine, but adding support for it should be easy, as the FIFO file can be implemented with a named pipe, which is standard on Windows and works pretty much the same way.
The existing test which didn't pass on Linux, now passes.
Differential Revision: https://reviews.llvm.org/D93951
2020-12-29 04:00:47 +08:00
|
|
|
RunInTerminal.cpp
|
2018-08-17 01:59:38 +08:00
|
|
|
SourceBreakpoint.cpp
|
|
|
|
|
VSCode.cpp
|
|
|
|
|
|
|
|
|
|
LINK_LIBS
|
|
|
|
|
liblldb
|
|
|
|
|
${extra_libs}
|
|
|
|
|
|
|
|
|
|
LINK_COMPONENTS
|
2020-02-22 00:13:05 +08:00
|
|
|
Option
|
2018-08-17 01:59:38 +08:00
|
|
|
Support
|
|
|
|
|
)
|
[CMake] Revised RPATH handling
Summary:
If we build LLDB.framework, dependant tools need appropriate RPATHs in both locations, the build-tree (for testing) and the install-tree (for deployment). Luckily, CMake can handle it for us: https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/RPATH-handling.
* In the build-tree, tools use the absolute path to the framework's actual output location.
* In the install-tree, tools get a list of RPATHs to look for the framework when deployed.
`LLDB_FRAMEWORK_INSTALL_DIR` is added to the `CMAKE_INSTALL_PREFIX` to change the relative location of LLDB.framework in the install-tree.
If it is not empty, it will be added as an additional RPATH to all dependant tools (so they are functional in the install-tree).
If it is empty, LLDB.framework goes to the root and tools will not be functional in the directory structure of the LLVM install-tree.
For historical reasons `LLDB_FRAMEWORK_INSTALL_DIR` defaults to "Library/Frameworks".
Reviewers: xiaobai, JDevlieghere, aprantl, clayborg
Reviewed By: JDevlieghere
Subscribers: ki.stfu, mgorny, lldb-commits, #lldb
Differential Revision: https://reviews.llvm.org/D55330
llvm-svn: 350392
2019-01-04 20:46:57 +08:00
|
|
|
|
|
|
|
|
if(LLDB_BUILD_FRAMEWORK)
|
2019-05-29 19:26:06 +08:00
|
|
|
# In the build-tree, we know the exact path to the framework directory.
|
|
|
|
|
# The installed framework can be in different locations.
|
|
|
|
|
lldb_setup_rpaths(lldb-vscode
|
|
|
|
|
BUILD_RPATH
|
2019-10-31 01:33:05 +08:00
|
|
|
"${LLDB_FRAMEWORK_ABSOLUTE_BUILD_DIR}"
|
2019-05-29 19:26:06 +08:00
|
|
|
INSTALL_RPATH
|
|
|
|
|
"@loader_path/../../../SharedFrameworks"
|
|
|
|
|
"@loader_path/../../System/Library/PrivateFrameworks"
|
|
|
|
|
"@loader_path/../../Library/PrivateFrameworks"
|
|
|
|
|
)
|
[CMake] Revised RPATH handling
Summary:
If we build LLDB.framework, dependant tools need appropriate RPATHs in both locations, the build-tree (for testing) and the install-tree (for deployment). Luckily, CMake can handle it for us: https://gitlab.kitware.com/cmake/community/wikis/doc/cmake/RPATH-handling.
* In the build-tree, tools use the absolute path to the framework's actual output location.
* In the install-tree, tools get a list of RPATHs to look for the framework when deployed.
`LLDB_FRAMEWORK_INSTALL_DIR` is added to the `CMAKE_INSTALL_PREFIX` to change the relative location of LLDB.framework in the install-tree.
If it is not empty, it will be added as an additional RPATH to all dependant tools (so they are functional in the install-tree).
If it is empty, LLDB.framework goes to the root and tools will not be functional in the directory structure of the LLVM install-tree.
For historical reasons `LLDB_FRAMEWORK_INSTALL_DIR` defaults to "Library/Frameworks".
Reviewers: xiaobai, JDevlieghere, aprantl, clayborg
Reviewed By: JDevlieghere
Subscribers: ki.stfu, mgorny, lldb-commits, #lldb
Differential Revision: https://reviews.llvm.org/D55330
llvm-svn: 350392
2019-01-04 20:46:57 +08:00
|
|
|
endif()
|