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
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
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
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
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
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
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
Resumbitting the commit after fixing the following problems:
- broken unit tests on windows: incorrect gtest usage on my part (TEST vs. TEST_F)
- the new code did not correctly handle the case where we went to interrupt the process, but it
stopped due to a different reason - the interrupt request would remain queued and would
interfere with the following "continue". I also added a unit test for this case.
This reapplies r277156 and r277139.
llvm-svn: 278118
also take the opportunity to replace NULL with nullptr and add clang-format guards to prevent it
from messing up the nice table there.
llvm-svn: 278005
It only contained a reimplementation of std::to_string, which I have replaced with usages of
pre-existing llvm::to_string (also, injecting members into the std namespace is evil).
llvm-svn: 278000
Also re-write how most of the directory indexing is done - as it has
grown over the years, it has become a bit of a mess and was overdue
for a cleanup.
Most importantly, this allows you to specify a directory with the
platform.plugin.darwin-kernel.kext-directories setting and now lldb
will search for kexts and kernels in those directories recursively.
<rdar://problem/20754467>
llvm-svn: 277789
This was a shadowed variable error from the big Expression Parser plugin-ification. I also
added a test case for this.
<rdar://problem/27682376>
llvm-svn: 277662
Due to internal reuse of buffers in the RenderScript runtime by the system allocator,
comparing pointers is not a safe way to check whether an allocation is tracked by lldb.
This change updates the lldb RenderScript internal hook callback to properly
identify and remove old allocations that had have an address that is currently
being tracked.
This change also removes the need for `lldb_private::renderscript::LookupAllocation`
to take a `create` flag, as this is now always the case.
Original Author: <dean@codeplay.com>
Subscribers: lldb-commits
llvm-svn: 277613
``num_params`` was unused in RenderScript ABI fixup pass ``cloneToStructRetFnTy``
and was only used in an `assert()` that the number of function parameters for the cloned
function was correct.
Now we actually use this variable, rather than recomputing it, and avoid the unused variable
warning when building without asserts enabled.
Subscribers: lldb-commits
llvm-svn: 277608
This introduces basic support for debugging OCaml binaries.
Use of the native compiler with DWARF emission support (see
https://github.com/ocaml/ocaml/pull/574) is required.
Available variables are considered as 64 bits unsigned integers,
their interpretation will be left to a OCaml-made debugging layer.
Differential revision: https://reviews.llvm.org/D22132
llvm-svn: 277443
frame to another was triggering an early stop when stepping back out to a
real frame. Check that we're doing this only for inlined frames.
<rdar://problem/26482931>
llvm-svn: 277185
This reverts commit r277139, because:
- broken unittest on windows (likely typo on my part)
- seems to break TestCallThatRestart (needs investigation)
llvm-svn: 277154
Summary:
There were places in the code, assuming(hardcoding) offsets
and types that were only valid for the x86_64 elf core file format.
The NT_PRSTATUS and NT_PRPSINFO structures are with the 64 bit layout.
I have reused them and parse i386 files manually, and fill them in the
same struct.
Also added some error handling during parsing that checks if the
available bytes in the buffer are enough to fill the structures.
The i386 core file test case now passes.
For reference on the structures layout, I generally used the
source of binutils (bfd, readelf)
Bug: https://llvm.org/bugs/show_bug.cgi?id=26947
Reviewers: labath
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D22917
llvm-svn: 277140
