@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
Summary:
As this test will create a new target, it will cause all following tests
to fail when running in platform mode, if the new target does not match
the existing architecture (for example, x86 vs x86_64).
Reviewers: zturner, spyffe, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D21906
llvm-svn: 274364
I overlooked the possibility of certain targets translating increment statement into a read and write.
In this case we replace increment statement with an assignment.
llvm-svn: 274215
Summary:
This removes the last usage of Platform plugins in lldb-server -- it was used for launching child
processes, where it can be trivially replaced by Host::LaunchProces (as lldb-server is always
running on the host).
Removing platform plugins enables us to remove a lot of other unused code, which was pulled in as
a transitive dependency, and it reduces lldb-server size by 4%--9% (depending on build type and
architecture).
Reviewers: clayborg
Subscribers: tberghammer, danalbert, srhines, lldb-commits
Differential Revision: http://reviews.llvm.org/D20440
llvm-svn: 274125
Patch by Nitesh Jain.
Summary : The problem appears while linking liblldb.so. The class Address contain atomic variable m_offset. The loading and storing of variable is access via atomic_load_8 and atomic_store_8 functions. Some target fail to implicitly link libatomic, which cause undefine reference to atomic_store_8/atomic_load_8. This patch uses http://reviews.llvm.org/D20896 to check if libatomic need to be explicitly link.
Reviewed by labath.
Differential: D20464
llvm-svn: 274121
A few fixes:
- Check the process state to make sure it is stopped
- Grab the frame from the "exe_ctx" so this will work during breakpoint callbacks
- Print out the SBDeclaration objects of the variables that shadow each other so we can see the source locations of which variable declarations are shodowing each other.
llvm-svn: 273963
Target::Install() was assuming the module at index 0 was the executable.
This is often true, but not guaranteed to be the case. The
TestInferiorChanged.py test highlighted this when run against iOS.
After the binary is replaced in the middle of the test, it becomes the
last module in the list. The rest of the Target::Install() logic then
clobbers the executable file by using whatever happens to be the first
module in the target module list.
This change also marks the TestInferiorChanged.py test as a no-debug-info
test.
llvm-svn: 273960
explicit in how it adds the kernel binary, to guard against the
case where a kernel corefile might incorrectly include the kernel's
UUID in it (so calling ::GetSharedModule may end up returning the
global module cache's copy of the core file instead of adding the
kerenl binary).
<rdar://problem/26988816>
llvm-svn: 273954
We were checking for integer types only before this. So I added the ability for CompilerType objects to check for integer and enum types.
Then I searched for places that were using the CompilerType::IsIntegerType(...) function. Many of these places also wanted to be checking for enumeration types as well, so I have fixed those places. These are in the ABI plug-ins where we are figuring out which arguments would go in where in regisers/stack when making a function call, or determining where the return value would live. The real fix for this is to use clang to compiler a CGFunctionInfo and then modify the code to be able to take the IR and a calling convention and have the backend answer the questions correctly for us so we don't need to create a really bad copy of the ABI in each plug-in, but that is beyond the scope of this bug fix.
Also added a test case to ensure this doesn't regress in the future.
llvm-svn: 273750
This:
a) teaches PythonCallable to look inside a callable object
b) teaches PythonCallable to discover whether a callable method is bound
c) teaches lldb.command to dispatch to either the older 4 argument version or the newer 5 argument version
llvm-svn: 273640
This shows how to grab individual blocks from stack frames and get only the variables from those blocks. It then will iterate over all of the parent blocks and look for shadowed variables.
llvm-svn: 273604
Summary:
This adds new SB API calls and classes to allow a user of the SB API to obtain a full list of memory regions accessible within the process. Adding this to the API makes it possible use the API for tasks like scanning memory for blocks allocated with a header and footer to track down memory leaks, otherwise just inspecting every address is impractical especially for 64 bit processes.
These changes only add the API itself and a base implementation of GetMemoryRegions() to lldb_private::Process::GetMemoryRegions.
I will submit separate patches to fill in lldb_private::Process::GetMemoryRegionInfoList and GetMemoryRegionInfo for individual platforms.
The original discussion about this is here:
http://lists.llvm.org/pipermail/lldb-dev/2016-May/010203.html
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D20565
llvm-svn: 273547
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 change adds a new Xcode variable, LLDB_ENABLE_COVERAGE.
If set to 1, then the Xcode build will produce a clang
coverage-style build of LLDB. This can be done with a commandline
invocation such as:
xcodebuild -scheme desktop -configuration Debug build LLDB_ENABLE_COVERAGE=1
Alternatively, the variable can be locally modified from within Xcode
and built with the Xcode IDE.
llvm-svn: 273332
In Address.cpp, we were asking for the lldb::eSymbolContextVariable to be resolved, yet we weren't using the variable. This code gets called when disassembling and can cause the manual creation of all global variables variables which can take minutes. Removing eSymbolContextVariable allows disassembly to not create these long pauses.
In Module.cpp, if someone only specified the lldb::eSymbolContextVariable flag, we would not look into a module's debug info, now we will.
<rdar://problem/26907449>
llvm-svn: 273307
which doesn't like against all the extra UI frameworks on ios)
so it now generates a binary called "debugserver-nonui" and puts
it in /usr/local/bin instead of /Developer/usr/bin.
Add some cruft to RNBDefs.h to get the version number (provided
by Xcode at build time) with either the name "debugserver" or
"debugserver_nonui" as appropriate.
Add the "debugserver-mini" target to the top level "ios" target
in lldb xcode project file, so this nonui debugserver will be
built along with the normal lldb / debugserver.
<rdar://problem/24730789>
llvm-svn: 273236
This patch allows LLDB for AArch64 to watch all bytes, words or double words individually on non 8-byte alligned addresses.
This patch also adds tests to verify this functionality.
Differential revision: http://reviews.llvm.org/D21280
llvm-svn: 272916
Greg Clayton