| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 279057
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Before this, each function had a copy of the code which handled appending of the thread suffix to
the packet (or using $Hg instead). I have moved that code into a single function and made
everyone else use that. The function takes the partial packet as a StreamString rvalue reference,
to avoid a copy and to remind the users that the packet will have undeterminate contents after
the call.
This also fixes the incorrect formatting of the QRestoreRegisterState packet in case thread
suffix is not supported.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D23604
llvm-svn: 279040
|
|
|
|
|
|
|
|
| |
Part of TestGDBRemoteMemoryRead has been disabled since r259379 because it was incompatible with
python3. This changes the test to use the lldb-server test framework, which is a more appropriate
method of testing raw stub behaviour anyway (and should avoid the whole python 3 issue).
llvm-svn: 279039
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
CPlusPlusLanguage::MethodName was not correctly parsing templated functions whose demangled name
included the return type -- the space before the function name was included in the "context" and
the context itself was not terminated correctly due to a misuse of the substr function (second
argument is length, not the end position). Fix that and add a regression test.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D23608
llvm-svn: 279038
|
|
|
|
|
|
| |
Differential revision: https://reviews.llvm.org/D20386
llvm-svn: 278947
|
|
|
|
|
|
|
| |
Apparently clang will happily capture a const variable in a lambda without it being specified in
the capture clause. MSVC does not like that.
llvm-svn: 278925
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Cmake 2.8 support is gone and not coming back. We can remove a bit of legacy code now.
Reviewers: zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D23554
llvm-svn: 278924
|
|
|
|
| |
llvm-svn: 278918
|
|
|
|
|
|
| |
GDBRemoteRegisterContext::SetPrimordialRegister
llvm-svn: 278916
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
class
Summary:
When saving/restoring registers the GDBRemoteRegisterContext class was manually constructing
the register save/restore packets. This creates appropriate helper functions in
GDBRemoteCommunicationClient, and switches the class to use those. It also removes what a
duplicate packet send in some of those functions, a thing that I can only attribute to a bad
merge artefact.
I also add a test framework for testing gdb-remote client functionality and add tests for the new
functions I introduced. I'd like to be able to test the register context changes in isolation as
well, but currently there doesn't seem to be a way to reasonably construct a standalone register
context object, so we'll have to rely on the end-to-end tests to verify that.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D23553
llvm-svn: 278915
|
|
|
|
|
|
|
|
|
|
|
| |
back up the iterator, as long as it still contains the address.
std::lower_bound will point us to the entry after the one we
are really interested in, leading to problems with backtracing
in corefiles.
<rdar://problem/27823549>
llvm-svn: 278901
|
|
|
|
|
|
|
| |
Despite its comment, the function is only used in the Client class, and its presence was merely
complicating mock implementation in unit tests.
llvm-svn: 278785
|
|
|
|
|
|
|
| |
RenderScript was missing from the covered switch. Add it to avoid a warning of
the missing entry. NFC.
llvm-svn: 278774
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
referencing a user-defined operator new was triggering an assert in clang because we were
registering the function name as string "operator new", instead of using the special operator
enum, which clang has for this purpose. Method operators already had code to handle this, and now
I extend this to cover free standing operator functions as well. Test included.
Reviewers: spyffe
Subscribers: sivachandra, paulherman, lldb-commits
Differential Revision: http://reviews.llvm.org/D17856
llvm-svn: 278670
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The following problem was occuring:
- broadcaster B had two listeners: L1 and L2 (thread T1)
- (T1) B has started to broadcast an event, it has locked a shared_ptr to L1 (in
ListenerIterator())
- on another thread T2 the penultimate reference to L1 was destroyed (the transient object in B is
now the last reference)
- (T2) the last reference to L2 was destroyed as well
- (T1) B has finished broadcasting the event to L1 and destroyed the last shared_ptr
- (T1) this triggered the destructor, which called into B->RemoveListener()
- (T1) all pointers in the m_listeners list were now stale, so RemoveListener emptied the list
- (T1) Eventually control returned to the ListenerIterator() for doing broadcasting, which was
still in the middle of iterating through the list
- (T1) Only now, it was holding onto a dangling iterator. BOOM.
I fix this issue by making sure nothing can interfere with the
iterate-and-remove-expired-pointers loop, by moving this logic into a single function, which
first locks (or clears) the whole list and then returns the list of valid and locked Listeners
for further processing. Instead of std::list I use an llvm::SmallVector which should hopefully
offset the fact that we create a copy of the list for the common case where we have only a few
listeners (no heap allocations).
A slight difference in behaviour is that now RemoveListener does not remove an element from the
list -- it only sets it's mask to 0, which means it will be removed during the next iteration of
GetListeners(). This is purely an implementation detail and it should not be externally
noticable.
I was not able to reproduce this bug reliably without inserting sleep statements into the code,
so I do not add a test for it. Instead, I add some unit tests for the functions that I do modify.
Reviewers: clayborg, jingham
Subscribers: tberghammer, lldb-commits
Differential Revision: https://reviews.llvm.org/D23406
llvm-svn: 278664
|
|
|
|
|
|
|
|
| |
The commit started passing a nullptr port into GDBRemoteCommunication::StartDebugserverProcess.
The function was mostly handling the null value correctly, but it one case it did not check it's
value before assigning to it. Fix that.
llvm-svn: 278662
|
|
|
|
|
|
|
| |
It was being set to the fp reg set's byte order due to an apparent
copy-and-pasteo.
llvm-svn: 278625
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change r278527 was filtering out too many libraries.
The Xcode lldb-gtest target depends on linking libgtest*.a,
but those were not being included. This caused the lldb-gtest
linkage step to fail to find a main entry point that is present
in the filtered out libs.
This change restores the libgtest* libraries to the link list
by whitelisting them in the filter.
llvm-svn: 278552
|
|
|
|
|
|
| |
Test frequently times out stalling the test runner.
llvm-svn: 278529
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The Xcode macOS build of LLDB is currently broken after
https://reviews.llvm.org/D23232 landed, see
http://lab.llvm.org:8080/green/job/lldb_build_test/20014/console,
because we’re trying to link against all .a files found in the
llvm-build/lib directory. Let’s be more specific in what we link
against. This patch applies a regexp to only use “libclang.*”,
“libLLVM.*” and not “libclang_rt.*” static archives.
Change by Kuba Mracek (formerly Kuba Brecka)
See review here:
https://reviews.llvm.org/D23444
Reviewers: tfiala, compnerd
llvm-svn: 278527
|
|
|
|
| |
llvm-svn: 278526
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
are twice as fast as TCP sockets (on macOS at least).
This change opens a socket pair and passes the second socket pair file descriptor down to the debugserver binary using a new option: "--fd=N" where N is the file descriptor. This file descriptor gets passed via posix_spawn() so that there is no need to do any bind/listen or bind/accept calls and eliminates the hanshake unix socket that is used to pass the result of the actual port that ends up being used so it can save time on launch as well as being faster.
This is currently only enabled on __APPLE__ builds. Other OSs should try modifying the #define from ProcessGDBRemote.cpp but the first person will need to port the --fd option over to lldb-server. Any OSs that enable USE_SOCKETPAIR_FOR_LOCAL_CONNECTION in their native builds can use the socket pair stuff. The #define is Apple only right now, but looks like:
#if defined (__APPLE__)
#define USE_SOCKETPAIR_FOR_LOCAL_CONNECTION 1
#endif
<rdar://problem/27814880>
llvm-svn: 278524
|
|
|
|
|
|
|
|
|
| |
debuggerd is a crash reporting system on android what installs some
signal handler for SEGV to print a backtrace in the log. Its behavior
breaks tests where the test tries to continue after a SEGV so we skip
them as this behavior isn't required on android anyway.
llvm-svn: 278510
|
|
|
|
|
|
|
|
|
|
|
|
| |
FD_SETSIZE on windows limits the number of file descriptors, rather than their individual
magnitude (the underlying implementation uses an array rather than a bitset). This meant that the
assert in the SelectHelper was incorrect, and failing all the time. Fix that.
I am not sure whether this should be #ifdef MSVC, or #ifdef WINDOWS, but my feeling is that a
more posix-conforming implementation on windows would choose the bitset implementation, so I'm
sticking with the former.
llvm-svn: 278500
|
|
|
|
| |
llvm-svn: 278491
|
|
|
|
| |
llvm-svn: 278490
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Options used to store a reference to the CommandInterpreter instance
in the base Options class. This made it impossible to parse options
independent of a CommandInterpreter.
This change removes the reference from the base class. Instead, it
modifies the options-parsing-related methods to take an
ExecutionContext pointer, which the options may inspect if they need
to do so.
Closes https://reviews.llvm.org/D23416
Reviewers: clayborg, jingham
llvm-svn: 278440
|
|
|
|
| |
llvm-svn: 278373
|
|
|
|
|
|
|
|
|
| |
Factor out some common logic used to find the runtime library in a list
of modules.
Differential Revision: https://reviews.llvm.org/D23150
llvm-svn: 278368
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adapters for instrumentation runtimes have to do two basic things:
1) Load a runtime library.
2) Install breakpoints in that library.
This logic is duplicated in the adapters for asan and tsan. Factor it
out and document bits of it to make it easier to add new adapters.
I tested this with check-lldb, and double-checked
testcases/functionalities/{a,t}san.
Differential Revision: https://reviews.llvm.org/D23043
llvm-svn: 278367
|
|
|
|
|
|
| |
Python headers need to be included before PosixApi.h
llvm-svn: 278345
|
|
|
|
|
|
| |
This makes lldb still compile on linux after a project-wide clang-format
llvm-svn: 278335
|
|
|
|
|
|
|
|
| |
thumb instructions
Differential revision: https://reviews.llvm.org/D23395
llvm-svn: 278326
|
|
|
|
|
|
|
| |
I accidentaly added the send both to the base class and the derived class in my refactor. Fix
that.
llvm-svn: 278325
|
|
|
|
|
|
|
|
|
|
| |
work of
setting & deleting the breakpoints to watch for this.
<rdar://problem/27780214>
llvm-svn: 278305
|
|
|
|
|
|
|
|
| |
and sent up to LLDB and converted to StructuredData, it would not be able to parse the full 64 bit value. A number like 0xf000000000000000L could be placed into a dictionary, and sent to LLDB and it would end up being 0xffffffffffffffff since it would overflow a int64_t. We leave the old code there, but if it overflows, we treat the number like a uint64_t and get it to decode correctly. Added a gtest to cover this so we don't regress. I verified the gtest failed prior to the fix, and it succeeds after it.
<rdar://problem/27409265>
llvm-svn: 278304
|
|
|
|
|
|
| |
<rdar://problem/27652051>
llvm-svn: 278302
|
|
|
|
|
|
|
|
|
| |
of system specific optimizations to deal with more file descriptors than FD_SETSIZE on some systems.
<rdar://problem/25325383>
https://reviews.llvm.org/D22950
llvm-svn: 278299
|
|
|
|
|
|
|
| |
Tracked by:
rdar://27792848
llvm-svn: 278289
|
|
|
|
| |
llvm-svn: 278286
|
|
|
|
|
|
|
| |
lldb-private-interfaces.h included lldb-private.h, and
lldb-private.h included lldb-private-interfaces.h.
llvm-svn: 278253
|
|
|
|
|
|
| |
preparation for the big clang-format.
llvm-svn: 278222
|
|
|
|
| |
llvm-svn: 278197
|
|
|
|
|
|
|
| |
We don't take a dependency on LLVM in debugserver.
This was failing to compile before.
llvm-svn: 278190
|
|
|
|
| |
llvm-svn: 278188
|
|
|
|
|
|
|
|
| |
gettimeofday() isn't defined without a special header. Rather
than rely on C apis, let's just use modern C++11 to do this
portably on all platforms using std::chrono.
llvm-svn: 278182
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's always hard to remember when to include this file, and
when you do include it it's hard to remember what preprocessor
check it needs to be behind, and then you further have to remember
whether it's windows.h or win32.h which you need to include.
This patch changes the name to PosixApi.h, which is more appropriately
named, and makes it independent of any preprocessor setting.
There's still the issue of people not knowing when to include this,
because there's not a well-defined set of things it exposes other
than "whatever is missing on Windows", but at least this should
make it less painful to fix when problems arise.
This patch depends on LLVM revision r278170.
llvm-svn: 278177
|
|
|
|
|
|
| |
rdar://27732333 and rdar://27732377
llvm-svn: 278166
|
|
|
|
| |
llvm-svn: 278158
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D23070
llvm-svn: 278142
|