summaryrefslogtreecommitdiffstats
path: root/lldb/source/Target/StackFrame.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Fix a bug caught by adding LLVM_NODISCARD to StringRef.Zachary Turner2016-11-211-1/+1
| | | | llvm-svn: 287598
* Fix warnings and errors introduced with UUID changes.Zachary Turner2016-11-171-6/+8
| | | | llvm-svn: 287208
* Make GetValueForVariableExpression use StringRef.Zachary Turner2016-11-171-546/+523
| | | | | | | | | Also significantly reduced the indentation level by use of early returns, and simplified some of the logic by using StringRef functions such as consumeInteger() and getAsInteger() instead of strtoll, etc. llvm-svn: 287189
* Don't allow direct access to StreamString's internal buffer.Zachary Turner2016-11-161-29/+29
| | | | | | | | | | | | | | | This is a large API change that removes the two functions from StreamString that return a std::string& and a const std::string&, and instead provide one function which returns a StringRef. Direct access to the underlying buffer violates the concept of a "stream" which is intended to provide forward only access, and makes porting to llvm::raw_ostream more difficult in the future. Differential Revision: https://reviews.llvm.org/D26698 llvm-svn: 287152
* Make ValueObjectMemory::Create accept StringRefs.Zachary Turner2016-11-121-1/+1
| | | | llvm-svn: 286726
* Make lldb -Werror clean on Windows.Zachary Turner2016-10-051-0/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D25247 llvm-svn: 283344
* Introduced a null check to avoid a crash in a test on i386.Sean Callanan2016-09-291-0/+4
| | | | llvm-svn: 282653
* Fix -Wcovered-switch-default warning in StackFrame.cppEd Maste2016-09-211-2/+0
| | | | | | | | The switch coveres all possible values. If a new one is added in the future the compiler will start warning, providing a notification that the switch needs updating. llvm-svn: 282111
* add stop column highlighting supportTodd Fiala2016-09-211-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change introduces optional marking of the column within a source line where a thread is stopped. This marking will show up when the source code for a thread stop is displayed, when the debug info knows the column information, and if the optional column marking is enabled. There are two separate methods for handling the marking of the stop column: * via ANSI terminal codes, which are added inline to the source line display. The default ANSI mark-up is to underline the column. * via a pure text-based caret that is added in the appropriate column in a newly-inserted blank line underneath the source line in question. There are some new options that control how this all works. * settings set stop-show-column This takes one of 4 values: * ansi-or-caret: use the ANSI terminal code mechanism if LLDB is running with color enabled; if not, use the caret-based, pure text method (see the "caret" mode below). * ansi: only use the ANSI terminal code mechanism to highlight the stop line. If LLDB is running with color disabled, no stop column marking will occur. * caret: only use the pure text caret method, which introduces a newly-inserted line underneath the current line, where the only character in the new line is a caret that highlights the stop column in question. * none: no stop column marking will be attempted. * settings set stop-show-column-ansi-prefix This is a text format that indicates the ANSI formatting code to insert into the stream immediately preceding the column where the stop column character will be marked up. It defaults to ${ansi.underline}; however, it can contain any valid LLDB format codes, e.g. ${ansi.fg.red}${ansi.bold}${ansi.underline} * settings set stop-show-column-ansi-suffix This is the text format that specifies the ANSI terminal codes to end the markup that was started with the prefix described above. It defaults to: ${ansi.normal}. This should be sufficient for the common cases. Significant leg-work was done by Adrian Prantl. (Thanks, Adrian!) differential review: https://reviews.llvm.org/D20835 reviewers: clayborg, jingham llvm-svn: 282105
* More cleanup in `frame diagnose,` eliminating a bunch of messy cases.Sean Callanan2016-09-141-60/+20
| | | | llvm-svn: 281545
* Replaced two instances of std::function with auto.Sean Callanan2016-09-141-4/+3
| | | | | | | | Thanks to Zachary Turner for the suggestion. It's distasteful that the actual type of the lambda can't be spelled out, but it should be evident from the definition of the lambda body. llvm-svn: 281536
* Cleaned up a little bit of redundant code in 'frame diagnose.`Sean Callanan2016-09-141-11/+19
| | | | llvm-svn: 281534
* Cleaned up the code that handles function return addresses in "frame diagnose."Sean Callanan2016-09-141-18/+33
| | | | llvm-svn: 281428
* Cleaned up some of the "frame diagnose" code to use Operands as currency.Sean Callanan2016-09-131-13/+11
| | | | | | | Also added some utility functions around Operands to make code easier and more compact to write. llvm-svn: 281398
* Fix about a dozen compile warningsIlia K2016-09-121-5/+6
| | | | | | | | | | | | | | | | | | | | | | Summary: It fixes the following compile warnings: 1. '0' flag ignored with precision and ‘%d’ gnu_printf format 2. enumeral and non-enumeral type in conditional expression 3. format ‘%d’ expects argument of type ‘int’, but argument 4 has type ... 4. enumeration value ‘...’ not handled in switch 5. cast from type ‘const uint64_t* {aka ...}’ to type ‘int64_t* {aka ...}’ casts away qualifiers 6. extra ‘;’ 7. comparison between signed and unsigned integer expressions 8. variable ‘register_operand’ set but not used 9. control reaches end of non-void function Reviewers: jingham, emaste, zturner, clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D24331 llvm-svn: 281191
* I'm experimenting with changing how the mixed source & assemblyJason Molenda2016-09-081-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | mode in lldb works. I've been discussing this with Jim Ingham, Greg Clayton, and Kate Stone for the past week or two. Previously lldb would print three source lines (centered on the line table entry line for the current line) followed by the assembly. It would print the context information (module`function + offset) before those three lines of source. Now lldb will print up to two lines before/after the line table entry. It prints two '*' characters for the line table line to make it clear what line is showing assembly. There is one line of whitespace before/after the source lines so the separation between source & assembly is clearer. I don't print the context line (module`function + offset). I stop printing context lines if it's a different line table entry, or if it's a source line I've already printed as context to another source line. If I have two line table entries one after another for the same source line (I get these often with clang - with different column information in them), I only print the source line once. I'm also using the target.process.thread.step-avoid-regexp setting (which keeps you from stepping into STL functions that have been inlined into your own code) and avoid printing any source lines from functions that match that regexp. When lldb disassembles into a new function, it will try to find the declaration line # for the function and print all of the source lines between the decl and the first line table entry (usually a { curly brace) so we have a good chance of including the arguments, at least with the debug info emitted by clang. Finally, the # of source lines of context to show has been separated from whether we're doing mixed source & assembly or not. Previously specifying 0 lines of context would turn off mixed source & assembly. I think there's room for improvement, and maybe some bugs I haven't found yet, but it's in good enough shape to upstream and iterate at this point. I'm not sure how best to indicate which source line is the actual line table # versus context lines. I'm using '**' right now. Both Kate and Greg had the initial idea to reuse '->' (normally used to indicate "currently executing source line") - I tried it but I wasn't thrilled, I'm too used to the established meaning of ->. Greg had the interesting idea of avoiding context source lines only in two line table entries in the same source file. So we'd print two lines before & after a source line, and then the next line table entry (if it was on the next source line after those two context lines) we'd display only the following two lines -- the previous two had just been printed. If an inline source line was printed between these two, though, we'd print the context lines for both of them. It's an interesting idea, and I want to see how it works with both -O0 and -O3 codegen where we have different amounts of inlining. <rdar://problem/27961419> llvm-svn: 280906
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-061-1965/+1715
| | | | | | | | | | | | | | | | | | | | | | | *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
* Fix build breakage in r280692Pavel Labath2016-09-061-1/+1
| | | | | | | | | The commit introduced an array of const objects, which libstdc++ does not like. Make the object non-const. Also fix a compiler warning while I'm in there. llvm-svn: 280697
* Added the "frame diagnose" command and use its output to make crash info better.Sean Callanan2016-09-061-0/+583
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When a process stops due to a crash, we get the crashing instruction and the crashing memory location (if there is one). From the user's perspective it is often unclear what the reason for the crash is in a symbolic sense. To address this, I have added new fuctionality to StackFrame to parse the disassembly and reconstruct the sequence of dereferneces and offsets that were applied to a known variable (or fuction retrn value) to obtain the invalid pointer. This makes use of enhancements in the disassembler, as well as new information provided by the DWARF expression infrastructure, and is exposed through a "frame diagnose" command. It is also used to provide symbolic information, when available, in the event of a crash. The algorithm is very rudimentary, and it needs a bunch of work, including - better parsing for assembly, preferably with help from LLVM - support for non-Apple platforms - cleanup of the algorithm core, preferably to make it all work in terms of Operands instead of register/offset pairs - improvement of the GetExpressioPath() logic to make prettier expression paths, and - better handling of vtables. I welcome all suggestios, improvements, and testcases. llvm-svn: 280692
* Typo corrections identified by codespellEd Maste2016-07-191-1/+1
| | | | | | | | | Submitted by giffunip@yahoo.com; I fixed a couple of nearby errors and incorrect changes in the patch. llvm.org/pr27634 llvm-svn: 275983
* second pass over removal of Mutex and ConditionSaleem Abdulrasool2016-05-191-103/+87
| | | | llvm-svn: 270024
* Keep original source path and mapped path in LineEntryTed Woodward2016-05-111-8/+1
| | | | | | | | | | | | | | | | | Summary: The "file" variable in a LineEntry was mapped using target.source-map, except when stepping through inlined code. This patch adds a new variable to LineEntry, "original_file", that contains the original file from the debug info. "file" will continue to (possibly) be mapped. Some code has been changed to use "original_file". This is code dealing with symbols. Code dealing with source files will still use "file". Reviewers, please confirm that these particular changes are correct. Tests run on Ubuntu 12.04 show no regression. Reviewers: clayborg, jingham Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D20135 llvm-svn: 269250
* When building the list of variables we're going to write "using ↵Jim Ingham2016-04-261-2/+5
| | | | | | | | | $_lldb_local_vars" statements for, be sure not to include variables that have no locations. We wouldn't be able to realize them, and that will cause all expressions to fail. llvm-svn: 267500
* Fix StackFrame::GetVariables(...) function that was broken by 261858 when ↵Greg Clayton2016-04-251-1/+1
| | | | | | | | lambda functions were added to Block::AppendBlockVariables(). The Stackframe::GetVariables(...) function should get all variables regardless if they are in scope. This wasn't caught by the test suite so I added a test for it. llvm-svn: 267478
* Improve the 'type lookup' command such that it guesses to use the current's ↵Enrico Granata2016-03-151-1/+19
| | | | | | frame language as the one to start searching from. llvm-svn: 263592
* Add support for DW_OP_push_object_address in dwarf expressionsTamas Berghammer2016-02-261-2/+9
| | | | | | | | | Additionally fix the type of some dwarf expression where we had a confusion between scalar and load address types after a dereference. Differential revision: http://reviews.llvm.org/D17604 llvm-svn: 262014
* Handle the case when a variable is only valid in part of the enclosing scopeTamas Berghammer2016-02-251-1/+6
| | | | | | | | | | | DWARF stores this information in the DW_AT_start_scope attribute. This CL add support for this attribute and also changes the functions displaying frame variables to only display the variables currently in scope. Differential revision: http://reviews.llvm.org/D17449 llvm-svn: 261858
* Fix Clang-tidy modernize-use-nullptr warnings in some files in ↵Eugene Zelenko2016-02-181-64/+47
| | | | | | source/Target; other minor fixes. llvm-svn: 261242
* Add -Wimplicit-fallthrough command line option to clang inJason Molenda2016-02-161-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | the xcode project file to catch switch statements that have a case that falls through unintentionally. Define LLVM_FALLTHROUGH to indicate instances where a case has code and intends to fall through. This should be in llvm/Support/Compiler.h; Peter Collingbourne originally checked in there (r237766), then reverted (r237941) because he didn't have time to mark up all the 'case' statements that were intended to fall through. I put together a patch to get this back in llvm http://reviews.llvm.org/D17063 but it hasn't been approved in the past week. I added a new lldb-private-defines.h to hold the definition for now. Every place in lldb where there is a comment that the fall-through is intentional, I added LLVM_FALLTHROUGH to silence the warning. I haven't tried to identify whether the fallthrough is a bug or not in the other places. I haven't tried to add this to the cmake option build flags. This warning will only work for clang. This build cleanly (with some new warnings) on macosx with clang under xcodebuild, but if this causes problems for people on other configurations, I'll back it out. llvm-svn: 260930
* Fix a thinko in StackFrame::GetInScopeVariableList.Siva Chandra2016-02-021-1/+1
| | | | | | | | | | Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D16745 llvm-svn: 259607
* [LLDB] Switch to assembly view if source is movedMohit K. Bhakkad2015-12-031-4/+13
| | | | | | | | Reviewers: clayborg, jingham, jasonmolenda. Subscribers: jaydeep, bhushan, sagar, nitesh.jain,lldb-commits. Differential Revision: http://reviews.llvm.org/D12877 llvm-svn: 254588
* Fix up LLDB for a change in the way clang represents anonymous unions such ↵Enrico Granata2015-11-191-3/+35
| | | | | | that the 'frame variable' command can still find the members of such union as if they were top-level variables in the current scope llvm-svn: 253613
* Use eAddressClassCode for address lookup for opcodes for stack framesTamas Berghammer2015-09-071-1/+1
| | | | | | | | | | | | | | | It is required because of the following edge case on arm: bx <addr> Non-tail call in a no return function [data-pool] Marked with $d mapping symbol The return address of the function call will point to the data pool but we have to treat it as code so the StackFrame can calculate the symbols correctly. Differential revision: http://reviews.llvm.org/D12556 llvm-svn: 246958
* Set the default language to use when evaluating to that of the frame's CU.Dawn Perchik2015-09-041-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | * Use the frame's context (instead of just the target's) when evaluating, so that the language of the frame's CU can be used to select the compiler and/or compiler options to use when parsing the expression. This allows for modules built with mixed languages to be parsed in the context of their frame. * Add all C and C++ language variants when determining the language options to set. * Enable C++ language options when language is C or ObjC as a workaround since the expression parser uses features of C++ to capture values. * Enable ObjC language options when language is C++ as a workaround for ObjC requirements. * Disable C++11 language options when language is C++03. * Add test TestMixedLanguages.py to check that the language being used for evaluation is that of the frame. * Fix test TestExprOptions.py to check for C++11 instead of C++ since C++ has to be enabled for C, and remove redundant expr --language test for ObjC. * Fix TestPersistentPtrUpdate.py to not require C++11 in C. Reviewed by: clayborg, spyffe, jingham Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D11102 llvm-svn: 246829
* Final bit of type system cleanup that abstracts declaration contexts into ↵Greg Clayton2015-08-241-9/+9
| | | | | | | | | | | | | | | | | | | | lldb_private::CompilerDeclContext and renames ClangType to CompilerType in many accessors and functions. Create a new "lldb_private::CompilerDeclContext" class that will replace all direct uses of "clang::DeclContext" when used in compiler agnostic code, yet still allow for conversion to clang::DeclContext subclasses by clang specific code. This completes the abstraction of type parsing by removing all "clang::" references from the SymbolFileDWARF. The new "lldb_private::CompilerDeclContext" class abstracts decl contexts found in compiler type systems so they can be used in internal API calls. The TypeSystem is required to support CompilerDeclContexts with new pure virtual functions that start with "DeclContext" in the member function names. Converted all code that used lldb_private::ClangNamespaceDecl over to use the new CompilerDeclContext class and removed the ClangNamespaceDecl.cpp and ClangNamespaceDecl.h files. Removed direct use of clang APIs from SBType and now use the abstract type systems to correctly explore types. Bulk renames for things that used to return a ClangASTType which is now CompilerType: "Type::GetClangFullType()" to "Type::GetFullCompilerType()" "Type::GetClangLayoutType()" to "Type::GetLayoutCompilerType()" "Type::GetClangForwardType()" to "Type::GetForwardCompilerType()" "Value::GetClangType()" to "Value::GetCompilerType()" "Value::SetClangType (const CompilerType &)" to "Value::SetCompilerType (const CompilerType &)" "ValueObject::GetClangType ()" to "ValueObject::GetCompilerType()" many more renames that are similar. llvm-svn: 245905
* Fix resolution conflict between global and class static variables in C++Paul Herman2015-08-181-1/+1
| | | | llvm-svn: 245381
* Don't #include "lldb-python.h" from anywhere.Zachary Turner2015-05-291-2/+0
| | | | | | | | | | | | | Since interaction with the python interpreter is moving towards being more isolated, we won't be able to include this header from normal files anymore, all includes of it should be localized to the python library which will live under source/bindings/API/Python after a future patch. None of the files that were including this header actually depended on it anyway, so it was just a dead include in every single instance. llvm-svn: 238581
* Remove duplicated code for synthetic array members.Bruce Mitchener2015-02-261-1/+1
| | | | | | | | | | | | | | | | | Summary: The code for GetSyntheticArrayMemberFromPointer and GetSyntheticArrayMemberFromArray was identical, so just collapse the the methods into one. Reviewers: granata.enrico, clayborg Reviewed By: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D7911 llvm-svn: 230708
* Change the default disassembly format again. First attempt atJason Molenda2015-02-131-1/+3
| | | | | | | | | | | | | | | | changing it was in r219544 - after living on that for a few months, I wanted to take another crack at this. The disassembly-format setting still exists and the old format can be user specified with a setting like ${current-pc-arrow}${addr-file-or-load}{ <${function.name-without-args}${function.concrete-only-addr-offset-no-padding}>}: This patch was discussed in http://reviews.llvm.org/D7578 <rdar://problem/19726421> llvm-svn: 229186
* Get rid of Debugger::FormatPrompt() and replace it with the new FormatEntity ↵Greg Clayton2015-02-041-2/+3
| | | | | | | | | | | | | | | | | | | class. Why? Debugger::FormatPrompt() would run through the format prompt every time and parse it and emit it piece by piece. It also did formatting differently depending on which key/value pair it was parsing. The new code improves on this with the following features: 1 - Allow format strings to be parsed into a FormatEntity::Entry which can contain multiple child FormatEntity::Entry objects. This FormatEntity::Entry is a parsed version of what was previously always done in Debugger::FormatPrompt() so it is more efficient to emit formatted strings using the new parsed FormatEntity::Entry. 2 - Allows errors in format strings to be shown immediately when setting the settings (frame-format, thread-format, disassembly-format 3 - Allows auto completion by implementing a new OptionValueFormatEntity and switching frame-format, thread-format, and disassembly-format settings over to using it. 4 - The FormatEntity::Entry for each of the frame-format, thread-format, disassembly-format settings only replaces the old one if the format parses correctly 5 - Combines all consecutive string values together for efficient output. This means all "${ansi.*}" keys and all desensitized characters like "\n" "\t" "\0721" "\x23" will get combined with their previous strings 6 - ${*.script:} (like "${var.script:mymodule.my_var_function}") have all been switched over to use ${script.*:} "${script.var:mymodule.my_var_function}") to make the format easier to parse as I don't believe anyone was using these format string power user features. 7 - All key values pairs are defined in simple C arrays of entries so it is much easier to add new entries. These changes pave the way for subsequent modifications where we can modify formats to do more (like control the width of value strings can do more and add more functionality more easily like string formatting to control the width, printf formats and more). llvm-svn: 228207
* Fix a corner case with the handling of noreturn functions.Jason Molenda2014-11-081-0/+24
| | | | | | | | | | | | | | | | | | If a noreturn function was the last function in a section, we wouldn't correctly back up the saved-pc value into the correct section leading to us showing the wrong function in the backtrace. Also add a backtrace test with an attempt to elicit this particular layout. It happens to work out with clang -Os but other compilers may not quite get the same layout I'm getting at that opt setting. We'll still be exercising the basic noreturn handling in the unwinder even if we don't get one function at the very end of a section. <rdar://problem/16051613> llvm-svn: 221575
* Expose the type-info flags at the public API layer. These flags provide much ↵Enrico Granata2014-10-211-2/+2
| | | | | | more informational content to consumers of the LLDB API than the existing TypeClass. Part of the fix for rdar://18517593 llvm-svn: 220322
* Add a new disassembly-format specification so that the disassemblerJason Molenda2014-10-101-1/+3
| | | | | | | | | | | | | | | | | | | | | output style can be customized. Change the built-in default to be more similar to gdb's disassembly formatting. The disassembly-format for a gdb-like output is ${addr-file-or-load} <${function.name-without-args}${function.concrete-only-addr-offset-no-padding}>: The disassembly-format for the lldb style output is {${function.initial-function}{${module.file.basename}`}{${function.name-without-args}}:\n}{${function.changed}\n{${module.file.basename}`}{${function.name-without-args}}:\n}{${current-pc-arrow} }{${addr-file-or-load}}: The two backticks in the lldb style formatter triggers the sub-expression evaluation in CommandInterpreter::PreprocessCommand() so you can't use that one as-is ... changing to use ' characters instead of ` would work around that. <rdar://problem/9885398> llvm-svn: 219544
* Add a mutex lock to StackFrame to protect race conditions forJason Molenda2014-10-021-3/+20
| | | | | | | | | updating its ivars. We've had a lot of crash reports and careful analysis shows that we've got multiple threads operating on the same StackFrame objects, changing their m_sc and m_flags ivars. <rdar://problem/18406111> llvm-svn: 218845
* Fix typos.Bruce Mitchener2014-07-081-1/+1
| | | | llvm-svn: 212553
* Allow specification of no source display on stop.Todd Fiala2014-07-071-5/+4
| | | | | | | | See http://llvm.org/bugs/show_bug.cgi?id=20149 for details. Change by Randy Smith. llvm-svn: 212485
* sanitise sign comparisonsSaleem Abdulrasool2014-04-021-2/+2
| | | | | | | | This is a mechanical change addressing the various sign comparison warnings that are identified by both clang and gcc. This helps cleanup some of the warning spew that occurs during builds. llvm-svn: 205390
* Add new ivars to StackFrame so it can represent a stack collectedJason Molenda2013-11-041-1/+48
| | | | | | | | | | | | | | | | | | at some point in the past. We may have nothing more than a pc value for this type of stack frame -- hopefully we'll have a pc and a stop_id so we can track module loads and unloads over time and symbolicate the pc at the correct point in time. Also add a flag to indicate if the CFA for the frame is available (a bit different from a CFA of LLDB_INVALID_ADDRESS) and also an overall setting to indicate whether this is a history stack frame or not. A history stack frame may not have a CFA, it may not have a register context, it may not have variables, it may not have a frame pointer or a stack pointer. <rdar://problem/15314068> llvm-svn: 193987
* Roll back the changes I made in r193907 which created a new FrameJason Molenda2013-11-041-35/+37
| | | | | | | | | | pure virtual base class and made StackFrame a subclass of that. As I started to build on top of that arrangement today, I found that it wasn't working out like I intended. Instead I'll try sticking with the single StackFrame class -- there's too much code duplication to make a more complicated class hierarchy sensible I think. llvm-svn: 193983
* Add a new base class, Frame. It is a pure virtual function whichJason Molenda2013-11-021-37/+35
| | | | | | | | | | | | | | | | | | | | | defines a protocol that all subclasses will implement. StackFrame is currently the only subclass and the methods that Frame vends are nearly identical to StackFrame's old methods. Update all callers to use Frame*/Frame& instead of pointers to StackFrames. This is almost entirely a mechanical change that touches a lot of the code base so I'm committing it alone. No new functionality is added with this patch, no new subclasses of Frame exist yet. I'll probably need to tweak some of the separation, possibly moving some of StackFrame's methods up in to Frame, but this is a good starting point. <rdar://problem/15314068> llvm-svn: 193907
OpenPOWER on IntegriCloud