| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
regardless of the actual callable
llvm-svn: 254758
|
|
|
|
|
|
|
|
| |
print a fairly large std::list<T>
This is meant to help me track optimizations to the libc++ std::list data formatter
llvm-svn: 254755
|
|
|
|
|
|
|
| |
Tracked here:
https://llvm.org/bugs/show_bug.cgi?id=25743
llvm-svn: 254746
|
|
|
|
| |
llvm-svn: 254744
|
|
|
|
|
|
|
|
|
|
| |
Patch by Nitesh Jain
Reviewers: clayborg, ovyalov.
Subscribers: jaydeep, bhushan, mohit.bhakkad, sagar.
Differential Revision: http://reviews.llvm.org/D15103
llvm-svn: 254711
|
|
|
|
|
|
|
|
|
|
|
| |
SUMMARY:
Marked TestCrashDuringStep.py as XFAIL for MIPS. The test generates IO error due to breakpoint at invalid address.
Reviewers: clayborg, labath
Subscribers: nitesh.jain, mohit.bhakkad, sagar, bhushan and lldb-commits
Differential Revision: http://reviews.llvm.org/D15182
llvm-svn: 254710
|
|
|
|
| |
llvm-svn: 254633
|
|
|
|
|
|
|
|
|
|
| |
Previously we used sys.os.path for appending target pathes what failed
when cased dlopen to fail on the target because of the '\'.
The fix won't work for local Windows tests but dlopen don't available
on Windows anyway so the test don't make sense in that context.
llvm-svn: 254602
|
|
|
|
| |
llvm-svn: 254563
|
|
|
|
| |
llvm-svn: 254550
|
|
|
|
|
|
|
|
| |
formatter.
Also cleans up pylint warnings (stock settings) in the modified function.
llvm-svn: 254546
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Also cleans up some usages of strings where symbolic names
were safer and made more sense.
Try a test run with something like this to check out the new
basic results formatter (not used by default):
time test/dotest.py --executable `pwd`/build/Debug/lldb --results-formatter lldbsuite.test.basic_results_formatter.BasicResultsFormatter --results-file stdout
This will yield something like:
Testing: 1 test suites, 8 threads
1 out of 1 test suites processed - TestHelp.py
Test Results
Total Test Methods Run (excluding reruns): 13
Test Method rerun count: 0
===================
Test Result Summary
===================
Success: 13
Expected Failure: 0
Failure: 0
Error: 0
Unexpected Success: 0
Skip: 0
Whereas something with a bit of error will look more like this:
42 out of 42 test suites processed - TestSymbolTable.py
Test Results
Total Test Methods Run (excluding reruns): 166
Test Method rerun count: 0
===================
Test Result Summary
===================
Success: 93
Expected Failure: 10
Failure: 2
Error: 2
Unexpected Success: 0
Skip: 59
Details:
FAIL:
TestModulesInlineFunctions.ModulesInlineFunctionsTestCase.test_expr_dsym
(/Users/tfiala/work/lldb-tot/git-svn/lldb/packages/Python/lldbsuite/test/lang/objc/modules-inline-functions/TestModulesInlineFunctions.py)
FAIL:
TestModulesInlineFunctions.ModulesInlineFunctionsTestCase.test_expr_dwarf
(/Users/tfiala/work/lldb-tot/git-svn/lldb/packages/Python/lldbsuite/test/lang/objc/modules-inline-functions/TestModulesInlineFunctions.py)
ERROR: TestObjCCheckers.ObjCCheckerTestCase.test_objc_checker_dsym
(/Users/tfiala/work/lldb-tot/git-svn/lldb/packages/Python/lldbsuite/test/lang/objc/objc-checker/TestObjCCheckers.py)
ERROR: TestObjCCheckers.ObjCCheckerTestCase.test_objc_checker_dwarf
(/Users/tfiala/work/lldb-tot/git-svn/lldb/packages/Python/lldbsuite/test/lang/objc/objc-checker/TestObjCCheckers.py)
The Details header only prints if there are any issues to report. The
Details section has tags that should get picked up using the normal
issue text scrapers (e.g. buildbot).
Test numbers reported are strictly test method runs.
The rerun bit at the top is in support of the multi-pass test
runner code (to run the low-load, single worker test pass for
tests that failed the first run), which I'll be able to put up
for review after this.
ResultsFormatters now have the ability to indicate they replace
the legacy summary, as this one does.
Once we come to agreement on the exact format, I will switch
us over to using this by default.
llvm-svn: 254530
|
|
|
|
|
|
|
| |
The test failing most likely because clang 3.5 and 3.6 uses an incorrect
ABI for returning small structs from a function.
llvm-svn: 254507
|
|
|
|
|
|
|
|
|
|
|
| |
On android the symbols exposed by libdl (dlopen, dlclose, dlerror)
prefixed by "__dl_". This change moves the handling of process
load/unload to the platform object and override it for android to
handle the special prefix.
Differential revision: http://reviews.llvm.org/D11465
llvm-svn: 254504
|
|
|
|
|
|
|
|
|
| |
.o files on Darwin."
The commit caused a test failure on the linux buildbot in
TestDataFormatterSynthVal.
llvm-svn: 254502
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
- Problem occurs when:
-- 32-bit inferiors run on x86_32 machine and
the architecture doesn't have AVX feature
-- This causes FPRType to be set to eFPRTypeFXSAVE
-- PTRACE_GETFPREGS was being used to read FXSAVE area
-- For 32-bit inferiors running on x86_32 machine,
PTRACE_GETFPREGS reads FSAVE area and not FXSAVE area
- Changed ptrace API to PTRACE_GETREGSET for 32-bit inferiors
-- This reads FPR data in FXSAVE format.
-- For 64-bit inferiors, no change has been made.
- Modified XFAIL for TestReturnValue.py
-- Earlier, this test was passing for Linux OS
-- Now, it passes for Android OS as well
Change-Id: Ieed72bc969b79516fc7b263b32493aa1e7a1a2ac
Signed-off-by: Abhishek Aggarwal <abhishek.a.aggarwal@intel.com>
Reviewers: ovyalov, jingham, lldb-commits, tberghammer, labath
Subscribers: jevinskie, labath, tberghammer, danalbert
Differential Revision: http://reviews.llvm.org/D15042
llvm-svn: 254499
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
on Darwin.
This is done by finding the types that are forward declarations that come from a module, and loading that module's debug info in a separate lldb_private::Module, and copying the type over into the current module using a ClangASTImporter object. ClangASTImporter objects are already used to copy types from on clang::ASTContext to another for expressions so the type copying code has been around for a while.
A new FindTypes variant was added to SymbolVendor and SymbolFile:
size_t
SymbolVendor::FindTypes (const std::vector<CompilerContext> &context, bool append, TypeMap& types);
size_t
SymbolVendor::FindTypes (const std::vector<CompilerContext> &context, bool append, TypeMap& types);
The CompilerContext is a way to represent the exact context of a type and pass it through an agnostic API boundary so that we can find that exact context elsewhere in another file. This was required here because we can have a module that has submodules, both of which have a "foo" type.
I am not able to add tests for this yet as we currently don't build our C/C++/ObjC binaries with the clang binary that we build. There are some driver issues where it can't find the header files for the C and C++ standard library which makes compiling these tests hard. We can't also guarantee that if we are building with clang that it supporst the exact format of -gmodule debugging that we are trying to test. We have had other versions of clang that had a different implementation of -gmodule debugging that we are no longer supporting, so we can't enable tests if we are building with clang without compiling something and looking at the structure of the DWARF that was generated to ensure that it is the format we can actually use.
llvm-svn: 254476
|
|
|
|
|
|
| |
The android buildbot gets quite flaky after this change. I'm reverting it while I investigate.
llvm-svn: 254430
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The following situation was occuring in TestAttachResume:
- we did a "continue" from a breakpoint (which involves a private start-stop to step over the
breakpoint)
- after receiving the stop-reply from the step-over, we issue a "detach" (which requires a
process interrupt)
- at this moment, the public state is "running", private state is "about-to-be-stopped" (the
stopped event was broadcast, but it was not received yet)
- StopForDestroyOrDetach (public thread) notes the public state is running, sends an interrupt
request to the private thread
- private thread gets the eBroadcastBitInterrupt (before the eStateStopped message), and asks the
process plugin to stop (via Halt())
- process plugin says it has nothing to do as the process is already stopped
- private thread shrugs and carries on. receives the stop event, restores the breakpoint and
resumes the process.
- after a while, the public thread times out and says it failed to stop the process
This patch does the following:
- splits Halt() into two functions, private and public, their usage depends on the context
- public Halt(): sends eBroadcastBitInterrupt to the private thread and waits for the Stop
event
- HaltPrivate(): asks the plugin to stop and makes a note that the halt was requested. When the
next stop event comes it sets the interrupt flag on it.
- removes HijackPrivateProcessEvents(), as the only user (old Halt()) has gone away
- removes the m_currently_handling_event hack, as the new Halt() does not need it
- adds a use_run_lock parameter to public Halt() and WaitForProcessToStop(). This was needed
because RunThreadPlan uses Halt() while holding the run lock and we don't want Halt() to take
it away from him.
Reviewers: clayborg, jingham
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D14989
llvm-svn: 254403
|
|
|
|
|
|
|
|
|
|
|
| |
SUMMARY:
For MIPS, ARCH is specified without m.
Reviewers: clayborg
Subscribers: nitesh.jain, mohit.bhakkad, sagar, bhushan and lldb-commits
Differential Revision: http://reviews.llvm.org/D14978
llvm-svn: 254376
|
|
|
|
|
|
|
| |
The test is flakey but it fails too often with gcc 4.9.2 on x86_64 to
be marked only as expected flakey.
llvm-svn: 254194
|
|
|
|
|
|
|
| |
Previously it tried to write a bit in the FPSCR register marked as
do not modify what failed on some device.
llvm-svn: 254166
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Differential revision: http://reviews.llvm.org/D15010
llvm-svn: 254153
|
|
|
|
|
|
| |
test reliably passed last 100 buildbot runs. Enable it and see what happens.
llvm-svn: 254072
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With this patch, the client will package up all the required
inputs into a compressed zip file, establish a connection to the
server, send the input to the server, and wait for the server to
send a response (in this case the response is just echoed back to
the client).
This gets the network communication in place, and in a subsequent
patch I will follow up with the code that actually runs swig on
the server and sends back the output instead of echoing back the
input.
llvm-svn: 254023
|
|
|
|
|
|
|
|
|
|
| |
FreeBSD
On FreeBSD we may get Clang via CC=cc or CC=/usr/bin/cc.
llvm.org/pr25626
llvm-svn: 254006
|
|
|
|
|
|
|
|
|
|
| |
This test was already expectedFlakeyLinux for occasional failures on the
Linux buildbot. It seems the new FreeBSD buildbot fails the same way on
occasion.
llvm.org/pr25172
llvm-svn: 254002
|
|
|
|
|
|
|
|
|
| |
These pass on my FreeBSD stable/10 desktop and my (not-yet-connected)
FreeBSD 11-CURRENT buildbot
llvm.org/pr20548
llvm-svn: 254001
|
|
|
|
|
|
|
|
|
| |
This passes on my FreeBSD stable/10 desktop and my new FreeBSD
11-current buildbot (which is not yet hooked up to the buildmaster).
llvm.org/pr18190
llvm-svn: 254000
|
|
|
|
|
|
| |
llvm.org/pr25624
llvm-svn: 253998
|
|
|
|
|
|
|
|
| |
targets.
Differential revision: http://reviews.llvm.org/D14823
llvm-svn: 253973
|
|
|
|
|
|
|
| |
I have plans to reuse this function in another script, so raising
this out of prepare_bindings allows this.
llvm-svn: 253755
|
|
|
|
|
|
|
|
| |
Also adds SB API to save a core and tests that use it.
Differential Revision: http://reviews.llvm.org/D14793
llvm-svn: 253734
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: This reverts commit 70dca28976ee8137acce2cc203dd394f4d761276.
Reviewers: amccarth, zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D14881
llvm-svn: 253704
|
|
|
|
|
|
| |
the test yet
llvm-svn: 253697
|
|
|
|
|
|
|
|
| |
Accidentally commited before I was done.
This reverts commit 2ec2da4ee52780582d5e9c88b2e982a688fbdbe1.
llvm-svn: 253685
|
|
|
|
| |
llvm-svn: 253684
|
|
|
|
| |
llvm-svn: 253683
|
|
|
|
| |
llvm-svn: 253679
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This reverts commit 251965377bdfb6227eea42c12a792c059e4e8a4b
as a test marked "skipIf(compiler='gcc')" runs when testing with GCC.
Reviewers: amccarth
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D14852
llvm-svn: 253631
|
|
|
|
| |
llvm-svn: 253623
|
|
|
|
|
|
| |
that the 'frame variable' command can still find the members of such union as if they were top-level variables in the current scope
llvm-svn: 253613
|
|
|
|
|
|
| |
infrastructure; the tests are now xfailed on Darwin pending investigation
llvm-svn: 253604
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-fms-compatibility-version defaults to VS 2013. When using
VS 2015, this will lead to compilation failures of the test
inferiors in the C++ standard library for language conformance
reasons.
The fix here is to simply pass -fms-compatibility-version=19.0 when
we detect that a VS 2015 compiler is present. Even though we're
actually using clang to do the compilation, clang uses this same
detection algorithm to determine the location of the standard
library. So this check is tantanmount to saying "If clang is going
to find MSVC 2015's standard library, then pass 19.0 for
-fms-compatibility-version.
llvm-svn: 253589
|
|
|
|
|
|
|
|
|
|
|
| |
Patch by Nitesh Jain
Summary: This patch check whether first register is readable.
Subscribers: lldb-commits, mohit.bhakkad, sagar, bhushan
Reviewers: clayborg, ovyalov, jaydeep
Differential: http://reviews.llvm.org/D14635
llvm-svn: 253555
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D14784
llvm-svn: 253505
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: ovyalov
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D14765
llvm-svn: 253488
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch fixes two issues:
1) Popen needs to be used with universal_newlines=True by default.
This elicits automatic decoding from bytes -> string in Py3,
and has no negative effects in other Py versions.
2) The swig typemaps for converting between string and (char*, int)
did not work correctly when the length of the string was 0,
indicating an error. In this case we would try to construct a
string from uninitialized data.
3) Ironically, the bug mentioned in #2 led to a test passing on
Windows that was actually broken, because the test was written
such that the assertion was never even getting checked, so it
passed by default. So we additionally fix this test to also
fail if the method errors. By fixing this test it's now broken
on Windows, so we also xfail it.
llvm-svn: 253487
|
|
|
|
|
|
|
|
|
|
|
| |
Patch by Nitesh Jain
Summary: The break is opcode for breakpoint instruction.
Subscribers: lldb-commits, mohit.bhakkad, sagar, bhushan
Reviewers: clayborg, ovyalov, jaydeep
Differential: http://reviews.llvm.org/D14634
llvm-svn: 253445
|