In 0e9b0b6d11 I introduced the
HistoryOperation enum to navigate the history. While this fixed the
behavior of HistoryOperation::Older and HistoryOperation::Newer, it
confused the mapping for HistoryOperation::Oldest and
HistoryOperation::Newest.
I tried to write a PExpect test to make sure this doesn't regress, but
I'm unable to prime the history in such a way that it recalls a known
element. I suspect this is an LLDB bug, but the most recent entry
doesn't get update with entries from the current session. I considered
spoofing the home directory but that needs to happen before libLLDB is
loaded and you'll need to account for the widechar support. If anyone
has another suggestion I'd love to hear it.
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.
Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp -------------------------------------------------===//
```
However in LLDB most of our source files have arbitrary changes to this format and
these changes are spreading through LLDB as folks usually just use the existing
source files as templates for their new files (most notably the unnecessary
editor language indicator `-*- C++ -*-` is spreading and in every review
someone is pointing out that this is wrong, resulting in people pointing out that this
is done in the same way in other files).
This patch removes most of these inconsistencies including the editor language indicators,
all the different missing/additional '-' characters, files that center the file name, missing
trailing `===//` (mostly caused by clang-format breaking the line).
Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73258
The VFS mapping writer assumes that all the paths it gets are files.
When passed a directory, it ends up as a file in the VFS mapping twice,
once as a file and once as a directory.
{
'type': 'file',
'name': "Output",
'external-contents': "/root/path/to/Output"
},
{
'type': 'directory',
'name': "Output",
'contents': [ ... ]
}
Summary: There are a few places in LLDB where we do a `reinterpret_cast` for conversions that we could also do with `static_cast`. This patch moves all this code to `static_cast`.
Reviewers: shafik, JDevlieghere, labath
Reviewed By: labath
Subscribers: arphaman, usaxena95, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D72161
This constructor is supposed to take a string representing an llvm::Triple.
We might as well take a llvm::Triple here which saves us all the string
conversions in the call sites and we make this more type safe.
echo -e '#include <unistd.h>\nint main(void){\nsync();return 0;}'|./bin/clang -g -x c -;./bin/lldb -o 'file ./a.out' -o 'b main' -o r -o 'p (void)sync()'
Actual:
error: Expression can't be run, because there is no JIT compiled function
Expected:
<nothing, sync() has been executed>
This patch has been checked by:
D71707: clang-tidy: new bugprone-pointer-cast-widening
https://reviews.llvm.org/D71707
Casting from 32-bit `void *` to `uint64_t` requires an intermediate `uintptr_t` cast otherwise the pointer gets sign-extended:
echo -e '#include <stdio.h>\n#include <stdint.h>\nint main(void){void *p=(void *)0x80000000;unsigned long long ull=(unsigned long long)p;unsigned long long ull2=(unsigned long
long)(uintptr_t)p;printf("p=%p ull=0x%llx ull2=0x%llx\\n",p,ull,ull2);return 0;}'|gcc -Wall -m32 -x c -;./a.out
<stdin>: In function ‘main’:
<stdin>:3:66: warning: cast from pointer to integer of different size [-Wpointer-to-int-cast]
p=0x80000000 ull=0xffffffff80000000 ull2=0x80000000
With debug output:
Actual:
IRMemoryMap::WriteMemory (0xb6ff8640, 0xffffffffb6f82158, 0x112) went to [0xb6ff8640..0xb6ff86b3)
Code can be run in the target.
Found function, has local address 0xffffffffb6f84000 and remote address 0xffffffffffffffff
Couldn't disassemble function : Couldn't find code range for function _Z12$__lldb_exprPv
Sections:
[0xb6f84000+0x3c]->0xb6ff9020 (alignment 4, section ID 0, name .text)
...
HandleCommand, command did not succeed
error: Expression can't be run, because there is no JIT compiled function
Expected:
IRMemoryMap::WriteMemory (0xb6ff8640, 0xb6faa15c, 0x128) went to [0xb6ff8640..0xb6ff86c3)
IRExecutionUnit::GetRemoteAddressForLocal() found 0xb6fac000 in [0xb6fac000..0xb6fac040], and returned 0xb6ff9020 from [0xb6ff9020..0xb6ff9060].
Code can be run in the target.
Found function, has local address 0xb6fac000 and remote address 0xb6ff9020
Function's code range is [0xb6ff9020+0x40]
...
Function data has contents:
0xb6ff9020: 10 4c 2d e9 08 b0 8d e2 08 d0 4d e2 00 40 a0 e1
...
Function disassembly:
0xb6ff9020: 0xe92d4c10 push {r4, r10, r11, lr}
Differential revision: https://reviews.llvm.org/D71498
Summary:
HostInfo's state isn't actually fully rested after calling ::Terminate. Currently we only reset the
values of all the `HostInfoBaseFields` but not all the variables with static storage that
keep track of whether the fields need to be initialised. This breaks random unit tests as running
them twice (or running multiple test instances in one run) will cause that the second time
we ask HostInfo for any information we get the default value back for any field.
This patch moves all the once_flag's into the `HostInfoBaseFields` so that they also get reseted
by ::Terminate and removes all the `success` bools. We should also rewrite half this code but
I would prefer if my tests aren't broken over the holidays so let's just put some duct tape on it
for now.
Reviewers: labath
Reviewed By: labath
Subscribers: abidh, JDevlieghere, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D71748
This renames LLDB_CONFIG_TERMIOS_SUPPORTED to LLDB_ENABLE_TERMIOS. It
now also uses cmakedefine01 to keep things consistent with out other
optional dependencies. But more importantly it won't silently fail when
you forget to include Config.h.
The naming used by editline for the history operations is counter
intuitive to how it's used in lldb for the REPL.
- The H_PREV operation returns the previous element in the history,
which is newer than the current one.
- The H_NEXT operation returns the next element in the history, which
is older than the current one.
This exposed itself as a bug in the REPL where the behavior of up- and
down-arrow was inverted. This wasn't immediately obvious because of how
we save the current "live" entry.
This patch fixes the bug and introduces and enum to wrap the editline
operations that match the semantics of lldb.
Differential revision: https://reviews.llvm.org/D70932
This feature is mostly there to aid debugging of Clang module issues,
since the only useful actual the end-user can to is to recompile their
program.
Differential Revision: https://reviews.llvm.org/D70272
Summary:
This adds several 5C/5D escape codes that allow moving forward/backward words similar to bash command line navigation.
On my terminal, `ctrl+v ctrl+<left arrow>` prints `^[[1;5D`. However, it seems inputrc also maps other escape variants of this to forward/backward word, so I've included those too. Similar for 5C = ctrl+right arrow.
Reviewers: JDevlieghere, labath
Reviewed By: JDevlieghere, labath
Subscribers: merge_guards_bot, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D70137
This warning triggers when a class defines a copy constructor but not a
copy-assignment operator (which then gets auto-generated by the
compiler). Fix the warning by deleting the other operator too, as the
default implementation works just fine.
Summary:
Here's another instance where we were calling fflush on an input
stream, which is illegal on NetBSD.
Reviewers: labath, mgorny
Reviewed By: mgorny
Subscribers: krytarowski, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D69488
Summary:
This makes SBFile::GetFile public and adds a SWIG typemap to convert
the result back into a python native file.
If the underlying File itself came from a python file, it is returned
identically. Otherwise a new python file object is created using
the file descriptor.
Reviewers: JDevlieghere, jasonmolenda, labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68737
llvm-svn: 374911
Summary:
This patch re-types everywhere that passes a File::OpenOptions
as a uint32_t so it actually uses File::OpenOptions.
It also converts some OpenOptions related functions that fail
by returning 0 or NULL into llvm::Expected
split off from https://reviews.llvm.org/D68737
Reviewers: JDevlieghere, jasonmolenda, labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68853
llvm-svn: 374817
The "b" (binary) flag is meaningless most of the time, but the relevant
standars allow it. The standards permit one to spell it both as "r+b"
and "rb+", so handle both cases.
This fixes TestFileHandle.test_binary_inout with python2.
llvm-svn: 374331
Summary:
If the .symtab section is stripped from the binary it might be that
there's a .gnu_debugdata section which contains a smaller .symtab in
order to provide enough information to create a backtrace with function
names or to set and hit a breakpoint on a function name.
This change looks for a .gnu_debugdata section in the ELF object file.
The .gnu_debugdata section contains a xz-compressed ELF file with a
.symtab section inside. Symbols from that compressed .symtab section
are merged with the main object file's .dynsym symbols (if any).
In addition we always load the .dynsym even if there's a .symtab
section.
For example, the Fedora and RHEL operating systems strip their binaries
but keep a .gnu_debugdata section. While gdb already can read this
section, LLDB until this patch couldn't. To test this patch on a
Fedora or RHEL operating system, try to set a breakpoint on the "help"
symbol in the "zip" binary. Before this patch, only GDB can set this
breakpoint; now LLDB also can do so without installing extra debug
symbols:
lldb /usr/bin/zip -b -o "b help" -o "r" -o "bt" -- -h
The above line runs LLDB in batch mode and on the "/usr/bin/zip -h"
target:
(lldb) target create "/usr/bin/zip"
Current executable set to '/usr/bin/zip' (x86_64).
(lldb) settings set -- target.run-args "-h"
Before the program starts, we set a breakpoint on the "help" symbol:
(lldb) b help
Breakpoint 1: where = zip`help, address = 0x00000000004093b0
Once the program is run and has hit the breakpoint we ask for a
backtrace:
(lldb) r
Process 10073 stopped
* thread #1, name = 'zip', stop reason = breakpoint 1.1
frame #0: 0x00000000004093b0 zip`help
zip`help:
-> 0x4093b0 <+0>: pushq %r12
0x4093b2 <+2>: movq 0x2af5f(%rip), %rsi ; + 4056
0x4093b9 <+9>: movl $0x1, %edi
0x4093be <+14>: xorl %eax, %eax
Process 10073 launched: '/usr/bin/zip' (x86_64)
(lldb) bt
* thread #1, name = 'zip', stop reason = breakpoint 1.1
* frame #0: 0x00000000004093b0 zip`help
frame #1: 0x0000000000403970 zip`main + 3248
frame #2: 0x00007ffff7d8bf33 libc.so.6`__libc_start_main + 243
frame #3: 0x0000000000408cee zip`_start + 46
In order to support the .gnu_debugdata section, one has to have LZMA
development headers installed. The CMake section, that controls this
part looks for the LZMA headers and enables .gnu_debugdata support by
default if they are found; otherwise or if explicitly requested, the
minidebuginfo support is disabled.
GDB supports the "mini debuginfo" section .gnu_debugdata since v7.6
(2013).
Reviewers: espindola, labath, jankratochvil, alexshap
Reviewed By: labath
Subscribers: rnkovacs, wuzish, shafik, emaste, mgorny, arichardson, hiraditya, MaskRay, lldb-commits
Tags: #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D66791
llvm-svn: 373891
Summary:
This patch factors out File as an abstract base
class and moves most of its actual functionality into
a subclass called NativeFile. In the next patch,
I'm going to be adding subclasses of File that
don't necessarily have any connection to actual OS files,
so they will not inherit from NativeFile.
This patch was split out as a prerequisite for
https://reviews.llvm.org/D68188
Reviewers: JDevlieghere, jasonmolenda, labath
Reviewed By: labath
Subscribers: lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D68317
llvm-svn: 373564
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
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
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
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
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
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
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:
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
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
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 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
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
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
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:
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
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
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
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:
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
SetFile has an optional style argument which defaulted to the native
style. This patch makes that argument mandatory so clients of the
FileSpec class are forced to think about the correct syntax.
At the same time this introduces a (protected) convenience method to
update the file from within the FileSpec class that keeps the current
style.
These two changes together prevent a potential pitfall where the style
might be forgotten, leading to the path being updated and the style
unintentionally being changed to the host style.
llvm-svn: 334663
Summary:
This patch adds a modulemap which allows compiling the lldb headers into C++ modules
(for example in builds with LLVM_ENABLE_MODULES=On).
Even though most of the affected code has been cleaned up to work with the more strict
C++ module semantics, there are still some workarounds left in the current modulemap
(the most obvious one is the big `lldb` wrapper module).
It also moves the Obj-C++ files in lldb to their own subdirectories. This was necessary
because we need to filter out the modules flags for this code.
Note: With the latest clang and libstdc++ it seems necessary to have a STL C++ module
to get a working LLVM_ENABLE_MODULES build for lldb. Otherwise clang will falsely
detect ODR violations in the textually included STL code inside the lldb modules.
Reviewers: aprantl, bruno
Reviewed By: aprantl, bruno
Subscribers: mgorny, yamaguchi, v.g.vassilev, lldb-commits
Differential Revision: https://reviews.llvm.org/D47929
llvm-svn: 334611
Host depended on clang because HostInfo had a function to get
the directory where clang was installed. We move this over to
the clang expression parser plugin where it's more at home.
Differential Revision: https://reviews.llvm.org/D47384
llvm-svn: 333933
The first fix wasn't enough, there is still a missing
ProcessInstanceInfo include in Host.mm. I won't be able to test a fix
before leaving work, so I am reverting both commits.
This reverts commit r332250 and the subsequent fix attempt.
llvm-svn: 332261
The Process class was only being referenced because of the last-ditch
effort in the process launchers to set a process death callback in case
one isn't set already.
Although launching a process for debugging is the most important kind of
"launch" we are doing, it is by far not the only one, so assuming this
particular callback is the one to be used is not a good idea (besides
breaking layering). Instead of assuming a particular exit callback, I
change the launcher code to require the callback to be set by the user (and fix
up the two call sites which did not set the callback already).
Reviewers: jingham, davide
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D46395
llvm-svn: 332250
Summary:
The comments on this class were out of date with the implementation, and
the implementation itself was inconsistent with our usage of the Timeout
class (I started converting everything to use this class back in D27136,
but I missed this one). I avoid duplicating the waiting logic by
introducing a templated WaitFor function, and make other functions
delegate to that. This function can be also used as a replacement for
the unused WaitForBitToBeSet functions I removed, if it turns out to be
necessary.
As this changes the meaning of a "zero" timeout, I tracked down all the
callers of these functions and updated them accordingly. Propagating the
changes to all the callers of RunShellCommand was a bit too much for
this patch, so I stopped there and will continue that in a follow-up
patch.
I also add some basic unittests for the functions I modified.
Reviewers: jingham, clayborg
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D46580
llvm-svn: 331880
The function can only return in one of two ways: the Predicate value is
successfully set within the allotted time, or it isn't (the wait times
out). These states can be represented in the return value, and the extra
arg adds no value.
llvm-svn: 331458
This is intended as a clean up after the big clang-format commit
(r280751), which unfortunately resulted in many of the comment
paragraphs in LLDB being very hard to read.
FYI, the script I used was:
import textwrap
import commands
import os
import sys
import re
tmp = "%s.tmp"%sys.argv[1]
out = open(tmp, "w+")
with open(sys.argv[1], "r") as f:
header = ""
text = ""
comment = re.compile(r'^( *//) ([^ ].*)$')
special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$')
for line in f:
match = comment.match(line)
if match and not special.match(match.group(2)):
# skip intentionally short comments.
if not text and len(match.group(2)) < 40:
out.write(line)
continue
if text:
text += " " + match.group(2)
else:
header = match.group(1)
text = match.group(2)
continue
if text:
filled = textwrap.wrap(text, width=(78-len(header)),
break_long_words=False)
for l in filled:
out.write(header+" "+l+'\n')
text = ""
out.write(line)
os.rename(tmp, sys.argv[1])
Differential Revision: https://reviews.llvm.org/D46144
llvm-svn: 331197
LLVM_ON_WIN32 is set exactly with MSVC and MinGW (but not Cygwin) in
HandleLLVMOptions.cmake, which is where _WIN32 defined too. Just use the
default macro instead of a reinvented one.
See thread "Replacing LLVM_ON_WIN32 with just _WIN32" on llvm-dev and cfe-dev.
No intended behavior change.
llvm-svn: 329697
These functions were unused as everyone just went straight for the
direct operations on the register context. In fact, the
Save/RestoreAllRegisters actually appear to be wrong (inverted). Thanks
to Tatyana for pointing this out.
These functions are not very useful now that we can guarantee that each
thread always contains a valid register context, so I just delete them.
llvm-svn: 328770
The difference between this and the previous patch is that now we use
ELF physical addresses only for loading objects into the target (and the
rest of the module load address logic still uses virtual addresses).
Summary:
When writing an object file over gdb-remote, use the vFlashErase, vFlashWrite, and vFlashDone commands if the write address is in a flash memory region. A bare metal target may have this kind of setup.
- Update ObjectFileELF to set load addresses using physical addresses. A typical case may be a data section with a physical address in ROM and a virtual address in RAM, which should be loaded to the ROM address.
- Add support for querying the target's qXfer:memory-map, which contains information about flash memory regions, leveraging MemoryRegionInfo data structures with minor modifications
- Update ProcessGDBRemote to use vFlash commands in DoWriteMemory when the target address is in a flash region
Original discussion at http://lists.llvm.org/pipermail/lldb-dev/2018-January/013093.html
Reviewers: clayborg, labath
Reviewed By: labath
Subscribers: llvm-commits, arichardson, emaste, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D42145
Patch by Owen Shaw <llvm@owenpshaw.net>.
llvm-svn: 327970
This reverts commit r326261 as it introduces inconsistencies in the
handling of load addresses for ObjectFileELF -- some parts of the class
use physical addresses, and some use virtual. This has manifested itself
as us not being able to set the load address of the vdso "module" on
android.
llvm-svn: 326367
Summary:
When writing an object file over gdb-remote, use the vFlashErase, vFlashWrite, and vFlashDone commands if the write address is in a flash memory region. A bare metal target may have this kind of setup.
- Update ObjectFileELF to set load addresses using physical addresses. A typical case may be a data section with a physical address in ROM and a virtual address in RAM, which should be loaded to the ROM address.
- Add support for querying the target's qXfer:memory-map, which contains information about flash memory regions, leveraging MemoryRegionInfo data structures with minor modifications
- Update ProcessGDBRemote to use vFlash commands in DoWriteMemory when the target address is in a flash region
Original discussion at http://lists.llvm.org/pipermail/lldb-dev/2018-January/013093.html
Reviewers: clayborg, labath
Reviewed By: labath
Subscribers: arichardson, emaste, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D42145
Patch by Owen Shaw <llvm@owenpshaw.net>
llvm-svn: 326261
Summary:
The PowerPC64 ABI plugin was modified to:
- properly handle vector type return values
- implement support for struct/class return values
A refactoring in the code that handles return values was also performed, to make it possible to handle structs without repeating (when possible) code that handles its fields.
There was also an issue with CreateInstance(), that only created an instance in the first time it was called and then cached it in a static var. When restarting a process under LLDB's control, the ABI's process weak pointer would become null, and using it would result in a segmentation fault. This issue became more evident after the latest changes to PPC64 plugin, that now uses the process pointer to get the target byte order, making LLDB to seg fault when restarting a program. This was fixed by making CreateInstance() to always create a new ABI instance.
All of LLDB's ReturnValue tests are passing for PPC64le now. It should work for PPC64be too, although this was not tested.
Reviewers: labath, clayborg
Reviewed By: labath
Subscribers: lbianc, anajuliapc, llvm-commits, alexandreyy, nemanjai, kbarton
Differential Revision: https://reviews.llvm.org/D42468
Patch by Leandro Lupori <leandro.lupori@gmail.com>.
llvm-svn: 325324
I have found LLDB cannot find separate debug info of Fedora /usr/bin/gdb.
It is because:
lrwxrwxrwx 1 root root 14 Jan 25 20:41 /usr/bin/gdb -> ../libexec/gdb*
-rwxr-xr-x 1 root root 10180296 Jan 25 20:41 /usr/libexec/gdb*
ls: cannot access '/usr/lib/debug/usr/bin/gdb-8.0.1-35.fc27.x86_64.debug': No such file or directory
-r--r--r-- 1 root root 29200464 Jan 25 20:41 /usr/lib/debug/usr/libexec/gdb-8.0.1-35.fc27.x86_64.debug
FYI that -8.0.1-35.fc27.x86_64.debug may look confusing, it was always just
.debug before.
Why is /usr/bin/gdb a symlink is offtopic for this bugreport, Fedora has it so
for some reasons.
It is always safest to look at the .debug file only after resolving all
symlinks on the binary file.
Differential revision: https://reviews.llvm.org/D42853
llvm-svn: 324224
I have found the lookup by build-id
(when lookup by /usr/lib/debug/path/name/exec.debug failed) does not work as
LLDB tries the build-id hex string in uppercase but Fedora uses lowercase.
xubuntu-16.10 also uses lowercase during my test:
/usr/lib/debug/.build-id/6c/61f3566329f43d03f812ae7057e9e7391b5ff6.debug
Differential revision: https://reviews.llvm.org/D42852
llvm-svn: 324222
Summary:
The ObjectFile class was used to determine the architecture of a running
process by inspecting it's main executable. There were two issues with
this:
- it's in the wrong layer
- the call can be very expensive (it can end up computing the crc of the
whole file).
Since the process is running on the host, ideally we would be able to
just query the data straight from the OS like darwin does, but there
doesn't seem to be a reasonable way to do that. So, this fixes the
layering issue by using the llvm object library to inspect the file.
Since we know the process is already running on the host, we just need
to peek at a few bytes of the elf header to determine whether it's 32-
or 64-bit (which should make this faster as well).
Pretty much the same logic was implemented in
NativeProcessProtocol::ResolveProcessArchitecture, so I delete this
logic and replace calls with GetProcessInfo.
Reviewers: eugene, krytarowski
Subscribers: mgorny, hintonda, lldb-commits
Differential Revision: https://reviews.llvm.org/D42488
llvm-svn: 323637
Summary:
These were used by Host::LaunchProcess to "resolve" the executable it
was about to launch. The only parts of Platform::ResolveExecutable, which
seem to be relevant here are the FileSpec::ResolvePath and
ResolveExecutableLocation calls.
The rest (most) of that function deals with selecting an architecture
out of a fat binary and making sure we are able to create a Module with that
slice. These are reasonable actions when selecting a binary to debug,
but not for a generic process launching framework (it's technically even
wrong because we should be able to launch a binary with execute
permissions only, but trying to parse such file will obviously fail).
I remove the platform call by inlining the relevant FileSpec calls and
ignoring the rest of the Platform::ResolveExecutable code. The
architecture found by the slice-searching code is being ignored already
anyway, as we use the one specified in the LaunchInfo, so the only
effect of this should be a different error message in case the
executable does not contain the requested architecture -- before we
would get an error message from the Platform class, but now we will get
an error from the actual posix_spawn syscall (this is only relevant on
mac, as it's the only target supporting fat binaries).
Launching targets for debugging should not be affected as here the
executable is pre-resolved at the point when the Target is created.
Reviewers: jingham, clayborg
Subscribers: lldb-commits, emaste
Differential Revision: https://reviews.llvm.org/D41902
llvm-svn: 322935
The comment seems to indicate that this function would return the "bin"
directory on linux. I've verified that this is not the case, so I'm
updating the comment to match.
llvm-svn: 322472
Summary:
For ptys (at least on Linux), the end-of-file (closing of the slave FD)
is signalled by the POLLHUP flag. We were ignoring this flag, which
meant that when this happened, we would spin in a loop, continuously
calling poll(2) and not making any progress.
This makes sure we treat POLLHUP as a read event (reading will return
0), and we call the registered callback when it happens. This is the
behavior our clients expect (and is consistent with how select(2)
works).
Reviewers: eugene, beanz
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D41008
llvm-svn: 320345
1. Move TaskPool into the namespace lldb_private.
2. Add missing std::move in TaskPoolImpl::Worker.
3. std:🧵:hardware_concurrency may return 0,
handle this case correctly.
Differential revision: https://reviews.llvm.org/D40587
Test plan: make check-all
llvm-svn: 319492
The rationale here is that ArchSpec is used throughout the codebase,
including in places which should not depend on the rest of the code in
the Core module.
This commit touches many files, but most of it is just renaming of
#include lines. In a couple of cases, I removed the #include ArchSpec
line altogether, as the file was not using it. In one or two places,
this necessitated adding other #includes like lldb-private-defines.h.
llvm-svn: 318048
Summary:
In D39387, I was quick to jump to conclusion that ArchSpec has no
external dependencies. It turns there still was one call to
HostInfo::GetArchitecture left -- for implementing the "systemArch32"
architecture and friends.
Since GetAugmentedArchSpec is the place we handle these "incomplete"
triples that don't specify os or vendor and "systemArch" looks very much
like an incomplete triple, I move its handling there.
After this ArchSpec *really* does not have external dependencies, and
I'll move it to the Utility module as a follow-up.
Reviewers: zturner, clayborg, jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D39896
llvm-svn: 318046
Summary:
This commit removes the concrete_frame_idx member from
NativeRegisterContext and related functions, which was always set to
zero and never used.
I also change the native thread class to store a NativeRegisterContext
as a unique_ptr (documenting the ownership) and make sure it is always
initialized (most of the code was already blindly dereferencing the
register context pointer, assuming it would always be present -- this
makes its treatment consistent).
Reviewers: eugene, clayborg, krytarowski
Subscribers: aemerson, sdardis, nemanjai, javed.absar, arichardson, kristof.beyls, kbarton, uweigand, alexandreyy, lldb-commits
Differential Revision: https://reviews.llvm.org/D39837
llvm-svn: 317881
Summary:
These functions used to return bool to signify whether they were able to
retrieve the data. This is redundant because the ArchSpec and ByteOrder
already have their own "invalid" states, *and* because both of the
current implementations (linux, netbsd) can always provide a valid
result.
This allows us to simplify bits of the code handling these values.
Reviewers: eugene, krytarowski
Subscribers: javed.absar, lldb-commits
Differential Revision: https://reviews.llvm.org/D39733
llvm-svn: 317779
SetOututFileHandle to work with IOBase.
I did make one change after checking with Larry --
I renamed SBDebugger::Flush to FlushDebuggerOutputHandles
and added a short docstring to the .i file to make it
a little clearer under which context programs may need
to use this API.
Differential Revision: https://reviews.llvm.org/D39128
<rdar://problem/34870417>
llvm-svn: 317182
SetOututFileHandle to work with IOBase.
I did make one change after checking with Larry --
I renamed SBDebugger::Flush to FlushDebuggerOutputHandles
and added a short docstring to the .i file to make it
a little clearer under which context programs may need
to use this API.
Differential Revision: https://reviews.llvm.org/D38829
llvm-svn: 317180
Summary:
ArchSpec::SetTriple was taking a Platform as an argument, and used it to
fill in missing pieces of the specified triple. I invert the dependency
by moving this code to other classes. For this purpose, I've created
three new functions.
- HostInfo::GetAugmentedArchSpec: fills in the triple using the host
platform (this used to be implemented by passing a null platform
pointer). By putting this code in the Host module, we can provide a
way to anyone who does not have a platform instance (lldb-server) an
easy way to get Host data.
- Platform::GetAugmentedArchSpec: if you have a platform instance, you
can call this to let it fill in the triple.
- static Platform::GetAugmentedArchSpec: implements the "if platform ==
0 then use_host() else use_platform()" part.
Reviewers: zturner, jingham, clayborg
Subscribers: mgorny, javed.absar, lldb-commits
Differential Revision: https://reviews.llvm.org/D39387
llvm-svn: 316987
Versions of android before kitkat implemented pselect non-atomically,
which caused flakyness, as we were relying on it atomically setting the
signal mask to implement waiting for signals.
This patch implements a direct call to the the pselect kernel syscall,
which does not suffer from this problem. The code itself is not very
pretty, but fortunately the uglyness is contained in the
android version of the MainLoop::RunImpl::Poll function.
llvm-svn: 316915
Jonas Devlieghere