f59388aa57559d7d074613d65b88abacfd699845 |
|
14-Sep-2012 |
Jim Ingham <jingham@apple.com> |
Make the unwinding of the stack part of "thread return" work, and add the thread return command. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@163867 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/RegisterContext.cpp
|
f4124deeb9532044a38c0774ced872f2709347da |
|
21-Feb-2012 |
Greg Clayton <gclayton@apple.com> |
Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr objects for the backlink to the lldb_private::Process. The issues we were running into before was someone was holding onto a shared pointer to a lldb_private::Thread for too long, and the lldb_private::Process parent object would get destroyed and the lldb_private::Thread had a "Process &m_process" member which would just treat whatever memory that used to be a Process as a valid Process. This was mostly happening for lldb_private::StackFrame objects that had a member like "Thread &m_thread". So this completes the internal strong/weak changes. Documented the ExecutionContext and ExecutionContextRef classes so that our LLDB developers can understand when and where to use ExecutionContext and ExecutionContextRef objects. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@151009 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/RegisterContext.cpp
|
289afcb5e26c2527a0d2e71f84e780b86bbcf90a |
|
18-Feb-2012 |
Greg Clayton <gclayton@apple.com> |
The second part in thread hardening the internals of LLDB where we make the lldb_private::StackFrame objects hold onto a weak pointer to the thread object. The lldb_private::StackFrame objects the the most volatile objects we have as when we are doing single stepping, frames can often get lost or thrown away, only to be re-created as another object that still refers to the same frame. We have another bug tracking that. But we need to be able to have frames no longer be able to get the thread when they are not part of a thread anymore, and this is the first step (this fix makes that possible but doesn't implement it yet). Also changed lldb_private::ExecutionContextScope to return shared pointers to all objects in the execution context to further thread harden the internals. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@150871 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/RegisterContext.cpp
|
2f085c6ca2895663687dca704589478ff040b849 |
|
15-May-2011 |
Greg Clayton <gclayton@apple.com> |
Added the ability to get the return value from a ThreadPlanCallFunction thread plan. In order to get the return value, you can call: void ThreadPlanCallFunction::RequestReturnValue (lldb::ValueSP &return_value_sp); This registers a shared pointer to a return value that will get filled in if everything goes well. After the thread plan is run the return value will be extracted for you. Added an ifdef to be able to switch between the LLVM MCJIT and the standand JIT. We currently have the standard JIT selected because we have some work to do to get the MCJIT fuctioning properly. Added the ability to call functions with 6 argument in the x86_64 ABI. Added the ability for GDBRemoteCommunicationClient to detect if the allocate and deallocate memory packets are supported and to not call allocate memory ("_M") or deallocate ("_m") if we find they aren't supported. Modified the ProcessGDBRemote::DoAllocateMemory(...) and ProcessGDBRemote::DoDeallocateMemory(...) to be able to deal with the allocate and deallocate memory packets not being supported. If they are not supported, ProcessGDBRemote will switch to calling "mmap" and "munmap" to allocate and deallocate memory instead using our trivial function call support. Modified the "void ProcessGDBRemote::DidLaunchOrAttach()" to correctly ignore the qHostInfo triple information if any was specified in the target. Currently if the target only specifies an architecture when creating the target: (lldb) target create --arch i386 a.out Then the vendor, os and environemnt will be adopted by the target. If the target was created with any triple that specifies more than the arch: (lldb) target create --arch i386-unknown-unknown a.out Then the target will maintain its triple and not adopt any new values. This can be used to help force bare board debugging where the dynamic loader for static files will get used and users can then use "target modules load ..." to set addressses for any files that are desired. Added back some convenience functions to the lldb_private::RegisterContext class for writing registers with unsigned values. Also made all RegisterContext constructors explicit to make sure we know when an integer is being converted to a RegisterValue. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@131370 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/RegisterContext.cpp
|
061b79dbf1fefaf157d414747e98a463a0f32eda |
|
09-May-2011 |
Greg Clayton <gclayton@apple.com> |
While implementing unwind information using UnwindAssemblyInstEmulation I ran into some cleanup I have been wanting to do when reading/writing registers. Previously all RegisterContext subclasses would need to implement: virtual bool ReadRegisterBytes (uint32_t reg, DataExtractor &data); virtual bool WriteRegisterBytes (uint32_t reg, DataExtractor &data, uint32_t data_offset = 0); There is now a new class specifically designed to hold register values: lldb_private::RegisterValue The new register context calls that subclasses must implement are: virtual bool ReadRegister (const RegisterInfo *reg_info, RegisterValue ®_value) = 0; virtual bool WriteRegister (const RegisterInfo *reg_info, const RegisterValue ®_value) = 0; The RegisterValue class must be big enough to handle any register value. The class contains an enumeration for the value type, and then a union for the data value. Any integer/float values are stored directly in an appropriate host integer/float. Anything bigger is stored in a byte buffer that has a length and byte order. The RegisterValue class also knows how to copy register value bytes into in a buffer with a specified byte order which can be used to write the register value down into memory, and this does the right thing when not all bytes from the register values are needed (getting a uint8 from a uint32 register value..). All RegiterContext and other sources have been switched over to using the new regiter value class. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@131096 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/RegisterContext.cpp
|
4fdf7602bedd8be648f3c549074cf13d90a05f03 |
|
20-Mar-2011 |
Greg Clayton <gclayton@apple.com> |
Split all of the core of LLDB.framework/lldb.so into a static archive that can be linked against. LLDB.framework/lldb.so exports a very controlled API. Splitting the API into a static library allows other tools (debugserver for now) to use the power of the LLDB debugger core, yet not export it as its API is not portable or maintainable. The Host layer and many of the other internal only APIs can now be statically linked against. Now LLDB.framework/lldb.so links against "liblldb-core.a" instead of compiling the .o files only for the shared library. This fix is only for compiling with Xcode as the Makefile based build already does this. The Xcode projecdt compiler has been changed to LLVM. Anyone using Xcode 3 will need to manually change the compiler back to GCC 4.2, or update to Xcode 4. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@127963 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/RegisterContext.cpp
|
cd548034fa23113e995b8463d14f910ba2f7298c |
|
01-Feb-2011 |
Greg Clayton <gclayton@apple.com> |
Endian patch from Kirk Beitz that allows better cross platform building. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@124643 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/RegisterContext.cpp
|
a875b64ab8d258b28959d05eea37cb5dfdd72730 |
|
09-Jan-2011 |
Greg Clayton <gclayton@apple.com> |
Put more smarts into the RegisterContext base class. Now the base class has a method: void RegisterContext::InvalidateIfNeeded (bool force); Each time this function is called, when "force" is false, it will only call the pure virtual "virtual void RegisterContext::InvalideAllRegisters()" if the register context's stop ID doesn't match that of the process. When the stop ID doesn't match, or "force" is true, the base class will clear its cached registers and the RegisterContext will update its stop ID to match that of the process. This helps make it easier to correctly flush the register context (possibly from multiple locations depending on when and where new registers are availabe) without inadvertently clearing the register cache when it doesn't need to be. Modified the ProcessGDBRemote plug-in to be much more efficient when it comes to: - caching the expedited registers in the stop reply packets (we were ignoring these before and it was causing us to read at least three registers every time we stopped that were already supplied in the stop reply packet). - When a thread has no stop reason, don't keep asking for the thread stopped info. Prior to this fix we would continually send a qThreadStopInfo packet over and over when any thread stop info was requested. We now note the stop ID that the stop info was requested for and avoid multiple requests. Cleaned up some of the expression code to not look for ClangExpressionVariable objects up by name since they are now shared pointers and we can just look for the exact pointer match and avoid possible errors. Fixed an bug in the ValueObject code that would cause children to not be displayed. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@123127 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/RegisterContext.cpp
|
08d7d3ae16110aa68ed40c161eac8571aeb94cd9 |
|
06-Jan-2011 |
Greg Clayton <gclayton@apple.com> |
Fixed issues with RegisterContext classes and the subclasses. There was an issue with the way the UnwindLLDB was handing out RegisterContexts: it was making shared pointers to register contexts and then handing out just the pointers (which would get put into shared pointers in the thread and stack frame classes) and cause double free issues. MallocScribble helped to find these issues after I did some other cleanup. To help avoid any RegisterContext issue in the future, all code that deals with them now returns shared pointers to the register contexts so we don't end up with multiple deletions. Also now that the RegisterContext class doesn't require a stack frame, we patched a memory leak where a StackFrame object was being created and leaked. Made the RegisterContext class not have a pointer to a StackFrame object as one register context class can be used for N inlined stack frames so there is not a 1 - 1 mapping. Updates the ExecutionContextScope part of the RegisterContext class to never return a stack frame to indicate this when it is asked to recreate the execution context. Now register contexts point to the concrete frame using a concrete frame index. Concrete frames are all of the frames that are actually formed on the stack of a thread. These concrete frames can be turned into one or more user visible frames due to inlining. Each inlined stack frame has the exact same register context (shared via shared pointers) as any parent inlined stack frames all the way up to the concrete frame itself. So now the stack frames and the register contexts should behave much better. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@122976 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/RegisterContext.cpp
|
8280cbe80c79bc206335831dd732e0f9fb69c519 |
|
25-Oct-2010 |
Jason Molenda <jmolenda@apple.com> |
Check in the native lldb unwinder. Not yet enabled as the default unwinder but there are no known backtrace problems with the code at this point. Added 'log enable lldb unwind' to help diagnose backtrace problems; this output needs a little refining but it's a good first step. eh_frame information is currently read unconditionally - the code is structured to allow this to be delayed until it's actually needed. There is a performance hit when you have to parse the eh_frame information for any largeish executable/library so it's necessary to avoid if possible. It's confusing having both the UnwindPlan::RegisterLocation struct and the RegisterConextLLDB::RegisterLocation struct, I need to rename one of them. The writing of registers isn't done in the RegisterConextLLDB subclass yet; neither is the running of complex DWARF expressions from eh_frame (e.g. used for _sigtramp on Mac OS X). git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@117256 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/RegisterContext.cpp
|
a830adbcd63d1995a01e6e18da79893c1426ca43 |
|
04-Oct-2010 |
Greg Clayton <gclayton@apple.com> |
There are now to new "settings set" variables that live in each debugger instance: settings set frame-format <string> settings set thread-format <string> This allows users to control the information that is seen when dumping threads and frames. The default values are set such that they do what they used to do prior to changing over the the user defined formats. This allows users with terminals that can display color to make different items different colors using the escape control codes. A few alias examples that will colorize your thread and frame prompts are: settings set frame-format 'frame #${frame.index}: \033[0;33m${frame.pc}\033[0m{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{ \033[0;35mat \033[1;35m${line.file.basename}:${line.number}}\033[0m\n' settings set thread-format 'thread #${thread.index}: \033[1;33mtid\033[0;33m = ${thread.id}\033[0m{, \033[0;33m${frame.pc}\033[0m}{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{, \033[1;35mstop reason\033[0;35m = ${thread.stop-reason}\033[0m}{, \033[1;36mname = \033[0;36m${thread.name}\033[0m}{, \033[1;32mqueue = \033[0;32m${thread.queue}}\033[0m\n' A quick web search for "colorize terminal output" should allow you to see what you can do to make your output look like you want it. The "settings set" commands above can of course be added to your ~/.lldbinit file for permanent use. Changed the pure virtual void ExecutionContextScope::Calculate (ExecutionContext&); To: void ExecutionContextScope::CalculateExecutionContext (ExecutionContext&); I did this because this is a class that anything in the execution context heirarchy inherits from and "target->Calculate (exe_ctx)" didn't always tell you what it was really trying to do unless you look at the parameter. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@115485 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/RegisterContext.cpp
|
3a4ea24572fad1e22525f8efb718d49d41e30398 |
|
10-Sep-2010 |
Jason Molenda <jmolenda@apple.com> |
The first part of an lldb native stack unwinder. The Unwind and RegisterContext subclasses still need to be finished; none of this code is used by lldb at this point (unless you call into it by hand). The ObjectFile class now has an UnwindTable object. The UnwindTable object has a series of FuncUnwinders objects (Function Unwinders) -- one for each function in that ObjectFile we've backtraced through during this debug session. The FuncUnwinders object has a few different UnwindPlans. UnwindPlans are a generic way of describing how to find the canonical address of a given function's stack frame (the CFA idea from DWARF/eh_frame) and how to restore the caller frame's register values, if they have been saved by this function. UnwindPlans are created from different sources. One source is the eh_frame exception handling information generated by the compiler for unwinding an exception throw. Another source is an assembly language inspection class (UnwindAssemblyProfiler, uses the Plugin architecture) which looks at the instructions in the funciton prologue and describes the stack movements/register saves that are done. Two additional types of UnwindPlans that are worth noting are the "fast" stack UnwindPlan which is useful for making a first pass over a thread's stack, determining how many stack frames there are and retrieving the pc and CFA values for each frame (enough to create StackFrameIDs). Only a minimal set of registers is recovered during a fast stack walk. The final UnwindPlan is an architectural default unwind plan. These are provided by the ArchDefaultUnwindPlan class (which uses the plugin architecture). When no symbol/function address range can be found for a given pc value -- when we have no eh_frame information and when we don't have a start address so we can't examine the assembly language instrucitons -- we have to make a best guess about how to unwind. That's when we use the architectural default UnwindPlan. On x86_64, this would be to assume that rbp is used as a stack pointer and we can use that to find the caller's frame pointer and pc value. It's a last-ditch best guess about how to unwind out of a frame. There are heuristics about when to use one UnwindPlan versues the other -- this will all happen in the still-begin-written UnwindLLDB subclass of Unwind which runs the UnwindPlans. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@113581 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/RegisterContext.cpp
|
24943d2ee8bfaa7cf5893e4709143924157a5c1e |
|
08-Jun-2010 |
Chris Lattner <sabre@nondot.org> |
Initial checkin of lldb code from internal Apple repo. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@105619 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Target/RegisterContext.cpp
|