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
