Commit Graph

124 Commits

Author SHA1 Message Date
Greg Clayton 63a27afae3 Added support for thread local variables on all Apple OS variants.
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
2016-07-01 17:17:23 +00:00
Jim Ingham c481c7eeb4 Make all the SBFrame API's take the target lock.
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
2016-06-10 00:37:44 +00:00
Saleem Abdulrasool bb19a13c0b second pass over removal of Mutex and Condition
llvm-svn: 270024
2016-05-19 05:13:57 +00:00
Jim Ingham 7fa7dc36fe Take the API lock in SBThread::IsValid & SBFrame::IsValid.
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
2016-05-07 00:54:56 +00:00
Greg Clayton 349213f941 Fix TestGetVariables.py so it works correctly. We had duplicate static 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
2016-04-29 21:00:38 +00:00
Saleem Abdulrasool 358efd6557 API: fix a -Wunused-variable warning
expr_log is only conditionally used via preprocessing.  Ensure that we guard the
definition accordingly.  NFC.

llvm-svn: 267001
2016-04-21 16:56:02 +00:00
Tamas Berghammer 72ac8a840f Handle the case when a variable is only valid in part of the enclosing scope
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
2016-02-25 12:23:37 +00:00
Eugene Leviant 24785bd0b8 Ignore breakpoints by default in SBFrame::EvaluateExpression
llvm-svn: 259185
2016-01-29 10:48:11 +00:00
Ryan Brown 998c8a1c1c Create an expression parser for Go.
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
2015-11-02 19:30:40 +00:00
Eugene Zelenko dbb0abbf47 Fix Clang-tidy modernize-use-nullptr warnings in include/lldb/API and source/API; other minor fixes.
Other fixes should reduce number of readability-redundant-smartptr-get and readability-implicit-bool-cast.

llvm-svn: 251733
2015-10-31 01:22:59 +00:00
Sean Callanan 8f1f9a1be3 Now persistent expression data no longer lives with the Target, but rather with
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
2015-09-30 19:57:57 +00:00
Sean Callanan 4dbb271fcc Moved more Clang-specific parts of the expression parser into the Clang plugin.
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
2015-09-25 20:35:58 +00:00
Jim Ingham 151c032c86 This patch makes Clang-independent base classes for all the expression types 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
2015-09-15 21:13:50 +00:00
Tamas Berghammer 25b9f7ebd3 Use eAddressClassCode for address lookup for opcodes for stack frames
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
2015-09-07 09:58:09 +00:00
Sean Callanan bc8ac34e61 This patch separates the generic portion of ClangExpressionVariable, which
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
2015-09-04 20:49:51 +00:00
Greg Clayton ddaf6a7259 Make many mangled functions that might demangle a name be allowed to specify 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
2015-07-08 22:32:23 +00:00
Enrico Granata c1f705c229 Add a GetDisplayName() API to SBFrame, SBFunction and SBSymbol
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
2015-07-06 18:28:46 +00:00
Oleksiy Vyalov 05f75e9ffb Add const versions of SBFrame::GetFunctionName and SBFrame::IsInlined.
http://reviews.llvm.org/D10711

llvm-svn: 240660
2015-06-25 17:41:41 +00:00
Oleksiy Vyalov 6345fe3eb3 Revert rL240435: "Mark SBFrame::GetFunctionName and SBFrame::IsInlined as const.".
llvm-svn: 240565
2015-06-24 18:35:36 +00:00
Oleksiy Vyalov a5d9c1d32f Mark SBFrame::GetFunctionName and SBFrame::IsInlined as const.
llvm-svn: 240435
2015-06-23 18:21:55 +00:00
Greg Clayton 424a5dbc73 Added a new API to SBFrame:
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
2015-05-28 03:27:22 +00:00
Chaoren Lin 0efb51a072 Fix SBFrame::FindValue for when only global variables exist.
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
2015-03-19 22:00:13 +00:00
Zachary Turner af0f45f1c9 Don't #include ClangPersistentVariables.h from Process.h
Nothing from this header file was even being referenced in
Process.h anyway, so it was a completely unnecessary include.

