Summary:
SBFile is a scripting API wrapper for lldb_private::File
This is the first step in a project to enable arbitrary python
io.IOBase file objects -- including those that override the read()
and write() methods -- to be used as the main debugger IOStreams.
Currently this is impossible because python file objects must first
be converted into FILE* streams by SWIG in order to be passed into
the debugger.
full prototype: https://github.com/smoofra/llvm-project/tree/files
Reviewers: JDevlieghere, jasonmolenda, zturner, jingham, labath
Reviewed By: labath
Subscribers: labath, mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67793
llvm-svn: 373562
Summary:
File::Clear() is an ugly function. It's only used in one place,
which is the swig typemaps for FILE*. This patch refactors and
renames that function to make it clear what it's really for and
why nobody else should use it.
Both File::TakeStreamAndClear() and the FILE* typemaps will be
removed in later patches after a suitable replacement is in place.
Reviewers: JDevlieghere, jasonmolenda, labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68160
llvm-svn: 373285
Summary:
m_should_close_fd doesn't need to be in IOObject. It will be useful
for my next change to move it down into File and Socket.
Reviewers: labath, JDevlieghere, jasonmolenda
Reviewed By: JDevlieghere
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68152
llvm-svn: 373126
Summary:
This patch removes File::SetStream() and File::SetDescriptor(),
and replaces most direct uses of File with pointers to File.
Instead of calling SetStream() on a file, we make a new file and
replace it.
My ultimate goal here is to introduce a new API class SBFile, which
has full support for python io.IOStream file objects. These can
redirect read() and write() to python code, so lldb::Files will
need a way to dispatch those methods. Additionally it will need some
form of sharing and assigning files, as a SBFile will be passed in and
assigned to the main IO streams of the debugger.
In my prototype patch queue, I make File itself copyable and add a
secondary class FileOps to manage the sharing and dispatch. In that
case SBFile was a unique_ptr<File>.
(here: https://github.com/smoofra/llvm-project/tree/files)
However in review, Pavel Labath suggested that it be shared_ptr instead.
(here: https://reviews.llvm.org/D67793)
In order for SBFile to use shared_ptr<File>, everything else should
as well.
If this patch is accepted, I will make SBFile use a shared_ptr
I will remove FileOps from future patches and use subclasses of File
instead.
Reviewers: JDevlieghere, jasonmolenda, zturner, jingham, labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67891
llvm-svn: 373090
Summary:
This patch converts FileSystem::Open from this prototype:
Status
Open(File &File, const FileSpec &file_spec, ...);
to this one:
llvm::Expected<std::unique_ptr<File>>
Open(const FileSpec &file_spec, ...);
This is beneficial on its own, as llvm::Expected is a more modern
and recommended error type than Status. It is also a necessary step
towards https://reviews.llvm.org/D67891, and further developments
for lldb_private::File.
Reviewers: JDevlieghere, jasonmolenda, labath
Reviewed By: labath
Subscribers: mgorny, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67996
llvm-svn: 373003
> Use symbolic constants for the platform identifiers rather than replicating them
> locally.
This broke the build of LLDB on Windows, see
http://lab.llvm.org:8011/builders/lldb-x64-windows-ninja/builds/9182 which
fails with e.g.
E:\build_slave\lldb-x64-windows-ninja\llvm\include\llvm/BinaryFormat/COFF.h(96): error C2059: syntax error: 'constant'
E:\build_slave\lldb-x64-windows-ninja\llvm\include\llvm/BinaryFormat/COFF.h(96): error C3805: 'constant': unexpected token, expected either '}' or a ','
E:\build_slave\lldb-x64-windows-ninja\llvm\include\llvm/BinaryFormat/COFF.h(128): error C2059: syntax error: 'constant'
...
llvm-svn: 372847
lvm_private::File::GetStream() can fail if m_options == 0
It's not clear from the header a File created with a descriptor will be
not be usable by many parts of LLDB unless SetOptions is also called,
but it is.
This is because those parts of LLDB rely on GetStream() to use the
file, and that in turn relies on calling fdopen on the descriptor. When
calling fdopen, GetStream relies on m_options to determine the access
mode. If m_options has never been set, GetStream() will fail.
This patch adds options as a required argument to File::SetDescriptor
and the corresponding constructor.
Patch by: Lawrence D'Anna
Differential revision: https://reviews.llvm.org/D67792
llvm-svn: 372652
If the file has m_stream, it may not have a m_descriptor.
GetWaitableHandle() should call GetDescriptor(), which will call
fileno(), so it will get waitable descriptor whenever one is available.
Patch by: Lawrence D'Anna
Differential revision: https://reviews.llvm.org/D67789
llvm-svn: 372644
These ifdefs contain code that isn't specific to MSVC but useful for
any windows target, like MinGW.
Differential Revision: https://reviews.llvm.org/D67893
llvm-svn: 372592
vsnprintf(NULL, 0, ...) works for measuring the needed string
size on all supported Windows variants; it's supported since
at least MSVC 2015 (and LLVM requires a newer version than that),
and works on both msvcrt.dll (since at least XP) and UCRT with MinGW.
The previous use of ifdefs was wrong as well, as __MINGW64__ only is
defined for 64 bit targets, and the define without trailing
underscores is never defined automatically (neither by clang nor
by gcc).
Differential Revision: https://reviews.llvm.org/D67861
llvm-svn: 372591
This fixes build warnings in MinGW mode.
Also remove leftover if (log) {} around the log macro.
Differential Revision: https://reviews.llvm.org/D67896
llvm-svn: 372590
This silences warnings about comparison of integers between unsigned
long long (which is what the Windows SOCKET type is) and signed int
when building in MinGW mode.
Differential Revision: https://reviews.llvm.org/D67863
llvm-svn: 372486
This code is trying too hard and failing. Either the result of
gethostname() is canonical or it is not. If it is not, then trying to
canonicalize it is – for various reasons – a lost cause. For example, a
given machine might have multiple network interfaces with multiple
addresses per interface, each with a different canonical name.
Separably, the result of HostInfoPosix::GetHostname() and latency
thereof shouldn't depend on whether networking is up or down or what
network the machine happened to be attached to at any given moment (like
a laptop that travels between work and home).
https://reviews.llvm.org/D67230
llvm-svn: 371596
This removes the CleanUp class and replaces its usages with llvm's
ScopeExit, which has similar semantics.
Differential revision: https://reviews.llvm.org/D67378
llvm-svn: 371474
plugin.
Unfortunately the test is currently XFAILed because of missing changes
to the clang driver.
Differential Revision: https://reviews.llvm.org/D67124
llvm-svn: 370931
We change num_bytes in this method, so this doesn't actually
log the parameter that we called the function with. No test
as we don't test logging code.
llvm-svn: 370887
Summary: It's neither used or tested here and in swift-lldb, so let's get rid of it.
Reviewers: #lldb, davide
Reviewed By: #lldb, davide
Subscribers: davide, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D67116
llvm-svn: 370802
On the command line we usually insert a space after a completion to indicate that
the completion was successful. After the completion API refactoring, this also
happens with directories which essentially breaks file path completion (as
adding a space terminates the path and starts a new arg). This patch restores the old
behavior by again allowing partial completions. Also extends the iohandler
and SB API tests as the implementation for this is different in Editline
and SB API.
llvm-svn: 370043
The disconnect method sets the shutdown flag to true. This currently
only prevents any reads from happening, but not writes, which is
incorrect. Presumably this was just an oversight when adding
synchronization to the class. This adds the same shutdown check to the
Write method.
Over-the-shoulder reviewed by Jim!
llvm-svn: 370002
Summary:
We still have some leftovers of the old completion API in the internals of
LLDB that haven't been replaced by the new CompletionRequest. These leftovers
are:
* The return values (int/size_t) in all completion functions.
* Our result array that starts indexing at 1.
* `WordComplete` mode.
I didn't replace them back then because it's tricky to figure out what exactly they
are used for and the completion code is relatively untested. I finally got around
to writing more tests for the API and understanding the semantics, so I think it's
a good time to get rid of them.
A few words why those things should be removed/replaced:
* The return values are really cryptic, partly redundant and rarely documented.
They are also completely ignored by Xcode, so whatever information they contain will end up
breaking Xcode's completion mechanism. They are also partly impossible to even implement
as we assign negative values special meaning and our completion API sometimes returns size_t.
Completion functions are supposed to return -2 to rewrite the current line. We seem to use this
in some untested code path to expand the history repeat character to the full command, but
I haven't figured out why that doesn't work at the moment.
Completion functions return -1 to 'insert the completion character', but that isn't implemented
(even though we seem to activate this feature in LLDB sometimes).
All positive values have to match the number of results. This is obviously just redundant information
as the user can just look at the result list to get that information (which is what Xcode does).
* The result array that starts indexing at 1 is obviously unexpected. The first element of the array is
reserved for the common prefix of all completions (e.g. "foobar" and "footar" -> "foo"). The idea is
that we calculate this to make the life of the API caller easier, but obviously forcing people to have
1-based indices is not helpful (or even worse, forces them to manually copy the results to make it
0-based like Xcode has to do).
* The `WordComplete` mode indicates that LLDB should enter a space behind the completion. The
idea is that we let the top-level API know that we just provided a full completion. Interestingly we
`WordComplete` is just a single bool that somehow represents all N completions. And we always
provide full completions in LLDB, so in theory it should always be true.
The only use it currently serves is providing redundant information about whether we have a single
definitive completion or not (which we already know from the number of results we get).
This patch essentially removes `WordComplete` mode and makes the result array indexed from 0.
It also removes all return values from all internal completion functions. The only non-redundant information
they contain is about rewriting the current line (which is broken), so that functionality was moved
to the CompletionRequest API. So you can now do `addCompletion("blub", "description", CompletionMode::RewriteLine)`
to do the same.
For the SB API we emulate the old behaviour by making the array indexed from 1 again with the common
prefix at index 0. I didn't keep the special negative return codes as we either never sent them before (e.g. -2) or we
didn't even implement them in the Editline handler (e.g. -1).
I tried to keep this patch minimal and I'm aware we can probably now even further simplify a bunch of related code,
but I would prefer doing this in follow-up NFC commits
Reviewers: JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arphaman, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D66536
llvm-svn: 369624
Originally I wanted to remove the RegularExpression class in Utility and
replace it with llvm::Regex. However, during that transition I noticed
that there are several places where need the regular expression string.
So instead I propose to keep the RegularExpression class and make it a
thin wrapper around llvm::Regex.
This patch also removes the workaround for empty regular expressions.
The result is that we are now (more or less) POSIX conformant.
Differential revision: https://reviews.llvm.org/D66174
llvm-svn: 369153
This patch moves the remaining completion functions from the
old completion API (that used several variables) to just
passing a single CompletionRequest.
This is for the most part a simple change as we just replace
the old arguments with a single CompletionRequest argument.
There are a few places where I had to create new CompletionRequests
in the called functions as CompletionRequests itself are immutable
and don't expose their internal match list anymore. This means that
if a function wanted to change the CompletionRequest or directly
access the result list, we need to work around this by creating
a new CompletionRequest and a temporary match/description list.
Preparation work for rdar://53769355
llvm-svn: 369000
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 function is not portable, and there are only a handful of usages of
it anyway. Replacing it with std::this_thread::sleep_for enables us to
get rid of the compatibility code in PosixApi.h.
llvm-svn: 367814
Completion requests have two fields that are essentially unimplemented:
`m_match_start_point` and `m_max_return_elements`. This would've been
okay, if it wasn't for the fact that this caused a bunch of useless
parameters to be passed around. Occasionally there would be a comment or
assert saying that they are not supported. This patch removes them.
llvm-svn: 367385
Instead of passing the FileCollector around as a reference or raw
pointer, use a shared_ptr. This change's motivation is twofold. First it
adds compatibility for the newly added `FileCollectorFileSystem`.
Secondly, it addresses a lifetime issue we only see when LLDB is used
from Xcode, where a reference to the FileCollector outlives the
reproducer instance.
llvm-svn: 367258
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
the input StringRef is not guaranteed to be null-terminated, so using
data to get the c string is wrong. Luckily, in two of the usages the
target function already accepts a StringRef so we can just drop the
data() call, and the third one is easily replaced by a stringref-aware
function.
Issue found by msan.
llvm-svn: 355817
Summary: This function is useful for expression evaluation, especially when doing swift debugging on windows.
Reviewers: aprantl, labath
Reviewed By: labath
Subscribers: teemperor, jdoerfert, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D59072
llvm-svn: 355631
My apologies for the large patch. With the exception of ConstString.h
itself it was entirely produced by sed.
ConstString has exactly one const char * data member, so passing a
ConstString by reference is not any more efficient than copying it by
value. In both cases a single pointer is passed. But passing it by
value makes it harder to accidentally return the address of a local
object.
(This fixes rdar://problem/48640859 for the Apple folks)
Differential Revision: https://reviews.llvm.org/D59030
llvm-svn: 355553
This was reverted because it breaks the GreenDragon bot, but
the reason for the breakage is lost, so I'm resubmitting this
now so we can find out what the problem is.
llvm-svn: 355528
The intention in r355323 has been to implement a no-op resolver in the
HostInfoBase class, which will then be shadowed a an implementation in
the HostInfoPosix class. However, I add the shadowing declaration in
HostInfoPosix.h, and instead had implemented the HostInfoBase function
in HostInfoPosix.cpp. This has lead to undefined symbols on windows, and
a subsequent implementation of a no-op resolver in HostInfoWindows
(r355329).
Since now there is no point on having a no-op resolver in the base
class, I just remove the base declaration altogether, and have
HostInfoPosix implement the (newly-declared) HostInfoPosix version of
that function.
llvm-svn: 355398
There are set of classes in Target that describe the parameters of a
process - e.g. it's PID, name, user id, and similar. However, since it
is a bare description of a process and contains no actual functionality,
there's nothing specifically that makes this appropriate for being in
Target -- it could just as well be describing a process on the host, or
some hypothetical virtual process that doesn't even exist.
To cement this, I'm moving these classes to Utility. It's possible that
we can find a better place for it in the future, but as it is neither
Host specific nor Target specific, Utility seems like the most appropriate
place for the time being.
After this there is only 2 remaining references to Target from Host,
which I'll address in a followup.
Differential Revision: https://reviews.llvm.org/D58842
llvm-svn: 355342
That patch added a function to HostInfo that returns an instance
of UserIDResolver, but this function was unimplemented on Windows,
leading to linker errors. For now, just return a dummy implementation
that doesn't resolve user ids to get the build green.
llvm-svn: 355329
Summary:
This creates an abstract base class called "UserIDResolver", which can
be implemented to provide user/group ID resolution capabilities for
various objects. Posix host implement a PosixUserIDResolver, which does
that using posix apis (getpwuid and friends). PlatformGDBRemote
forwards queries over the gdb-remote link, etc. ProcessInstanceInfo
class is refactored to make use of this interface instead of taking a
platform pointer as an argument. The base resolver class already
implements caching and thread-safety, so implementations don't have to
worry about that.
The main motivating factor for this was to remove external dependencies
from the ProcessInstanceInfo class (so it can be put next to
ProcessLaunchInfo and friends), but it has other benefits too:
- ability to test the user name caching code
- ability to test ProcessInstanceInfo dumping code
- consistent interface for user/group resolution between Platform and
Host classes.
Reviewers: zturner, clayborg, jingham
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D58167
llvm-svn: 355323
The existing comment about over-allocating the command line was incorrect. The
contents of the command line may be changed, but it's not necessary to over
allocate. The changes will be limited to the existing contents of the string
(e.g., by replacing spaces with L'\0' to tokenize the command line).
Also added a comment explaining a possible cause of failure to save the next
programmer some time when they try to debug a 64-bit process from a 32-bit
LLDB.
llvm-svn: 355121
Given that we have a target named Symbols, one wonders why a
file named Symbols.cpp is not in this target. To be clear,
the functions exposed from this file are really focused on
*locating* a symbol file on a given host, which is where the
ambiguity comes in. However, it makes more sense conceptually
to be in the Symbols target. While some of the specific places
to search for symbol files might change depending on the Host,
this is not inherently true in the same way that, for example,
"accessing the file system" or "starting threads" is
fundamentally dependent on the Host.
PDBs, for example, recently became a reality on non-Windows platforms,
and it's theoretically possible that DSYMs could become a thing on non
MacOSX platforms (maybe in a remote debugging scenario). Other types of
symbol files, such as DWO, DWP, etc have never been tied to any Host
platform anyway.
After this patch, there is only one remaining dependency from
Host to Target.
Differential Revision: https://reviews.llvm.org/D58730
llvm-svn: 355032
Host had a function to get the UnixSignals instance corresponding
to the current host architecture. This means that Host had to
include a file from Target. To break this dependency, just make
this a static function directly in UnixSignals. We already have
the function UnixSignals::Create(ArchSpec) anyway, so we just
need to have UnixSignals::CreateForHost() which determines which
value to pass for the ArchSpec.
The goal here is to eventually break the Host->Target->Host
circular dependency.
Differential Revision: https://reviews.llvm.org/D57780
llvm-svn: 354168
Add missing EINTR handling for kevent() calls. If the call is
interrupted, return from Poll() as if zero events were returned and let
the polling resume on next iteration. This fixes test flakiness
on NetBSD.
Includes a test case suggested by Pavel Labath on D42206.
Differential Revision: https://reviews.llvm.org/D58230
llvm-svn: 354122
Remove the redundant termination clause from within the loop. Since
the check is done at the end of the loop, it's entirely redundant
to the 'while' condition. If termination was requested, the latter
will become false and the 'while' loop will terminate, resulting
in the 'return' statement below the loop being executed (which is
equivalent to the one used inside 'if').
Differential Revision: https://reviews.llvm.org/D58227
llvm-svn: 354050
Modify the kevent() error reporting to use errno rather than returning
the return value. At least on FreeBSD and NetBSD, kevent() always
returns -1 in case of error, and the actual error is returned via errno.
Differential Revision: https://reviews.llvm.org/D58229
llvm-svn: 354029
The `ap` suffix is a remnant of lldb's former use of auto pointers,
before they got deprecated. Although all their uses were replaced by
unique pointers, some variables still carried the suffix.
In r353795 I removed another auto_ptr remnant, namely redundant calls to
::get for unique_pointers. Jim justly noted that this is a good
opportunity to clean up the variable names as well.
I went over all the changes to ensure my find-and-replace didn't have
any undesired side-effects. I hope I didn't miss any, but if you end up
at this commit doing a git blame on a weirdly named variable, please
know that the change was unintentional.
llvm-svn: 353912
Unlike std::make_unique, which is only available since C++14,
std::make_shared is available since C++11. Not only is std::make_shared
a lot more readable compared to ::reset(new), it also performs a single
heap allocation for the object and control block.
Differential revision: https://reviews.llvm.org/D57990
llvm-svn: 353764
Fix MainLoop::RunImpl::get_sigmask() to correctly return empty sigset_t
when SIGNAL_POLLING_UNSUPPORTED is true. On NetBSD (and probably
on some other platforms), integers are not implicitly convertible to
sigset_t, so 'return 0' is erraneous. Instead, sigset_t should be reset
through sigemptyset().
While at it, move common parts out of the #ifdef.
Differential Revision: https://reviews.llvm.org/D57959
llvm-svn: 353675
Summary: Update the OpenBSD Host.cpp for the new SetFile() function signature. Fixes compiling lldb on OpenBSD.
Reviewers: krytarowski
Reviewed By: krytarowski
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D57907
llvm-svn: 353642
Summary:
This commit contains the following changes:
- Rewrite vfile close/read/write packet handlers with portable routines from lldb.
This removes #if(s) and allows the handlers to work on Windows.
- Fix a bug in File::Write. This is intended to write data at an offset to a file
but actually writes at the current position of the file.
- Add a default boolean argument 'should_close_fd' to FileSystem::Open to
let the user decide whether to close the fd or not.
Reviewers: zturner, llvm-commits, labath
Reviewed By: zturner
Subscribers: Hui, labath, abidh, lldb-commits
Differential Revision: https://reviews.llvm.org/D56231
llvm-svn: 353446
Summary:
These classes describe the details of the process we are about to
launch, and so they are naturally used by the launching code in the Host
module. Previously they were present in Target because that is the most
important (but by far not the only) user of the launching code.
Since the launching code has other customers, must of which do not care
about Targets, it makes sense to move these classes to the Host layer,
next to the launching code.
This move reduces the number of times that Target is included from host
to 8 (it used to be 14).
Reviewers: zturner, clayborg, jingham, davide, teemperor
Subscribers: emaste, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D56602
llvm-svn: 353047
This patch adds the file provider which is responsible for capturing
files used by LLDB.
When capturing a reproducer, we use a file collector that is very
similar to the one used in clang. For every file that we touch, we add
an entry with a mapping from its virtual to its real path. When we
decide to generate a reproducer we copy over the files and their
permission into to reproducer folder.
When replaying a reproducer, we load the VFS mapping and instantiate a
RedirectingFileSystem. The latter will transparently use the files
available in the reproducer.
I've tested this on two macOS machines with an artificial example.
Still, it is very likely that I missed some places where we (still) use
native file system calls. I'm hoping to flesh those out while testing
with more advanced examples. However, I will fix those things in
separate patches.
Differential revision: https://reviews.llvm.org/D54617
llvm-svn: 352538
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
Summary:
This adds unnamed pipe support in PipeWindows to support communication between a debug server and child process.
Modify PipeWindows::CreateNew to support the creation of an unnamed pipe.
Rename the previous method that created a named pipe to PipeWindows::CreateNewNamed.
Reviewers: zturner, llvm-commits
Reviewed By: zturner
Subscribers: Hui, labath, lldb-commits
Differential Revision: https://reviews.llvm.org/D56234
llvm-svn: 350784
There is already in use:
lit/lit-lldb-init:
settings set symbols.enable-external-lookup false
packages/Python/lldbsuite/test/lldbtest.py:
self.runCmd('settings set symbols.enable-external-lookup false')
But those are not in effect during MI part of the testsuite. Another problem is
that symbols.enable-external-lookup (read by GetEnableExternalLookup) has been
currently read only by LocateMacOSXFilesUsingDebugSymbols and therefore it had
no effect on Linux.
On Red Hat platforms (Fedoras, RHEL-7) there is DWZ in use and so
MiSyntaxTestCase-test_lldbmi_output_grammar FAILs due to:
AssertionError: error: inconsistent pattern ''^.+?\n'' for state 0x5f
(matched string: warning: (x86_64) /lib64/libstdc++.so.6 unsupported
DW_FORM values: 0x1f20 0x1f21
It is the only testcase with this error. It happens due to:
(lldb) target create "/lib64/libstdc++.so.6"
Current executable set to '/lib64/libstdc++.so.6' (x86_64).
(lldb) b main
warning: (x86_64) /lib64/libstdc++.so.6 unsupported DW_FORM values: 0x1f20 0x1f21
Breakpoint 1: no locations (pending).
WARNING: Unable to resolve breakpoint to any actual locations.
which happens only with gcc-base-debuginfo rpm installed (similarly for other packages).
It should also speed up the testsuite as it no longer needs to read
/usr/lib/debug symbols which have no effect (and should not have any effect) on
the testsuite results.
Differential Revision: https://reviews.llvm.org/D55859
llvm-svn: 350368
Using compare is verbose, bug prone and potentially inefficient (because
of early termination). Replace relevant call sites with the (in)equality
operator.
llvm-svn: 349972
Currently spawnLldbMi accepts both lldb-mi options and executable to debug as
a single parameter. Split them.
As in D55859 we will need to execute one lldb-mi command before loading the
exe. Therefore we can no longer use the exe as lldb-mi command-line parameter
as then there is no way to execute a command before loading exe specified as
lldb-mi command-line parameter.
LocateExecutableSymbolFileDsym should be static, that is also a little
refactorization.
Differential Revision: https://reviews.llvm.org/D55858
llvm-svn: 349607
This patch simplifies boolean expressions acorss LLDB. It was generated
using clang-tidy with the following command:
run-clang-tidy.py -checks='-*,readability-simplify-boolean-expr' -format -fix $PWD
Differential revision: https://reviews.llvm.org/D55584
llvm-svn: 349215
Summary: Instead use a more reasonable value to start and rely on the fact that SmallString will resize if necessary.
Reviewers: labath, asmith
Reviewed By: labath
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D55457
llvm-svn: 348775
This patch changes the way the reproducer is initialized. Rather than
making changes at run time we now do everything at initialization time.
To make this happen we had to introduce initializer options and their SB
variant. This allows us to tell the initializer that we're running in
reproducer capture/replay mode.
Because of this change we also had to alter our testing strategy. We
cannot reinitialize LLDB when using the dotest infrastructure. Instead
we use lit and invoke two instances of the driver.
Another consequence is that we can no longer enable capture or replay
through commands. This was bound to go away form the beginning, but I
had something in mind where you could enable/disable specific providers.
However this seems like it adds very little value right now so the
corresponding commands were removed.
Finally this change also means you now have to control this through the
driver, for which I replaced --reproducer with --capture and --replay to
differentiate between the two modes.
Differential revision: https://reviews.llvm.org/D55038
llvm-svn: 348152
When trying to fix the bots we expected that the cast would be needed in
different places. Ultimately it turned out only the
SymbolFileDWARFDebugMap was affected so, as Pavel correctly notes, it
makes more sense to do the cast just there instead of in teh FS.
llvm-svn: 347660
After a recent change in LLVM the TimePoint encoding become more
precise, exceeding the precision of the TimePoint obtained from the
DebugMap. This patch adds a flag to the GetModificationTime helper in
the FileSystem to return the modification time with less precision.
Thanks to Davide for bisecting this failure on the LLDB bots.
llvm-svn: 347615
This patch removes the comments grouping header includes. They were
added after running IWYU over the LLDB codebase. However they add little
value, are often outdates and burdensome to maintain.
llvm-svn: 346626
This patch removes the comments following the header includes. They were
added after running IWYU over the LLDB codebase. However they add little
value, are often outdates and burdensome to maintain.
Differential revision: https://reviews.llvm.org/D54385
llvm-svn: 346625
This moves construction of data buffers into the FileSystem class. Like
some of the previous refactorings we don't translate the path yet
because the functionality hasn't been landed in LLVM yet.
Differential revision: https://reviews.llvm.org/D54272
llvm-svn: 346598
The whole point of this change was making it possible to resolve paths
without depending on the FileSystem, which is not what I did here. Not
sure what I was thinking...
llvm-svn: 346466
In order to call real_path from the TildeExpressionResolver we need
access to the FileSystem. Since the resolver lives under utility we have
to pass in the FS.
llvm-svn: 346457
Replace calls to LLVM's is_directory with calls to LLDB's FileSytem
class. For this I introduced a new convenience method that, like the
other methods, takes either a path or filespec. This still uses the LLVM
functions under the hood.
Differential revision: https://reviews.llvm.org/D54135
llvm-svn: 346375
Summary:
A fairly simple operation as setting a breakpoint (writing a breakpoint
opcode) at a given address was going through three classes:
NativeProcessProtocol which called NativeBreakpointList, which then
called SoftwareBrekpoint, only to end up again in NativeProcessProtocol
to do the actual writing itself. This is unnecessarily complex and can
be simplified by moving all of the logic into NativeProcessProtocol
class itself, removing a lot of boilerplate.
One of the reeasons for this complexity was that (it seems)
NativeBreakpointList class was meant to hold both software and hardware
breakpoints. However, that never materialized, and hardware breakpoints
are stored in a separate map holding only hardware breakpoints.
Essentially, this patch makes software breakpoints follow that approach
by replacing the heavy SoftwareBraekpoint with a light struct of the
same name, which holds only the data necessary to describe one
breakpoint. The rest of the logic is in the main class. As, at the
lldb-server level, handling software and hardware breakpoints is very
different, this seems like a reasonable state of things.
Reviewers: krytarowski, zturner, clayborg
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D52941
llvm-svn: 346093
This patch modifies how we open File instances in LLDB. Rather than
passing a path or FileSpec to the constructor, we now go through the
virtual file system. This is needed in order to make things work with
the VFS in the future.
Differential revision: https://reviews.llvm.org/D54020
llvm-svn: 346049
This patch removes the static accessor in File to get a file's
permissions. Permissions should be checked through the FileSystem class.
llvm-svn: 345901
This patch removes the logic for resolving paths out of FileSpec and
updates call sites to rely on the FileSystem class instead.
Differential revision: https://reviews.llvm.org/D53915
llvm-svn: 345890
There were some calls left to Exists() on non-darwin platforms (Windows,
Linux and FreeBSD) that weren't yet updated to use the FileSystem.
llvm-svn: 345857
This patch removes the Exists method from FileSpec and updates its uses
with calls to the FileSystem.
Differential revision: https://reviews.llvm.org/D53845
llvm-svn: 345854
This patch removes the ResolveExecutableLocation method from FileSpec
and updates its uses with calls to the FileSystem.
Differential revision: https://reviews.llvm.org/D53834
llvm-svn: 345853
Speculative fix for the Xcode bots where we were seeing the assertion
being triggered because we would re-initialize the FileSystem without
terminating it.
llvm-svn: 345849
This patch removes the GetByteSize method from FileSpec and updates its
uses with calls to the FileSystem.
Differential revision: https://reviews.llvm.org/D53788
llvm-svn: 345812
The new implementation of EnumerateDirectory relies on `::no_push()`
being implemented for the VFS recursive directory iterators. However
this patch (D53465) hasn't been landed yet.
llvm-svn: 345787
This patch extends the FileSystem class with a bunch of functions that
are currently implemented as methods of the FileSpec class. These
methods will be removed in future commits and replaced by calls to the
file system.
The new functions are operated in terms of the virtual file system which
was recently moved from clang into LLVM so it could be reused in lldb.
Because the VFS is stateful, we turned the FileSystem class into a
singleton.
Differential revision: https://reviews.llvm.org/D53532
llvm-svn: 345783
Summary:
This patch makes Windows threads to compare by a thread ID, not by a handle.
It's because the same thread can have different handles on Windows
(for example, `GetCurrentThread` always returns the fake handle `-2`).
This leads to some incorrect behavior. For example, in `Process::GetRunLock`
always `m_public_run_lock` is returned without this patch.
Reviewers: zturner, clayborg, stella.stamenova
Reviewed By: stella.stamenova
Subscribers: stella.stamenova, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D53357
llvm-svn: 344729
in r344626 & recommitting. Original commit msg:
Simplify LocateDSYMInVincinityOfExecutable by moving
some redundant code into a separate function,
LookForDsymNextToExecutablePath, and having that function
also look for .dSYM.yaa files in addition to .dSYM
bundles.
Differential Revision: https://reviews.llvm.org/D53305
<rdar://problem/40406580>
llvm-svn: 344646
some redundant code into a separate function,
LookForDsymNextToExecutablePath, and having that function
also look for .dSYM.yaa files in addition to .dSYM
bundles.
Differential Revision: https://reviews.llvm.org/D53305
<rdar://problem/40406580>
llvm-svn: 344626
LC_BUILD_VERSION load command handling - this
commit is a combination of patches by Adrian
Prantl and myself. llvm::Triple::BridgeOS
isn't defined yet, so all references to that
are currently commented out.
Also update Xcode project file to build the
NativePDB etc plugins.
<rdar://problem/43353615>
llvm-svn: 344209
Summary:
This function existed (with identical code) in both NativeProcessLinux
and NativeProcessNetBSD, and it is likely that it would be useful to any
future implementation of NativeProcessProtocol.
Therefore I move it to the base class.
Reviewers: krytarowski
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D52719
llvm-svn: 343683
Summary:
This function encodes the knowledge of whether the PC points to the
breakpoint instruction of the one following it after the breakpoint is
"hit". This behavior mainly(*) depends on the architecture and not on the
OS, so it makes sense for it to be implemented in the base class, where
it can be shared between different implementations (Linux and NetBSD
atm).
(*) It is possible for an OS to expose a different API, perhaps by doing
some fixups in the kernel. In this case, the implementation can override
this function to implement custom behavior.
Reviewers: krytarowski, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D52532
llvm-svn: 343409
NativeProcessProtocol::ReadMemoryWithoutTrap had a bug, where it failed
to properly remove inserted breakpoint opcodes if the memory read
partially overlapped the trap opcode. This could not happen on x86
because it has a one-byte breakpoint instruction, but it could happen on
arm, which has a 4-byte breakpoint instruction (in arm mode).
Since triggerring this condition would only be possible on an arm
machine (and even then it would be a bit tricky). I test this using a
NativeProcessProtocol unit test.
llvm-svn: 343076
Summary:
This patch adds a framework for adding descriptions to the command completions we provide.
It also adds descriptions for completed top-level commands so that we can test this code.
Completions are in general supposed to be displayed alongside the completion itself. The descriptions
can be used to provide additional information about the completion to the user. Examples for descriptions
are function signatures when completing function calls in the expression command or the binary name
when providing completion for a symbol.
There is still some boilerplate code from the old completion API left in LLDB (mostly because the respective
APIs are reused for non-completion related purposes, so the CompletionRequest doesn't make sense to be
used), so that's why I still had to change some function signatures. Also, as the old API only passes around a
list of matches, and the descriptions are for these functions just another list, I had to add some code that
essentially just ensures that both lists are always the same side (e.g. all the manual calls to
`descriptions->AddString(X)` below a `matches->AddString(Y)` call).
The initial command descriptions that come with this patch are just reusing the existing
short help that is already added in LLDB.
An example completion with descriptions looks like this:
```
(lldb) pl
Available completions:
platform -- Commands to manage and create platforms.
plugin -- Commands for managing LLDB plugins.
```
Reviewers: #lldb, jingham
Reviewed By: #lldb, jingham
Subscribers: jingham, JDevlieghere, lldb-commits
Differential Revision: https://reviews.llvm.org/D51175
llvm-svn: 342181
The two existing implementations have the function implemented
identically, and there's no reason to believe that this would be
different for other implementations.
llvm-svn: 342167
Summary:
One of the conclusions of the discussion on D49740 was that SafeMachO is better
off in the Host module (as that's the only place which should include
mach/machine.h, which is what this header is working around). Also, Utility,
which is the only module which cannot include Host, should not be doing
anything with object file formats.
This patch implements that move, and also removes any unneded includes of that
file.
I've verified that MacOS still compiles after this.
Reviewers: jingham, zturner, teemperor
Subscribers: fedor.sergeev, lldb-commits
Differential Revision: https://reviews.llvm.org/D50383
llvm-svn: 342050
This recommits r341487, which was reverted due to failing tests with
clang. It turned out I had incorrectly expected that the literal arrays
passed to ArrayRef constructor will have static (permanent) storage.
This was only the case with gcc, while clang was constructing them on
stack, leading to dangling pointers when the function returns.
The fix is to explicitly assign static storage duration to the opcode
arrays.
llvm-svn: 341758
Summary:
Previously we SetUseColor(true) wrongly when output was not a terminal so it broken some (not public) bots.
Thanks for issue report, @stella.stamenova
Reviewers: stella.stamenova, zturner
Reviewed By: stella.stamenova
Subscribers: abidh, lldb-commits, stella.stamenova
Differential Revision: https://reviews.llvm.org/D51772
llvm-svn: 341746
return the opcode as a Expected<ArrayRef> instead of a
Status+pointer+size combo.
I also move the linux implementation to the base class, as the trap
opcodes are likely to be the same for all/most implementations of the
class (except the arm one, where linux chooses a different opcode than
what the arm spec recommends, which I keep linux-specific).
llvm-svn: 341487
Summary:
LLVM provide (str)errno helpers, so convert code to use it.
Also fixes warning:
/home/xbolva00/LLVM/llvm/tools/lldb/source/Host/common/PseudoTerminal.cpp:248:25: warning: ignoring return value of ‘char* strerror_r(int, char*, size_t)’, declared with attribute warn_unused_result [-Wunused-result]
::strerror_r(errno, error_str, error_len);
Reviewers: JDevlieghere
Reviewed By: JDevlieghere
Subscribers: abidh, lldb-commits
Differential Revision: https://reviews.llvm.org/D51591
llvm-svn: 341320
Summary:
This class was initially in Host because its implementation used to be
very OS-specific. However, with C++11, it has become a very simple
std::condition_variable wrapper, with no host-specific code.
It is also a general purpose utility class, so it makes sense for it to
live in a place where it can be used by everyone.
This has no effect on the layering right now, but it enables me to later
move the Listener+Broadcaster+Event combo to a lower layer, which is
important, as these are used in a lot of places (notably for launching a
process in Host code).
Reviewers: jingham, zturner, teemperor
Reviewed By: zturner
Subscribers: xiaobai, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D50384
llvm-svn: 341089
These three classes have no external dependencies, but they are used
from various low-level APIs. Moving them down to Utility improves
overall code layering (although it still does not break any particular
dependency completely).
The XCode project will need to be updated after this change.
Differential Revision: https://reviews.llvm.org/D49740
llvm-svn: 339127
Summary:
LLDB_PLUGINS doesn't exist as a variable, so this line doesn't add any dependencies and is
just confusing. It seems this slipped in from the gdb-remote CMake I was using as a CMake template.
The gdb-remote CMake itself is using a local LLDB_PLUGINS variable, so that code is fine.
Reviewers: davide
Reviewed By: davide
Subscribers: davide, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D49695
llvm-svn: 337741
Summary: Right now we always try to retrieve ComSpec and if we fail, we give up. This rarely fails, but we can update the logic so that we fail even less frequently. Since there is a well-known path (albeit not always correct), try the path when we failed to retrieve it. Note that on other platforms, we generally just return a well-known path without any checking.
Reviewers: asmith, zturner, labath
Reviewed By: zturner, labath
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D49451
llvm-svn: 337395
I've made the code accept only 16 byte UUIDs, which is technically not
NFC (previously it would also accept 20 byte ones, but use only the
first 16 bytes), but this should be more correct as mac UUIDs are always
16 byte long.
llvm-svn: 335247
Summary:
The only reason python was used in the Host module was to compute the
python path. I resolve this the same way as D47384 did for clang, by
moving the path computation into the python plugin and modifying
SBHostOS class to call into this module for ePathTypePythonDir.
Reviewers: zturner, jingham, davide
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D48215
llvm-svn: 335104
Summary:
Instead of a function taking an enum value determining which path to
return, we now have a suite of functions, each returning a single path
kind. This makes it easy to move the python-path function into a
specific plugin in a follow-up commit.
All the users of GetLLDBPath were converted to call specific functions
instead. Most of them were hard-coding the enum value anyway, so this
conversion was simple. The only exception was SBHostOS, which I've
changed to use a switch on the incoming enum value.
Reviewers: clayborg, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D48272
llvm-svn: 335052
I actually did check that macos builds before committing, but this error
was in conditionally compiled code that did not seem to be used on my
machine.
I also fix a typo in the previous speculative NetBSD patch.
llvm-svn: 334955
Lawrence D'Anna