| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 265869
|
|
|
|
| |
llvm-svn: 265865
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
thread id
-thread-info in lldbmi does not conform to protocol. Should end with
current thread id as described here:
https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI-Thread-Commands.html#GDB_002fMI-Thread-Commands
When printing all threads, the current thread id should be printed
afterwards.
Example:
-thread-info
^done,threads=[
{id="2",target-id="Thread 0xb7e14b90 (LWP 21257)",
frame={level="0",addr="0xffffe410",func="__kernel_vsyscall",
args=[]},state="running"},
{id="1",target-id="Thread 0xb7e156b0 (LWP 21254)",
frame={level="0",addr="0x0804891f",func="foo",
args=[{name="i",value="10"}],
file="/tmp/a.c",fullname="/tmp/a.c",line="158"},
state="running"}],
current-thread-id="1"
(gdb)
Patch from jacdavis@microsoft.com
Reviewers: zturner, chuckr
Differential Revision: http://reviews.llvm.org/differential/revision/edit/18880/
llvm-svn: 265858
|
|
|
|
|
|
| |
Fixes <rdar://problem/25629755>
llvm-svn: 265849
|
|
|
|
|
|
| |
http://reviews.llvm.org/D18886
llvm-svn: 265843
|
|
|
|
|
|
|
|
|
| |
This triggers in some timeout scenarios in the LLDB test suite.
Fixes:
https://bugs.swift.org/browse/SR-1193
llvm-svn: 265821
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 265527
|
|
|
|
| |
llvm-svn: 265524
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This test sets the compiler optimization level to -O1 and
makes some assumptions about how local frame vars will be
stored (i.e. in registers). These assumptions are not always
true.
I did a first-pass set of improvements that:
(1) no longer assumes that every one of the target locations has
every variable in a register. Sometimes the compiler
is even smarter and skips the register entirely.
(2) simply expects one of the 5 or so variables it checks
to be in a register.
This test probably passes on a whole lot more systems than it
used to now. This is certainly true on OS X.
llvm-svn: 265498
|
|
|
|
|
|
|
|
| |
work that way."
This reverts commit e5f0ba4fcf977ad6baaaca700d3646675cdac19b.
llvm-svn: 265476
|
|
|
|
|
|
| |
way.
llvm-svn: 265461
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The '-p' option for dotest.py was ignored in multiprocess mode,
as the -p argument to the inferior would overwrite the -p argument
passed on the command line.
Reviewers: zturner, tfiala
Subscribers: lldb-commits, sas
Differential Revision: http://reviews.llvm.org/D18779
Change by Francis Ricci <fjricci@fb.com>
llvm-svn: 265422
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 265392
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
This test is failing on the CI but not locally for me. Needs
investigation.
tracked by:
https://llvm.org/bugs/show_bug.cgi?id=27182
llvm-svn: 265175
|
|
|
|
|
|
|
|
| |
breakage
http://llvm.org/bugs/show_bug.cgi?id=27179
llvm-svn: 265165
|
|
|
|
|
|
|
| |
The test was failing on windows because the clean rule (which is executed even if the test is
skipped) returned an error there.
llvm-svn: 265140
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Debug info is used only by the client and lldb-server tests do not even have the client component
running, as they communicate with the server directly. Therefore, running the tests for each
debug info type is unnecessarry.
This adds general ability to mark a test class as not dependent on debug info, and marks all
lldb-server tests as such.
Reviewers: tberghammer, tfiala
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D18598
llvm-svn: 265017
|
|
|
|
|
|
| |
specify a help string for an alias as they are defining it
llvm-svn: 264980
|
|
|
|
|
|
| |
no formatters matching the constraints could be found
llvm-svn: 264957
|
|
|
|
|
|
| |
<rdar://problem/25447765>
llvm-svn: 264914
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
setting to
quietly apply fixits for those who really trust clang's fixits.
Also, moved the retry into ClangUserExpression::Evaluate, where I can make a whole new ClangUserExpression
to do the work. Reusing any of the parts of a UserExpression in situ isn't supported at present.
<rdar://problem/25351938>
llvm-svn: 264793
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Top-level Clang expressions are expressions that act as new translation units,
and define their own symbols. They do not have function wrappers like regular
expressions do, and declarations are persistent regardless of use of the dollar
sign in identifiers. Names defined by these are given priority over all other
symbol lookups.
This patch adds a new expression option, '-p' or '--top-level,' which controls
whether the expression is treated this way. It also adds a flag controlling
this to SBExpressionOptions so that this API is usable externally. It also adds
a test that validates that this works. (The test requires a fix to the Clang
AST importer which I will be committing shortly.)
<rdar://problem/22864976>
llvm-svn: 264662
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"." for "->".)
This feature is controlled by an expression command option, a target property and the
SBExpressionOptions setting. FixIt's are only applied to UserExpressions, not UtilityFunctions,
those you have to get right when you make them.
This is just a first stage. At present the fixits are applied silently. The next step
is to tell the user about the applied fixit.
<rdar://problem/25351938>
llvm-svn: 264379
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Win32 API calls that are Unicode aware require wide character
strings, but LLDB uses UTF8 everywhere. This patch does conversions
wherever necessary when passing strings into and out of Win32 API
calls.
Patch by Cameron
Differential Revision: http://reviews.llvm.org/D17107
Reviewed By: zturner, amccarth
llvm-svn: 264074
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
the main reason is that our decorator contains extra fluff to "expect" crashes (which seem to
happen occasionaly on the android buildbot).
llvm-svn: 263633
|
|
|
|
|
| |
cause: Async output arrival over pty
llvm-svn: 263631
|