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
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
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
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
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
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
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
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
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
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
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
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
-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
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
