Commit Graph

95 Commits

Author SHA1 Message Date
Daniel Malea 89660bf795 More Linux warnings fixes (remove default labels as needed):
- as per http://llvm.org/docs/CodingStandards.html#don-t-use-default-labels-in-fully-covered-switches-over-enumerations

Patch by Matt Kopec!

llvm-svn: 169633
2012-12-07 20:51:09 +00:00
Daniel Malea 93a64300f8 Fix Linux build warnings due to redefinition of macros:
- add new header lldb-python.h to be included before other system headers
- short term fix (eventually python dependencies must be cleaned up)

Patch by Matt Kopec!

llvm-svn: 169341
2012-12-05 00:20:57 +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
Enrico Granata 48ea80f9ff Reimplementing SBValue/ValueObject.GetValueAsUnsigned() in terms of appropriate calls in Scalar - Making sure Scalar does the right thing when casting signed values to unsigned ones.
llvm-svn: 166618
2012-10-24 20:24:39 +00:00
Enrico Granata 7e137e3d8f <rdar://problem/12481949> Fixing SBValue.GetValueAsSigned() to do the right thing when dealing with a 32-bit negative value
llvm-svn: 166603
2012-10-24 18:14:21 +00:00
Jim Ingham a7dfb665e3 Watchpoints remember the type of the expression or variable they were set with, and use
it to print the old and new values.
Temporarily disable the "out of scope" checking since it didn't work correctly, and was
not what people generally expected watchpoints to be doing.  

llvm-svn: 166472
2012-10-23 07:20:06 +00:00
Greg Clayton 4a792072ce <rdar://problem/12493007>
Added a new API call to help efficiently determine if a SBValue could have children:

     bool
     SBValue::MightHaveChildren ();
     
This is inteneded to be used bui GUI programs that need to show if a SBValue needs a disclosure triangle when displaying a hierarchical type in a tree view without having to complete the type (by calling SBValue::GetNumChildren()) as completing the type is expensive.

llvm-svn: 166460
2012-10-23 01:50:10 +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 10de09044e <rdar://problem/12462744> Implement a new SBDeclaration class to wrap an lldb_private::Declaration - make a GetDeclaration() API on SBValue to return a declaration. This will only work for vroot variables as they are they only objects for which we currently provide a valid Declaration
llvm-svn: 165672
2012-10-10 22:54:17 +00:00
Greg Clayton 43e0af06b4 Stop using the "%z" size_t modifier and cast all size_t values to uint64_t. Some platforms don't support this modification.
llvm-svn: 164148
2012-09-18 18:04:04 +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 48cdc58f0a SBValue::GetTypeName and SBValue::GetByteSize might have to update the dynamic value - which might involve running code. So they need to take the stop lock & target locks.
<rdar://problem/12001204>

llvm-svn: 162250
2012-08-21 01:46:35 +00:00
Johnny Chen 974759fd8b Funnel the old API call SBValue::Watch (bool resolve_location, bool read, bool write) to the one which takes an SBError.
llvm-svn: 157969
2012-06-05 00:14:15 +00:00
Johnny Chen d3761a7e10 Cannot break the existing API client of SBValue::Watch(bool resolve_location, bool read, bool write).
Leave this method in the codebase for a while.

llvm-svn: 157967
2012-06-04 23:45:50 +00:00
Johnny Chen b90827e66c rdar://problem/11584012
Refactorings of watchpoint creation APIs so that SBTarget::WatchAddress(), SBValue::Watch(), and SBValue::WatchPointee()
now take an additional 'SBError &error' parameter (at the end) to contain the reason if there is some failure in the
operation.  Update 'watchpoint set variable/expression' commands to take advantage of that.

Update existing test cases to reflect the API change and add test cases to verify that the SBError mechanism works for
SBTarget::WatchAddress() by passing an invalid watch_size.

llvm-svn: 157964
2012-06-04 23:19:54 +00:00
Greg Clayton eac87f87ce Patch that fixes log messages in SBValue.cpp from Lau Sennels.
llvm-svn: 157949
2012-06-04 20:13:23 +00:00
Enrico Granata 07a4ac22ed <rdar://problem/11239650> Fixing a bug where the SetValueFromCString() method failed to operate on dynamic values. The fix consists in making the set operation fall through to the parent. We only actually allow this if the dynamic value is at a 0-offset from the parent, or the new value is 0. Other scenarios would need agreement on the actual meaning of the set operation (do we keep offsetting? do we just assume the user knows what they are doing?) so we prevent them, and let the expression parser deal with the complexity
llvm-svn: 156422
2012-05-08 21:25:06 +00:00
Enrico Granata 886147f0ac First part of a fix to make GetNonSyntheticValue() work correctly
llvm-svn: 156397
2012-05-08 18:47:08 +00:00
Jim Ingham cbbdaa9378 Couple more places in SBValue where you need to take the run-lock.
llvm-svn: 154683
2012-04-13 18:30:20 +00:00
Greg Clayton c9858e4d05 Added logging when API calls try to do something that shouldn't be done when the process is stopped by having logging calls that end with "error: process is running".
Also test for the process to be stopped when many SBValue API calls are made to make sure it is safe to evaluate values, children of values and much more.

llvm-svn: 154160
2012-04-06 02:17:47 +00:00
Enrico Granata c5bc412cf6 Synthetic values are now automatically enabled and active by default. SBValue is set up to always wrap a synthetic value when one is available.
A new setting enable-synthetic-value is provided on the target to disable this behavior.
There also is a new GetNonSyntheticValue() API call on SBValue to go back from synthetic to non-synthetic. There is no call to go from non-synthetic to synthetic.
The test suite has been changed accordingly.
Fallout from changes to type searching: an hack has to be played to make it possible to use maps that contain std::string due to the special name replacement operated by clang
Fixing a test case that was using libstdcpp instead of libc++ - caught as a consequence of said changes to type searching

llvm-svn: 153495
2012-03-27 02:35:13 +00:00
Greg Clayton 84db9105d2 <rdar://problem/11113279>
Fixed type lookups to "do the right thing". Prior to this fix, looking up a type using "foo::bar" would result in a type list that contains all types that had "bar" as a basename unless the symbol file was able to match fully qualified names (which our DWARF parser does not). 

This fix will allow type matches to be made based on the basename and then have the types that don't match filtered out. Types by name can be fully qualified, or partially qualified with the new "bool exact_match" parameter to the Module::FindTypes() method.

This fixes some issue that we discovered with dynamic type resolution as well as improves the overall type lookups in LLDB.

llvm-svn: 153482
2012-03-26 23:03:23 +00:00