summaryrefslogtreecommitdiffstats
path: root/lldb/source/API/SBFrame.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Handle the case when a variable is only valid in part of the enclosing scopeTamas Berghammer2016-02-251-1/+3
| | | | | | | | | | | 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
* Ignore breakpoints by default in SBFrame::EvaluateExpressionEugene Leviant2016-01-291-0/+3
| | | | llvm-svn: 259185
* Create an expression parser for Go.Ryan Brown2015-11-021-0/+18
| | | | | | | | | | | The Go interpreter doesn't JIT or use LLVM, so this also moves all the JIT related code from UserExpression to a new class LLVMUserExpression. Differential Revision: http://reviews.llvm.org/D13073 Fix merge llvm-svn: 251820
* Fix Clang-tidy modernize-use-nullptr warnings in include/lldb/API and ↵Eugene Zelenko2015-10-311-56/+51
| | | | | | | | source/API; other minor fixes. Other fixes should reduce number of readability-redundant-smartptr-get and readability-implicit-bool-cast. llvm-svn: 251733
* Now persistent expression data no longer lives with the Target, but rather withSean Callanan2015-09-301-1/+1
| | | | | | | | | | the corresponding TypeSystem. This makes sense because what kind of data there is -- and how it can be looked up -- depends on the language. Functionality that is common to all type systems is factored out into PersistentExpressionState. llvm-svn: 248934
* Moved more Clang-specific parts of the expression parser into the Clang plugin.Sean Callanan2015-09-251-1/+1
| | | | | | | | | There are still a bunch of dependencies on the plug-in, but this helps to identify them. There are also a few more bits we need to move (and abstract, for example the ClangPersistentVariables). llvm-svn: 248612
* This patch makes Clang-independent base classes for all the expression types ↵Jim Ingham2015-09-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | that lldb currently vends. Before we had: ClangFunction ClangUtilityFunction ClangUserExpression and code all over in lldb that explicitly made Clang-based expressions. This patch adds an Expression base class, and three pure virtual implementations for the Expression kinds: FunctionCaller UtilityFunction UserExpression You can request one of these expression types from the Target using the Get<ExpressionType>ForLanguage. The Target will then consult all the registered TypeSystem plugins, and if the type system that matches the language can make an expression of that kind, it will do so and return it. Because all of the real expression types need to communicate with their ExpressionParser in a uniform way, I also added a ExpressionTypeSystemHelper class that expressions generically can vend, and a ClangExpressionHelper that encapsulates the operations that the ClangExpressionParser needs to perform on the ClangExpression types. Then each of the Clang* expression kinds constructs the appropriate helper to do what it needs. The patch also fixes a wart in the UtilityFunction that to use it you had to create a parallel FunctionCaller to actually call the function made by the UtilityFunction. Now the UtilityFunction can be asked to vend a FunctionCaller that will run its function. This cleaned up a lot of boiler plate code using UtilityFunctions. Note, in this patch all the expression types explicitly depend on the LLVM JIT and IR, and all the common JIT running code is in the FunctionCaller etc base classes. At some point we could also abstract that dependency but I don't see us adding another back end in the near term, so I'll leave that exercise till it is actually necessary. llvm-svn: 247720
* 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
* This patch separates the generic portion of ClangExpressionVariable, whichSean Callanan2015-09-041-1/+1
| | | | | | | | | stores information about a variable that different parts of LLDB use, from the compiler-specific portion that only the expression parser cares about. http://reviews.llvm.org/D12602 llvm-svn: 246871
* Make many mangled functions that might demangle a name be allowed to specify ↵Greg Clayton2015-07-081-2/+2
| | | | | | a language to use in order to soon support Pascal and Java demangling. Dawn Perchik will take care of making this so. llvm-svn: 241751
* Add a GetDisplayName() API to SBFrame, SBFunction and SBSymbolEnrico Granata2015-07-061-0/+56
| | | | | | | | | | This API is currently a no-op (in the sense that it has the same behavior as the already existing GetName()), but is meant long-term to provide a best-for-visualization version of the name of a function It is still not hooked up to the command line 'bt' command, nor to the 'gui' mode, but I do have ideas on how to make that work going forward rdar://21203242 llvm-svn: 241482
* Add const versions of SBFrame::GetFunctionName and SBFrame::IsInlined.Oleksiy Vyalov2015-06-251-1/+12
| | | | | | http://reviews.llvm.org/D10711 llvm-svn: 240660
* Revert rL240435: "Mark SBFrame::GetFunctionName and SBFrame::IsInlined as ↵Oleksiy Vyalov2015-06-241-2/+2
| | | | | | const.". llvm-svn: 240565
* Mark SBFrame::GetFunctionName and SBFrame::IsInlined as const.Oleksiy Vyalov2015-06-231-2/+2
| | | | llvm-svn: 240435
* Added a new API to SBFrame:Greg Clayton2015-05-281-0/+11
| | | | | | | | | | lldb::addr_t SBFrame::GetCFA(); This gets the CFA (call frame address) of the frame so it allows us to take an address that is on the stack and figure out which thread it comes from. Also modified the heap.py module to be able to find out which variable in a frame's stack frame contains an address. This way when ptr_refs finds a match on the stack, it get then report which variable contains the pointer. llvm-svn: 238393
* Fix SBFrame::FindValue for when only global variables exist.Chaoren Lin2015-03-191-20/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: sc.block->AppendVariables(...) returns 0 if there are no arguments or local variables, but we still need to check for global variables. Test Plan: ``` $ cat test.cpp int i; int main() { } $ lldb test -o 'b main' -o r (lldb) script >>> print lldb.frame.FindValue('i', lldb.eValueTypeVariableGlobal) (int) i = 0 # as opposed to "No value" ``` Reviewers: jingham, ovyalov, vharron, clayborg Reviewed By: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D8464 llvm-svn: 232767
* Don't #include ClangPersistentVariables.h from Process.hZachary Turner2015-03-031-0/+1
| | | | | | | Nothing from this header file was even being referenced in Process.h anyway, so it was a completely unnecessary include. llvm-svn: 231131
* Revert "Revert "I had recently added a new SBFrame::GetVariables() overload ↵Zachary Turner2015-02-171-17/+34
| | | | | | | | | | | with yet another bool argument"" Reverting this commit led to other failures which I did not see at first. This turned out to be an easy problem to fix, so I added SBVariablesOptions.cpp to the CMakeLists.txt. In the future please try to make sure new files are added to CMake. llvm-svn: 229516
* Revert "I had recently added a new SBFrame::GetVariables() overload with yet ↵Zachary Turner2015-02-171-34/+17
| | | | | | | | | | | | | | another bool argument" This reverts commit r228975. It was causing link errors on the Windows bots, since last Thursday. http://lab.llvm.org:8011/builders/lldb-x86-win7-msvc/builds/725 Conflicts: lldb.xcodeproj/project.pbxproj llvm-svn: 229514
* I had recently added a new SBFrame::GetVariables() overload with yet another ↵Enrico Granata2015-02-121-17/+34
| | | | | | | | | | bool argument We talked about it internally - and came to the conclusion that it's time to have an options class This commit adds an SBVariablesOptions class and goes through all the required dance llvm-svn: 228975
* Introduce the notion of "runtime support values"Enrico Granata2015-02-111-0/+25
| | | | | | | | | | | | A runtime support value is a ValueObject whose only purpose is to support some language runtime's operation, but it does not directly provide any user-visible benefit As such, unless the user is working on the runtime support, it is mostly safe for them not to see such a value when debugging It is a language runtime's job to check whether a ValueObject is a support value, and that - in conjunction with a target setting - is used by frame variable and target variable SBFrame::GetVariables gets a new overload with yet another flag to dictate whether to return those support values to the caller - that which defaults to the setting's value rdar://problem/15539930 llvm-svn: 228791
* Rename eExecution*** to eExpression*** to be consistent with the result type.Jim Ingham2014-05-051-1/+1
| | | | llvm-svn: 207945
* Make the Expression Execution result enum available to the SB API layer.Jim Ingham2014-05-051-1/+1
| | | | | | | | | Add a callback that will allow an expression to be cancelled between the expression evaluation stages (for the ClangUserExpressions.) <rdar://problem/16790467>, <rdar://problem/16573440> llvm-svn: 207944
* sweep up -Wformat warnings from gccSaleem Abdulrasool2014-04-041-78/+89
| | | | | | | This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
* Restore the ability of SBFrame::FindValue() to look for file global variablesEnrico Granata2014-02-191-2/+10
| | | | | | This should clean up the new test failures caused by r201614 llvm-svn: 201710
* <rdar://problem/15960553>Enrico Granata2014-02-181-13/+7
| | | | | | Fix a bug where calling SBFrame::FindValue() would cause a copy of all variables in the block to be inserted in the frame's variable list, regardless of whether those same variables were there or not - which means one could end up with a frame with lots of duplicate copies of the same variables llvm-svn: 201614
* Add a setting to allow users to enable expressions that crash LLDB to show ↵Greg Clayton2013-12-061-10/+12
| | | | | | | | up in crash logs. <rdar://problem/11549320> llvm-svn: 196613
* Roll back the changes I made in r193907 which created a new FrameJason Molenda2013-11-041-38/+38
| | | | | | | | | | 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-38/+38
| | | | | | | | | | | | | | | | | | | | | 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
* Fix the logging messages for SBFrame::FindRegister().Jason Molenda2013-07-261-3/+3
| | | | llvm-svn: 187264
* Add an SBFrame::FindRegister() method to make it a littleJason Molenda2013-07-261-0/+58
| | | | | | easier to retrieve a register value. llvm-svn: 187184
* Fixed a few obvious errors pointed out by the static analyzer.Jim Ingham2013-05-151-1/+1
| | | | llvm-svn: 181911
* <rdar://problem/13521159>Greg Clayton2013-03-271-27/+27
| | | | | | | | 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
* Renaming SBValueList::get() to Enrico Granata2013-02-071-2/+2
| | | | | | opaque_ptr since it returns a void* instead of an usable object. llvm-svn: 174673
* Correct logging for function calls that return SBValueListEnrico Granata2013-02-071-2/+2
| | | | llvm-svn: 174670
* <rdar://problem/13107151>Enrico Granata2013-02-071-3/+2
| | | | | | | SBValueList was backed by a ValueObjectList. This caused us to lose track of the additional metadata in the ValueImpl that backs SBValue. This checkin fixes that by backing SBValueList with ValueListImpl (that essentially wraps a vector<SBValue>). llvm-svn: 174638
* Resolve printf formatting warnings on Linux:Daniel Malea2012-11-291-4/+4
| | | | | | | | - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
* Tighten up how we acquire the underlying frame in the SBFrame methods. We ↵Jim Ingham2012-11-291-278/+538
| | | | | | | | | | | | were getting the frame and then getting the run lock. Which means that our frame could have gotten invalidated by stopping between the time we got the frame and assured the the target was stopped. Now we get the run lock first, and THEN resolve the underlying frame object. <rdar://problem/12621607> llvm-svn: 168838
* <rdar://problem/12437442>Enrico Granata2012-10-221-10/+13
| | | | | | | | | | | Given our implementation of ValueObjects we could have a scenario where a ValueObject has a dynamic type of Foo* at one point, and then its dynamic type changes to Bar* If Bar* has synthetic children enabled, by the time we figure that out, our public API is already vending SBValues wrapping a DynamicVO, instead of a SyntheticVO and there was no trivial way for us to change the SP inside an SBValue on the fly This checkin reimplements SBValue in terms of a wrapper, ValueImpl, that allows this substitutions on-the-fly by overriding GetSP() to do The Right Thing (TM) As an additional bonus, GetNonSyntheticValue() now works, and we can get rid of the ForceDisableSyntheticChildren idiom in ScriptInterpreterPython Lastly, this checkin makes sure the synthetic VOs get the correct m_value and m_data from their parents (prevented summaries from working in some cases) llvm-svn: 166426
* API cleanup.Greg Clayton2012-10-161-4/+4
| | | | llvm-svn: 166070
* Add the ability to set timeout & "run all threads" options both from the ↵Jim Ingham2012-10-161-9/+21
| | | | | | | | | | "expr" command and from the SB API's that evaluate expressions. <rdar://problem/12457211> llvm-svn: 166062
* Implementing an Options class for EvaluateExpression() in order to make the ↵Enrico Granata2012-09-051-9/+6
| | | | | | signature more compact and make it easy to 'just run an expression' llvm-svn: 163239
* <rdar://problem/11757916>Greg Clayton2012-08-291-0/+2
| | | | | | | | | | | | 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
* Rework how the API mutex is acquired when filling out an ExecutionContext ↵Jim Ingham2012-08-221-45/+64
| | | | | | | | | | | | | | | | | from an ExecutionContextRef, particularly in the SBThread & SBFrame interfaces. Instead of filling the whole context & then getting the API mutex, we now get only the target, acquire the API mutex from it, then fill out the rest of the context. This removes a race condition where you get a ThreadSP, then wait on the API mutex while another command Destroy's the Thread you've just gotten. Also fixed the ExecutionContextRef::Get*SP calls so they don't return invalid objects. Also fixed the ExecutionContext::Has*Scope calls so they don't claim to have a scope if the object representing that scope has been destroyed. Also fixed a think-o in Thread::IsValid which was causing it to return the opposite of the desired value. <rdar://problem/11995490> llvm-svn: 162401
* Ran the static analyzer on the codebase and found a few things.Greg Clayton2012-07-171-1/+1
| | | | llvm-svn: 160338
* <rdar://problem/11870357>Greg Clayton2012-07-141-1/+1
| | | | | | Allow "frame variable" to find ivars without the need for "this->" or "self->". llvm-svn: 160211
* rdar://problem/10996978 - Fixing an issue where crash reports for the ↵Enrico Granata2012-05-291-2/+4
| | | | | | expression parser might include symbols from the user's application llvm-svn: 157631
* Found one more place where the OkayToDiscard needs to be consulted.Jim Ingham2012-05-111-1/+6
| | | | | | | Also changed the defaults for SBThread::Step* to not delete extant plans. Also added some test cases to test more complex stepping scenarios. llvm-svn: 156667
* We take the API mutex first and the stop mutex second in general, so do it ↵Jim Ingham2012-04-191-4/+2
| | | | | | here as well. llvm-svn: 155077
* The API lock was getting dropped too soon in GetVariables. ↵Jim Ingham2012-04-131-5/+2
| | | | | | GetValueObjectForFrameVariable could run the target (to get dynamic values) and that requires the target lock. llvm-svn: 154711
OpenPOWER on IntegriCloud