summaryrefslogtreecommitdiffstats
path: root/lldb/source/API/SBFrame.cpp
Commit message (Collapse)AuthorAgeFilesLines
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-061-1483/+1225
| | | | | | | | | | | | | | | | | | | | | | | *** 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
* Added support for thread local variables on all Apple OS variants.Greg Clayton2016-07-011-26/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We had support that assumed that thread local data for a variable could be determined solely from the module in which the variable exists. While this work for linux, it doesn't work for Apple OSs. The DWARF for thread local variables consists of location opcodes that do something like: DW_OP_const8u (x) DW_OP_form_tls_address or DW_OP_const8u (x) DW_OP_GNU_push_tls_address The "x" is allowed to be anything that is needed to determine the location of the variable. For Linux "x" is the offset within the TLS data for a given executable (ModuleSP in LLDB). For Apple OS variants, it is the file address of the data structure that contains a pthread key that can be used with pthread_getspecific() and the offset needed. This fix passes the "x" along to the thread: virtual lldb::addr_t lldb_private::Thread::GetThreadLocalData(const lldb::ModuleSP module, lldb::addr_t tls_file_addr); Then this is passed along to the DynamicLoader::GetThreadLocalData(): virtual lldb::addr_t lldb_private::DynamicLoader::GetThreadLocalData(const lldb::ModuleSP module, const lldb::ThreadSP thread, lldb::addr_t tls_file_addr); This allows each DynamicLoader plug-in do the right thing for the current OS. The DynamicLoaderMacOSXDYLD was modified to be able to grab the pthread key from the data structure that is in memory and call "void *pthread_getspecific(pthread_key_t key)" to get the value of the thread local storage and it caches it per thread since it never changes. I had to update the test case to access the thread local data before trying to print it as on Apple OS variants, thread locals are not available unless they have been accessed at least one by the current thread. I also added a new lldb::ValueType named "eValueTypeVariableThreadLocal" so that we can ask SBValue objects for their ValueType and be able to tell when we have a thread local variable. <rdar://problem/23308080> llvm-svn: 274366
* Make all the SBFrame API's take the target lock.Jim Ingham2016-06-101-14/+43
| | | | | | | | | | For some reason, the conversion to taking the target lock when acquiring the ExecutionContext was only done for some of the functions here. That was allowing lock inversion in some complex uses. <rdar://problem/26705635> llvm-svn: 272354
* second pass over removal of Mutex and ConditionSaleem Abdulrasool2016-05-191-47/+47
| | | | llvm-svn: 270024
* Take the API lock in SBThread::IsValid & SBFrame::IsValid.Jim Ingham2016-05-071-1/+14
| | | | | | | | The IsValid calls can try to reconstruct the thread & frame, which can take various internal locks. This can cause A/B locking issues with the Target lock, so these calls need to that the Target lock. llvm-svn: 268828
* Fix TestGetVariables.py so it works correctly. We had duplicate static ↵Greg Clayton2016-04-291-1/+9
| | | | | | values showing up as we would find static variables in the Block and also in the compile unit. We now make sure a variable hasn't been added to the list before we add it. llvm-svn: 268101
* API: fix a -Wunused-variable warningSaleem Abdulrasool2016-04-211-0/+2
| | | | | | | expr_log is only conditionally used via preprocessing. Ensure that we guard the definition accordingly. NFC. llvm-svn: 267001
* 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
OpenPOWER on IntegriCloud