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
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
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
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
Jason Molenda