Summary:
This adds the jModulesInfo packet, which is the equivalent of qModulesInfo, but it enables us to
query multiple modules at once. This makes a significant speed improvement in case the
application has many (over a hundred) modules, and the communication link has a non-negligible
latency. This functionality is accessed by ProcessGdbRemote::PrefetchModuleSpecs(), which does
the caching. GetModuleSpecs() is modified to first consult the cache before asking the remote
stub. PrefetchModuleSpecs is currently only called from POSIX-DYLD dynamic loader plugin, after
it reads the list of modules from the inferior memory, but other uses are possible.
This decreases the attach time to an android application by about 40%.
Reviewers: clayborg
Subscribers: tberghammer, lldb-commits, danalbert
Differential Revision: https://reviews.llvm.org/D24236
llvm-svn: 280919
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:
Firstly, merging this particular commit into a downstream fork may be a huge
effort. Alternatively, it may be worth merging all changes up to this commit,
performing the same reformatting operation locally, and then discarding the
merge for this particular commit. The commands used to accomplish this
reformatting were as follows (with current working directory as the root of
the repository):
find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} +
find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ;
The version of clang-format used was 3.9.0, and autopep8 was 1.2.4.
Secondly, “blame” style tools will generally point to this commit instead of
a meaningful prior commit. There are alternatives available that will attempt
to look through this change and find the appropriate prior commit. YMMV.
llvm-svn: 280751
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
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
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
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
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
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
@unittest2.expectedFailure("rdar://7796742")
Which was covering up the fact this was failing on linux and hexagon. I added back a decorator so we don't break any build bots.
llvm-svn: 274388
We had support that assumed that thread local data for a variable could be determined solely from the module in which the variable exists. While this work for linux, it doesn't work for Apple OSs. The DWARF for thread local variables consists of location opcodes that do something like:
DW_OP_const8u (x)
DW_OP_form_tls_address
or
DW_OP_const8u (x)
DW_OP_GNU_push_tls_address
The "x" is allowed to be anything that is needed to determine the location of the variable. For Linux "x" is the offset within the TLS data for a given executable (ModuleSP in LLDB). For Apple OS variants, it is the file address of the data structure that contains a pthread key that can be used with pthread_getspecific() and the offset needed.
This fix passes the "x" along to the thread:
virtual lldb::addr_t
lldb_private::Thread::GetThreadLocalData(const lldb::ModuleSP module, lldb::addr_t tls_file_addr);
Then this is passed along to the DynamicLoader::GetThreadLocalData():
virtual lldb::addr_t
lldb_private::DynamicLoader::GetThreadLocalData(const lldb::ModuleSP module, const lldb::ThreadSP thread, lldb::addr_t tls_file_addr);
This allows each DynamicLoader plug-in do the right thing for the current OS.
The DynamicLoaderMacOSXDYLD was modified to be able to grab the pthread key from the data structure that is in memory and call "void *pthread_getspecific(pthread_key_t key)" to get the value of the thread local storage and it caches it per thread since it never changes.
I had to update the test case to access the thread local data before trying to print it as on Apple OS variants, thread locals are not available unless they have been accessed at least one by the current thread.
I also added a new lldb::ValueType named "eValueTypeVariableThreadLocal" so that we can ask SBValue objects for their ValueType and be able to tell when we have a thread local variable.
<rdar://problem/23308080>
llvm-svn: 274366
for TestNamespaceLookup.py; didn't see anything obviously wrong so I'll
need to look at this more closely before re-committing. (passed OK on
macOS ;)
llvm-svn: 273531
There's uses of "macosx" that will be more tricky to
change, like in triples (e.g. "x86_64-apple-macosx10.11") -
for now I'm just updating source comments and strings printed
for humans.
llvm-svn: 273524
This is a pretty straightforward first pass over removing a number of uses of
Mutex in favor of std::mutex or std::recursive_mutex. The problem is that there
are interfaces which take Mutex::Locker & to lock internal locks. This patch
cleans up most of the easy cases. The only non-trivial change is in
CommandObjectTarget.cpp where a Mutex::Locker was split into two.
llvm-svn: 269877
Summary:
The logic to read modules from memory was added to LoadModuleAtAddress
in the dynamic loader, but not in process gdb remote. This means that when
the remote uses svr4 packets to give library info, libraries only present
on the remote will not be loaded.
This patch therefore involves some code duplication from LoadModuleAtAddress
in the dynamic loader, but removing this would require some amount of code
refactoring.
Reviewers: ADodds, tberghammer, tfiala, deepak2427, ted
Subscribers: tfiala, lldb-commits, sas
Differential Revision: http://reviews.llvm.org/D18531
Change by Francis Ricci <fjricci@fb.com>
llvm-svn: 265418
Summary:
There was a bug in linux core file handling, where if there was a running process with the same
process id as the id in the core file, the core file debugging would fail, as we would pull some
pieces of information (ProcessInfo structure) from the running process instead of the core file.
I fix this by routing the ProcessInfo requests through the Process class and overriding it in
ProcessElfCore to return correct data.
A (slightly convoluted) test is included.
Reviewers: clayborg, zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D18697
llvm-svn: 265391
The problem was that the static DynamicLoaderDarwinKernel::Initialize() was recently changed to come before DynamicLoaderMacOSXDYLD::Initialize() which caused the DynamicLoaderDarwinKernel::CreateInstance(...) to be called before DynamicLoaderMacOSXDYLD::CreateInstance(...) and DynamicLoaderDarwinKernel would claim it could be the dynamic loader for a user space MacOSX process. The fix is to make DynamicLoaderDarwinKernel::CreateInstance() a bit more thourough when vetting the process so that it doesn't claim MacOSX user space processes.
<rdar://problem/25425373>
llvm-svn: 264794
That way you can set offset breakpoints that will move as the function they are
contained in moves (which address breakpoints can't do...)
I don't align the new address to instruction boundaries yet, so you have to get
this right yourself for now.
<rdar://problem/13365575>
llvm-svn: 263049
user process dyld binary and/or a mach kernel binary image. By
default, it prefers the kernel if it finds both.
But if it finds two kernel binary images (which can happen when
random things are mapped into memory), it may pick the wrong
kernel image.
DynamicLoaderDarwinKernel has heuristics to find a kernel in memory;
once we've established that there is a kernel binary in memory,
call over to that class to see if it can find a kernel address via
its search methods. If it does, use that.
Some minor cleanups to DynamicLoaderDarwinKernel while I was at it.
<rdar://problem/24446112>
llvm-svn: 259983
Summary:
Allows the remote to enumerate the link map when adding and removing
shared libraries, so that lldb doesn't need to read it manually from
the remote's memory.
This provides very large speedups (on the order of 50%) in total
startup time when using the ds2 remote on android or Tizen devices.
Reviewers: ADodds, tberghammer, tfiala
Subscribers: tberghammer, sas, danalbert, llvm-commits, srhines
Differential Revision: http://reviews.llvm.org/D16004
Change by Francis Ricci <fjricci@fb.com>
llvm-svn: 257502
Also, add an async error message if the dyld solib loaded callback function
can't find an ABI (which results in no solibs being loaded in the process).
This is a big error and we should call attention to it.
<rdar://problem/23471384>
llvm-svn: 252581
Summary:
Since this is within the lldb namespace, the compiler tries to
export a symbol for it. Unfortunately, since it is inlined, the
symbol is hidden and this results in a mess of warnings when
building on OS X with cmake.
Moving it to the lldb_private namespace eliminates that problem.
Reviewers: clayborg
Subscribers: emaste, lldb-commits
Differential Revision: http://reviews.llvm.org/D14417
llvm-svn: 252396
in places where we check for Triple::IOS. They're mostly the same as far
as lldb is conerned.
.
Also add a base cass implementation for Process::IsAlive - Greg added this
last year but it didn't get upstreamed.
llvm-svn: 252227
Summary:
Virtual dynamic shared objects, or vdso files were
not loaded for Linux OS.In Bug 17384 the call
stack could not be unwinded from functions
residing in the vdso object.
This commit adds support for loading such files by
reading the Aux vectors since a vdso is invisibily
mapped to the inferiors address space and the
actual file is not present in the filesystem. The
presence of the vdso is detected by inspecting
the Aux vector for AT_SYSINFO_EHDR tag.
Reviewers: lldb-commits, ovyalov, tberghammer
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D14118
llvm-svn: 251505
It is a new function added to the llvm::Triple class to simplify the
checking if we are targeting android to clean up the confusion between
android being an OS or an environment.
llvm-svn: 250286
Summary:
EnablePluginLogging, GetPluginCommandHelp and ExecutePluginCommand aren't
implemented or used anywhere, so remove them from the Hexagon and POSIX
Dynamic Loaders as well as the FreeBSD process.
Reviewers: clayborg, labath, emaste
Subscribers: lldb-commits, emaste
Differential Revision: http://reviews.llvm.org/D13581
llvm-svn: 249840
The hack is there to work around an incorrect load address reported
by the android linker on API 21 and 22 devices. This CL restricts the
hack to those android API levels.
Differential revision: http://reviews.llvm.org/D13288
llvm-svn: 249012
Summary:
This doesn't exist in other LLVM projects any longer and doesn't
do anything.
Reviewers: chaoren, labath
Subscribers: emaste, tberghammer, lldb-commits, danalbert
Differential Revision: http://reviews.llvm.org/D12586
llvm-svn: 246749
Added a new class called DWARFDIE that contains a DWARFCompileUnit and DWARFDebugInfoEntry so that these items always stay together.
There were many places where we just handed out DWARFDebugInfoEntry pointers and then use them with a compile unit that may or may not be the correct one. Clients outside of DWARFCompileUnit and DWARFDebugInfoEntry should all be dealing with DWARFDIE instances instead of playing with DWARFCompileUnit/DWARFDebugInfoEntry pairs manually.
This paves to the way for some modifications that are coming for DWO.
llvm-svn: 246100
Create a new "lldb_private::CompilerDeclContext" class that will replace all direct uses of "clang::DeclContext" when used in compiler agnostic code, yet still allow for conversion to clang::DeclContext subclasses by clang specific code. This completes the abstraction of type parsing by removing all "clang::" references from the SymbolFileDWARF. The new "lldb_private::CompilerDeclContext" class abstracts decl contexts found in compiler type systems so they can be used in internal API calls. The TypeSystem is required to support CompilerDeclContexts with new pure virtual functions that start with "DeclContext" in the member function names. Converted all code that used lldb_private::ClangNamespaceDecl over to use the new CompilerDeclContext class and removed the ClangNamespaceDecl.cpp and ClangNamespaceDecl.h files.
Removed direct use of clang APIs from SBType and now use the abstract type systems to correctly explore types.
Bulk renames for things that used to return a ClangASTType which is now CompilerType:
"Type::GetClangFullType()" to "Type::GetFullCompilerType()"
"Type::GetClangLayoutType()" to "Type::GetLayoutCompilerType()"
"Type::GetClangForwardType()" to "Type::GetForwardCompilerType()"
"Value::GetClangType()" to "Value::GetCompilerType()"
"Value::SetClangType (const CompilerType &)" to "Value::SetCompilerType (const CompilerType &)"
"ValueObject::GetClangType ()" to "ValueObject::GetCompilerType()"
many more renames that are similar.
llvm-svn: 245905
The POSIX linker generally reports the load bias for the loaded
libraries but in some case it is useful to handle a library based on
absolute load address. Example usecases:
* Windows linker uses absolute addresses
* Library list came from different source (e.g. /proc/<pid>/maps)
Differential revision: http://reviews.llvm.org/D12233
llvm-svn: 245834
This reverts commit 7749a10ddbe22767d0e055753c674fcde7f28d39.
This commit introduces about 15-20 new test failures with windows local
targets.
llvm-svn: 245765
Summary:
This commit implements basic DidAttach and DidLaunch for the windows
DynamicLoader plugin which allow us to load shared libraries from the
inferior.
At the moment, I'm unsure how we're going to gather the load address of
the main module over gdb protocol so I always use an offset of 0, which
works well for processes we create ourselves (no randomization). I will
address this point later on.
Reviewers: clayborg, zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12245
llvm-svn: 245725
Summary:
This uses the .clang-format at the root of the LLDB repo and is just a
mechanical change that precedes more work in this file.
Reviewers: clayborg, zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12217
llvm-svn: 245634
This is more preparation for multiple different kinds of types from different compilers (clang, Pascal, Go, RenderScript, Swift, etc).
llvm-svn: 244689
dSYMs, or reading binaries out of memory to the 'Host' log channel.
There's more to be done here, both for Mac and for other platforms,
but the initial set of new loggings are useful enough to check in
at this point.
llvm-svn: 243200
Summary:
This replaces (void)x; usages where they x was subsequently
involved in an assertion with this macro to make the
intent more clear.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D11451
llvm-svn: 243074
Target and breakpoints options were added:
breakpoint set --language lang --name func
settings set target.language pascal
These specify the Language to use when interpreting the breakpoint's
expression (note: currently only implemented for breakpoints on
identifiers). If the breakpoint language is not set, the target.language
setting is used.
This support is required by Pascal, for example, to set breakpoint at 'ns.foo'
for function 'foo' in namespace 'ns'.
Tests on the language were also added to Module::PrepareForFunctionNameLookup
for efficiency.
Reviewed by: clayborg
Subscribers: jingham, lldb-commits
Differential Revision: http://reviews.llvm.org/D11119
llvm-svn: 242844
Summary: This aligns the library names used by the Makefile build to be the same as those create by the CMake build to make switching between the two easier. The only major difficulty was lldbHost which was one library in the CMake system and several in the Makefile system. Most of the other changes are trivial renames.
Reviewers: labath
Subscribers: emaste, tberghammer, lldb-commits
Differential Revision: http://reviews.llvm.org/D11154
llvm-svn: 242196