This was originall reverted due to some test failures in
ModuleCache and TestCompDirSymlink. These issues have all
been resolved and the code now passes all tests.
Differential Revision: https://reviews.llvm.org/D30698
llvm-svn: 297300
If QPassSignals packaet is supported by lldb-server, lldb-client will
utilize it and ask the server to ignore signals that don't require stops
or notifications.
Such signals will be immediately re-injected into inferior to continue
normal execution.
Differential Revision: https://reviews.llvm.org/D30520
llvm-svn: 297231
this reverts r297116 because it breaks the unittests and
TestCompDirSymlink. The ModuleCache unit test is trivially fixable, but
the CompDirSymlink failure is a symptom of a deeper problem: llvm's stat
functionality is not a drop-in replacement for lldb's. The former is
based on stat(2) (which does symlink resolution), while the latter is
based on lstat(2) (which does not).
This also reverts subsequent build fixes (r297128, r297120, 297117) and
r297119 (Remove FileSpec dependency on FileSystem) which builds on top
of this.
llvm-svn: 297139
This deletes LLDB's FileType enumeration and replaces all
users, and all calls to functions that check whether a file
exists etc with corresponding calls to LLVM.
Differential Revision: https://reviews.llvm.org/D30624
llvm-svn: 297116
This functionality is subsumed by DataBufferLLVM, which is
also more efficient since it will try to mmap. However, we
don't yet support mmaping writable private sections, and in
some cases we were using ReadFileContents and then modifying
the buffer. To address that I've added a flag to the
DataBufferLLVM methods that allow you to map privately, which
disables the mmaping path entirely. Eventually we should teach
DataBufferLLVM to use mmap with writable private, but that is
orthogonal to this effort.
Differential Revision: https://reviews.llvm.org/D30622
llvm-svn: 297095
it was accessing the details of the Log class directly. Let it go
through the channel class instead.
This also discovered a bug when we were setting but not clearing the log
options when enabling a channel.
llvm-svn: 297053
In an effort to move the various DataBuffer / DataExtractor
classes from Core -> Utility, we have to separate the low-level
functionality from the higher level functionality. Only a
few functions required anything other than reading/writing
raw bytes, so those functions are separated out into a
more appropriate area. Specifically, Dump() and DumpHexBytes()
are moved into free functions in Core/DumpDataExtractor.cpp,
and GetGNUEHPointer is moved into a static function in the
only file that it's referenced from.
Differential Revision: https://reviews.llvm.org/D30560
llvm-svn: 296910
All references to Host and Core have been removed, so this
class can now safely be lowered into Utility.
Differential Revision: https://reviews.llvm.org/D30559
llvm-svn: 296909
Summary:
It does not change members or call non-const members.
HostInfo::GetArchitecture() returns a const object ref (maybe others?),
which can't access the non-const function.
Reviewers: labath, eugene
Reviewed By: labath, eugene
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D30515
Author: Jason Majors <jmajors@google.com>
llvm-svn: 296868
This in turn triggered some fallout where other files had
been transitively picking up includes that they needed from
FileSpec.h, so I've fixed those up as well.
llvm-svn: 296855
MSVC (at least the version I am using) does not want to implicitly
capture a const bool variable. Move it into the lambda, as it is not
used outside anyway.
llvm-svn: 296738
Summary:
Use StringRef and ArrayRef where possible. This adds an accessor to the
Args class to get a view of the arguments as ArrayRef<const char *>.
Reviewers: zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D30402
llvm-svn: 296592
Summary:
These two register contexts were identical, so this shouldn't cause any
regressions, but I'd appreciate it if you can check that this at least compiles.
Reviewers: emaste, sas
Subscribers: aemerson, rengolin, lldb-commits, mgorny
Differential Revision: https://reviews.llvm.org/D27126
llvm-svn: 296335
The channel refactor introduced a regression where we were not honoring
the log options passed when enabling the channel. Fix that and add a
test.
llvm-svn: 296329
Summary:
There is nothing we can do with the breakpoint once the associated
target becomes deleted. This will make sure we don't hold on to more
resources than we need in this case. In particular, this fixes the case
TestStepOverBreakpoint on windows, where a lingering SBBreakpoint object
causes us to nor unmap the executable file from memory.
Reviewers: clayborg, jingham
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D30249
llvm-svn: 296328
match but the 'is_regex' argument was not passed as true. Not sure
this is causing a bug, but noticed it while working on another bug.
These formatters gained a regex in r274489 for NDK but didn't pick
up the is_regex flag at the time.
<rdar://problem/30646077>
llvm-svn: 296243
After a series of patches on the LLVM side to get the mmaping
code up to compatibility with LLDB's needs, it is now ready
to go, which means LLDB's custom mmapping code is redundant.
So this patch deletes it all and uses LLVM's code instead.
In the future, we could take this one step further and delete
even the lldb DataBuffer base class and rely entirely on
LLVM's facilities, but this is a job for another day.
Differential Revision: https://reviews.llvm.org/D30054
llvm-svn: 296159
Summary: QPassSignals package allows lldb client to tell lldb-server to ignore certain types of signals and re-inject them back to inferior without stopping execution.
Reviewers: jmajors, labath
Subscribers: danalbert, srhines, emaste, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D30286
Author: Eugene Zemtsov <ezemtsov@google.com>
llvm-svn: 296101
acquired only after checking if the ivar shared pointer was already
filled in. But when I assign an UnwindPlan object to the shared
pointer, I assign an empty object and then fill it in. That leaves
a window where another thread could get the shared pointer to the
empty (but quickly being-filled-in) object and lead to a crash.
Also two changes from Greg for correctness on the TestMultipleDebuggers
test case.
<rdar://problem/30564102>
llvm-svn: 296084
Summary:
NetBSD 7.99.62 introduced Debug Registers interface similar to the FreeBSD one.
This interface will land NetBSD-8.0.
Introduce support for this interface in Register Context NetBSD x86_64 unconditionally as older versions of NetBSD will not be supported.
This change allows to reduce diff with other ports and remove local copy of the RegisterInfos_x86_64.h content.
NetBSD Register Context for 32-bit x86 support will be added later.
Sponsored by <The NetBSD Foundation>
Reviewers: labath, joerg, emaste, clayborg
Reviewed By: labath, clayborg
Subscribers: #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D30287
llvm-svn: 296071
Summary:
NetBSD 8.0 will ship with accept4(2) in libc wrapping paccept(2).
This change reduces needless difference with other platforms.
Older versions of NetBSD will not be supported.
No functional change.
Sponsored by <The NetBSD Foundation>
Reviewers: joerg, emaste, labath, clayborg
Reviewed By: emaste, labath, clayborg
Subscribers: #lldb
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D30288
llvm-svn: 296070
Summary:
This also removes magic rename code, which caused the channel to be
called "linux" when built on a linux machine, and "freebsd" when built
on a freebsd one, which seems unnecessary - registering a new channel is
sufficiently simple now that if we wish to log something extremely
os-specific, we can just create a new channel. None of the current
categories seem very specific to one OS or another.
Reviewers: emaste, krytarowski
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D30250
llvm-svn: 295954
Summary:
When lldb-server is started with the -P <port> or -m/-M <min/max port> options to specify which ports are available for remote connections the child debug server is told what port it should listen on. In those cases lldb-server needs to wait for the child to report it’s port number as otherwise it can tell the lldb client that the child is up and listening before it is actually listening on that port. lldb-server already waits in the cases where a port wasn’t specified by waiting until the child reports the port it is using. It was skipping this synchronisation step when passed a port numbers as it knew what the port would be however it does need to ensure the child process has had time to open that port and waiting until the child reports the port number makes sure this has happened.
This patch just removes the one case where a child was spawned and lldb-server did not wait for it to report it’s port number before telling the client lldb process the child is ready to connect to.
This issue was discussed on lldb-dev in a thread here:
http://lists.llvm.org/pipermail/lldb-dev/2017-February/012002.html
Reviewers: clayborg
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D30255
llvm-svn: 295947
- Allow zero byte size request for memory and ensure it gets a unique address
- Exit the free block loop when we find an appropriate free block
<rdar://problem/30644888>
llvm-svn: 295907
