If a lldbinline test's source file changed language, then the Makefile wasn't
updated. This was a problem if the Makefile was checked into the repository.
Now lldbinline.py always regenerates the Makefile and asserts if the
newly-generated version is not the same as the one already there. This ensures
that the repository will never be out of date without a buildbot failing.
http://reviews.llvm.org/D21032
llvm-svn: 272024
T x;
U y;
doing
x = *((T*)y)
is undefined behavior, even if sizeof(T) == sizeof(U), due to pointer aliasing rules
Fix up a couple of places in LLDB that were doing this, and transform them into a defined and safe memcpy() operation
Also, add a test case to ensure we didn't regress by doing this w.r.t. tagged pointer NSDate instances
llvm-svn: 270793
Remove XFAIL from some tests that now pass.
Add XFAIL to some tests that now fail.
Fix a crasher where a null pointer check isn't guarded.
Properly handle all types of errors in SymbolFilePDB.
llvm-svn: 269454
The adding of <atomic> to test_common.h broke 12 tests on Darwin. We work around this by not including <atomic> when building on darwin for libstdc++ tests.
llvm-svn: 269372
This option evaluates an expression and, if the result is of pointer type, treats it as if it was an array of that many elements and displays such elements
This has a couple subtle points but is mostly as straightforward as it sounds
Add a parray N <expr> alias for this new mode
Also, extend the --object-description mode to do the moral equivalent of the above but display each element in --object-description mode
Add a poarray N <expr> alias for this
llvm-svn: 267372
A number of test cases were failing on big-endian systems simply due to
byte order assumptions in the tests themselves, and no underlying bug
in LLDB.
These two test cases:
tools/lldb-server/lldbgdbserverutils.py
python_api/process/TestProcessAPI.py
actually check for big-endian target byte order, but contain Python errors
in the corresponding code paths.
These test cases:
functionalities/data-formatter/data-formatter-python-synth/TestDataFormatterPythonSynth.py
functionalities/data-formatter/data-formatter-smart-array/TestDataFormatterSmartArray.py
functionalities/data-formatter/synthcapping/TestSyntheticCapping.py
lang/cpp/frame-var-anon-unions/TestFrameVariableAnonymousUnions.py
python_api/sbdata/TestSBData.py (first change)
could be fixed to check for big-endian target byte order and update the
expected result strings accordingly. For the two synthetic tests, I've
also updated the source to make sure the fake_a value is always nonzero
on both big- and little-endian platforms.
These test case:
python_api/sbdata/TestSBData.py (second change)
functionalities/memory/cache/TestMemoryCache.py
simply accessed memory with the wrong size, which wasn't noticed on LE
but fails on BE.
Differential Revision: http://reviews.llvm.org/D18985
llvm-svn: 266315
Enrico has a bug on him to make this work across older libcxx list
and newer libcxx list simultaneously. Needed in preparation of
getting the OS X public CI to run the TSAN tests.
tracked by:
rdar://25499635
llvm-svn: 265188
We want to do a better job presenting errors that occur when evaluating
expressions. Key to this effort is getting away from a model where all
errors are spat out onto a stream where the client has to take or leave
all of them.
To this end, this patch adds a new class, DiagnosticManager, which
contains errors produced by the compiler or by LLDB as an expression
is created. The DiagnosticManager can dump itself to a log as well as
to a string. Clients will (in the future) be able to filter out the
errors they're interested in by ID or present subsets of these errors
to the user.
This patch is not intended to change the *users* of errors - only to
thread DiagnosticManagers to all the places where streams are used. I
also attempt to standardize our use of errors a bit, removing trailing
newlines and making clients omit 'error:', 'warning:' etc. and instead
pass the Severity flag.
The patch is testsuite-neutral, with modifications to one part of the
MI tests because it relied on "error: error:" being erroneously
printed. This patch fixes the MI variable handling and the testcase.
<rdar://problem/22864976>
llvm-svn: 263859
This can cause differences in which bit patterns end up meaning YES or NO. In general, however, 0 == NO and 1 == YES.
To keep it simple, LLDB will now show "YES" and "NO" only for 1 and 0 respectively, and format other values as the plain numeric value instead.
Fixes rdar://24809994
llvm-svn: 263604
Summary: This is the form on other libc++ tests.
Reviewers: sivachandra
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D17230
llvm-svn: 260793
On libc++ std::atomic is a fairly simple data type (layout wise, at least), wrapping actual contents in a member variable named "__a_"
All the formatters are doing is "peel away" this intermediate layer and exposing user data as direct children or values of the std::atomic root variable
Fixes rdar://24329405
llvm-svn: 260752
However, they also contain fallback logic that - in cases where LLDB can't recognize the specific subclass - actually does run code in order to inspect those objects.
The argument for this logic was that these data types are critical enough that the risk of getting it wrong is outweighed by the advantage of always providing accurate child information.
Practical experience however shows that "po" - a code running data-inspection command - is quite frequently used, and not considered burdensome by users.
As such, this makes the code-running fallback in the data formatters a risk that carries very little actual reward. Also, unlike the time this code was originally written, we now have accurate class information for Objective-C, and thus we are less likely to improperly identify classes.
This commit removes support for the code-running fallback, and aligns the data formatters for NSArray, NSDictionary and NSSet to the general no-code-running behavior of other data formatters.
While it is possible for us to add support for some subclasses that are now no longer covered by static inspection alone, this is beyond the scope of this commit.
llvm-svn: 260664
expectedFailureWindows is equivalent to using the general
expectedFailureAll decorator with oslist="windows". Additionally,
by moving towards these common decorators we can solve the issue
of having to support decorators that can be called with or without
arguments. Once all decorators are always called with arguments,
and this is enforced by design (because you can't specify the condition
you're decorating for without passing an argument) the implementation
of the decorators can become much simpler
Differential Revision: http://reviews.llvm.org/D16936
llvm-svn: 260134
This doesn't attempt to move every decorator. The reason for
this is that it requires touching every single test file to import
decorators.py. I would like to do this in a followup patch, but
in the interest of keeping the patches as bite-sized as possible,
I've only attempted to move the underlying common decorators first.
A few tests call these directly, so those tests are updated as part
of this patch.
llvm-svn: 259807
In Python 3, whitespace inconsistences are errors. This synthetic
provider had mixed tabs and spaces, as well as inconsistent
indentation widths. This led to the file not being imported,
and naturally the test failing. No functional change here, just
whitespace.
llvm-svn: 258751
These tests were fixed by r253026 but they was failing on the linux
build bot because of a system setup problem. Remove xfail from them
after we fixed the build bot.
llvm-svn: 254163
Summary:
- Reason of both bugs:
1. For the very first frame, Unwinder doesn't check the validity
of Full UnwindPlan before creating StackFrame from it:
When 'process launch' command is run after setting a breakpoint
in inferior, the Unwinder runs and saves only Frame 0 (the frame
in which breakpoint was set) in thread's StackFrameList i.e.
m_curr_frames_sp. However, it doesn't check the validity of the
Full UnwindPlan for this frame by unwinding 2 more frames further.
2. Unwinder doesn't update the CFA value of Cursor when Full UnwindPlan
fails and FallBack UnwindPlan succeeds in providing valid CFA values
for frames:
Sometimes during unwinding of stack frames, the Full UnwindPlan
inside the RegisterContextLLDB object may fail to provide valid
CFA values for these frames. Then the Fallback UnwindPlan is used
to unwind the frames.
If the Fallback UnwindPlan succeeds, then it provides a valid new
CFA value. The RegisterContextLLDB::m_cfa field of Cursor object
is updated during the Fallback UnwindPlan execution. However,
UnwindLLDB misses the implementation to update the 'cfa' field
of this Cursor with this valid new CFA value.
- This patch fixes both these issues.
- Remove XFAIL in test files corresponding to these 2 Bugs
Change-Id: I932ea407545ceee2d628f946ecc61a4806d4cc86
Signed-off-by: Abhishek Aggarwal <abhishek.a.aggarwal@intel.com>
Reviewers: jingham, lldb-commits, jasonmolenda
Subscribers: lldb-commits, ovyalov, tberghammer
Differential Revision: http://reviews.llvm.org/D14226
llvm-svn: 253026
This module was originally intended to be imported by top-level
scripts to be able to find the LLDB packages and third party
libraries. Packages themselves shouldn't need to import it,
because by the time it gets into the package, the top-level
script should have already done this. Indeed, it was just
adding the same values to sys.path multiple times, so this
patch is essentially no functional change.
To make sure it doesn't get re-introduced, we also delete the
`use_lldb_suite` module from `lldbsuite/test`, although the
original copy still remains in `lldb/test`
llvm-svn: 251963
For convenience, we had added the folder that dotest.py was in
to sys.path, so that we could easily write things like
`import lldbutil` from anywhere and any test. This introduces
a subtle problem when using Python's package system, because when
unittest2 imports a particular test suite, the test suite is detached
from the package. Thus, writing "import lldbutil" from dotest imports
it as part of the package, and writing the same line from a test
does a fresh import since the importing module was not part of
the same package.
The real way to fix this is to use absolute imports everywhere. Instead
of writing "import lldbutil", we need to write "import
lldbsuite.test.util". This patch fixes up that and all other similar
cases, and additionally removes the script directory from sys.path
to ensure that this can't happen again.
llvm-svn: 251886
This is the conclusion of an effort to get LLDB's Python code
structured into a bona-fide Python package. This has a number
of benefits, but most notably the ability to more easily share
Python code between different but related pieces of LLDB's Python
infrastructure (for example, `scripts` can now share code with
`test`).
llvm-svn: 251532
