| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
http://reviews.llvm.org/D15172
llvm-svn: 254638
|
|
|
|
| |
llvm-svn: 254634
|
|
|
|
| |
llvm-svn: 254633
|
|
|
|
|
|
|
|
|
|
| |
The code was duplicated to handle the custom symbol name for functions
in libdl.so for android. This change modify the way we handle the issue
to eliminate a lot of duplicated code.
Differential revision: http://reviews.llvm.org/D15183
llvm-svn: 254608
|
|
|
|
|
|
|
|
|
|
| |
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: 254593
|
|
|
|
|
|
|
| |
SUMMARY:
Using enum instead of a constant to fetch PC and CAUSE registers.
llvm-svn: 254590
|
|
|
|
|
|
|
|
| |
Reviewers: clayborg, jingham, jasonmolenda.
Subscribers: jaydeep, bhushan, sagar, nitesh.jain,lldb-commits.
Differential Revision: http://reviews.llvm.org/D12877
llvm-svn: 254588
|
|
|
|
| |
llvm-svn: 254563
|
|
|
|
| |
llvm-svn: 254550
|
|
|
|
|
|
|
|
| |
formatter.
Also cleans up pylint warnings (stock settings) in the modified function.
llvm-svn: 254546
|
|
|
|
|
|
|
| |
This is more pythonic and allows a more idiomatic way of getting
detailed usage information for each individual sub-command.
llvm-svn: 254533
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
Reviewers: clayborg.
Subscribers: jaydeep, bhushan, sagar, nitesh.jain,lldb-commits.
Differential Revision: http://reviews.llvm.org/D15106
llvm-svn: 254522
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
stepping on MIPS
This patch will clear bug 25194 - LLDB-Server Assertion raised when single stepping on MIPS. The problem was that while emulating instructions, old and new pc values would have garbage value in their upper 32 bits. Therefore checking if pc was changed (old_pc == new_pc) would always return false, because of which pc was not getting updated.
/* If we haven't changed the PC, change it here */
if (old_pc == new_pc)
{
new_pc += 4;
Context context;
return false;
}
Reviewers: tberghammer, clayborg
Subscribers: dsanders, lldb-commits, mohit.bhakkad, bhushan, jaydeep, nitesh.jain
Differential: http://reviews.llvm.org/D14633
llvm-svn: 254379
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
choice of format
llvm-svn: 254349
|
|
|
|
| |
llvm-svn: 254341
|
|
|
|
| |
llvm-svn: 254340
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D15092
llvm-svn: 254338
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds functionality for dumping allocations of struct elements. This involves:
+ Jitting the runtime for details on all the struct fields.
+ Finding the name of the struct type by looking for a global variable of the same type, which will have been reflected back to the java host code.
+ Using this struct type name to pass into expression evaluation for pretty printing the data for the dump command.
llvm-svn: 254294
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This makes sure we do not attempt to send output over the gdb-remote protocol when the client is
not expecting it (i.e., after sending the stop-reply packet). Normally, this should not happen
(the process cannot generate output when it is stopped), but due to the fact that pty
communication is asynchronous in the linux kernel (llvm.org/pr25652), we may sometimes get this
output too late. Instead, we just hold the output, and send it next time we resume. This is not
ideal, but at least it makes sure we do not violate the remote protocol. Given that this happens
extremely rarely it's not worth trying to work around it with sleeps or something like that.
I also remove the m_stdio_communication_mutex, as all of LLGS is now single-threaded anyway.
Reviewers: tberghammer, ovyalov
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D15019
llvm-svn: 254200
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Differential revision: http://reviews.llvm.org/D14985
llvm-svn: 254152
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were trying to be super smart and find all the supported language
bindings. This led to us scanning the directory and treating all
subdirectories as language binding directories. This makes it
hard to add unrelated code in this folder.
Besides, we only support one at the moment - Python. And when new
ones are added it will be trivial to just add their names to a list.
So this patch gets stupider about how to look for language binding
subfolders. Just put them in a list, and use the list.
llvm-svn: 254078
|
|
|
|
|
|
| |
test reliably passed last 100 buildbot runs. Enable it and see what happens.
llvm-svn: 254072
|
|
|
|
|
|
|
|
|
| |
This script really should not be assuming every subdirectory is
a language directory for swig generation. Using a hack to get
this working for now, but this should be solved once this script
is re-written similar to how prepare_bindings was.
llvm-svn: 254037
|
|
|
|
| |
llvm-svn: 254033
|
|
|
|
| |
llvm-svn: 254026
|
|
|
|
| |
llvm-svn: 254025
|
|
|
|
| |
llvm-svn: 254024
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 version supports local generation only. It's intentionally
stupid, and does not support any kind of dependency checking.
If you run the script, it's going to call SWIG. While this is
a slow process, we are going to combine the use of the swig bot
with checked in static bindings, meaning that it won't be terribly
important to only regenerate the bindings when the input files
have actually changed.
A side benefit of this is that the implementation is drastically
simpler.
This is all experimental at the moment, but it duplicates a lot
of the logic currently found in prepare_bindings.py. There was
not a good way to reuse some of the logic without invasive changes
on that script, and since this script is still experimental, it
makes sense to just copy them over, and if / when this becomes
more mature, we can get rid of the other ones.
llvm-svn: 254022
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
debug server connection failure.
http://reviews.llvm.org/D14895
llvm-svn: 253906
|