The FileCollector got lifted into LLVM and a shim was introduced in LLDB
to keep the old API that takes FileSpecs. This patch removes that shim
and converts the arguments in place.
llvm-svn: 366975
This patch changes the coding style of the FileCollector from the LLDB
to the LLVM coding style. Alex recently lifted it into LLVM and I
volunteered to do the conversion.
llvm-svn: 366966
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:
While investigating breakages caused by D63110, I noticed we were
building the short options strings in three places. Some of them used a
leading ':' to detect missing arguments, and some didn't. This was the
indirect cause of D63110. Here, I move the common code into a utility
function.
Also, unify the code which appends the sentinel value at the end of the
option vector, and make it harder for users to pass invalid argc-argv
combos to getopt (another component of D63110) by having the
OptionParser::Parse function take a (Mutable)ArrayRef.
This unification has uncovered that we don't handle missing arguments
while building aliases, However, it's not possible to write an effective
test for this, as right now it is not possible to return an error out of
the alias parsing code (which means we are printing the generic
"failure" message even after this patch).
Reviewers: mgorny, aprantl
Reviewed By: mgorny
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D63770
llvm-svn: 365665
Change the interface to return an expected, instead of taking a Status
pointer.
Differential revision: https://reviews.llvm.org/D64163
llvm-svn: 365226
Summary:
This is the fifth patch to improve module loading in a series that started here (where I explain the motivation and solution): D62499
Reading strings with ReadMemory is really slow when reading the path of the shared library. This is because we don't know the length of the path so use PATH_MAX (4096) and these strings are actually super close to the boundary of an unreadable page. So even though we use process_vm_readv it will usually fail because the read size spans to the unreadable page and we then default to read the string word by word with ptrace.
This new function is very similar to another ReadCStringFromMemory that already exists in lldb that makes sure it never reads cross page boundaries and checks if we already read the entire string by finding '\0'.
I was able to reduce the GetLoadedSharedLibraries call from 30ms to 4ms (or something of that order).
Reviewers: clayborg, xiaobai, labath
Reviewed By: labath
Subscribers: emaste, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D62503
llvm-svn: 363750
Before this patch, reproducers weren't relocatable. The reproducer
contained hard coded paths in the VFS mapping, as well in the yaml file
listing the different input files for the command interpreter. This
patch changes that:
- Use relative paths for the DataCollector.
- Use an overlay prefix for the FileCollector.
Differential revision: https://reviews.llvm.org/D63467
llvm-svn: 363697
The created string is one char too large, so it pulls the terminating NULL as
the last character of the string. This later causes SocketTest.cpp to fail.
llvm-svn: 362192
Summary:
My main goal here is to make lldb-server work with Android Studio.
This is currently not the case because lldb-server is started in platform mode listening on a domain socket. When Android Studio connects to it lldb-server crashes because even though it's listening on a domain socket as soon as it gets a connection it asserts that it's a TCP connection, which will obviously fails for any non-tcp connection.
To do this I came up with a new method called GetConnectURI() in Socket that returns the URI needed to connect to the connected portion of the socket.
Reviewers: labath, clayborg, xiaobai
Reviewed By: labath
Subscribers: mgorny, jfb, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D62089
llvm-svn: 362173
Summary:
This is a general fix for the ConnectionFileDescriptor class but my main motivation was to make lldb-server working with IPv6.
The connect URI can use square brackets ([]) to wrap the interface part of the URI (e.g.: <scheme>://[<interface>]:<port>). For IPv6 addresses this is a must since its ip can include colons and it will overlap with the port colon otherwise. The URIParser class parses the square brackets correctly but the ConnectionFileDescriptor doesn't generate them for IPv6 addresses making it impossible to connect to the gdb server when using this protocol.
How to reproduce the issue:
```
$ lldb-server p --server --listen [::1]:8080
...
$ lldb
(lldb) platform select remote-macosx
(lldb) platform connect connect://[::1]:8080
(lldb) platform process -p <pid>
error: unable to launch a GDB server on 'computer'
```
The server was actually launched we were just not able to connect to it. With this fix lldb will correctly connect. I fixed this by wrapping the ip portion with [].
Reviewers: labath
Reviewed By: labath
Subscribers: xiaobai, mgorny, jfb, lldb-commits, labath
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D61833
llvm-svn: 361898
Summary:
Fixing this error on windows build bot:
```
E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Host\common\HostNativeThreadBase.cpp(21): error C2440: 'initializing': cannot convert from 'nullptr' to 'lldb::thread_result_t'
E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Host\common\HostNativeThreadBase.cpp(21): note: A native nullptr can only be converted to bool or, using reinterpret_cast, to an integral type
E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Host\common\HostNativeThreadBase.cpp(21): error C2439: 'lldb_private::HostNativeThreadBase::m_result': member could not be initialized
E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\include\lldb/Host/HostNativeThreadBase.h(48): note: see declaration of 'lldb_private::HostNativeThreadBase::m_result'
E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Host\common\HostNativeThreadBase.cpp(24): error C2440: 'initializing': cannot convert from 'nullptr' to 'lldb::thread_result_t'
E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Host\common\HostNativeThreadBase.cpp(24): note: A native nullptr can only be converted to bool or, using reinterpret_cast, to an integral type
E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Host\common\HostNativeThreadBase.cpp(24): error C2439: 'lldb_private::HostNativeThreadBase::m_result': member could not be initialized
E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\include\lldb/Host/HostNativeThreadBase.h(48): note: see declaration of 'lldb_private::HostNativeThreadBase::m_result'
E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Host\common\HostNativeThreadBase.cpp(40): error C2440: '=': cannot convert from 'nullptr' to 'lldb::thread_result_t'
E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Host\common\HostNativeThreadBase.cpp(40): note: A native nullptr can only be converted to bool or, using reinterpret_cast, to an integral type
E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Host\common\HostNativeThreadBase.cpp(50): error C2440: '=': cannot convert from 'nullptr' to 'lldb::thread_result_t'
E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Host\common\HostNativeThreadBase.cpp(50): note: A native nullptr can only be converted to bool or, using reinterpret_cast, to an integral type
```
see http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/5050/steps/build/logs/stdio
Reviewers: stella.stamenova, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D62337
llvm-svn: 361565
Summary:
On Windows `lldb::thread_result_t` resolves to `typedef unsigned thread_result_t;` and on other platforms it resolves to `typedef void *thread_result_t;`.
Therefore one cannot use `nullptr` when returning from a function that returns `thread_result_t`.
I've made this change because a windows build bot fails with these errors:
```
E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Core\Communication.cpp(362): error C2440: 'return': cannot convert from 'nullptr' to 'lldb::thread_result_t'
E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Core\Communication.cpp(362): note: A native nullptr can only be converted to bool or, using reinterpret_cast, to an integral type
```
and
```
E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Core\Debugger.cpp(1619): error C2440: 'return': cannot convert from 'nullptr' to 'lldb::thread_result_t'
E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Core\Debugger.cpp(1619): note: A native nullptr can only be converted to bool or, using reinterpret_cast, to an integral type
E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Core\Debugger.cpp(1664): error C2440: 'return': cannot convert from 'nullptr' to 'lldb::thread_result_t'
E:\build_slave\lldb-x64-windows-ninja\llvm\tools\lldb\source\Core\Debugger.cpp(1664): note: A native nullptr can only be converted to bool or, using reinterpret_cast, to an integral type
```
This is the failing build: http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/5035/steps/build/logs/stdio
Reviewers: JDevlieghere, teemperor, jankratochvil, labath, clayborg, RKSimon, courbet, jhenderson
Reviewed By: labath, clayborg
Subscribers: labath, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D62305
llvm-svn: 361503
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
Rewrite the GetHistoryFilePath implementation without relying on
FileSpec in the spirit of our discussion in D61994.
It changes LLDBs behavior in two ways:
1. We now only use the -widehistory suffix when LLDB is built with wchar
support, instead of as the fallback from when the ~/.lldb directory
isn't writable.
2. When the ~/.lldb directory isn't writable, we don't write any history
files at all. Previously we would write them to the user's home
directory (with the incorrect wide suffix), polluting ~ with a
different file for every IO handler.
Differential revision: https://reviews.llvm.org/D62216
llvm-svn: 361412
When I moved the resolve code from FileSpec to the FileSystem class, I
introduced a regression. If you compare the two implementations, you'll
notice that if the path doesn't exist, we should only reverse the
effects of makeAbsolute, not the effects of tilde expansion.
As a result, the logic to create the ~/.lldb directory broke, because we
would resolve the path before creating it. Because the directory didn't
exist yet, we'd call create_directories on the unresolved path, which
failed.
Differential revision: https://reviews.llvm.org/D62219
llvm-svn: 361321
This reverts commit c28f81797084b8416ff5be4f9e79000a9741ca6a.
This reverts commit 7e79b64642486f510f7872174eb831df68d65b84.
Looks like there is more work to be done on this patch. I've spoken to
the author and for the time being we will revert to keep the buildbots
green.
llvm-svn: 361086
This is a general fix for the ConnectionFileDescriptor class but my main
motivation was to make lldb-server working with IPv6.
The connect URI can use square brackets ([]) to wrap the interface part
of the URI (e.g.: <scheme>://[<interface>]:<port>). For IPv6 addresses
this is a must since its ip can include colons and it will overlap with
the port colon otherwise. The URIParser class parses the square brackets
correctly but the ConnectionFileDescriptor doesn't generate them for
IPv6 addresses making it impossible to connect to the gdb server when
using this protocol.
How to reproduce the issue:
$ lldb-server p --server --listen [::1]:8080
...
$ lldb
(lldb) platform select remote-macosx
(lldb) platform connect connect://[::1]:8080
(lldb) platform process -p <pid>
error: unable to launch a GDB server on 'computer'
The server was actually launched we were just not able to connect to it.
With this fix lldb will correctly connect. I fixed this by wrapping the
ip portion with [].
Differential Revision: https://reviews.llvm.org/D61833
Patch by António Afonso <antonio.afonso@gmail.com>
llvm-svn: 361079
Get*AtIndex() can return nullptr. This only happens in the swift
REPL support, so it's hard to test upstream.
<rdar://problem/50875178>
llvm-svn: 361078
Summary:
libedit implementation of el_get(EL_GETTC) had a bug, where it was
consuming vararg arguments until reaching the first null pointer (and
not just two, as documented). This was causing (at least) errors to be
reported when running the tests under msan.
The issue has since been fixed in libedit, but this adds patch adds a
trivial workaround, so that we operate correctly with the libedit
versions which are already out there.
Reviewers: christos, krytarowski, davide
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D61191
llvm-svn: 359449
Under very specific circumstances the default shell /bin/sh might
print stuff to stderr before launching lldb-argdumper, which then
confuses the JSON parser. This patch suppresses stderr output from
lldb-argdumper to avoid this situation.
rdar://problem/50149390
Differential Revision: https://reviews.llvm.org/D61101
llvm-svn: 359156
LLVM's wchar to UTF8 conversion routine expects an empty string to store the output.
GetHostName() on Windows is sometimes called with a non-empty string which triggers
an assert. The simple fix is to clear the output string before the conversion.
llvm-svn: 358550
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
llvm::StringRef host_and_port is not guaranteed to be null-terminated.
Generally, it is not safe at all to convert a StringRef into a char *
by calling data() on it.
<rdar://problem/49698580>
llvm-svn: 357948
The utility library shouldn't depend on curses, libedit or python. Move
curses to core, libedit to host and python to the python plugin.
Differential revision: https://reviews.llvm.org/D59970
llvm-svn: 357287
