| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 266164
|
|
|
|
|
|
|
|
| |
When run with the multiprocess test runner, the getchar() trick doesn't work, so ninja check-lldb would fail on this test, but running the test directly worked fine.
Differential Revision: http://reviews.llvm.org/D19035
llvm-svn: 266145
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
specify the demangled name. So all of the following now work:
(lldb) b ~Foo
(lldb) b Foo::~Foo
(lldb) b Bar::Foo::~Foo
Improved out C++ breakpoint locations tests as well to cover this issue.
<rdar://problem/25577252>
llvm-svn: 266139
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The result variables aren't useful, and if you have a breakpoint on a
common function you can generate a lot of these. So I changed the
code that checks the condition to set ResultVariableIsInternal in the
EvaluateExpressionOptions that we pass to the execution.
Unfortunately, the check for this variable was done in the wrong place
(the static UserExpression::Evaluate) which is not how breakpoint
conditions execute expressions (UserExpression::Execute). So I moved
the check to UserExpression::Execute (which Evaluate also calls) and made the
overridden method DoExecute.
llvm-svn: 266093
|
|
|
|
|
|
| |
this test ever succeeded on OS X.
llvm-svn: 266092
|
|
|
|
|
|
|
| |
this test was unintentionally XFAILed due to a change in the behavior of the expectedFailure
decorator. Fix that. Also, mark the test as debug-info independent while I'm in there.
llvm-svn: 266072
|
|
|
|
| |
llvm-svn: 265906
|
|
|
|
|
|
| |
TSan logic from SBThread to InstrumentationRuntime plugin.
llvm-svn: 265905
|
|
|
|
| |
llvm-svn: 265869
|
|
|
|
| |
llvm-svn: 265865
|
|
|
|
|
|
| |
Fixes <rdar://problem/25629755>
llvm-svn: 265849
|
|
|
|
|
|
| |
http://reviews.llvm.org/D18886
llvm-svn: 265843
|
|
|
|
| |
llvm-svn: 265656
|
|
|
|
|
|
| |
Test passes there, and this would have helped me catch the snafu in the previous commit.
llvm-svn: 265650
|
|
|
|
|
|
|
| |
test_same_pid_running couldn't delete the temporary files, while we had them open. Deleting the
target should make things work.
llvm-svn: 265529
|
|
|
|
|
|
|
|
| |
work that way."
This reverts commit e5f0ba4fcf977ad6baaaca700d3646675cdac19b.
llvm-svn: 265476
|
|
|
|
|
|
| |
way.
llvm-svn: 265461
|
|
|
|
| |
llvm-svn: 265406
|
|
|
|
| |
llvm-svn: 265401
|
|
|
|
|
|
| |
work on OS X 10.10 and older).
llvm-svn: 265400
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously we had 3 different method to run shell commands on the
target and 4 copy of code waiting until a given file appears on the
target device (used for syncronization). This CL merges these methods
to 1 run_platform_command and 1 wait_for_file_on_target functions
located in some utility classes.
Differential revision: http://reviews.llvm.org/D18789
llvm-svn: 265398
|
|
|
|
| |
llvm-svn: 265396
|
|
|
|
| |
llvm-svn: 265395
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
There was a bug in linux core file handling, where if there was a running process with the same
process id as the id in the core file, the core file debugging would fail, as we would pull some
pieces of information (ProcessInfo structure) from the running process instead of the core file.
I fix this by routing the ProcessInfo requests through the Process class and overriding it in
ProcessElfCore to return correct data.
A (slightly convoluted) test is included.
Reviewers: clayborg, zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D18697
llvm-svn: 265391
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Teach LLDB that different shells have different characters they are sensitive to, and use that knowledge to do shell-aware escaping
This helps solve a class of problems on OS X where LLDB would try to launch via sh, and run into problems if the command line being passed to the inferior contained such special markers (hint: the shell would error out and we'd fail to launch)
This makes those launch scenarios work transparently via shell expansion
Slightly improve the error message when this kind of failure occurs to at least suggest that the user try going through 'process launch' directly
Fixes rdar://problem/22749408
llvm-svn: 265357
|
|
|
|
|
|
|
| |
These tests run fine locally for me but are failing on the Green Dragon
OS X CI.
llvm-svn: 265342
|
|
|
|
|
|
|
| |
This addresses the same problem as r264846 (the test not expecting the situation when two thread
hit the watchpoint simultaneously), but for a different test.
llvm-svn: 265294
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
libcxx
Enrico has a bug on him to make this work across older libcxx list
and newer libcxx list simultaneously. Needed in preparation of
getting the OS X public CI to run the TSAN tests.
tracked by:
rdar://25499635
llvm-svn: 265188
|
|
|
|
| |
llvm-svn: 265181
|
|
|
|
|
|
| |
no formatters matching the constraints could be found
llvm-svn: 264957
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
the inferior in the test deliberately does not lock a mutex when accessing the watched variable.
The reason for that is unclear as, based on the logs, the original intention of the test was to
check whether watchpoints get propagated to newly created threads, which should work fine even
with a mutex. Furthermore, in the unlikely event (which I have still observed happening from time
to time) that two threads do manage the execute the "critical section" simultaneously, the test
will fail, as it is expecting the watchpoint "hit count" to be 1, but in this case it will be 2.
Given this, I have simply chose to lock the mutex always, so that we have more predictible
behavior. Watchpoints being hit simultaneously is still (and correctly!) tested by
TestConcurrentEvents.
Reviewers: clayborg, jingham
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D18558
llvm-svn: 264846
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
that there are few things to watch out for when writing pexpect tests:
1 - If you plan on looking for the "(lldb) " prompt as a regular expression, look for "\(lldb\) " so you don't just find "lldb".
2 - Make sure to not use colors (specify --no-use-colors as an option to lldb when launching it) as our editline will print:
"(lldb) <color junk>(lldb) "
where "<color junk>" is a work around that is used to allow us to colorize our prompts. The bad thing is this will make pexepct code like this not execute as you would expect:
prompt = "\(lldb\) "
self.child.sendline("breakpoint set ...", prompt)
self.child.sendline("breakpoint clear ...", prompt)
The problem is the first "sendline" will create two lldb prompts and will match both the first and second prompts and you output will get off. So be sure to disable colors if you need to.
Fixed a case where "TestCommandScriptImmediateOutput.py" would fail if you have spaces in your directory names. I modified custom_command.py to use shlex to parse arguments and I quoted the file path we sent down to the custom_command.write_file function.
llvm-svn: 264810
|
|
|
|
|
|
|
|
| |
track the fact that an alias is an alias to a dash-dash alias
(and I hope I typed the word 'alias' enough times in this commit message :-)
llvm-svn: 264468
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Fixes SBCommandReturnObject::SetImmediateOutputFile() and
SBCommandReturnObject::SetImmediateOutputFile() for files opened
with "a" or "a+" by resolving inconsistencies between File and
our Python parsing of file objects.
Reviewers: granata.enrico, Eugene.Zelenko, jingham, clayborg
Subscribers: lldb-commits, sas
Differential Revision: http://reviews.llvm.org/D18228
Change by Francis Ricci <fjricci@fb.com>
llvm-svn: 264351
|
|
|
|
|
|
|
|
| |
when it can't find a type matching user input
It would be fun to make it provide suggestions (e.g. 'can't find NString, did you mean NSString instead?'), but this worries me a little bit on the account of just how thorough of a type system scan it would have to do
llvm-svn: 264343
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds ThreadSanitizer support into LLDB:
- Adding a new InstrumentationRuntime plugin, ThreadSanitizerRuntime, in the same way ASan is implemented.
- A breakpoint stops in `__tsan_on_report`, then we extract all sorts of information by evaluating an expression. We then populate this into StopReasonExtendedInfo.
- SBThread gets a new API, SBThread::GetStopReasonExtendedBacktraces(), which returns TSan’s backtraces in the form of regular SBThreads. Non-TSan stop reasons return an empty collection.
- Added some test cases.
Reviewed by Greg Clayton.
llvm-svn: 264162
|
|
|
|
|
|
|
|
|
|
| |
strings for commands
This solves issues such as 'apropos foo' returning valid matches just because syntax examples happen to use 'foo' as a placeholder token
Fixes rdar://9043025
llvm-svn: 264123
|
|
|
|
|
|
| |
terms of another alias, trying to run the nested command would actually cause a crash in the command interpreter
llvm-svn: 264096
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We want to do a better job presenting errors that occur when evaluating
expressions. Key to this effort is getting away from a model where all
errors are spat out onto a stream where the client has to take or leave
all of them.
To this end, this patch adds a new class, DiagnosticManager, which
contains errors produced by the compiler or by LLDB as an expression
is created. The DiagnosticManager can dump itself to a log as well as
to a string. Clients will (in the future) be able to filter out the
errors they're interested in by ID or present subsets of these errors
to the user.
This patch is not intended to change the *users* of errors - only to
thread DiagnosticManagers to all the places where streams are used. I
also attempt to standardize our use of errors a bit, removing trailing
newlines and making clients omit 'error:', 'warning:' etc. and instead
pass the Severity flag.
The patch is testsuite-neutral, with modifications to one part of the
MI tests because it relied on "error: error:" being erroneously
printed. This patch fixes the MI variable handling and the testcase.
<rdar://problem/22864976>
llvm-svn: 263859
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This also adds a basic smoke test for linux core file reading. I'm checking in the core files as
well, so that the tests can run on all platforms. With some tricks I was able to produce
reasonably-sized core files (~40K).
This fixes the first part of pr26322.
Reviewers: zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D18176
llvm-svn: 263628
|
|
|
|
|
|
|
|
|
|
|
|
| |
others, BOOL == signed char.
This can cause differences in which bit patterns end up meaning YES or NO. In general, however, 0 == NO and 1 == YES.
To keep it simple, LLDB will now show "YES" and "NO" only for 1 and 0 respectively, and format other values as the plain numeric value instead.
Fixes rdar://24809994
llvm-svn: 263604
|
|
|
|
|
|
| |
type NSError**. Fixes rdar://25060684
llvm-svn: 263603
|
|
|
|
|
|
|
|
| |
Use the same method to find the cache line as in Read().
Differential Revision: http://reviews.llvm.org/D18050
llvm-svn: 263233
|
|
|
|
|
|
|
|
|
|
| |
Patch by Nitesh Jain
Reviewers: clayborg, jaydeep.
Subscribers: bhushan, mohit.bhakkad, sagar, lldb-commits.
Differential Revision: http://reviews.llvm.org/D17597
llvm-svn: 262819
|
|
|
|
|
|
|
|
|
|
|
|
| |
SysV ARM (hard/soft) ABI."
This partially reverts commit r262218.
The commit added additional checks to a test case. The test case is too big so it's not feasible
to XFAIL it completely. Suggest to implement the checks as a separate test case, which can then
be XFAILed more surgically.
llvm-svn: 262223
|
|
|
|
|
|
|
|
|
|
| |
(hard/soft) ABI.
For details see:
Differential revision: http://reviews.llvm.org/D17708
llvm-svn: 262218
|
|
|
|
|
|
|
|
|
|
|
| |
Patch by Nitesh Jain.
Summary: The debug version of libc.so is require for backtracing which may not be available on all platforms.
Reviewers: ovyalov, clayborg
Subscribers: zturner, lldb-commits, mohit.bhakkad, sagar, bhushan, jaydeep
Differential: http://reviews.llvm.org/D17131
llvm-svn: 262011
|
|
|
|
|
|
|
|
|
|
|
|
| |
32-bit processes on 64-bit Windows run in a layer called WoW64 (Windows-on-Windows64). If you capture a mini dump of such a process from a 32-bit debugger, you end up with a register context for the 64-bit WoW64 process rather than the 32-bit one you probably care about.
This detects WoW64 by looking to see if there's a module named wow64.dll loaded. For such processes, it then looks in the 64-bit Thread Environment Block (TEB) to locate a copy of the 32-bit CONTEXT record that the plugin needs for the register context.
Added some rudimentary tests. I'd like to improve these later once we figure out how to get the exception information from these mini dumps.
Differential Revision: http://reviews.llvm.org/D17465
llvm-svn: 261808
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are two tests in this file. One which only runs on Windows
and tests that you can set a breakpoint with mismatched case. And
another that only runs on non-Windows and tests that you cannot set
a breakpoint with mismatched case. This latter test is failing on
non Windows platforms for some reason. It could be that the test
is just written incorrectly, as I think the actual functionality
actually works correctly on non-Windows platforms.
llvm-svn: 261800
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Paths on Windows are not case-sensitive. Because of this, if a file
is called main.cpp, you should be able to set a breakpoint on it
by using the name Main.cpp. In an ideal world, you could just
tell people to match the case, but in practice this can be a real
problem as it requires you to know whether the person who compiled
the program ran "clang++ main.cpp" or "clang++ Main.cpp", both of
which would work, regardless of what the file was actually called.
This fixes http://llvm.org/pr22667
Patch by Petr Hons
Differential Revision: http://reviews.llvm.org/D17492
Reviewed by: zturner
llvm-svn: 261771
|