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
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
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
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
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
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
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
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
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
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
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
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
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
There is a report in the PR from several months ago that it failed
intermittently, but it is passing consistently for me on FreeBSD 10
and 11. We can re-add a decorator if further testing shows it is
still flakey.
llvm.org/pr17214
llvm-svn: 261340
The race condition/use after free involved in setting long prompts
appears to be fixed now (although I do not know which commit fixed it).
llvm.org/pr22611
llvm-svn: 261266
The test fails very rarely. I suspect this is simply because the inferior does not have enough
time to create the file under heavy load.
llvm-svn: 260951
Summary: This is the form on other libc++ tests.
Reviewers: sivachandra
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D17230
llvm-svn: 260793
On libc++ std::atomic is a fairly simple data type (layout wise, at least), wrapping actual contents in a member variable named "__a_"
All the formatters are doing is "peel away" this intermediate layer and exposing user data as direct children or values of the std::atomic root variable
Fixes rdar://24329405
llvm-svn: 260752
However, they also contain fallback logic that - in cases where LLDB can't recognize the specific subclass - actually does run code in order to inspect those objects.
The argument for this logic was that these data types are critical enough that the risk of getting it wrong is outweighed by the advantage of always providing accurate child information.
Practical experience however shows that "po" - a code running data-inspection command - is quite frequently used, and not considered burdensome by users.
As such, this makes the code-running fallback in the data formatters a risk that carries very little actual reward. Also, unlike the time this code was originally written, we now have accurate class information for Objective-C, and thus we are less likely to improperly identify classes.
This commit removes support for the code-running fallback, and aligns the data formatters for NSArray, NSDictionary and NSSet to the general no-code-running behavior of other data formatters.
While it is possible for us to add support for some subclasses that are now no longer covered by static inspection alone, this is beyond the scope of this commit.
llvm-svn: 260664
clearing the map ended up calling back into the TypeSystemMap to do lookups.
Not a good idea, and in this case it would cause a deadlock.
You would only see this when replacing the target contents after an exec, and only if you
had stopped before the exec, evaluated an expression, then continued
on to the point where you did the exec.
Fixed this by making sure the TypeSystemMap::Clear tears down the TypeSystems in the map before clearing the map.
I also add an expression before exec to the TestExec.py so that we'll catch this
issue if it crops up again in the future.
<rdar://problem/24554920>
llvm-svn: 260624
