| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 186717
|
|
|
|
|
|
|
|
| |
r186347 (thanks Greg!).
Your mileage may vary depending on the gcc and stl versions in use (see llvm.org/pr15301).
llvm-svn: 186706
|
|
|
|
|
|
| |
- should resolve remaining failures on clang buildbot
llvm-svn: 185576
|
|
|
|
|
|
| |
so LLDB does not read off the end of the array.
llvm-svn: 184877
|
|
|
|
|
|
| |
Hardening the libstdc++ std::map test case against line table changes
llvm-svn: 184265
|
|
|
|
|
|
| |
Hardening the libstdc++ std::vector test case against line table changes
llvm-svn: 184264
|
|
|
|
|
|
|
|
| |
debugging has a "ASTContext" that helps us to use the correct floating point semantics. Now that APFloat supports toString we now use that. If we don't have a target, we still fall back on the old display methodology, but the important formatting should always have a target available and thus use the compiler floating point code.
Modified the test programs to use floating point constants that always will display correctly. We had some numbers that were being rounded, and now that we are using clang, we no longer round them and we get more correct results.
llvm-svn: 183792
|
|
|
|
| |
llvm-svn: 183480
|
|
|
|
|
|
| |
- specify compiler flag -stdlib=libstdc++ only if using clang (not supported in gcc)
llvm-svn: 183333
|
|
|
|
|
|
|
| |
Adding data formatters for std::set, std::multiset and std::multimap for libc++
The underlying data structure is the same as std::map, so this change is very minimal and mostly consists of test cases
llvm-svn: 183323
|
|
|
|
|
|
|
|
|
|
| |
If you want to define a formatter for "array of Foo of any size", ordinarily you would say
-x "Foo \[[0-9]+\]"
this checkin allows you to instead say "Foo[]" (or "Foo []") and LLDB will automatically create the regular expression and add the -x flag on your behalf
llvm-svn: 183272
|
|
|
|
|
|
|
| |
- adding workaround recommended by Greg (-fno-limit-debug-info clang flag)
- filed bug llvm.org/pr16214 against Clang
llvm-svn: 183156
|
|
|
|
|
|
| |
- should resolve remaining buildbot issues with debian/clang builder
llvm-svn: 183044
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixing an issue where formats would not propagate from parents to children in all cases
Details follow:
an SBValue has children and those are fetched along with their values
Now, one calls SBValue::SetFormat() on the parent
Technically, the format choices should propagate onto the children (see ValueObject::GetFormat())
But if the children values are already fetched, they won't notice the format change and won't update themselves
This commit fixes that by making ValueObject::GetValueAsCString() check if any format change intervened from the previous call to the current one
A test case is also added
llvm-svn: 183030
|
|
|
|
|
|
|
|
| |
- The original test now passes on Linux with clang because a breakpoint is hit prior to evaluation of text_list, which improves text coverage.
- The new test fails because 4 steps are requested, and only two occur prior to evaluation of text_list.
--- Note that the loss of every second "next" command can be reproduced using lldb manually with this script.
llvm-svn: 182860
|
|
|
|
|
|
|
|
|
| |
- s/skipOnLinux/skipIfLinux/ to match style of every other decorator
- linkify bugizilla/PR numbers in comments
No intended change in functionality.
llvm-svn: 181913
|
|
|
|
|
|
|
|
| |
on the nexting always "getting it right" to stop at the locations of interest
This should make us more robust in the face of changing compiler line tables and other library modifications
llvm-svn: 181497
|
|
|
|
|
|
|
| |
- Using __builtin_trap confuses the stack unwinder
- __builtin_trap specific test will be added shortly
llvm-svn: 181441
|
|
|
|
|
|
|
| |
clang sugarcoats expressions of the sort *(int (*)[3])foo where foo is an int* saying that their type class is Paren
This checkin updates our lookup tables to properly desugar Paren into the actual type of interest
llvm-svn: 180938
|
|
|
|
|
|
| |
should enable us to get a more detailed perspective on which individual data formatters are broken
llvm-svn: 180128
|
|
|
|
|
|
| |
clearing the error messages here
llvm-svn: 177949
|
|
|
|
|
|
| |
pointer value as object>".
llvm-svn: 177926
|
|
|
|
|
|
| |
patch by Ashok Thirumurthi!
llvm-svn: 176462
|
|
|
|
|
|
| |
- fix is: don't pass incompatible -stdlib option when building with GCC
llvm-svn: 176460
|
|
|
|
|
|
|
|
| |
Remove the getCategory from TestDataFormatterObjC.py, since it was superceded by the .categories file,
and didn't work anyway (getCategories currently has to be a method on the test class, not on the test.)
Add a "basic_process" category, and start to find some tests for simple process running sniff tests.
llvm-svn: 176061
|
|
|
|
|
|
|
| |
Adding data formatters for iterators for std::map and std::vector (both libc++ and libstdcpp)
This does not include reverse iterators since they are both trickier (due to requirements the standard imposes on them) and much less useful
llvm-svn: 175787
|
|
|
|
|
|
|
|
|
| |
- TestNamespace expected to fail due to PR-15302
- TestCPPBool and TestUnsignedTypes updated to handle GCC style debug information
- TestRvalueReferences expected fail due to GCC (4.7) not outputting rvalue-reference debug information
- TestDataFormatterStdVBool expected to fail due to PR-15301
llvm-svn: 175551
|
|
|
|
|
|
| |
- do not pass (incompatible option) -stdlib=libstdc++ option if using GCC as test compiler
llvm-svn: 175522
|
|
|
|
|
|
| |
Synthetic children provider for NSSet
llvm-svn: 175468
|
|
|
|
|
|
|
|
| |
Split some NS* formatters in their own source files
Refactored a utility function for the C++ formatters to use
Fixed the skip-summary test case to be explicit about requiring libstdc++ for operation
llvm-svn: 175323
|
|
|
|
|
|
|
|
| |
- remove expectedFailure decorator from resolved rdar 12566646 and 10887661
- remove expectedFailure from TestBitfields testcase not actually affected by bug
- skip the (non-deterministic) TestStopHookMechanism.py to avoid a noisy suite on Linux
llvm-svn: 175307
|
|
|
|
|
|
| |
RecordLayoutBuilder::updateExternalFieldOffset().
llvm-svn: 175103
|
|
|
|
|
|
|
|
| |
RecordLayoutBuilder::updateExternalFieldOffset()
- Filed bugzilla PR-15256
llvm-svn: 175065
|
|
|
|
| |
llvm-svn: 174437
|
|
|
|
|
|
|
|
| |
Synthetic children and summary for std::vector<bool> (for both libcxx and libstdcpp).
std::vector<bool> is a special case and is custom-implemented to be a vector of bits, which means we failed to handle it with the standard std::vector<T> formatter.
This checkin provides custom formatters that work correctly
llvm-svn: 174333
|
|
|
|
|
|
|
|
|
|
|
| |
Data formatters now cache themselves.
This commit provides a new formatter cache mechanism. Upon resolving a formatter (summary or synthetic), LLDB remembers the resolution for later faster retrieval.
Also moved the data formatters subsystem from the core to its own group and folder for easier management, and done some code reorganization.
The ObjC runtime v1 now returns a class name if asked for the dynamic type of an object. This is required for formatters caching to work with the v1 runtime.
Lastly, this commit disposes of the old hack where ValueObjects had to remember whether they were queried for formatters with their static or dynamic type.
Now the ValueObjectDynamicValue class works well enough that we can use its dynamic value setting for the same purpose.
llvm-svn: 173728
|
|
|
|
|
|
| |
- Add new decorator "@skipIfGcc" to lldbtest.py
llvm-svn: 173394
|
|
|
|
|
|
| |
Making a summary for std::wstring as provided by libstdc++ along with a relevant test case
llvm-svn: 172286
|
|
|
|
|
|
|
|
|
| |
Providing a data formatter for libc++ std::wstring
In the process, refactoring the std::string data formatter to be written in C++ so that commonalities between the two can be exploited
Also, providing a new API on the ValueObject to navigate a hierarchy by index-path
Lastly, an appropriate test case is included
llvm-svn: 172282
|
|
|
|
|
|
|
|
|
|
| |
Adding useful formatting options to the expression (expr) command.
As a side effect of this change, the -d option now supports the same three-values enumeration that frame variables uses (run, don't run, none) instead of a boolean like it did previously
These options do not apply to print, p or po because these are aliased to not take any options.
In order to use them, use expression or expr.
llvm-svn: 171993
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
for reporting class types from Objective-C runtime
class symbols. Instead, LLDB now queries the
Objective-C runtime for class types.
We have also added a (minimal) Objective-C runtime
type vendor for Objective-C runtime version 1, to
prevent regressions when calling class methods in
the V1 runtime.
Other components of this fix include:
- We search the Objective-C runtime in a few more
places.
- We enable enumeration of all members of
Objective-C classes, which Clang does in certain
circumstances.
- SBTarget::FindFirstType and SBTarget::FindTypes
now query the Objective-C runtime as needed.
- I fixed several test cases.
<rdar://problem/12885034>
llvm-svn: 170601
|
|
|
|
|
|
| |
location for the makefile to find libc++.
llvm-svn: 170575
|
|
|
|
|
|
|
|
|
|
| |
Supporting a compact display syntax for ObjC pointers where 0x00.....0 is replaced by a much more legible "nil"
e.g. this would show:
(NSArray *) $2 = nil
instead of:
(NSArray *) $2 = 0x0000000000000000 <nil>
llvm-svn: 170161
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the option to print the runtime-specific description has been modified in the frame variable, memory read and expression command.
All three commands now support a --object-description option, with a shortcut of -O (uppercase letter o)
This is a breaking change:
frame variable used --objc as the long option name
expression used -o as a shortcut
memory read uses --objd as the long option name
Hopefully, most users won't be affected by the change since people tend to access "expression --object-description" under the alias "po" which still works
The test suite has been tweaked accordingly.
llvm-svn: 169961
|
|
|
|
|
|
|
|
|
|
| |
might theoretically be added to the general OptionValue base class should the need arise)
Using this mechanism, making sure that the options to pass a summary string or a named summary to frame variable do not have invalid values
<rdar://problem/11576143>
llvm-svn: 169927
|
|
|
|
|
|
| |
Adding a summary for NSError
llvm-svn: 169792
|
|
|
|
|
|
|
|
|
|
|
|
| |
Cleaned up the option parsing code to always pass around the short options as integers. Previously we cast this down to "char" and lost some information. I recently added an assert that would detect duplicate short character options which was firing during the test suite.
This fix does the following:
- make sure all short options are treated as "int"
- make sure that short options can be non-printable values when a short option is not required or when an option group is mixed into many commands and a short option is not desired
- fix the help printing to "do the right thing" in all cases. Previously if there were duplicate short character options, it would just not emit help for the duplicates
- fix option parsing when there are duplicates to parse options correctly. Previously the option parsing, when done for an OptionGroup, would just start parsing options incorrectly by omitting table entries and it would end up setting the wrong option value
llvm-svn: 169189
|
|
|
|
| |
llvm-svn: 168454
|
|
|
|
|
|
|
|
|
|
| |
Changed all relevant test cases to verify that MightHaveChildren() works correctly for objects of interest
Added a bunch of convenience methods for test cases to use: target(), process(), thread() and frame() which mimic the lldb.X convenience variables
As a bonus, edited the documentation on the website to describe the new method available for synthetic children providers writers to implement!
That's all folks!
llvm-svn: 166535
|
|
|
|
|
|
|
|
|
|
|
| |
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
|