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
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
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
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
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
Previously we used UINT16_MAX to mean no port/no specifc
port. This leads to confusion because 65535 is a valid
port number.
Instead use an optional. If you want a specific port call
LaunchGDBServer as normal, otherwise pass an empty optional
and it will be set to the port that gets chosen.
(or left empty in the case where we fail to find a port)
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D92035
Previously if you did:
$ lldb-server platform --server <...> --min-gdbserver-port 12346
--max-gdbserver-port 12347
(meaning only use port 12346 for gdbservers)
Then tried to launch two gdbservers on the same connection,
the second one would return port 65535. Which is a real port
number but it actually means lldb-server didn't find one it was
allowed to use.
send packet: $qLaunchGDBServer;<...>
read packet: $pid:1919;port:12346;#c0
<...>
send packet: $qLaunchGDBServer;<...>
read packet: $pid:1927;port:65535;#c7
This situation should be an error even if port 65535 does happen
to be available on the current machine.
To fix this make PortMap it's own class within
GDBRemoteCommunicationServerPlatform.
This almost the same as the old typedef but for
GetNextAvailablePort() returning an llvm::Expected.
This means we have to handle not finding a port,
by returning an error packet.
Also add unit tests for this new PortMap class.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D91634
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
Add a new FreeBSD Process plugin using client/server model. This plugin
is based on the one used by NetBSD. It currently supports a subset
of functionality for amd64. It is automatically used when spawning
lldb-server. It can also be used by lldb client by setting
FREEBSD_REMOTE_PLUGIN environment variable (to any value).
The code is capable of debugging simple single-threaded programs. It
supports general purpose, debug and FPU registers (up to XMM) of amd64,
basic signalling, software breakpoints.
Adding the support for the plugin involves removing some dead code
from FreeBSDPlatform plugin (that was not ever used because
CanDebugProcess() returned false), and replacing it with appropriate
code from NetBSD platform support.
Differential Revision: https://reviews.llvm.org/D88796
When running in an ipv6-only environment where `AF_INET` sockets are not available, many lldb tests (mostly gdb remote tests) fail because things like `127.0.0.1` don't work there.
Use `localhost` instead of `127.0.0.1` whenever possible, or include a fallback of creating `AF_INET6` sockets when `AF_INET` fails.
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D87333
`lldb-server platform --socket-file /any/path` currently always fails to create
the socket file. This stopped working after D67424 which changed the
input variables of `writeFileAtomically` slightly. We're expected to
pass in a temporary path template (`/tmp/foo-%%%%%`) and the final
path we want to write. Instead we currently pass in the never set
`temp_file_path` as the temporary path (which will make this function always
fail) and pass in the temp_file_spec's path as the final path (which is actually
the template path such as `/tmp/foo-%%%%%`) instead of the actual path
we want to write (e.g. `/tmp/foo`).
Reviewed By: labath
Differential Revision: https://reviews.llvm.org/D85890
This patch configures LLDB.framework to build as a flat unversioned
framework on non-macOS Darwin targets, which have never supported the
macOS framework layout.
This patch also renames the 'IOS' cmake variable to 'APPLE_EMBEDDED' to
reflect the fact that lldb is built for several different kinds of embedded
Darwin targets, not just iOS.
Differential Revision: https://reviews.llvm.org/D85770
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
StringRef will call strlen on the C string which is inefficient (as ConstString already
knows the string lenght and so does StringRef). This patch replaces all those calls
with GetStringRef() which doesn't recompute the length.
This is how it should've been and brings it more in line with
std::string_view. There should be no functional change here.
This is mostly mechanical from a custom clang-tidy check, with a lot of
manual fixups. It uncovers a lot of minor inefficiencies.
This doesn't actually modify StringRef yet, I'll do that in a follow-up.
In the documentation of `include_directories`, it notes that
`target_include_directories` is preferred because it affects
specific targets intead of propagating include search paths
to the entire project.
No files in lldb-server are including a header from a plugin without the
whole path to the header relative to the lldb source directory. There is
no need to include the specific directories as a result.
Allow clients of the llvm library to opt-in to one-shot SIGPIPE
handling, instead of forcing them to undo llvm's SIGPIPE handler
registration (which is brittle).
The current behavior is preserved for all llvm-derived tools (except
lldb) by means of a default-`true` flag in the InitLLVM constructor.
This prevents "IO error" crashes in long-lived processes (lldb is the
motivating example) which both a) load llvm as a dynamic library and b)
*really* need to ignore SIGPIPE.
As llvm signal handlers can be installed when calling into libclang
(say, via RemoveFileOnSignal), thereby overriding a previous SIG_IGN for
SIGPIPE, there is no clean way to opt-out of "exit-on-SIGPIPE" in the
current model.
Differential Revision: https://reviews.llvm.org/D70277
This should allow lldb-server to operate on files with non-ascii
pathnames.
I tried looking around in lldb/tools, and this seemed like the only
other tool (other than the main lldb driver itself) that would be
used (implicitly) by an end user (which could be working in
non-ascii paths).
Differential Revision: https://reviews.llvm.org/D68864
llvm-svn: 374537
Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.
Differential revision: https://reviews.llvm.org/D66259
llvm-svn: 368933
Summary:
This commit contains three small changes to enable lldb-server on Windows.
- Add lldb-server for Windows to the build
- Disable pty redirection on Windows for the initial lldb-server bring up
- Add a support to get the parent pid for a process on Windows
- Ifdef some signals which aren't supported on Windows
Thanks to Hui Huang for the help with this patch!
Reviewers: labath
Reviewed By: labath
Subscribers: JDevlieghere, compnerd, Hui, amccarth, xiaobai, srhines, mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D61686
llvm-svn: 368774
This patch replaces explicit calls to log::Printf with the new LLDB_LOGF
macro. The macro is similar to LLDB_LOG but supports printf-style format
strings, instead of formatv-style format strings.
So instead of writing:
if (log)
log->Printf("%s\n", str);
You'd write:
LLDB_LOG(log, "%s\n", str);
This change was done mechanically with the command below. I replaced the
spurious if-checks with vim, since I know how to do multi-line
replacements with it.
find . -type f -name '*.cpp' -exec \
sed -i '' -E 's/log->Printf\(/LLDB_LOGF\(log, /g' "{}" +
Differential revision: https://reviews.llvm.org/D65128
llvm-svn: 366936
Summary: The LLDB test suite doesn't need lldb-server in the framework bundle anymore.
Reviewers: JDevlieghere, jasonmolenda, xiaobai
Reviewed By: JDevlieghere
Subscribers: mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D62474
llvm-svn: 361947
Summary:
Modify the way LLDB.framework tools are collected. This allows for better fine-tuning of the install behavior downstream. Each target calls `lldb_add_to_framework()` individually. When entering the function, the target exists and we can tweak its very own post-build and install steps. This was not possible with the old `LLDB_FRAMEWORK_TOOLS` approach.
No function change otherwise.
This is a reduced follow-up from the proposal in D61952.
Reviewers: xiaobai, compnerd, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: clayborg, friss, ki.stfu, mgorny, lldb-commits, labath, #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D62472
llvm-svn: 361946
Summary:
NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]]
This commit is the result of modernizing the LLDB codebase by using
`nullptr` instread of `0` or `NULL`. See
https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html
for more information.
This is the command I ran and I to fix and format the code base:
```
run-clang-tidy.py \
-header-filter='.*' \
-checks='-*,modernize-use-nullptr' \
-fix ~/dev/llvm-project/lldb/.* \
-format \
-style LLVM \
-p ~/llvm-builds/debug-ninja-gcc
```
NOTE: There were also changes to `llvm/utils/unittest` but I did not
include them because I felt that maybe this library shall be updated in
isolation somehow.
NOTE: I know this is a rather large commit but it is a nobrainer in most
parts.
Reviewers: martong, espindola, shafik, #lldb, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits
Tags: #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D61847
llvm-svn: 361484
`terminate` overlaps with a C function on Windows:
```
D:\a\1\s\lldb\tools\lldb-server\lldb-server.cpp(45,13): warning: 'terminate' redeclared without 'dllimport' attribute: 'dllexport' attribute added [-Winconsistent-dllimport]
static void terminate() { g_debugger_lifetime->Terminate(); }
^
C:\Program Files (x86)\Windows Kits\10\include\10.0.17763.0\ucrt\corecrt_terminate.h(29,48): note: previous declaration is here
_ACRTIMP __declspec(noreturn) void __cdecl terminate() throw();
^
D:\a\1\s\lldb\tools\lldb-server\lldb-server.cpp(45,61): warning: function declared 'noreturn' should not return [-Winvalid-noreturn]
static void terminate() { g_debugger_lifetime->Terminate(); }
^
```
Rename the function to `terminate_debugger` to avoid the errant match.
llvm-svn: 360693
The debug server does not need to use the instruction emulation. This
helps reduce the size of the final lldb-server binary by another ~100K
(~1% savings).
llvm-svn: 360067
A lot of comments in LLDB are surrounded by an ASCII line to delimit the
begging and end of the comment.
Its use is not really consistent across the code base, sometimes the
lines are longer, sometimes they are shorter and sometimes they are
omitted. Furthermore, it looks kind of weird with the 80 column limit,
where the comment actually extends past the line, but not by much.
Furthermore, when /// is used for Doxygen comments, it looks
particularly odd. And when // is used, it incorrectly gives the
impression that it's actually a Doxygen comment.
I assume these lines were added to improve distinguishing between
comments and code. However, given that todays editors and IDEs do a
great job at highlighting comments, I think it's worth to drop this for
the sake of consistency. The alternative is fixing all the
inconsistencies, which would create a lot more churn.
Differential revision: https://reviews.llvm.org/D60508
llvm-svn: 358135
In mail
[lldb-dev] Remote debugging a docker process
https://lists.llvm.org/pipermail/lldb-dev/2019-March/014795.html
user was confused by --min-gdbserver-port and --max-gdbserver-port options
being ignored. I think there is even a bug that --max-gdbserver-port is upper
exclusive limit (and not upper inclusive limit appropriate for max).
At least this patch should catch such mistake by an error message. The question
is whether --max-gdbserver-port should not be changed to really be max and not
max+1 but that would break backward compatibility.
Now the mail example does produce:
error: --min-gdbserver-port (5001) is not lower than --max-gdbserver-port (5001)
Differential Revision: https://reviews.llvm.org/D58962
llvm-svn: 355554
As per the discussion on the mailing list:
http://lists.llvm.org/pipermail/lldb-commits/Week-of-Mon-20190218/048007.html
This commit implements option (3):
> Go back to initializing the reproducer before the rest of the debugger.
> The method wouldn't be instrumented and guarantee no other SB methods are
> called or SB objects are constructed. The initialization then becomes part
> of the replay.
Differential revision: https://reviews.llvm.org/D58410
llvm-svn: 354631
Catch the possible error from lldb-gdbserver's main loop, and report
it verbosely. Currently, if the loop fails the server exits normally,
rendering the problem indistinguishable from regular termination.
Differential Revision: https://reviews.llvm.org/D58228
llvm-svn: 354030
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
Raphael Isemann