this is a resubmission of r280476. The problem with the original commit was that it was printing
out all numbers as signed, which was wrong for unsigned numbers with the MSB set. Fix that and
add a unit test covering that case.
llvm-svn: 280480
This reverts commit r280476 as it breaks several tests on i386. I was fixing an 32-bit
breakage, and I did not run the 32-bit test suite before submitting, oops.
llvm-svn: 280478
Summary:
It seems the original intention of the function was printing signed values in decimal format, and
unsigned values in hex (without the leading "0x"). However, signed and unsigned long were
exchanged, which lead to amusing test failures in TestMemoryFind.py.
Instead of just switching the two, I think we should just print everything in decimal here, as
the current behaviour is very confusing (especially when one does not request printing of types).
Nothing seems to depend on this behaviour except and we already have a way for the user to
request the format he wants when printing values for most commands (which presumably does not go
through this function).
I also add a unit tests for the function in question.
Reviewers: clayborg, granata.enrico
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D24126
llvm-svn: 280476
Summary:
This is a Minidump parsing code.
There are still some more structures/data streams that need to be added.
The aim ot this is to be used in the implementation of
a minidump debugging plugin that works on all platforms/architectures.
Currently we have a windows-only plugin that uses the WinAPI to parse
the dump files.
Also added unittests for the current functionality.
Reviewers: labath, amccarth
Subscribers: tberghammer, danalbert, srhines, lldb-commits, dschuff
Differential Revision: https://reviews.llvm.org/D23545
llvm-svn: 280356
the test fails for a very prosaic reason: `(const char *)0x1000` returns "4096" on x86_64 and
"1000" (without the "0x") on i386. I haven't tried other 32-bit arches, but I am guessing the
behaviour is the same. XFAIL until someone can get a chance to look at this.
llvm-svn: 280344
Summary:
The vdso is full of hand-written assembly which the instruction emulator has a hard time
understanding. Luckily, the kernel already provides us with correct unwind info for them. So
let's use it.
This fixes (at least) the AssertingInferiorTestCase.test_inferior_asserting_disassemble test on
android N i386.
Reviewers: tberghammer
Subscribers: tberghammer, danalbert, lldb-commits
Differential Revision: https://reviews.llvm.org/D24079
llvm-svn: 280264
Summary:
- copies the new file in the cmake build
- adds an additional import statement
- marks the test as no-debug-info specific, as it seems to be testing a python feature
Reviewers: granata.enrico
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D24074
llvm-svn: 280261
The rewrite of StringExtractor::GetHexMaxU32 changes functionality in a way which makes
lldb-server crash. The crash (assert) happens when parsing the "qRegisterInfo0" packet, because
the function tries to drop_front more bytes than the packet contains. It's not clear to me
whether we should consider this a bug in the caller or the callee, but it any case, it worked
before, so I am reverting this until we can figure out what the proper interface should be.
llvm-svn: 280207
Summary:
e80f43fd78
greatly improved an API, but missed one more occurence of legacy usage.
This leads to:
if (extractor.GetHexBytes(&payload_bytes[0], payload_bytes.size(), '\xdd') != payload_bytes.size())
~~~~~~~~~~~~~~~~~~~~~ ^~~~~~
/lldb/include/lldb/Utility/StringExtractor.h:151:5: note: 'GetHexBytes' declared here
Reviewers: zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D24064
Author: Taras Tsugrii <ttsugrii@fb.com>
llvm-svn: 280202
This class enables one to easily write a synthetic child provider by writing a class that returns pairs of names and primitive Python values - the base class then converts those into LLDB SBValues
Comes with a test case
llvm-svn: 280172
Makes Peek() return a StringRef instead of a const char*.
This leads to a few callers of Peek() being able to be made a
little nicer (for example using StringRef member functions instead
of c-style strncmp and related functions) and generally safer
usage.
llvm-svn: 280139
LLDB was rolling its own endian conversion code, but functions to
do this already exist in LLVM. While the code was probably
correct, no point reinventing the wheel when we have well tested
equivalents in LLVM that are one-liners.
llvm-svn: 280137
This is a NFC that adds more unit test coverage of the GetHex***
functions as well as the functions to extract numbers with a
specific endianness.
llvm-svn: 280124
MutableArrayRef<T> is essentially a safer version of passing around
(T*, length) pairs and provides some convenient functions for working
with the data without having to manually manipulate indices.
This is a minor NFC.
llvm-svn: 280123
autoconf+make have been removed from LLVM and LLDB ~6month ago. We
shouldn't advertise it on the website as a valid way to build LLDB.
Differential revision: https://reviews.llvm.org/D24025
llvm-svn: 280102
StringExtractor::GetNameColonValue() looks for a substring of the
form "<name>:<value>" and returns <name> and <value> to the caller.
This results in two unnecessary string copies, since the name and
value are not translated in any way and simply returned as-is.
By converting this to return StringRefs we can get rid of hundreds
of string copies.
llvm-svn: 280000
I have some improvements to make to StringExtractor that require
using LLVM. debugserver can't take a dependency on LLVM but uses
this file, so I'm forking it off into StdStringExtractor and
StringExtractor, so that StringExtractor can take advantage of
some performance improvements and readability improvements that
LLVM can provide.
llvm-svn: 279997
std::atomic<uint64_t> requires 64-bit alignment in order to
guarantee atomicity. Normally the compiler is pretty good about
aligning types, but an exception to this is when the type is
passed by value as a function parameter. In this case, if your
stack is 4-byte aligned, most modern compilers (including clang
as of LLVM 4.0) fail to align the type, rendering the atomicity
ineffective.
A deeper investigation of the class's implementation suggests
that the use of atomic was in vain anyway, because if the class
were to be shared amongst multiple threads, there were already
other data races present, and that the proper way to ensure
thread-safe access to this data would be to use a mutex from a
higher level.
Since the std::atomic was not serving its intended purpose anyway,
and since the presence of it generates compiler errors on some
platforms that cannot be workaround, we remove std::atomic from
Address here. Although unlikely, if data races do resurface
the proper fix should involve a mutex from a higher level, or an
attempt to limit the Address's access to a single thread.
llvm-svn: 279994
These are helpful on their own, but will be even more useful
once the GetNameColonValue is updated to return StringRefs
instead of std::strings.
llvm-svn: 279919
This started as an effort to change StringExtractor to store a
StringRef internally instead of a std::string. I got that working
locally with just 1 test failure which I was unable to figure out the
cause of. But it was also a massive changelist due to a trickle
down effect of changes.
So I'm starting over, using what I learned from the first time to
tackle smaller, more isolated changes hopefully leading up to
a full conversion by the end.
At first the changes (such as in this CL) will seem mostly
a matter of preference and pointless otherwise. However, there
are some places in my larger CL where using StringRef turned 20+
lines of code into 2, drastically simplifying logic. Hopefully
once these go in they will illustrate some of the benefits of
thinking in terms of StringRef.
llvm-svn: 279917
easier to scan a set of options with a relatively large number of positional
arguments. This commit standardizes their formatting throughout LLDB and
applies surrounding directives to exempt them from being formatted by
clang-format.
These kinds of exemptions should be rare cases that benefit significantly
from alternative formatting. They also imply a long-term obligation to
maintain their format since the automated tools will not do so.
llvm-svn: 279882
Reports an error instead. We can fix this later to make persistent variables
work, but right now we hit an LLVM assertion if we get this wrong.
<rdar://problem/27770298>
llvm-svn: 279850
Summary:
Oleksiy is no longer active in LLDB, I'd like to formally assume ownership of the linux and
android parts.
Reviewers: ovyalov, clayborg
Subscribers: tberghammer, danalbert, lldb-commits
Differential Revision: https://reviews.llvm.org/D23877
llvm-svn: 279812
Summary:
Previously the builting demangler was on for platforms that explicitly set a flag by modifying
Mangled.cpp (windows, freebsd). The Xcode build always used builtin demangler by passing a
compiler flag. This adds a cmake flag (defaulting to ON) to configure the demangling library used
at build time. The flag is only available on non-windows platforms as there the system demangler
is not present (in the form we're trying to use it, at least).
The impact of this change is:
- linux: switches to the builtin demangler
- freebsd, windows: NFC (I hope)
- netbsd: switches to the builtin demangler
- osx cmake build: switches to the builtin demangler (matching the XCode build)
The main motivation for this is the cross-platform case, where it should bring more consistency
by removing the dependency on the host demangler (which can be completely unrelated to the debug
target).
Reviewers: zturner, emaste, krytarowski
Subscribers: emaste, clayborg, lldb-commits
Differential Revision: https://reviews.llvm.org/D23830
llvm-svn: 279808
Clang on ARM64 was making the three Function methods with identical bodies have
one implementation that was shared. That threw off the count of breakpoints, since
we don't count as separate locations three functions with the same address.
I also cleaned up the test case while I was at it.
<rdar://problem/27001915>
llvm-svn: 279800
Summary:
This is a preparatory commit for D22914, where I'd like to replace this mutex by an R/W lock
(which is also not recursive). This required a couple of changes:
- The only caller of Read/WriteRegister, GDBRemoteRegisterContext class, was already acquiring
the mutex, so these functions do not need to. All functions which now do not take a lock, take
an lock argument instead, to remind the caller of this fact.
- GetThreadSuffixSupported() was being called from locked and unlocked contexts (including
contexts where the process was running, and the call would fail if it did not have the result
cached). I have split this into two functions, one which computes the thread suffix support and
caches it (this one always takes the lock), and another, which returns the cached value (and
never needs to take the lock). This feels quite natural as ProcessGdbRemote was already
pre-caching this value at the start.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D23802
llvm-svn: 279725
Summary:
Moving a temporary object prevents copy elision, which is exactly
what clang points out by warning about this pattern.
The fix is simply removal of std::move applied to temporary objects.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D23825
Author: Taras Tsugrii <ttsugrii@fb.com>
llvm-svn: 279724
and we couldn't find a dyld binary on the debug system, override
that setting and read dyld out of memory - we need to put an
internal breakpoint on dyld to register binaries being loaded or
unloaded; the debugger won't work right without dyld symbols.
<rdar://problem/27857025>
llvm-svn: 279704
PlatformRemoteAppleWatch, PlatformRemoteAppleTV and remove the
GetFileInSDKRoot method from those classes.
The rewrite uses the more modern FileSpec etc API to simplify,
and handles the case where an SDK Root is given to lldb with
the "/Symbols" directory name already appended. The new version
will try appending "/Symbols" and "/Symbols.Internal" to the
sdk root directories, and will also try appending nothing to
the sdk root directory in case it's handed such an sdkroot.
<rdar://problem/28000054>
llvm-svn: 279688
The newer event-based tests I added neglected to do the
macOS 10.12 check in the setup. This caused earlier macOS
test suite runs to attempt to compile code that doesn't exist.
llvm-svn: 279672
When, for instance, "step-in" steps into a function that it doesn't want
to stop in (e.g. has no debug info) it will push a step-out plan to implement
the step out so it can then continue stepping. These step out's don't use
the result of the function stepped out of, so they shouldn't spend the time
to compute it.
llvm-svn: 279540
The test was attempting to backtrace a process after every state change event (including the
"running", and "restarted" ones), which is not a good idea.
llvm-svn: 279512
The lldb-gtest target is for CI and runs the tests as
part of the build phase. It does not support debugging
the gtests from Xcode, though, due to the run happening
during the build phase.
This change adds a lldb-gtest-for-debugging target that
can be used to debug gtests.
llvm-svn: 279354
This is useful because that knowledge will in turn allow no-code-running formatting of boolean NSNumbers; but that's a commit that will have to wait Monday..
llvm-svn: 279353
This test was using a condition that would compare a variable against the register that would hold
it. It was failing with clang on arm64 because clang put the variable on the stack.
This is not a supportable way to write tests.
llvm-svn: 279345
expression evaluation.
OrcMCJITReplacement is a reimplementation of MCJIT using ORC components, and
provides an easy upgrade path to ORC for existing MCJIT clients. There should be
no functional changes resulting from this switch.
llvm-svn: 279327
This reverts commit r279296. Including LLDBDependencies breaks the
netbsd lldb bot because it exposes LLDB_USED_LIBS, which causes
lldb_link_common_libs to run to completion in unintended sites, which
results in a malformed call to target_link_libraries.
http://lab.llvm.org:8011/builders/lldb-amd64-ninja-netbsd7/builds/5989
Thanks to Chris Bieneman for figuring this out!
llvm-svn: 279322
It's pulling in all kinds of things it doesn't need (e.g, clang-tidy!).
Eliminating this dependency removes 1056 dependencies from the
'CommandObjectFrame.cpp.o' target and 454 dependencies from the 'lldb'
target. On my machine, this shaves 7 minutes off of a clean build of
lldb.
Thanks to Zachary Turner for pointing out some issues with an earlier
version of this patch!
Differential Revision: https://reviews.llvm.org/D22987
llvm-svn: 279296
Summary:
The tricky part here was that the exisiting implementation of WriteAllRegisters was expecting
hex-encoded data (as that was what the first implementation I replaced was using, but here we had
binary data to begin with. I thought the read/write register functions would be more useful if
they handled the hex-encoding themselves (all the other client functions provide the responses in
a more-or-less digested form). The read functions return a DataBuffer, so they can allocate as
much memory as they need to, while the write functions functions take an llvm::ArrayRef, as that
can be constructed from pretty much anything.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D23659
llvm-svn: 279232
This change adds the Process/gdb-remote gtests to the Xcode
build. It also adds a virtual method impl to the continuation
delegate that I added with the StructuredDataPlugin change.
llvm-svn: 279203
Take 2, with missing cmake line fixed. Build tested on
Ubuntu 14.04 with clang-3.6.
See docs/structured_data/StructuredDataPlugins.md for details.
differential review: https://reviews.llvm.org/D22976
reviewers: clayborg, jingham
llvm-svn: 279202
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
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
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
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
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
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
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
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
This removes references to PT_XXX macros from the file, as they were not used anyway. It also
changes the macro used to check for the definition of __ptrace_request, as there are other C
libraries which do not define this type.
llvm-svn: 278001
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 commit is causing problems on gcc-* compiler with version number sufix.
Requires a new solution will post a follow up patch.
Differential revision: https://reviews.llvm.org/D20386
llvm-svn: 277453
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 undoes my last commit. It collided with Pavel undoing
his change that my previous commit was adjusting for in the
Xcode file.
This reverts commit f6f29cb7d7c56f96f21d9c115ecc66d652639df3.
llvm-svn: 277157
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
SendContinuePacketAndWaitForResponse was huge function with very complex interactions with
several other functions (SendAsyncSignal, SendInterrupt, SendPacket). This meant that making any
changes to how packet sending functions and threads interact was very difficult and error-prone.
This change does not add any functionality yet, it merely paves the way for future changes. In a
follow-up, I plan to add the ability to have multiple query packets in flight (i.e.,
request,request,response,response instead of the usual request,response sequences) and use that
to speed up qModuleInfo packet processing.
Here, I introduce two special kinds of locks: ContinueLock, which is used by the continue thread,
and Lock, which is used by everyone else. ContinueLock (atomically) sends a continue packet, and
blocks any other async threads from accessing the connection. Other threads create an instance of
the Lock object when they want to access the connection. This object, while in scope prevents the
continue from being send. Optionally, it can also interrupt the process to gain access to the
connection for async processing.
Most of the syncrhonization logic is encapsulated within these two classes. Some of it still
had to bleed over into the SendContinuePacketAndWaitForResponse, but the function is still much
more manageable than before -- partly because of most of the work is done in the ContinueLock
class, and partly because I have factored out a lot of the packet processing code separate
functions (this also makes the functionality more easily testable). Most importantly, there is
none of syncrhonization code in the async thread users -- as far as they are concerned, they just
need to declare a Lock object, and they are good to go (SendPacketAndWaitForResponse is now a
very thin wrapper around the NoLock version of the function, whereas previously it had over 100
lines of synchronization code). This will make my follow up changes there easy.
I have written a number of unit tests for the new code and I have ran the test suite on linux and
osx with no regressions.
Subscribers: tberghammer
Differential Revision: https://reviews.llvm.org/D22629
llvm-svn: 277139
The commit accidentally switched a timed wait on a condition variable into an infinite timeout.
Change that back. Android tests were timeing out without this.
llvm-svn: 277133
Summary:
- Modified code that enables writing new user-defined commands
and use them through LLDB CLI. Modifications are:
-- Define the 'syntax' for each user-defined command
--- Added an argument in SBCommandInterpreter::AddCommand()
and SBCommand::AddCommand() API
--- Allow passing syntax for each user-defined command
--- Earlier, only 'help' could be defined and passed for commands
-- Passed 'number of arguments' entered on CLI for user-defined commands
--- Added an argument (number of options) in SBCommandPluginInterface::DoExecute()
API to know the number of arguments passed for commands
-- In CommandPluginInterfaceImplementation class:
--- Make the data member m_backend a shared_ptr
--- Avoids memory leaks of dynamically allocated SBCommandPluginInterface instances
created in lldb::PluginInitialize() API
Signed-off-by: Abhishek Aggarwal <abhishek.a.aggarwal@intel.com>
Reviewers: jingham, granata.enrico, clayborg
Subscribers: labath, lldb-commits
Differential Revision: https://reviews.llvm.org/D22863
llvm-svn: 277125
that it finds on the local computer in "well known" locations
when we start up the darwin-kernel platform. It did not
distinguish between kexts/kernels with dSYMs from others -
when it needed a kernel/kext with a given UUID, it would grab
the first one it finds.
This change separates these into two vectors -- a collection
of kexts and kernels with dSYMs next t othem, and a collection
of kexts and kernels without dSYMs. When we have a bundle ID
and uuid to search for, we first try the collections with
dSYMs, and if that fails, then we try the collections that
did not have dSYMs next to them.
Often times we'll have a situation where a kext will be
installed in multiple locations on a system, but only one
of them will have a dSYM next to it, where the dev just copied
it to a local directory. This fixes that problem, giving
precedence to those binaries with debug information.
llvm-svn: 277123
Summary:
When trying to parse the -break-insert arguments as a named location, the string parsing was not configured to allow directory paths. This patch adds a constructor to allow the parsing of string as directory path along with the other parameters.
This fixes https://llvm.org/bugs/show_bug.cgi?id=28709
Patch from malaperle@gmail.com
Reviewers: clayborg, ki.stfu
Subscribers: lldb-commits, ki.stfu
Differential Revision: https://reviews.llvm.org/D22902
llvm-svn: 277117
cache from ObjectFileMachO (very wrong place) to the DynamicLoader
plugins (better place). Not much change to the code itself, although
the old ObjectFileMachO method would try both the new dyld SPI and
reading the dyld_all_image_infos structure. In the new methods,
I've separated those into the appropriate DynamicLoader plugins.
llvm-svn: 277088
Greg added in r272276 -- when working with a non-user-process mach-o
core file, force the permissions to readable + executable, else the
unwinder can stop backtracing early if it gets a pc value in a segment
that it thinks is non-executable.
<rdar://problem/27138456>
<rdar://problem/27462904>
llvm-svn: 277065
Summary:
This is supposed to find the python lib dir and seems like it's just
been copied twice by mistake.
Reviewers: tfiala
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D22891
llvm-svn: 277060
Clean up format string warnings in ValueObjectSyntheticFilter.cpp to explictly cast "%p" params to void *`
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D22923
llvm-svn: 277016
std::condition::wait_for takes a std::unique_lock<T>. The previous commit
accidentally left a reference to `m_mutex` instead of `lock`. Update that.
Should restore the android lldb builder to green.
llvm-svn: 277013
This finally removes the use of the Mutex and Condition classes. This is an
intricate patch as the Mutex and Condition classes were tied together.
Furthermore, many places had slightly differing uses of time values. Convert
timeout values to relative everywhere to permit the use of
std::chrono::duration, which is required for the use of
std::condition_variable's timeout. Adjust all Condition and related Mutex
classes over to std::{,recursive_}mutex and std::condition_variable.
This change primarily comes at the cost of breaking the TracingMutex which was
based around the Mutex class. It would be possible to write a wrapper to
provide similar functionality, but that is beyond the scope of this change.
llvm-svn: 277011
Expression evaluation for function calls to certain public RenderScript
API functions in libRSCPURef can segfault.
`slang`,
the compiler frontend for RenderScript embeds an ARM specific triple in
IR that is shipped in the app, after generating IR that has some
assumptions that an ARM device is the target.
As the IR is then compiled on a device of unknown (at time the IR was
generated at least) architecture, when calling RenderScript API function
as part of debugger expressions, we have to perform a fixup pass that
removes those assumptions right before the module is sent to be
generated by the llvm backend.
This issue is caused by multiple problems with the ARMv7-specific
assumptions encoded in the LLVM IR. x86 large value returns use a hidden
first argument (mapping to llvm::Attribute::StructRet), which can't be
picked up by the JIT due to the mismatch between IR generated by the
slang frontend and llvm backend. This means that code generated by bcc
did not necessarily match the default SysV Linux/Android ABI used by the
LLDB JIT
- Original Authors: Luke Drummond (@ldrumm), Function declarations fixed by Aidan Dodds (@ADodds)
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D18059
llvm-svn: 276976
We were just checking the public state, but that meant if you were hung in a long
running hand-called function, we wouldn't know to interrupt the process, and we would
not succeed in killing it.
<rdar://problem/24805082>
llvm-svn: 276795
The Green Dragon builder for macOS started failing yesterday with
session filenames that were too long. This change modifies the
Xcode target that runs the test suite and specifies a shorter
session filename format.
rdar://27539818
llvm-svn: 276760
Summary:
We were checking whether an attribute is in block form by getting the block data pointer, which
was not correct as the pointer be null even if the attribute is in block form. Other places in
the file already use the correct test.
To make this work, I've needed to add DW_FORM_exprlock to the list of "block" forms, which seems
correct as that is how we are parsing it.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D22756
llvm-svn: 276735
Summary:
The function was returning the null pointer for peeks of size zero, which seems like a sensible
thing to do, but is actually pretty easy to get bitten by that if you are extracting a variable
length field which happens to be of zero length and then doing pointer arithmetic on that (which
SymbolFileDWARF does, and ended up crashing in case of empty DW_AT_location).
This changes the function to return a null pointer only when it gets queried for data which is
outside of the range of the extractor, which is more c++-y, as one can still do reasonable things
with pointers to data of size zero (think, end() iterators).
I also add a test and fix some signedness warnings in the existing data extractor tests.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D22755
llvm-svn: 276734
that may be embedded in the Contents/Resources subdir of a dSYM
bundle. These allow for the specification of a build-time path
to debug-time path remapping for source files. Files may be built
in /BuildDirectory/sources/project-100 but when the debugger is
run, they're actually found via ~sources/project-100 - this plist
allows for that remapping through the DBGBuildSourcePath and
DBGSourcePath keys.
This patch adds support for a new DBGSourcePathRemapping
dictionary in the plist where the keys are the build-time paths
and the values are the debug-time paths that they should be
remapped to. There are instances were we have multiple possible
build-time paths that need to be included, so the dictionary was
required.
<rdar://problem/26725174>
llvm-svn: 276729
This change breaks up the monolithic TestConcurrentEvents.py into a
separate subdir per test method. This allows them to run concurrently,
reduces the chance of a timeout occurring during normal operation, and
allows us to home in on any test methods that may be locking up.
This is step one in the process of squashing timeouts in these test
methods.
The reason for breaking each test method into its own file is to make it
very clear to us if there are a subset of the tests that do in fact lock
up frequently. This will limit how much hunting we need to do to
recreate it.
The reason for putting each file in a separate subdirectory is so that
our concurrent test runner can run multiple test files at the same time.
The unit of serialization in the LLDB test suite is the test directory,
so moving them into separate directories enables the test runner to do
more at the same time.
This change introduces usage of VPATH from gnu make. I use that to
facilitate keeping a single copy of the main.cpp in the parent
concurrent_events directory. Initially I had tried specifying the source
file as ../main.cpp, but our current makefile rules get confused by that
and then also build the output into the parent directory, which defeats
the ability to run each of the test methods concurrently. In the event
that not all systems support VPATH, I can do a bit of surgery on the
Makefile rules and attempt to make it smarter with regards to relative
paths to source files used in the build.
llvm-svn: 276478
"Incorrect" file name seen on Android whene the main executable is
called "app_process32" (or 64) but the linker specifies the package
name (e.g. com.android.calculator2). Additionally it can be present
in case of some linker bugs.
This CL adds logic to try to fetch the correct file name from the proc
file system based on the base address sepcified by the linker in case
we are failed to load the module by name.
Differential revision: http://reviews.llvm.org/D22219
llvm-svn: 276411
Summary:
The binary layout of prstatus and prpsinfo was wrong.
Some of the member variables where not aligned properly
and others where with a wrong type (e.g. the time related
stuff in prstatus).
I used the structs defined in bfd in binutils to see what the layout
of the elf-core format in these section is.
(https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=bfd/hosts/x86-64linux.h;h=4e420a1f2081dd3b51f5d6b7a8e4093580f5cdb5;hb=master)
Note: those structures are only for x86 64 bit elf-core files
This shouldn't have any impact on the functionality, because
lldb actually uses only a few of the member variables of those structs
and they are with a correct type and alignment.
I found this while trying to add/fix the support for
i386 core files (https://llvm.org/bugs/show_bug.cgi?id=26947)
Reviewers: labath
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D22628
Author: Dimitar Vlahovski <dvlahovski@google.com>
llvm-svn: 276406
debugserver jGetSharedCacheInfo packet instead of reading
the dyld internal data structures directly. This code is
(currently) only used for ios native lldb's - I should really
move this ObjectFileMachO::GetProcessSharedCacheUUID method
somewhere else, it makes less and less sense being in the
file reader.
<rdar://problem/25251243>
llvm-svn: 276369
Summary:
We've had two copies of code for launching processes:
- one in NativeProcessLinux, used for launching debugged processes
- one in ProcessLauncherAndroid, used on android for launching all other kinds of processes
These have over time acquired support for various launch options, but neither supported all of
them. I now replace them with a single implementation ProcessLauncherLinux, which supports all
the options the individual versions supported and set it to be used to launch all processes on
linux.
This also works around the ETXTBSY issue on android when the process is started from the platform
instance, as that used to go through the version which did not contain the workaround.
Reviewers: tberghammer
Subscribers: tberghammer, danalbert, srhines, lldb-commits
Differential Revision: https://reviews.llvm.org/D22457
llvm-svn: 276288
for the fall (northern hemisphere) 2016 Darwin platforms to learn
about loaded images, instead of reading dyld internal data structures.
These new SPI don't exist on older releases, and new packets are
needed from debugserver to use them (those changes are already committed).
I had to change the minimum deployment target for debugserver in the xcode
project file to macOS 10.10 so that debugserver will use the
[[NSProcessInfo processInfo] operatingSystemVersion]
call in MachProcess::GetOSVersionNumbers to get the operarting system
version # -- this API is only available in macOS 10.10 and newer
("OS X Yosemite", released Oct 2014). If we have many people building
llvm.org lldb on older systems still, we can back off on this for the
llvm.org sources.
There should be no change in behavior with this commit, either to
older darwin systems or newer darwin systems.
For now the new DynamicLoader plugin is never activated - I'm forcing
the old plugin to be used in DynamicLoaderDarwin::UseDYLDSPI.
I'll remove that unconditional use of the old plugin soon, so the
newer plugin is used on the newest Darwin platforms.
<rdar://problem/25251243>
llvm-svn: 276254
Only ever warn about missing ObjC runtime class data if one either can't run the expressions to obtain such data, or the total count of classes is below a threshold that makes things sound really suspicious
Fixes rdar://27438500
llvm-svn: 276220
They will dump pretty-print (indentation, extra whitepsace) by default.
I'll make a change to ProcessGDBRemote soon so it stops sending JSON strings
to debugserver pretty-printed; it's unnecessary extra bytes being sent between
the two.
llvm-svn: 276079
This reverts r275782.
The problem with the commit is that it reports an additional "exit (1)" error for every file
containing a failing test, which is far more than I had intended to do. I'll need to come up with
a more fine-grained way of achieving the result.
llvm-svn: 275791
Summary:
We've run into this problem when the test errored out so early (because it could not connect to
the remote device), that the code in D20193 did not catch the error. This resulted in the test
suite reporting success with 0 tests being run.
This patch makes sure that any non-zero exit code from the inferior process gets reported as an
error. Basically I expand the concept of "exceptional exits", which was previously being used for
signals to cover these cases as well.
Reviewers: tfiala, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D22404
llvm-svn: 275782
Summary:
This patch fills in the implementation of GetMemoryRegions() on the Windows live process and minidump implementations of lldb_private::Process (ProcessWindowsLive::GetMemoryRegionInfo and ProcessWinMiniDump::Impl::GetMemoryRegionInfo.) The GetMemoryRegions API was added under: http://reviews.llvm.org/D20565
The existing Windows implementations didn’t fill in the start and end addresses within MemoryRegionInfo. This patch fixes that and adds support for the new mapped flag on MemoryRegionInfo that says whether a memory range is mapped into the process address space or not.
The behaviour of both live and core implementations should match the behaviour documented on Process::GetMemoryRegionInfo (in Process.h) which in turn should match the behaviour of the qMemoryRegionInfo query documented in lldb-gdb-remote.txt.
Reviewers: clayborg, amccarth
Subscribers: amccarth, lldb-commits
Differential Revision: https://reviews.llvm.org/D22352
llvm-svn: 275778
a base class and a derived class, with the derived class containing
the methods specific to reading dyld's all_image_infos, dyld's
method of specifying images that have been loaded or unloaded, the
place where we put a breakpoint in dyld to get notified about newly
loaded or unloaded images.
This is in preparation for a second derived class which will use
some alternate methods for getting this information; that will be
a separate commit in the next few days.
There's a couple of ivars that should probably be in the derived
DyanmicLoaderMacOSX class instead of the base DynamicLoaderDarwin
class (m_dyld_image_infos, m_dyld_image_infos_stop_id). I don't
think I'll need to use these in the new derived class - I'll
move them down to DynamicLoaderMacOSX if it works out that way;
it'll simplify locking if I can do that.
<rdar://problem/25251243>
llvm-svn: 275733
$BUILT_PRODUCTS_DIR is usually the same as $CONFIGURATION_BUILD_DIR, but differs
when LLDB is being built BuildAndIntegration, in which case $BUILT_PRODUCTS_DIR
is more accurate.
llvm-svn: 275652
* include CheckAtomic to set HAVE_CXX_ATOMICS64_WITHOUT_LIB properly (introduced in r274121)
* hint Clang CMake files for LLVM CMake files location (inctroduced in ~ r274176)
Differential revision: https://reviews.llvm.org/D22322
llvm-svn: 275641
Summary:
This removes one level of indirection, which was just packing and repacking launch args into
different structures. NFC.
Reviewers: tberghammer
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D22357
llvm-svn: 275544
review it for consistency, accuracy, and clarity. These changes attempt to
address all of the above while keeping the text relatively terse.
<rdar://problem/24868841>
llvm-svn: 275485
trade-offs. When LLDB's multi-line editing support was first introduced
for expressions / REPL contexts the behavior was as follows:
* The Return key is treated as a line-break except at the end of the input
buffer, where a completeness test is applied
This worked well enough when writing code, and makes it trivial to insert
new lines above code you've already typed. Just use cursor navigation to
move up and type freely. Where it was awkward is that the gesture to insert
a line break and end editing is conflated for most people. Sometimes you
want Return to end the editing session and other times you want to insert
a line break.
This commit changes the behavior as follows:
* The Return key is treated as the end of editing except at the end of the
input buffer, where a completeness test is applied
* The Meta+Return sequence is always treated as a line break. This is
consistent with conventions in Facebook and elsewhere since
Alt/Option+Return is often mapped to Meta+Return. The unfortunate
exception is on macOS where this *can* be the case, but isn't by
default. Sigh.
Note that by design both before and after the patch pasting a Return
character always introduces a line break.
<rdar://problem/26886287>
llvm-svn: 275482
Changes to the underlying logging infrastructure in Fall 2016 Darwin
OSes were no longer showing up NSLog messages in command-line LLDB.
This change restores that functionality, and adds test cases to
verify the new behavior.
rdar://26732492
llvm-svn: 275472
Android API <= 16 header do not have these symbols defined, but the kernel does support the
relevant calls. And in general, since these calls are on a best-effort basis, it won't hurt even
if we try to run in on a really ancient kernel.
llvm-svn: 275393
* Previously -break-enable mistakenly set BP's enabled flag to false.
* These commands print fake =breakpoint-modified messages, what's not
needed anymore because that events are come in normal way.
* Add tests for -break-enable/-break-disable commands
Initial patch from xuefangliang@hotmail.com. The test case was improved by me.
Differential Revision: http://reviews.llvm.org/D21757
llvm-svn: 275381
Summary:
The function FunctionCaller::WriteFunctionArguments returns false on
errors, so they should check for the false return value.
Change by Walter Erquinigo <a20012251@gmail.com>
Reviewers: jingham, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D22278
llvm-svn: 275287
Background: symbols and functions can be looked up by full mangled name and by basename. SymbolFile and ObjectFile are expected to be able to do the lookups based on full mangled name or by basename, so when the user types something that is incomplete, we must be able to look it up efficiently. For example the user types "a:🅱️:c" as a symbol to set a breakpoint on, we will break this down into a 'lookup "c"' and then weed out N matches down to just the ones that match "a:🅱️:c". Previously this was done manaully in many functions by calling Module::PrepareForFunctionNameLookup(...) and then doing the lookup and manually pruning the results down afterward with duplicated code. Now all places use Module::LookupInfo to do the work in one place.
This allowed me to fix the name lookups to look for "func" with eFunctionNameTypeFull as the "name_type_mask", and correctly weed the results:
"func", "func()", "func(int)", "a::func()", "b::func()", and "a:🅱️:func()" down to just "func", "func()", "func(int)". Previously we would have set 6 breakpoints, now we correctly set just 3. This also extends to the expression parser when it looks up names for functions it needs to not get multiple results so we can call the correct function.
<rdar://problem/24599697>
llvm-svn: 275281
Summary:
This adds the knowledge of the DW_CFA_GNU_args_size instruction to the eh_frame parsing code.
Right now it is ignored as I am unsure how is it supposed to be handled, but now we are at least
able to parse the rest of the FDE containing this instruction.
I also add a fix for a bug which was exposed by this instruction. Namely, a mismatched sequence
of remember/restore instructions in the input could cause us to pop an empty stack and crash. Now
we just log the error and ignore the offending instruction.
Reviewers: jasonmolenda
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D22266
llvm-svn: 275260
The lookup tables can get out of date during the lifetime of the object so we
need to preserve LLDB's ability to answer questions about TagDecls' contents.
<rdar://problem/20751935>
llvm-svn: 275223
Loading a dynamic library can take quite a long time, since it triggers a number of
shared-library-event stops for dependent libraries. This is especially true for remote targets
due to communication latency. Increase the default 500ms timeout to account for that.
Committing as obvious.
llvm-svn: 275185
Summary:
LLDBTestResult.hardMarkAsSkipped marked the whole class as skipped when the first class in the
test failed the category check. This meant that subsequent tests in the same class did not run
even if they were passing the category filter. Fix that.
Reviewers: tfiala
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D22213
llvm-svn: 275173
Summary:
Process::SetExitStatus was popping the process io handler and resetting m_process_input_reader
shared pointer, which is not a safe thing to do as the function is called asynchronously and
other threads may be accessing the member variable. (E.g. if the process terminates really
quickly, the private state thread might only be in the process of pushing the handler on the
stack. Sometimes, this leads to deadlock, as the shared pointer's state gets corrupted by the
concurrent access.
Since the IOHandler will be popped anyway in Process:HandleProcessStateChangedEvent when the
exited event gets processed, doing the same in SetExitStatus seems to be unnecessary.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D22209
llvm-svn: 275165
Summary:
void typedefs do not have a DW_AT_type attribute, so we end up with an empty encoding_uid
variable. These don't need to be looked up and trying to look that will assert in a debug build.
Reviewers: clayborg
Subscribers: lldb-commits, tberghammer
Differential Revision: http://reviews.llvm.org/D22218
llvm-svn: 275164
is passed a ModuleSpec with a UUID, it won't accept a file it finds
with a matching FileSpec & ArchSpec, but with a different UUID.
<rdar://problem/27258864>
llvm-svn: 275151
Summary:
Some thread plans have public contructors, some others have protected
constructors with friend classes. Not sure how these were determined,
but this thread plan is going to be required to implement trampoline
step-through on Windows.
Reviewers: clayborg, zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D22230
llvm-svn: 275139
Summary:
This is already done when building for linux with the CMake build
system. This functionality disappeared recently when some of the build
scripts used by the xcode build system changed.
Reviewers: tfiala, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D22233
llvm-svn: 275134
The issue was we have two global variables: one that contains a DebuggerList pointer and one that contains a std::mutex pointer. These get initialized in Debugger::Initialize(), and everywhere that uses these does:
if (g_debugger_list_ptr && g_debugger_list_mutex_ptr)
{
std::lock_guard<std::recursive_mutex> guard(*g_debugger_list_mutex_ptr);
// do work while mutex is locked
}
Debugger::Terminate() was deleting and nulling out g_debugger_list_ptr which meant we had a race condition where someone might do the if statement and it evaluates to true, then another thread calls Debugger::Terminate() and deletes and nulls out g_debugger_list_ptr while holding the mutex, and another thread then locks the mutex and tries to use g_debugger_list_ptr. The fix is to just not delete and null out the g_debugger_list_ptr variable.
llvm-svn: 275119
If LLDB reads some incorrect input form /proc/<pid>/maps then it
should report an error instead of assert-ing as we don't want to
crash in case of an incorrect maps file.
Differential revision: http://reviews.llvm.org/D22211
llvm-svn: 275060
We had some clients that had added old source paths remappings to their .lldbinit files and they were causing trouble at a later date. This fix should help mitigate these issues.
<rdar://problem/26358860>
llvm-svn: 274948
This feature was added to solve a lookup problem in expressions when local variables
shadow ivars. That solution requires fully realizing all local variables to evaluate
any expression, and can cause significant performance problems when evaluating
expressions in frames that have many complex locals.
Until we get a better solution, this setting mitigates the problem when you don't
have local variables that shadow ivars.
<rdar://problem/27226122>
llvm-svn: 274783
When multiple Android devices are attached, the default behaviour of ADB
is to resolve a device number based on the presence of ANDROID_SERIAL if
the serial number is not explicitly passed by the -s parameter. This patch
emulates that behaviour in lldb's ADB platform connector
Differential Revision: http://reviews.llvm.org/D22052
llvm-svn: 274776
On android M it can happen that we get a ETXTBSY, when we try to launch the inferior. Sleeping
and retrying should help us get more stable results.
llvm-svn: 274763
Summary:
The issue arises due to the wrong unwinder used for the first
stack frame, where the default unwinder returns erroneous frame
whereas the fallback would have given the correct frame had it
been used.
The following fix consists of two parts ->
1) The first part changes the unwinding strategy, earlier the
default unwinder was used to get 2 more stack frames and if it
failed a fallback unwinder was used. Now we try to obtain as many
frames (max 10) as we can get from default unwinder and also
fallback unwinder and use the one that gives more number of frames.
2) Normally unwindplans are assosciated with functions and the
row to be used is obtained from the offset (obtained from the low_pc
of the function symbol). Sometimes it may occur that the unwindplan
is assosciated to the complete Elf section in which case the offset
calculation would be wrong as the debugger uses the same offset originally
obtained from the function symbol. Hence this offset is recalculated.
Reviewers: tberghammer, lldb-commits, labath, jasonmolenda
Subscribers: jingham
Differential Revision: http://reviews.llvm.org/D21221
llvm-svn: 274750
Summary:
This patch fills in the implementation of GetMemoryRegions() on the Linux and Mac OS core file implementations of lldb_private::Process (ProcessElfCore::GetMemoryRegions and ProcessMachCore::GetMemoryRegions.) The GetMemoryRegions API was added under: http://reviews.llvm.org/D20565
The patch re-uses the m_core_range_infos list that was recently added to implement GetMemoryRegionInfo in both ProcessElfCore and ProcessMachCore to ensure the returned regions match the regions returned by Process::GetMemoryRegionInfo(addr_t load_addr, MemoryRegionInfo ®ion_info).
Reviewers: clayborg
Subscribers: labath, lldb-commits
Differential Revision: http://reviews.llvm.org/D21751
llvm-svn: 274741
os name and version # from the mach-o binary as it scans the
header/load commands from memory and sends the details back
in the jGetLoadedDynamicLibrariesInfos response. lldb isn't
using these fields yet but I have a suspicion I'm going to
need them soon.
<rdar://problem/25251243>
llvm-svn: 274725
to find the solibs loaded in a process. Support two new ways of
sending the jGetLoadedDynamicLibrariesInfos packet to debugserver
and add a new jGetSharedCacheInfo packet. Update the documentation
for these packets as well. The changes to lldb to use these will
be a separate commit.
<rdar://problem/25251243>
llvm-svn: 274718
"frame variable" and "target variable" are trying to emulate the expression parser when doing things like:
(lldb) frame variable &my_struct.my_bitfield
And since the expression parser doesn't allow this, we shouldn't allow "frame variable" or "target variable" to succeed.
<rdar://problem/27208607>
llvm-svn: 274703
Bitfields were not correctly describing their offsets within the integer that they are contained within. If we had a bitfield like:
struct MyStruct {
uint32_t a:8;
uint32_t b:8;
};
ClangASTContext::GetChildCompilerTypeAtIndex would say that child a and b had the following values in their respective ValueObjectChild objects:
name byte-size bit-size bit-offset byte-offset-from-parent
==== ========= ======== ========== =======================
"a" 4 8 0 0
"b" 4 8 0 1
So if we had a "MyStruct" at address 0x1000, we would end up reading 4 bytes from 0x1000 for "a", and 4 bytes from 0x1001 for "b". The fix for this is to fix the "child_byte_offset" and "child_bitfield_bit_offset" values returned by ClangASTContext::GetChildCompilerTypeAtIndex() so that now the table looks like:
name byte-size bit-size bit-offset byte-offset-from-parent
==== ========= ======== ========== =======================
"a" 4 8 0 0
"b" 4 8 8 0
Then we don't run into a problem when reading data from a file's section info using "target variable" before running. It will also stop us from not being able to display a bitfield values if the bitfield is in the last bit of memory before an unmapped region. (Like if address 0x1004 was unmapped and unreadable in the example above, if we tried to read 4 bytes from 0x1001, the memory read would fail and we wouldn't be able to display "b").
<rdar://problem/27208225>
llvm-svn: 274701
may be in a function that is non-ABI conformant, and the eh_frame
instructions correctly describe how to unwind out of this function,
but the assembly parsing / arch default unwind plans would be
incorrect.
This is to address a problem that Ravitheja Addepally reported in
http://reviews.llvm.org/D21221 - I wanted to try handling the problem
with this approach which I think may be more generally helpful,
Ravitheja tested it and said it solves the problem on Linux/FreeBSD.
Ravi has a test case in http://reviews.llvm.org/D21221 that will
be committed separately.
Thanks for all the help on this one, Ravi.
llvm-svn: 274700
- if a synthetic child comes from the same hierarchy as its parent object, then it can't be cached by SharedPointer inside the synthetic provider, or it will cause a reference loop;
- but, if a synthetic child is made from whole cloth (e.g. from an expression, a memory region, ...), then it better be cached by SharedPointer, or it will be cleared out and cause an assert() to fail if used at a later point
For most cases of self-rooted synthetic children, we have a flag we set "IsSyntheticChildrenGenerated", but we were not using it to track caching. So, what ended up happening is each provider would set up its own cache, and if it got it wrong, a hard to diagnose crash would ensue
This patch fixes that by centralizing caching in ValueObjectSynthetic - if a provider returns a self-rooted child (as per the flag), then it gets cached centrally by the ValueObject itself
This cache is used only for lifetime management and not later retrieval of child values - a different cache handles that (because we might have a mix of self-rooted and properly nested child values for the same parent, we can't trivially use this lifetime cache for retrieval)
Fixes rdar://26480007
llvm-svn: 274683
Summary:
We are seeing infrequent failures to launch the inferior process on android. The failing call
seems to be execve(). This adds more logging to see the actual error reported by the call.
Reviewers: tberghammer
Subscribers: tberghammer, lldb-commits, danalbert
Differential Revision: http://reviews.llvm.org/D22039
llvm-svn: 274624
settings or raise no error if not found.
From time to time it is useful to add some setting to work around or enable
a transitory feature. We've been reluctant to remove them later because then
we will break folks .lldbinit files. With this change you can add an "experimental"
node to the settings. If you later decide you want to keep the option, just move
it to the level that contained the "experimental" setting and it will still be
found. Or just remove it - setting it will then silently fail and won't halt
the .lldbinit file execution.
llvm-svn: 274593
I changed "m_is_optimized" in lldb_private::CompileUnit over to be a lldb::LazyBool so that it can be set to eLazyBoolCalculate if it needs to be parsed later. With SymbolFileDWARFDebugMap, we don't actually open the DWARF in the .o files for each compile unit until later, and we can't tell if a compile unit is optimized ahead of time. So to avoid pulling in all .o right away just so we can answer the questions of "is this compile unit optimized" we defer it until a point where we will have the compile unit parsed.
<rdar://problem/26068360>
llvm-svn: 274585
Summary:
One of the tests there does not work with gcc, so I'm spinning that off into a separate test, so
that we can XFAIL it with more granularity.
I am also renaming the test to reflect the fact that it no longer tests only integer arguments.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D21923
llvm-svn: 274505
These are artifical symbols inside android oat files without any value
for the user while causing a significant perfoamce hit inside the
unwinder. We were already ignoring it inside system@framework@boot.oat
bot they have to be ignored in every oat file. Considering that oat
files are only used on android this have no effect on any other
platfrom.
llvm-svn: 274500
It is sufficient to set the handeler to SIG_IGN, to get the desired behaviour. Also, the handler
calling a lot of signal-unsafe functions.
llvm-svn: 274499
Summary:
This is a slightly reworked version of D16322, which I had reverted because it did not do what it
advertised. Differences from the previous version are:
- moved the code for cleaning up the remote working dir to a later point as it was removing the
log file before we could get to it.
- specialised log downloading code for gdb-remote tests is not needed, as this will cover that
use case as well.
Reviewers: tfiala
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D21898
llvm-svn: 274491
The libc++ shipped with the android NDK is shipped using a different
internal namespace then the upstream libc++ (__ndk1 vs. __1) to avoid
an ODR violation between the platform and the user application. This
change fixes our pretty printers to be able to work with the types
from the android NDK libc++.
Differential revision: http://reviews.llvm.org/D21680
llvm-svn: 274489
Tamas Berghammer