| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When running the test suite on Windows, we can't have Windows popping
up dialogs when LLDB crashes in native code because it will hang
the test suite. This patch silences those dialogs by checking an
environment variable at startup and configuring Windows based on
its value.
This patch also adds an environment variable to force inferiors to
never spawn in their own console window. This is useful to prevent
new window spawm when running the test suite.
Reviewed by: Scott Graham
Differential Revision: http://reviews.llvm.org/D6628
llvm-svn: 224137
|
|
|
|
|
|
|
| |
This still relies on PutSTDIN, just indirectly. So it was hanging
due to not being able to get stdin from the test.
llvm-svn: 223983
|
|
|
|
| |
llvm-svn: 223905
|
|
|
|
|
|
|
|
|
|
| |
clang does not yet support MS-ABI record layout for externally-sourced
ASTs. As a result, attempting to format something that requires data
layout results in undefined behavior in clang, in this case an assert.
http://llvm.org/pr21800 tracks fixing this on the clang side.
llvm-svn: 223868
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
synthetic children
Because of the way they are created, synthetic children cannot (in general) have a sane expression path
A solution to this would be letting the parent front-end generate expression paths for its children
Doing so requires a significant amount of refactoring, and might not always lead to better results (esp. w.r.t. C++ templates)
This commit takes a simpler approach:
- if a synthetic child is of pointer type and it's a target pointer, then emit *((T)value)
- if a synthetic child is a non-pointer, but its location is in the target, then emit *((T*)loadAddr)
- if a synthetic child has a value, emit ((T)value)
- else, don't emit anything
Fixes rdar://18442386
llvm-svn: 223836
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Getting this working correctly is a significant amount of work.
Assertions on Windows show up as error code 0xC0000409, which is
STATUS_STACK_BUFFER_OVERRUN. In order to accurately determine
that this is not just any stack buffer overrun, but one triggered
by a call to abort, we would need to analyze the call stack. This
in turn requires better symbol support for Windows executables,
and work on LLDB to make stack frames better on Windows.
For now, these are XFAIL'ed and tracked in http://llvm.org/pr21793.
llvm-svn: 223816
|
|
|
|
| |
llvm-svn: 223731
|
|
|
|
|
|
|
|
|
|
|
|
| |
Such a persisted version is equivalent to evaluating the value via the expression evaluator, and holding on to the $n result of the expression, except this API can be used on SBValues that do not obviously come from an expression (e.g. are the result of a memory lookup)
Expose this via SBValue::Persist() in our public API layer, and ValueObject::Persist() in the lldb_private layer
Includes testcase
Fixes rdar://19136664
llvm-svn: 223711
|
|
|
|
| |
llvm-svn: 223700
|
|
|
|
|
|
|
|
|
|
| |
There was an error in ORing mask which is used for getting a list of variables.
Previously, these constants were unnamed, and possible it become the reason of this
bug. Also added test case for -stack-list-local and -stack-list_arguments.
Patch from Ilia K <ki.stfu@gmail.com>.
llvm-svn: 223674
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: If lldb is not built, dotest.py throws an exception because we are using an unset variable.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D6516
llvm-svn: 223446
|
|
|
|
|
|
| |
Was causing dosep to hang in some cases.
llvm-svn: 223441
|
|
|
|
|
|
|
|
|
|
|
| |
There is at least one test that hangs on the Linux debian buildbot.
When that test hangs, the buildbot kills dosep which loses all test
results. This change kills just the hung test and should let us see
which test is hanging. This is useful for that test and any others
in the future which start hanging.
llvm-svn: 223423
|
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D6484
Reviewed by: Oleksiy Vyalov
llvm-svn: 223155
|
|
|
|
|
|
|
|
| |
and invalid environment - make lldbtest.registerSharedLibrariesWithTarget to support multiple platforms.
http://reviews.llvm.org/D6392
llvm-svn: 223091
|
|
|
|
|
|
|
|
|
|
| |
Clang generates DWARF debug info with section names longer
than 8 characters. This is only supported by an extension
to PE/COFF which the MSVC linker doesn't implement. So
trying to link DWARF-enabled object files with MSVC will
lead to corrupt debug information in the executable.
llvm-svn: 223088
|
|
|
|
|
|
|
|
|
| |
This file tests the sequence of digits that can come before
an MI command.
Patch from dawn@burble.org.
llvm-svn: 222873
|
|
|
|
|
|
|
|
| |
and invalid environment.
http://reviews.llvm.org/D6392
llvm-svn: 222845
|
|
|
|
|
|
|
|
|
|
|
|
| |
summary of changes:
Cleanup: Use "line_number" API instead of hardcoded source lines
Combine child.sendline with previous child.send command.
test_lldbmi_tokens: Add test for MI tokens.
test_lldbmi_badpathexe: Remove check for prompt so test for bad path can be enabled.
Patch from dawn@burble.org.
llvm-svn: 222838
|
|
|
|
|
|
|
|
|
|
| |
These methods are difficult / impossible to implement in a way
that is semantically equivalent to the expectations set by LLDB
for using them. In the future, we should find an alternative
strategy (for example, i/o redirection) for achieving similar
functionality, and hopefully deprecate these APIs someday.
llvm-svn: 222775
|
|
|
|
|
|
|
|
| |
Test 'test_lldbmi_interrupt' is only enabled for Darwin as
it seems to cause a timeout error on Linux.
Patch from dawn@burble.org.
llvm-svn: 222750
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The following lldb unit tests fail check-lldb on ubuntu:
TestDataFormatterStdMap.py
TestDataFormatterStdVBool.py
TestDataFormatterStdVector.py
TestDataFormatterSynthVal.py
TestEvents.py
TestInitializerList.py
TestMemoryHistory.py
TestReportData.py
TestValueVarUpdate.py
These unit test failures are for non-core functionality. The intent is to
reduce the check-lldb FAILS to core functionality FAILS and then circle
back later and fix these FAILS at a later date.
llvm-svn: 222608
|
|
|
|
| |
llvm-svn: 222589
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
test/api/multithreaded/test_listener_event_description.cpp to work properly on Linux/FreeBSD
Issue D5632 fixed an issue where linux would dump spurious output to tty on startup (due to a broadcast stop event). After the checkin, it was noticed on FreeBSD a unit test was now failing. On closer investigation I found the test was using the C++ API to launch an inferior while using an SBListener to monitor the public state changes. As on OSx, it was expecting to see:
eStateRunning
eStateStopped
On Linux/FreeBSD, there is an extra state change
eStateLaunching
eStateRunning
eStateStopped
I reworked the test to work for both cases and re-enabled the test of FreeBSD.
Differential Revision: http://reviews.llvm.org/D5837
llvm-svn: 222511
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The default value for opt.thread_count was multiprocessing.cpu_count(),
which meant the LLDB_TEST_THREADS environment variable was never used.
It's not easy to pass the -t option to the test run when invoking it
from e.g. 'ninja check-lldb', so having the environment variable as an
option is useful.
Change the logic so that the thread count is set by the first one of:
1. The -t option to test/dosep.py
2. The LLDB_TEST_THREADS environment variable
3. The machine's CPU count from multiprocessing.cpu_count()
llvm-svn: 222501
|
|
|
|
| |
llvm-svn: 222484
|
|
|
|
| |
llvm-svn: 222449
|
|
|
|
|
|
| |
llvm.org/pr21620
llvm-svn: 222442
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: In noack mode, these checksums are ignored by llgs, but some implementations need them still. Specify these checksums to ease integration.
Test Plan: Run the tests before and after the change and make sure nothing breaks.
Reviewers: clayborg, tfiala
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D6343
llvm-svn: 222441
|
|
|
|
|
|
|
|
|
|
| |
Process/ProcessPOSIX.cpp
and FreeBSD/ProcessMonitor.
http://reviews.llvm.org/D6240
llvm-svn: 222372
|
|
|
|
|
|
| |
options, we don't end up caching the summary hence obtained. You may want to obtain an uncapped summary, but this should not be reflected in the summary we cache. The drawback is that we don't cache as aggressively as we could, but at least you get to have different summaries with different options without having to reset formatters or the SBValue at each step
llvm-svn: 222280
|
|
|
|
|
|
| |
retrieve uncapped data
llvm-svn: 222277
|
|
|
|
| |
llvm-svn: 222276
|
|
|
|
| |
llvm-svn: 222246
|
|
|
|
|
|
| |
llvm.org/21599
llvm-svn: 222245
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The problem is that editline currently is trying to be smart when we paste things into a terminal window. It detects that input is pending and multi-line input is accepted as long as there is anything pending.
So if you open lldb and paste the text between the quotes:
"command regex carp
s/^$/help/
carp
"
We still still be stuck in the "command regex" multi-line input reader as it will have all three lines:
"s/^$/help/
carp
"
The true fix for this is something Kate Stone will soon work on:
- multi-line input readers must opt into this paste/pending input feature ("expr" will opt into it, all other commands won't)
- If we are in a multi-line input reader that requests this and stuff is pasted, then it will do what it does today
- if we start in a IOHandler that doesn't need/want pending input and text is pasted, and we transistion to a IOHandler that does want this functionality, then disable the pending input. Example text would be:
"frame variable
thread backtrace
expr
for (int i=0;i<10;++i)
(int)printf("i = %i\n", i);
frame select 0
"
When we push the expression multi-line reader we would disable the pending input because we had pending input _before_ we entered "expr".
If we did this first:
(lldb) expr
Then we pasted:
"void foo()
{
}
void bar()
{
}
"
Then we would allow the pending input to not look for an empty line to terminate the expression. We filed radar 19008425 to track fixing this issue.
llvm-svn: 222206
|
|
|
|
|
|
| |
a read error, and reporting spurious 'unable to read data' messages. rdar://19007243
llvm-svn: 222190
|
|
|
|
|
|
| |
that. getattr(,,None) is the closest to ?. we have in Python, so use that
llvm-svn: 222160
|
|
|
|
|
|
|
|
|
| |
Fixes include:
- Add a new lldbtest.TestBase function named registerSharedLibrariesWithTarget. This function can be called using the shared libraries for your test suite either as shared library basename ("foo"), path basename ("libfoo.dylib") or full path ("/tmp/lldb/test/lang/c/carp/libfoo.dylib"). These shared libraries are then registered with the target so they will be downloaded when the test is run remotely.
- Changed a lot of tests over to use SBDebugger::CreateTarget(...) calls instead of using "file a.out" commands.
- Cleaned up some tests to add new locations for breakpoints that all compilers should be able to abide by. Some tests and constants being loaded into values of structs and some compilers like arm64 will often combine two constant data loads into a single source line so some breakpoint locations were not being set correctly. Adding lines like 'puts("")' allow us to lock onto a source line that will have code.
llvm-svn: 222156
|
|
|
|
|
|
|
| |
- Added a new "--apple-sdk" flag that can be specified on Darwin only so the correct cross compilers can be auto-selected without having to specify the "--compiler" flag.
- Set SDKROOT if needed
llvm-svn: 222153
|
|
|
|
|
|
|
|
|
|
| |
This test has intermittently failed on FreeBSD for quite some time when
run as part of the full test suite. It generally passes when run by
itself. Mark as expected failure for now to reduce buildbot noise.
llvm.org/pr15039 test fails intermittently on FreeBSD
llvm-svn: 222134
|
|
|
|
|
|
|
|
|
| |
Effectively removes -lpthreads from linux/gcc build of test programs in test/api/multithreaded. This was done due to that combination causing a test program to hang due, likely due to an issue with gcc linker and libstdc++ conflicting pthreads code in test program and pthread used by lldb. Issue has been documented at:
http://llvm.org/bugs/show_bug.cgi?id=21553
Differential Revision: http://reviews.llvm.org/D5838
llvm-svn: 222031
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Something like "core:1" would match and try to be interpreted by the following code otherwise.
Test Plan: Run tests and make sure the ones failing previously now pass.
Reviewers: tfiala, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D6257
llvm-svn: 221980
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: These checksums are ignored by llgs but some implementations require them to be specified properly.
Test Plan: Re-run llgs tests with the checksums and make sure we don't break anything.
Reviewers: tfiala, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D6254
llvm-svn: 221927
|
|
|
|
|
|
|
|
|
|
|
| |
Part of TestConcurrentEvents starts threads that are supposed to be
delayed by one second.
Test was adding "delay" threads to the "actions" thread list instead
of the "delay_actions" list, which caused them to be started without
delay.
llvm-svn: 221859
|
|
|
|
| |
llvm-svn: 221830
|
|
|
|
|
|
| |
debug it when it fails.
llvm-svn: 221828
|
|
|
|
|
|
| |
llvm.org/pr21550
llvm-svn: 221815
|
|
|
|
|
|
| |
Reviewed by Ed Maste at MeetBSD.
llvm-svn: 221787
|
|
|
|
|
|
| |
eligible for oneline printing, and fixes rdar://18120906
llvm-svn: 221701
|