5f35a4be95aed0e5b2cb36f7d785bcbfc67284ae |
|
29-Nov-2012 |
Daniel Malea <daniel.malea@intel.com> |
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@168945 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/UnwindMacOSXFrameBackchain.cpp
|
49ce8969d3154e1560106cfe530444c09410f217 |
|
29-Aug-2012 |
Greg Clayton <gclayton@apple.com> |
<rdar://problem/11757916> 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. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@162860 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/UnwindMacOSXFrameBackchain.cpp
|
0c31d3d3a4a1d00d53346d8a23b0519f47e55d1f |
|
07-Mar-2012 |
Greg Clayton <gclayton@apple.com> |
<rdar://problem/10997402> This fix really needed to happen as a previous fix I had submitted for calculating symbol sizes made many symbols appear to have zero size since the function that was calculating the symbol size was calling another function that would cause the calculation to happen again. This resulted in some symbols having zero size when they shouldn't. This could then cause infinite stack traces and many other side affects. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@152244 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/UnwindMacOSXFrameBackchain.cpp
|
137e5230e8dfb1287dd7c5eaa943a39078e1fd8d |
|
21-Feb-2012 |
Benjamin Kramer <benny.kra@googlemail.com> |
Remove a ton of implicit narrowing conversions for C++11 compatibility. git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@151071 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/UnwindMacOSXFrameBackchain.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/Plugins/Process/Utility/UnwindMacOSXFrameBackchain.cpp
|
591cf15899706efe8878a0718daec056e1ffd442 |
|
21-Oct-2011 |
Jim Ingham <jingham@apple.com> |
Lock the Unwinder before accessing it. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@142632 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/UnwindMacOSXFrameBackchain.cpp
|
d3475a20433c7e7e94ff185b3c5640f14704b8cf |
|
04-Mar-2011 |
Greg Clayton <gclayton@apple.com> |
Allow the macosx frame backchain to use 32/64 bit as the selector when chosing which FP back-chain methods to use since we can rely upon generic register numbers after that. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@127044 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/UnwindMacOSXFrameBackchain.cpp
|
940b103224f3062578c7a7e6e76d8bf4a7956f2a |
|
23-Feb-2011 |
Greg Clayton <gclayton@apple.com> |
Abtracted all mach-o and ELF out of ArchSpec. This patch is a modified form of Stephen Wilson's idea (thanks for the input Stephen!). What I ended up doing was: - Got rid of ArchSpec::CPU (which was a generic CPU enumeration that mimics the contents of llvm::Triple::ArchType). We now rely upon the llvm::Triple to give us the machine type from llvm::Triple::ArchType. - There is a new ArchSpec::Core definition which further qualifies the CPU core we are dealing with into a single enumeration. If you need support for a new Core and want to debug it in LLDB, it must be added to this list. In the future we can allow for dynamic core registration, but for now it is hard coded. - The ArchSpec can now be initialized with a llvm::Triple or with a C string that represents the triple (it can just be an arch still like "i386"). - The ArchSpec can still initialize itself with a architecture type -- mach-o with cpu type and subtype, or ELF with e_machine + e_flags -- and this will then get translated into the internal llvm::Triple::ArchSpec + ArchSpec::Core. The mach-o cpu type and subtype can be accessed using the getter functions: uint32_t ArchSpec::GetMachOCPUType () const; uint32_t ArchSpec::GetMachOCPUSubType () const; But these functions are just converting out internal llvm::Triple::ArchSpec + ArchSpec::Core back into mach-o. Same goes for ELF. All code has been updated to deal with the changes. This should abstract us until later when the llvm::TargetSpec stuff gets finalized and we can then adopt it. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@126278 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/UnwindMacOSXFrameBackchain.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/Plugins/Process/Utility/UnwindMacOSXFrameBackchain.cpp
|
4fb08150367853dae24bb92904356788e919a72f |
|
30-Aug-2010 |
Greg Clayton <gclayton@apple.com> |
Clarified the intent of the SymbolContextScope class in the header documentation. Symbol now inherits from the symbol context scope so that the StackID can use a "SymbolContextScope *" instead of a blockID (which could have been the same as some other blockID from another symbol file). Modified the stacks that are created on subsequent stops to reuse the previous stack frame objects which will allow for some internal optimization using pointer comparisons during stepping. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@112495 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/UnwindMacOSXFrameBackchain.cpp
|
b04e7a805310f2f2cc77947a8b263de9061617ae |
|
24-Aug-2010 |
Greg Clayton <gclayton@apple.com> |
Got a lot of the kinks worked out in the inline support after debugging more complex inlined examples. StackFrame classes don't have a "GetPC" anymore, they have "GetFrameCodeAddress()". This is because inlined frames will have a PC value that is the same as the concrete frame that owns the inlined frame, yet the code locations for the frame can be different. We also need to be able to get the real PC value for a given frame so that variables evaluate correctly. To get the actual PC value for a frame you can use: addr_t pc = frame->GetRegisterContext()->GetPC(); Some issues with the StackFrame stomping on its own symbol context were resolved which were causing the information to change for a frame when the stack ID was calculated. Also the StackFrame will now correctly store the symbol context resolve flags for any extra bits of information that were looked up (if you ask for a block only and you find one, you will alwasy have the compile unit and function). git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@111964 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/UnwindMacOSXFrameBackchain.cpp
|
33ed170599d41fe407a4dcf5f0875c75e1ad1375 |
|
24-Aug-2010 |
Greg Clayton <gclayton@apple.com> |
Added support for inlined stack frames being represented as real stack frames which is now on by default. Frames are gotten from the unwinder as concrete frames, then if inline frames are to be shown, extra information to track and reconstruct these frames is cached with each Thread and exanded as needed. I added an inline height as part of the lldb_private::StackID class, the class that helps us uniquely identify stack frames. This allows for two frames to shared the same call frame address, yet differ only in inline height. Fixed setting breakpoint by address to not require addresses to resolve. A quick example: % cat main.cpp % ./build/Debug/lldb test/stl/a.out Current executable set to 'test/stl/a.out' (x86_64). (lldb) breakpoint set --address 0x0000000100000d31 Breakpoint created: 1: address = 0x0000000100000d31, locations = 1 (lldb) r Launching 'a.out' (x86_64) (lldb) Process 38031 Stopped * thread #1: tid = 0x2e03, pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280, stop reason = breakpoint 1.1, queue = com.apple.main-thread 277 278 _CharT* 279 _M_data() const 280 -> { return _M_dataplus._M_p; } 281 282 _CharT* 283 _M_data(_CharT* __p) (lldb) bt thread #1: tid = 0x2e03, stop reason = breakpoint 1.1, queue = com.apple.main-thread frame #0: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280 frame #1: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_rep() const at /usr/include/c++/4.2.1/bits/basic_string.h:288 frame #2: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::size() const at /usr/include/c++/4.2.1/bits/basic_string.h:606 frame #3: pc = 0x0000000100000d31, where = a.out`main [inlined] operator<< <char, std::char_traits<char>, std::allocator<char> > at /usr/include/c++/4.2.1/bits/basic_string.h:2414 frame #4: pc = 0x0000000100000d31, where = a.out`main + 33 at /Volumes/work/gclayton/Documents/src/lldb/test/stl/main.cpp:14 frame #5: pc = 0x0000000100000d08, where = a.out`start + 52 Each inline frame contains only the variables that they contain and each inlined stack frame is treated as a single entity. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@111877 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/UnwindMacOSXFrameBackchain.cpp
|
c0418155302e97d37571dfa41a38f6b33759a5e0 |
|
07-Jul-2010 |
Greg Clayton <gclayton@apple.com> |
typedef fixups, patch from Jean-Daniel Dupas. git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@107794 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/Utility/UnwindMacOSXFrameBackchain.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/Plugins/Process/Utility/UnwindMacOSXFrameBackchain.cpp
|