MmsOTDeveloperadded all modifications made for msdebug
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
Update com.apple.diagnosticd.diagnostic entitlement name to the newer com.apple.private.logging.diagnostic. <rdar://problem/47183116> llvm-svn: 355170 | 7 年前 | |
[lldb] Use std::optional instead of llvm::Optional (NFC) This patch replaces (llvm::|)Optional< with std::optional<. I'll post a separate patch to clean up the "using" declarations, #include "llvm/ADT/Optional.h", etc. This is part of an effort to migrate from llvm::Optional to std::optional: https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716 | 3 年前 | |
[lldb] Update header guards to be consistent and compliant with LLVM (NFC) LLDB has a few different styles of header guards and they're not very consistent because things get moved around or copy/pasted. This patch unifies the header guards across LLDB and converts everything to match LLVM's style. Differential revision: https://reviews.llvm.org/D74743 | 6 年前 | |
[lldb] Revise IDE folder structure (#89748) Update the folder titles for targets in the monorepository that have not seen taken care of for some time. These are the folders that targets are organized in Visual Studio and XCode ( set_property(TARGET <target> PROPERTY FOLDER "<title>")) when using the respective CMake's IDE generator. * Ensure that every target is in a folder * Use a folder hierarchy with each LLVM subproject as a top-level folder * Use consistent folder names between subprojects * When using target-creating functions from AddLLVM.cmake, automatically deduce the folder. This reduces the number of set_property/set_target_property, but are still necessary when add_custom_target, add_executable, add_library, etc. are used. A LLVM_SUBPROJECT_TITLE definition is used for that in each subproject's root CMakeLists.txt. | 2 年前 | |
[lldb] Introduce the concept of a log handler (NFC) This patch introduces the concept of a log handlers. Log handlers allow customizing the way log output is emitted. The StreamCallback class tried to do something conceptually similar. The benefit of the log handler interface is that you don't need to conform to llvm's raw_ostream interface. Differential revision: https://reviews.llvm.org/D127922 | 4 年前 | |
[lldb] Update header guards to be consistent and compliant with LLVM (NFC) LLDB has a few different styles of header guards and they're not very consistent because things get moved around or copy/pasted. This patch unifies the header guards across LLDB and converts everything to match LLVM's style. Differential revision: https://reviews.llvm.org/D74743 | 6 年前 | |
[lldb] Port lldb gdb-server to libOption The existing help text was very terse and was missing several important options. In the new version, I add a short description of each option and a slightly longer description of the tool as a whole. The new option list does not include undocumented no-op options: --debug and --verbose. It also does not include undocumented short aliases for long options, with two exceptions: -h, because it's well-known; and -S (--setsid), as it's used in one test. Using these options will now produce an error. I believe that is acceptable as users aren't generally invoking lldb-server directly, and the only way to learn about the short aliases was by looking at the source. Differential Revision: https://reviews.llvm.org/D89477 | 5 年前 | |
Revert "[lldb-server] Use Platform plugin corresponding to the host" This reverts commit 0c5cee779929f840f4f286c5894a01f583ee7b4a. As discussed in https://reviews.llvm.org/D146668 we'll find another way forward. | 3 年前 | |
[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 | 5 年前 | |
added all modifications made for msdebug | 7 个月前 | |
[lldb] Fixed the error unable to launch a GDB server in API tests (#98833) TestPlatformLaunchGDBServer.py runs ldb-server w/o parameters --min-gdbserver-port, --max-gdbserver-port or --gdbserver-port. So gdbserver_portmap is empty and gdbserver_portmap.GetNextAvailablePort() will return 0. Do not call portmap_for_child.AllowPort(0) in this case. Otherwise portmap_for_child.GetNextAvailablePort() will allocate and never free the port 0 and next call portmap_for_child.GetNextAvailablePort() will fail. Added few asserts in GDBRemoteCommunicationServerPlatform::PortMap to avoid such issue in the future. This patch fixes a bug added in #88845. The behaviour is very close to #97537 w/o parameters --min-gdbserver-port, --max-gdbserver-port and --gdbserver-port. | 2 年前 | |
added all modifications made for msdebug | 7 个月前 |