llvm-svn: 231131
2015-03-03 21:05:17 +00:00
Zachary Turner 51f96eeb24 Revert "Revert "I had recently added a new SBFrame::GetVariables() overload 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
2015-02-17 17:55:50 +00:00
Zachary Turner b3b8922cad Revert "I had recently added a new SBFrame::GetVariables() overload with yet 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
2015-02-17 17:42:05 +00:00
Enrico Granata e0d951db44 I had recently added a new SBFrame::GetVariables() overload with yet another 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
2015-02-12 23:09:17 +00:00
Enrico Granata 560558eb7c Introduce the notion of "runtime support values"
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
2015-02-11 02:35:39 +00:00
Jim Ingham 8646d3c164 Rename eExecution*** to eExpression*** to be consistent with the result type.
llvm-svn: 207945
2014-05-05 02:47:44 +00:00
Jim Ingham 1624a2d3c8 Make the Expression Execution result enum available to the SB API layer.
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
2014-05-05 02:26:40 +00:00
Saleem Abdulrasool 324a103619 sweep up -Wformat warnings from gcc
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
2014-04-04 04:06:10 +00:00
Enrico Granata 8a2a0dfba5 Restore the ability of SBFrame::FindValue() to look for file global variables
This should clean up the new test failures caused by r201614

llvm-svn: 201710
2014-02-19 19:35:13 +00:00
Enrico Granata 08a04327a9 <rdar://problem/15960553>
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
2014-02-18 23:48:11 +00:00
Greg Clayton fb6621ef4b Add a setting to allow users to enable expressions that crash LLDB to show up in crash logs.
<rdar://problem/11549320> 

llvm-svn: 196613
2013-12-06 21:59:52 +00:00
Jason Molenda b57e4a1bc6 Roll back the changes I made in r193907 which created a new Frame
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
2013-11-04 09:33:30 +00:00
Jason Molenda f23bf7432c Add a new base class, Frame. It is a pure virtual function which
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
2013-11-02 02:23:02 +00:00
Jason Molenda 5d35384292 Fix the logging messages for SBFrame::FindRegister().
llvm-svn: 187264
2013-07-26 22:52:30 +00:00
Jason Molenda ad9a53c510 Add an SBFrame::FindRegister() method to make it a little
easier to retrieve a register value.

llvm-svn: 187184
2013-07-26 02:08:48 +00:00
Jim Ingham 5c42d8a87c Fixed a few obvious errors pointed out by the static analyzer.
llvm-svn: 181911
2013-05-15 18:27:08 +00:00
Greg Clayton 5160ce5c72 <rdar://problem/13521159>
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
2013-03-27 23:08:40 +00:00
Enrico Granata 08ec0b6117 Renaming SBValueList::get() to
opaque_ptr since it returns a void* instead of an usable object.

llvm-svn: 174673
2013-02-07 22:57:46 +00:00
Enrico Granata d96f0682e5 Correct logging for function calls that return SBValueList
llvm-svn: 174670
2013-02-07 22:22:27 +00:00
Enrico Granata 85425d77b8 <rdar://problem/13107151>
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
2013-02-07 18:23:56 +00:00
Daniel Malea d01b2953fa Resolve printf formatting warnings on Linux:
- use macros from inttypes.h for format strings instead of OS-specific types

Patch from Matt Kopec!

llvm-svn: 168945
2012-11-29 21:49:15 +00:00
Jim Ingham 7730b9a47a Tighten up how we acquire the underlying frame in the SBFrame methods. We 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
2012-11-29 00:26:19 +00:00
Enrico Granata e3e91517ff <rdar://problem/12437442>
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
2012-10-22 18:18:36 +00:00
Greg Clayton cced1566e2 API cleanup.
llvm-svn: 166070
2012-10-16 22:58:25 +00:00
Jim Ingham 35e1bda695 Add the ability to set timeout & "run all threads" options both from the "expr" command and from
the SB API's that evaluate expressions.

<rdar://problem/12457211>

llvm-svn: 166062
2012-10-16 21:41:58 +00:00
Enrico Granata d4439aa9ed Implementing an Options class for EvaluateExpression() in order to make the signature more compact and make it easy to 'just run an expression'
llvm-svn: 163239
2012-09-05 20:41:26 +00:00
Greg Clayton 1f7460716b <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.

llvm-svn: 162860
2012-08-29 21:13:06 +00:00
Jim Ingham 4fc6cb9c76 Rework how the API mutex is acquired when filling out an ExecutionContext 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
2012-08-22 21:34:33 +00:00