namespace lldb_private {
class Thread
{
virtual lldb::StopInfoSP
GetPrivateStopReason() = 0;
};
}
To not be virtual. The lldb_private::Thread now handles the correct caching and will call a new pure virtual function:
namespace lldb_private {
class Thread
{
virtual bool
CalculateStopInfo() = 0;
}
}
This function must be overridden by thead lldb_private::Thread subclass and the only thing it needs to do is to set the Thread::StopInfo() with the current stop reason and return true, or return false if there is no stop reason. The lldb_private::Thread class will take care of calling this function only when it is required. This allows lldb_private::Thread subclasses to be a bit simpler and not all need to duplicate the cache and invalidation settings.
Also renamed:
lldb::StopInfoSP
lldb_private::Thread::GetPrivateStopReason();
To:
lldb::StopInfoSP
lldb_private::Thread::GetPrivateStopInfo();
Also cleaned up a case where the ThreadPlanStepOverBreakpoint might not re-set its breakpoint if the thread disappears (which was happening due to a bug when using the OperatingSystem plug-ins with memory threads and real threads).
llvm-svn: 181501
to the DeclContext. This fulfils the contract that
we make with Clang by returning ELR_AlreadyLoaded.
This is a little aggressive in that it does not allow
the ASTImporter to import the child decls with any
lexical parent other than the Decl that reported them
as children.
<rdar://problem/13517713>
llvm-svn: 181498
This commit changes the ${function.name-with-args} prompt keyword to also tackle structs
Previously, since aggregates have no values, this would show up as foo=(null)
This checkin changes that to instead print foo=(Foo at 0x123) (i.e. typename at address)
There are other potential choices here (summary, one-liner printout of all members, ...) and I would love to hear feedback about better options, if any
llvm-svn: 181462
- Played with the current dual run lock implementation for a few days, noticed
no regressions, so enabling in trunk so we see if any problems are detected
by buildbots.
llvm-svn: 181446
- verify that backtraces for stacks that include functions which contain
illegal instructions are correct, and that variables in said functions can be
printed.
llvm-svn: 181442
value. This fixes problems, for instance, with the StepRange plans, where they know that
they explained the stop because they were at their "run to here" breakpoint, then deleted
that breakpoint, so when they got asked again, doh! I had done this for a couple of plans
in an ad hoc fashion, this just formalizes it.
Also add a "ResumeRequested" in Process so that the code in the completion handlers can
tell the ShouldStop logic they want to resume rather than just directly resuming. That allows
us to handle resuming in a more controlled fashion.
Also, SetPublicState can take a "restarted" flag, so that it doesn't drop the run lock when
the target was immediately restarted.
--This line, and those below , will be ignored--
M test/lang/objc/objc-dynamic-value/TestObjCDynamicValue.py
M include/lldb/Target/ThreadList.h
M include/lldb/Target/ThreadPlanStepOut.h
M include/lldb/Target/Thread.h
M include/lldb/Target/ThreadPlanBase.h
M include/lldb/Target/ThreadPlanStepThrough.h
M include/lldb/Target/ThreadPlanStepInstruction.h
M include/lldb/Target/ThreadPlanStepInRange.h
M include/lldb/Target/ThreadPlanStepOverBreakpoint.h
M include/lldb/Target/ThreadPlanStepUntil.h
M include/lldb/Target/StopInfo.h
M include/lldb/Target/Process.h
M include/lldb/Target/ThreadPlanRunToAddress.h
M include/lldb/Target/ThreadPlan.h
M include/lldb/Target/ThreadPlanCallFunction.h
M include/lldb/Target/ThreadPlanStepOverRange.h
M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.h
M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.cpp
M source/Target/StopInfo.cpp
M source/Target/Process.cpp
M source/Target/ThreadPlanRunToAddress.cpp
M source/Target/ThreadPlan.cpp
M source/Target/ThreadPlanCallFunction.cpp
M source/Target/ThreadPlanStepOverRange.cpp
M source/Target/ThreadList.cpp
M source/Target/ThreadPlanStepOut.cpp
M source/Target/Thread.cpp
M source/Target/ThreadPlanBase.cpp
M source/Target/ThreadPlanStepThrough.cpp
M source/Target/ThreadPlanStepInstruction.cpp
M source/Target/ThreadPlanStepInRange.cpp
M source/Target/ThreadPlanStepOverBreakpoint.cpp
M source/Target/ThreadPlanStepUntil.cpp
M lldb.xcodeproj/xcshareddata/xcschemes/Run Testsuite.xcscheme
llvm-svn: 181381
a new section is added to the executable after the dSYM has been created, e.g.
the CTF segment added to mach_kernel after all other linking and processing has
been finished.
<rdar://problem/13258780>
llvm-svn: 181375
This module uses Python's sys.settrace() mechanism so setup a hook that can log every significant operation
This is a first step in providing a good debugging experience of Python embedded in LLDB
This module comprises an OO infrastructure that wraps Python's tracing and inspecting mechanisms, plus a very simple logging tracer
Output from this tracer looks like:
call print_keyword_args from <module> @ 243 args are kwargs are {'first_name': 'John', 'last_name': 'Doe'}
running print_keyword_args @ 228 locals are {'kwargs': {'first_name': 'John', 'last_name': 'Doe'}}
running print_keyword_args @ 229 locals are {'key': 'first_name', 'value': 'John', 'kwargs': {'first_name': 'John', 'last_name': 'Doe'}}
first_name = John
running print_keyword_args @ 228 locals are {'key': 'first_name', 'value': 'John', 'kwargs': {'first_name': 'John', 'last_name': 'Doe'}}
running print_keyword_args @ 229 locals are {'key': 'last_name', 'value': 'Doe', 'kwargs': {'first_name': 'John', 'last_name': 'Doe'}}
last_name = Doe
running print_keyword_args @ 228 locals are {'key': 'last_name', 'value': 'Doe', 'kwargs': {'first_name': 'John', 'last_name': 'Doe'}}
return from print_keyword_args value is None locals are {'key': 'last_name', 'value': 'Doe', 'kwargs': {'first_name': 'John', 'last_name': 'Doe'}}
llvm-svn: 181343
while we develop a better understanding of how to manage the thread lists in a platform-independant fashion.
Reviewed by: Daniel Malea
llvm-svn: 181323
If the user pressed ^D, that would bypass the exit confirmation mechanism
This checkin remedies that by making sure that users get prompted on exit when appropriate even if they use CTRL+D instead of typing quit at the prompt
llvm-svn: 181257
Make a summary format for libc++ STL containers that shows the number of items as before, but also shows the pointer value for pointer-to-container
llvm-svn: 181236
This checkin aims to fix this. The process now has two thread lists: a real thread list for threads that are created by the lldb_private::Process subclass, and the user visible threads. The user visible threads are the same as the real threas when no OS plug-in in used. But when an OS plug-in is used, the user thread can be a combination of real and "memory" threads. Real threads can be placed inside of memory threads so that a thread appears to be different, but is still controlled by the actual real thread. When the thread list needs updating, the lldb_private::Process class will call the: lldb_private::Process::UpdateThreadList() function with the old real thread list, and the function is expected to fill in the new real thread list with the current state of the process. After this function, the process will check if there is an OS plug-in being used, and if so, it will give the old user thread list, the new real thread list and the OS plug-in will create the new user thread list from both of these lists. If there is no OS plug-in, the real thread list is the user thread list.
These changes keep the lldb_private::Process subclasses clean and no changes are required.
llvm-svn: 181091
Most important was a new[] + delete mismatch in ScanFormatDescriptor()
and a couple of possible memory leaks in FileSpec::EnumerateDirectory().
llvm-svn: 181080
help performance -- if the FileSpec we're examining does not contain the
UUID we're looking for, don't bother examining the file any further.
llvm-svn: 181063
If someone on Linux and/or FreeBSD can try to comment out the " #if defined(__APPLE__)" that surrounds access to "m_private_run_lock" and run the test suite, that would be nice. The new location where the locking/unlocking happens is bulletproof on MacOSX, and I want to verify that it is good on linux as well.
llvm-svn: 181061
- Decouples RegisterContext_x86_64 from UserArea.
- Restores the original definition of UserArea so that it can be used to generate offsets for use with ptrace.
- Moves UserArea to the 64-bit Linux specialization.
- Also fixes an off-by-one error for the size of m_gpr.
- Also adds a TODO comment noting the need for a mechanism to identify the correct plugin based on the target OS (and architecture).
Reviewed by: Matt Kopec and Samuel Jacob
llvm-svn: 181055
Improvements to the std::map data formatter to recognize when invalid memory is being explored and bail out instead of looping for a potentially very long time
llvm-svn: 181044
thread before UnwindLLDB::AddOneMoreFrame calls it quits. We have
a couple of reports of unending backtraces in the field and we
haven't been able to collect any information about what kind of
backtrace is causing this. We've found on Mac OS X that it's tricky
to get more than around 200k stack frames before a process exceeds
its stack space so we're starting with a hard limit of 300,000 frames.
<rdar://problem/13383069>
llvm-svn: 180995
SWIG is smart enough to recognize that C++ operators == and != mean __eq__ and __ne__ in Python and do the appropriate translation
But it is not smart enough to recognize that mySBObject == None should return False instead of erroring out
The %pythoncode blocks are meant to provide those extra smarts (and they play some SWIG&Python magic to find the right function to call behind the scenes with no risk of typos :-)
Lastly, SBBreakpoint provides an == but never provided a != operator - common courtesy is to provide both
llvm-svn: 180987
Allow command script import to load packages.
e.g.:
egranata$ ./lldb
(lldb) command script import lldb.macosx.crashlog
"crashlog" and "save_crashlog" command installed, use the "--help" option for detailed help
"malloc_info", "ptr_refs", "cstr_refs", and "objc_refs" commands have been installed, use the "--help" options on these commands for detailed help.
The "unwind-diagnose" command has been installed, type "help unwind-diagnose" for detailed help.
(lldb)
./lldb
(lldb) command script import theFoo
I am happy
(lldb) fbc
àèìòù
(lldb)
egranata$ ls theFoo/
__init__.py theBar.py
egranata$ cat theFoo/__init__.py
import lldb
import theBar
def __lldb_init_module(debugger, internal_dict):
print "I am happy"
debugger.HandleCommand("command script add -f theFoo.theBar.theCommand fbc")
return None
egranata$ cat theFoo/theBar.py
#encoding=utf-8
def theCommand(debugger, command, result, internal_dict):
result.PutCString(u"àèìòù")
return None
llvm-svn: 180975
DynamicLoaderDarwinKernel finds in memory, have DynamicLoaderDarwinKernel
re-set the Target's arch based on the kernel's cpu type / cpu subtype.
llvm-svn: 180962
TestRegisters failing on buildbot on MacOSX. Some registers that were valid for linux/freebsd, were not valid on MacOSX. The tests now allow a register be skipped if it doesn't exist on the host.
llvm-svn: 180961
clang sugarcoats expressions of the sort *(int (*)[3])foo where foo is an int* saying that their type class is Paren
This checkin updates our lookup tables to properly desugar Paren into the actual type of interest
llvm-svn: 180938
support operands with vector types, it now reports
that it cannot interpret expressions that use
vector types. They get sent to the JIT instead.
<rdar://problem/13733651>
llvm-svn: 180899
in debug information more aggressive. Emitting
classes containing these methods causes crashes in
Clang when dealing with complex code bases.
<rdar://problem/12640887>
llvm-svn: 180895
<rdar://problem/13723772>
Modified the lldb_private::Thread to work much better with the OperatingSystem plug-ins. Operating system plug-ins can now return have a "core" key/value pair in each thread dictionary for the OperatingSystemPython plug-ins which allows the core threads to be contained with memory threads. It also allows these memory threads to be stepped, resumed, and controlled just as if they were the actual backing threads themselves.
A few things are introduced:
- lldb_private::Thread now has a GetProtocolID() method which returns the thread protocol ID for a given thread. The protocol ID (Thread::GetProtocolID()) is usually the same as the thread id (Thread::GetID()), but it can differ when a memory thread has its own id, but is backed by an actual API thread.
- Cleaned up the Thread::WillResume() code to do the mandatory parts in Thread::ShouldResume(), and let the thread subclasses override the Thread::WillResume() which is now just a notification.
- Cleaned up ClearStackFrames() implementations so that fewer thread subclasses needed to override them
- Changed the POSIXThread class a bit since it overrode Thread::WillResume(). It is doing the wrong thing by calling "Thread::SetResumeState()" on its own, this shouldn't be done by thread subclasses, but the current code might rely on it so I left it in with a TODO comment with an explanation.
llvm-svn: 180886
- Required for platform-independant handling of general purpose registers (i.e. for core dumps).
Thanks to Samuel Jacob for this patch.
llvm-svn: 180878
AppendMessage("") is called. This idiom is used in a handful of places
right now (e.g. to put space between different threads in 'bt all') but
the empty newline is being omitted instead of emitted.
<rdar://problem/13753830>
llvm-svn: 180841
UInts even if their contents were set as bytes.
This makes expressions using registers work
better, especially with core files.
<rdar://problem/13743427>
llvm-svn: 180810
Enabling LLDB to write to variables that are stored in registers
Previously, this would not work since the Value's Context loses the notion of the data being in a register
We now store an "original" context that comes out of DWARF parsing, and use that context's data when attempting a write
llvm-svn: 180803
finish-swig-Python-LLDB.sh to create a new lldb.diagnose subdirectory
in the LLDB framework; the first diagnostic command in this directory
is diagnose-unwind. There may be others added in the future.
Users can load these diagnostic tools into their session with
"script import lldb.diagnose".
llvm-svn: 180768
std::string
Module::GetSpecificationDescription () const;
This returns the module as "/usr/lib/libfoo.dylib" for normal files (calls "std::string FileSpec::GetPath()" on m_file) but it also might include the object name in case the module is for a .o file in a BSD archive ("/usr/lib/libfoo.a(bar.o)"). Cleaned up necessary logging code to use it.
llvm-svn: 180717
print the disassembly context around $pc -- just print the filename and line number, even if we
can't show the source code. Previously if the source file was not available, lldb would print
the source filename & line number and assembly.
<rdar://problem/13072951>
llvm-svn: 180706
will run xcode-select --print-path to find the currently selected
Xcode developer directory. Mostly useful for when lldb is not being run out
of the /Applications/Xcode.app bundle so it can't locate the iOS or
kernel SDKs.
llvm-svn: 180705
with directories, without increasing the size of the FileSpec object.
GetPath() returns a std::string of the full pathname of the file.
IsDirectory(), IsPipe(), IsRegularFile(), IsSocket(), and IsSymbolicLink()
can be used instead of getting the FileType() and comparing it to an enum.
Update PlatformDarwinKernel to use these new methods.
llvm-svn: 180704
mostly related to management of the stack frame
for the interpreter.
- First, if the expression can be interpreted,
allocate the stack frame in the target process
(to make sure pointers are valid) but only
read/write to the copy in the host's memory.
- Second, keep the memory allocations for the
stack frame and the materialized struct as
member variables of ClangUserExpression. This
avoids memory allocations and deallocations
each time the expression runs.
<rdar://problem/13043685>
llvm-svn: 180664
- Adds unique enums for ymm registers to the ABI and the POSIX register context.
- Reworks the register context data structures to support a union of FXSAVE and XSAVE
--- Allows the same code base to deal with the FPU independent of the availability of AVX.
- Determine if AVX is supported by attempting to read XSAVE using ptrace.
--- Support an extended register set for avx registers if available.
- Provide a mechanism to assemble/parse register halves into a single ymm buffer for use with RegisterValue.
--- Reworked Read/WriteRegister routines to read/write/parse ymm registers.
Adds tests for ymm register write with read-back, and expressions involving ymm registers.
- Tests vary depending on the availability of an avx register set.
Thanks to Daniel and Matt for their reviews.
llvm-svn: 180572
interpreter. They are a legacy from when the IR
interpreter didn't work with materialized values
but rather got values directly from
ClangExpressionDeclMap.
Also updated the #includes for IRInterpreter
accordingly.
llvm-svn: 180565
specially, and make sure we stop. This shouldn't happen, but if it does, the user will probably want to
see it.
<rdar://problem/13273125>
llvm-svn: 180244
There is a new static ObjectFile function you can call:
size_t
ObjectFile::GetModuleSpecifications (const FileSpec &file,
lldb::offset_t file_offset,
ModuleSpecList &specs)
This will fill in "specs" which the details of all the module specs (file + arch + UUID (if there is one) + object name (for BSD archive objects eventually) + file offset to the object in question).
This helps us when a user specifies a file that contains a single architecture, and also helps us when we are given a debug symbol file (like a dSYM file on MacOSX) that contains one or more architectures and we need to be able to match it up to an existing Module that has no debug info.
llvm-svn: 180224
The user was trying to obtain the address-of an std::vector and the experience was more painful than necessary because data formatters were kicking in for vector* objects
We got this right for libc++ - we should get it right for libstdc++ too
llvm-svn: 180219
(normally undefined) as indicating a breakpoint hit, in addition
to the normal (EXC_BREAKPOINT, EXC_ARM_BREAKPOINT) pair.
<rdar://problem/13730366>
llvm-svn: 180216
out of the runtime. This allows calling static methods
on classes whose symbols have been stripped out of the
binary.
<rdar://problem/12042992>
llvm-svn: 180210
not find multiple functions with the same name but
different types. Now we keep track of what types
we've already reported for a function and only elide
functions if we've already reported a conflicting
one.
Also added a test case.
<rdar://problem/11367837>
llvm-svn: 180167
Ashok Thirumurthi