| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 275225
|
|
|
|
|
|
| |
as an existing alias (or rather, one could but the results of invoking the command were far from satisfactory)
llvm-svn: 275080
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The issue arises due to the wrong unwinder used for the first
stack frame, where the default unwinder returns erroneous frame
whereas the fallback would have given the correct frame had it
been used.
The following fix consists of two parts ->
1) The first part changes the unwinding strategy, earlier the
default unwinder was used to get 2 more stack frames and if it
failed a fallback unwinder was used. Now we try to obtain as many
frames (max 10) as we can get from default unwinder and also
fallback unwinder and use the one that gives more number of frames.
2) Normally unwindplans are assosciated with functions and the
row to be used is obtained from the offset (obtained from the low_pc
of the function symbol). Sometimes it may occur that the unwindplan
is assosciated to the complete Elf section in which case the offset
calculation would be wrong as the debugger uses the same offset originally
obtained from the function symbol. Hence this offset is recalculated.
Reviewers: tberghammer, lldb-commits, labath, jasonmolenda
Subscribers: jingham
Differential Revision: http://reviews.llvm.org/D21221
llvm-svn: 274750
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch fills in the implementation of GetMemoryRegions() on the Linux and Mac OS core file implementations of lldb_private::Process (ProcessElfCore::GetMemoryRegions and ProcessMachCore::GetMemoryRegions.) The GetMemoryRegions API was added under: http://reviews.llvm.org/D20565
The patch re-uses the m_core_range_infos list that was recently added to implement GetMemoryRegionInfo in both ProcessElfCore and ProcessMachCore to ensure the returned regions match the regions returned by Process::GetMemoryRegionInfo(addr_t load_addr, MemoryRegionInfo ®ion_info).
Reviewers: clayborg
Subscribers: labath, lldb-commits
Differential Revision: http://reviews.llvm.org/D21751
llvm-svn: 274741
|
|
|
|
|
|
| |
Differential revision: http://reviews.llvm.org/D21984
llvm-svn: 274617
|
|
|
|
|
|
|
| |
I overlooked the possibility of certain targets translating increment statement into a read and write.
In this case we replace increment statement with an assignment.
llvm-svn: 274215
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Target::Install() was assuming the module at index 0 was the executable.
This is often true, but not guaranteed to be the case. The
TestInferiorChanged.py test highlighted this when run against iOS.
After the binary is replaced in the middle of the test, it becomes the
last module in the list. The rest of the Target::Install() logic then
clobbers the executable file by using whatever happens to be the first
module in the target module list.
This change also marks the TestInferiorChanged.py test as a no-debug-info
test.
llvm-svn: 273960
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: zturner, clayborg, tfiala
Subscribers: sas, lldb-commits
Differential Revision: http://reviews.llvm.org/D21648
llvm-svn: 273720
|
|
|
|
|
|
|
|
|
|
|
|
| |
AArch64 targets
This patch allows LLDB for AArch64 to watch all bytes, words or double words individually on non 8-byte alligned addresses.
This patch also adds tests to verify this functionality.
Differential revision: http://reviews.llvm.org/D21280
llvm-svn: 272916
|
|
|
|
|
|
|
|
|
| |
This enables a couple of tests which have been shown to run reliably on the
linux x86 buildbot. If you see a failure after this commit, feel free to add
the xfail back, but please make it as specific as possible (i.e., try to make
it not cover i386/x86_64 with clang-3.5, clang-3.9 or gcc-4.9).
llvm-svn: 272326
|
|
|
|
| |
llvm-svn: 272189
|
|
|
|
|
|
| |
This reverts commit r272024 as it is not windows-compatible.
llvm-svn: 272062
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For Thread Sanitizer reports, LLDB tries to find a global variable declaration
corresponding to the racy address in order to provide a filename and line
number. This commit changes the lookup of the variable to use the mangled
name for lookup and fall back to the demangled version if unavailable. This
is needed to report locations of races on Swift global variables.
I've also added a test to make sure we look up C++ globals correctly.
rdar://problem/26459401
Differential Revision: http://reviews.llvm.org/D20760
llvm-svn: 271433
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change adds the capability of building test inferiors
with the -gmodules flag to enable module debug info support.
Windows is excluded per @zturner.
Reviewers: granata.enrico, aprantl, zturner, labath
Subscribers: zturner, labath, lldb-commits
Differential Revision: http://reviews.llvm.org/D19998
llvm-svn: 270848
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
TestBSDArchives.py and TestWatchLocation.py fail due to unicode error and bug has already been reported for arm and macOSx.
TestConstVariables.py fails because lldb cant figure out frame variable type when used in expr.
llvm-svn: 270780
|
|
|
|
|
|
|
|
| |
unordered_map more than once in a stop due to the synthetic provider not properly caching the ValueObjects it was returning for the child elements
Fixes rdar://26470909
llvm-svn: 270752
|
|
|
|
|
|
|
|
| |
TestCallUserAnonTypedef.py and TestIRInterpreter.py fail to limitation of JIT expressions in handling hard float ABI targets.
TestBSDArchives.py fails due to python unicode error.
TestBuiltinTrap.py fails due to wrong line information generated by some gcc versions.
llvm-svn: 270745
|
|
|
|
| |
llvm-svn: 270364
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The error was not getting propagated to the caller, so the higher layers thought the breakpoint
was successfully set & resolved.
I added a testcase, but it assumes 0x0 is not a valid place to set a breakpoint. On most systems
that is true, but if it isn't true of your system, either find another good place and add it to the
test, or x-fail the test.
<rdar://problem/26345962>
llvm-svn: 270014
|
|
|
|
|
|
|
|
| |
TestWatchLocation.py fails on arm-linux target due to unicode error in lldb testsuite.
This is a known issue and same test fails on OS X with similar reason.
I have reported a bug and marked this test as xfail for arm-linux targets.
llvm-svn: 269860
|
|
|
|
|
|
|
|
| |
are part of a disabled category
Fixes rdar://26202006
llvm-svn: 269673
|
|
|
|
|
|
|
| |
Both of above tests fail on arm and bugs have been reported on android already.
Adding arm-linux decorator because android decorator doesnt xfail these test when run on linux.
llvm-svn: 269647
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
systems.
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
|
|
|
|
|
|
|
|
| |
Some watchpoint tests fail on aarch64-linux as it lacks support for intalling watchpoints which are not alligned at 8bytes boundary.
Marking them as xfail for now.
llvm-svn: 269187
|
|
|
|
|
|
|
| |
Test uses x1 in breakpoint expression while objdump shows that x1 is never used in the code and may have random values.
Using x0 make sure that we are using a registe that will have a positive value and breakpoint expression will evaluate true atleast once.
llvm-svn: 269164
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
TestExitDuringStep was very rarely hanging on the buildbots. I can't be sure, but I believe this
was because of the fact that it declared its pseudo_barrier variable as "volatile int", which is
not sufficient to guarantee corectness (also, all other tests used atomic variables for this, and
they were passing reliably AFAIK). Besides switching to an atomic variable in this test as well,
I have also took this opportunity to unify all the copies of the pseudo_barrier code to a single
place to reduce the chance of this happening again.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D20065
llvm-svn: 269025
|
|
|
|
|
|
|
| |
This tests both that we set the breakpoint on the right line, and that restricting by file
and/or the function, we get the right breakpoints.
llvm-svn: 269004
|
|
|
|
| |
llvm-svn: 268433
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
As these are really testing separate issues, they should be run as separate
tests.
Reviewers: zturner, granata.enrico, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D19690
llvm-svn: 268397
|
|
|
|
|
|
| |
children yesterday. Do so now
llvm-svn: 268263
|
|
|
|
| |
llvm-svn: 268194
|
|
|
|
|
|
| |
global variables.
llvm-svn: 267894
|
|
|
|
|
|
| |
if the selected compiler can't compile with "-fsanitize=thread".
llvm-svn: 267726
|
|
|
|
|
|
| |
The flakyness is no longer reproducible, and the tests seem to be passing reliably now.
llvm-svn: 267704
|
|
|
|
|
|
| |
The flakyness is no longer reproducible, and the tests seem to be passing reliably now.
llvm-svn: 267392
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 267133
|
|
|
|
|
|
| |
spawning an inferior process
llvm-svn: 266911
|
|
|
|
| |
llvm-svn: 266867
|
|
|
|
|
|
|
|
|
|
| |
environment and that might not always be set. Our FileSpec class uses this function to resolve any paths that start with "~/" on systems that support home directories as '~'. I have modified FileSpec::ResolveUsername (llvm::SmallVectorImpl<char> &path) to deal with the cases where llvm::sys::path::home_directory() returns false by digging a little further on unix systems and setting "HOME" in the environment so that subsequent calls to llvm::sys::path::home_directory() will succeed.
I also added a test to ensure we don't regress.
<rdar://problem/25342377>
llvm-svn: 266832
|
|
|
|
|
|
| |
Fix XFAILed tests in TestThreadStates for the new signature of wait_for_running_event.
llvm-svn: 266598
|
|
|
|
|
|
|
|
|
|
| |
Patch by Nitesh Jain
Reviewers: clayborg
Subscribers: jaydeep, bhushan, mohit.bhakkad, sagar
Differential Revision: http://reviews.llvm.org/D18389
llvm-svn: 266589
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The original breakpoint location test was failing for linux, because the compilers here tend to
merge the full-object and subobject destructors even at -O0 (as a result, we are getting only 2
breakpoint locations, and not 4 as the test expected. The fixup in r266164 substantially weakened
the test, as it now did not check whether both kinds of destructors were being found.
Because of these contraints, I have altered the logic of the test. It sets the
breakpoint by name, and then independently verifies that the breakpoint is set on the correct
demangled symbol name (which is not very meaningful since both kinds of destructors demangle to
the same name) *and* the correct symbol address (which is obtained by looking up the mangled
symbol name).
Reviewers: clayborg
Subscribers: ovyalov, zturner, lldb-commits
Differential Revision: http://reviews.llvm.org/D19052
llvm-svn: 266416
|
|
|
|
|
|
|
| |
This seems to hang on non-s390x hosts. Disable for now to get the build
bots going again.
llvm-svn: 266343
|
|
|
|
|
|
|
|
| |
The android dirty stderr problem has uncovered an issue where lldbutil.expect_state_changes was
reading events other than state change events, which resulted in general confusion. Make it more
strict to accept *only* state changes.
llvm-svn: 266327
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes several test case failure on s390x caused by the fact that
on this platform, the default "char" type is unsigned.
- In ClangASTContext::GetBuiltinTypeForEncodingAndBitSize we should return
an explicit *signed* char type for encoding eEncodingSint and bit size 8,
instead of the default platform char type (which may be unsigned).
This fix matches existing code in ClangASTContext::GetIntTypeFromBitSize,
and fixes the TestClangASTContext.TestBuiltinTypeForEncodingAndBitSize
unit test case.
- The test/expression_command/char/TestExprsChar.py test case is known to
fail on platforms defaulting to unsigned char (pr23069), and just needs
to be xfailed on s390x like on arm.
- The test/functionalities/watchpoint/watchpoint_on_vectors/main.c test
case defines a vector of "char" and implicitly assumes to be signed.
Use an explicit "signed char" instead.
Differential Revision: http://reviews.llvm.org/D18979
llvm-svn: 266309
|