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
<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
(normally undefined) as indicating a breakpoint hit, in addition
to the normal (EXC_BREAKPOINT, EXC_ARM_BREAKPOINT) pair.
<rdar://problem/13730366>
llvm-svn: 180216
Providing a dummy RegisterContext to secure against faulty Python OS plugins that do not return a valid RegisterContext
The RegisterContextDummy exports a PC with a constant 0xFFFFFFFFFFFFFFFF value
llvm-svn: 180033
Fixed the GDB remote with the python OS plug-in to not show core threads when they aren't desired and also to have the threads "to the right thing" when continuing.
llvm-svn: 179912
defines a Return Address register (e.g. lr on arm) but the RA register
hasn't been saved anywhere yet -- it is still in a live reg.
<rdar://problem/13503130>
llvm-svn: 179431
Made some fixes to the OperatingSystemPython class:
- If any thread dictionary contains any "core=N" key/value pairs then the threads obtained from the lldb_private::Process itself will be placed inside the ThreadMemory threads and will be used to get the information for a thread.
- Cleaned up all the places where a thread inside a thread was causing problems
llvm-svn: 179405
LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down.
All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down.
llvm-svn: 178191
StackFrame assumes m_sc is additive, but m_sc can lose its target. So now the SymbolContext::Clear() method takes a bool that indicates if the target should be cleared. Modified all existing code to properly set the bool argument.
llvm-svn: 175953
- generate-vers.pl has to be called by cmake to generate the version number
- parallel builds not yet supported; dependency on clang must be explicitly specified
Tested on Linux.
- Building on Mac will require code-signing logic to be implemented.
- Building on Windows will require OS-detection logic and some selective directory inclusion
Thanks to Carlo Kok (who originally prepared these CMakefiles for Windows) and Ben Langmuir
who ported them to Linux!
llvm-svn: 175795
to have it not named appropriately. Also in StopInfoMachException, we aren't testing for software or not software, just
whether the thing is a breakpoint we set. So don't use "software"...
llvm-svn: 175241
Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary.
So I defined a new "lldb::offset_t" which should be used for all file offsets.
After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed.
Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections.
llvm-svn: 173463
Modify UnwindLLDB::SearchForSavedLocationForRegister so if the register
save locations for a register mid-stack is in another register (or in the
same register, indicating the reg wasn't modified in this frame), don't
return that as a found location. Keep iterating down the array of frames
until a concrete location/value for the register is found, or until we
get to frame 0 where the reg value can be used as-is.
If lldb was trying to backtrace a program that blew out its stack via
recursion and the unwind instructions had some kind of
this-reg-is-saved-in-that-reg instruction, lldb would revert to doing
a recursive search for a concrete value and blow out its own stack.
llvm-svn: 172887
Added the ability for OS plug-ins to lazily populate the thread this. The python OS plug-in classes can now implement the following method:
class OperatingSystemPlugin:
def create_thread(self, tid, context):
# Return a dictionary for a new thread to create it on demand
This will add a new thread to the thread list if it doesn't already exist. The example code in lldb/examples/python/operating_system.py has been updated to show how this call us used.
Cleaned up the code in PythonDataObjects.cpp/h:
- renamed all classes that started with PythonData* to be Python*.
- renamed PythonArray to PythonList. Cleaned up the code to use inheritance where
- Centralized the code that does ref counting in the PythonObject class to a single function.
- Made the "bool PythonObject::Reset(PyObject *)" function be virtual so each subclass can correctly check to ensure a PyObject is of the right type before adopting the object.
- Cleaned up all APIs and added new constructors for the Python* classes to they can all construct form:
- PyObject *
- const PythonObject &
- const lldb::ScriptInterpreterObjectSP &
Cleaned up code in ScriptInterpreterPython:
- Made calling python functions safer by templatizing the production of value formats. Python specifies the value formats based on built in C types (long, long long, etc), and code often uses typedefs for uint32_t, uint64_t, etc when passing arguments down to python. We will now always produce correct value formats as the templatized code will "do the right thing" all the time.
- Fixed issues with the ScriptInterpreterPython::Locker where entering the session and leaving the session had a bunch of issues that could cause the "lldb" module globals lldb.debugger, lldb.target, lldb.process, lldb.thread, and lldb.frame to not be initialized.
llvm-svn: 172873
controlled by the --unwind-on-error flag, and --ignore-breakpoint which separately controls behavior when a called
function hits a breakpoint. For breakpoints, we don't unwind, we either stop, or ignore the breakpoint, which makes
more sense.
Also make both these behaviors globally settable through "settings set".
Also handle the case where a breakpoint command calls code that ends up re-hitting the breakpoint. We were recursing
and crashing. Now we just stop without calling the second command.
<rdar://problem/12986644>
<rdar://problem/9119325>
llvm-svn: 172503
Python OS plug-ins now fetch thread registers lazily.
Also changed SBCommandInterpreter::HandleCommand() to not take the API lock. The logic here is that from the command line you can execute a command that might result in another thread (like the private process thread) to execute python or run any code that can re-enter the public API. When this happens, a deadlock immediately occurs for things like "process launch" and "process attach".
llvm-svn: 171901
- remove unused members
- add NO_PEDANTIC to selected Makefiles
- fix return values (removed NULL as needed)
- disable warning about four-char-constants
- remove unneeded const from operator*() declaration
- add missing lambda function return types
- fix printf() with no format string
- change sizeof to use a type name instead of variable name
- fix Linux ProcessMonitor.cpp to be 32/64 bit friendly
- disable warnings emitted by swig-generated C++ code
Patch by Matt Kopec!
llvm-svn: 169645
- add new header lldb-python.h to be included before other system headers
- short term fix (eventually python dependencies must be cleaned up)
Patch by Matt Kopec!
llvm-svn: 169341
allowed volatile registers to be returned up the stack. That leads
to unexpected/incorrect values provided to the user and we need to
avoid that.
<rdar://problem/12714247>
llvm-svn: 168123
RegisterContextKDP_i386 was not correctly writing registers due to missing "virtual" keywords. Added the virtual keywords and made the functions pure virtual to ensure subclasses can't get away without implementing these functions.
llvm-svn: 167066
Full UnwindPlan is trying to do an impossible unwind; in that case
invalidate the Full UnwindPlan and replace it with the architecture
default unwind plan.
This is a scenario that happens occasionally with arm unwinds in
particular; the instruction analysis based full unwindplan can
mis-parse the functions and the stack walk stops prematurely. Now
we can do a simpleminded frame-chain walk to find the caller frame
and continue the unwind. It's not ideal but given the complicated
nature of analyzing the arm functions, and the lack of eh_frame
information on iOS, it is a distinct improvement and fixes some
long-standing problems with the unwinder on that platform.
This is fixing <rdar://problem/12091421>. I may re-use this
invalidate feature in the future if I can identify other cases where
the full unwindplan's unwind information is clearly incorrect.
This checkin also includes some cleanup for the volatile register
definition in the arm ABI plugin for <rdar://problem/10652166>
although work remains to be done for that bug.
llvm-svn: 166757
must push something on the stack for a function call or not. In
x86, the stack pointer is decremented when the caller's pc is saved
on the stack. In arm, the stack pointer and frame pointer don't
necessarily have to change for a function call, although most
functions need to use some stack space during their execution.
Use this information in the RegisterContextLLDB to detect invalid
unwind scenarios more accurately.
<rdar://problem/12348574>
llvm-svn: 166005
Then make the Thread a Broadcaster, and get it to broadcast when the selected frame is changed (but only from the Command Line) and when Thread::ReturnFromFrame
changes the stack.
Made the Driver use this notification to print the new thread status rather than doing it in the command.
Fixed a few places where people were setting their broadcaster class by hand rather than using the static broadcaster class call.
<rdar://problem/12383087>
llvm-svn: 165640
it is unconditionally present now.
ObjectContainerBSDArchive::CreateInstance %z8.8x is not a valid printf arg specifier, %8.8zx would work
for size_t arg but this arg is addr_t. use %8.8llx and cast up to uint64_t.
ObjectFile::FindPlugin ditto.
DynamicRegisterInfo::SetRegisterInfo ifdef this function out if LLDB_DISABLE_PYTHON.
llvm-svn: 163599
Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes:
- Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file".
- modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly
- Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was.
- modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile()
Cleaned up header includes a bit as well.
llvm-svn: 162860
Added code the initialize the register context in the OperatingSystemPython plug-in with the new PythonData classes, and added a test OperatingSystemPython module in lldb/examples/python/operating_system.py that we can use for testing.
llvm-svn: 162530
when you want to find the caller's saved pc, you look up the return address
register and use that. On arm, for instance, this would be the contents of
the link register (lr).
If the eh_frame CIE defines an RA, record that fact in the UnwindPlan.
When we're finding a saved register, if it's the pc, lok for the location
of the return address register instead.
<rdar://problem/12062310>
llvm-svn: 162167
