llvm-svn: 202726

llvm-svn: 202725

llvm-svn: 202724

llvm-svn: 202723

This seems reasonable and the BackticksWithNoTargetTestCase suggests it
should be this way.

llvm-svn: 202722

llvm-svn: 202718

<rdar://problem/15949113>

llvm-svn: 202561

read during materialization.  First of all, report
if we can't read the data for some reason.  Second,
consult the ValueObject's error and report that if
there's some problem.

<rdar://problem/16074201>

llvm-svn: 202552

This seems a little more straightforward and is equivalent to r201457
for ELF core files.  A case for FreeBSD i386 is also added (it was
incorrectly using the 64-bit register context and corrupting mememory).

Better (user-facing) error handling is still needed.

Review: http://llvm-reviews.chandlerc.com/D2765
llvm-svn: 202549

This change adds a missing include path to the
ObjC LanguageRuntime path to the MacOSX SystemRuntime
plugin's Makefile.

It also adds the panel and curses library to the liblldb
shared library linkage step.

Changes by Jevin Sweval with a minor tweak.

llvm-svn: 202547

Be sure to propagate the error back out SBTarget::Attach() when we fail to launch debugserver as root.

<rdar://problem/15669788>

llvm-svn: 202536

llvm-svn: 202535

I carefully reviewed exactly how the IOHandlers interact and found places where we weren't properly controlling things. There should be no overlapping prompts and all output should now come out in a controlled fashion.

<rdar://problem/16111293>

llvm-svn: 202525

llvm-svn: 202522

I suspect I may have misrun the test previously for check-in
r202456 re: pr15258.  This test fails consistently on my end.
I changed the test to expected failure on Linux.

llvm-svn: 202517

This worked 25 out of 25 times for me on Ubuntu 12.04 LTS x86_64 built
with gcc 4.8.2 and the July 2013 libedit.

llvm-svn: 202516

TestRegisterVariables.test_with_dwarf_and_run_command was being
skipped on Linux due to issues with clang. I converted it to a
@expectedFailureClang and no longer skip on Linux.

llvm-svn: 202515

TestConstVariables.py was disabled on Linux and marked as
unconditional expected failure. This change removes the Linux disable
and makes the expected failure conditional on using clang. The test
runs fine on gcc-built lldb.

llvm-svn: 202514

This was broken in the threaded inferior implementation for FreeBSD
(r196787) and caused FreeBSD to resume always with no signal.

llvm-svn: 202513

This test passed 50 out of 50 times for me on Unbuntu 12.04 LTS x86_64
with lldb built using gcc 4.8.2 and July 2013 libedit.

This is related to:
http://llvm.org/bugs/show_bug.cgi?id=16170

llvm-svn: 202512

Related to this bug:
http://llvm.org/bugs/show_bug.cgi?id=16714

On TOT lldb svn r202507, I found several of the tests disabled within
TestConcurrentEvents.py to run fine, and several of them to fail 100%
of the time on my system (25 out of 25 times).

This changes the following tests for Linux:

Enables (these all work consistently):
* test_many_watchpoints_dwarf
* test_signal_watch_break_dwarf (line 250)
* test_signal_watch_break_dwarf (line 260 - same named test?)
* test_crash_with_watchpoint_dwarf
* test_crash_with_watchpoint_breakpoint_signal_dwarf
* test_delayed_crash_with_breakpoint_watchpoint_dwarf

Marks as expected failure (these all fail consistently):
* test_many_watchpoints_dwarf
* test_watch_break_dwarf
* test_delay_watch_break_dwarf
* test_watch_break_dwarf_delay
* test_signal_watch_dwarf
* test_delay_signal_watch_dwarf
* test_signal_delay_watch_dwarf
* test_two_breakpoints_one_watchpoint_dwarf
* test_breakpoints_delayed_breakpoint_one_watchpoint_dwarf
* test_two_watchpoint_threads_dwarf
* test_watchpoint_with_delay_watchpoint_threads_dwarf
* test_two_watchpoints_one_breakpoint_dwarf
* test_two_watchpoints_one_delay_breakpoint_dwarf
* test_watchpoint_delay_watchpoint_one_breakpoint_dwarf
* test_two_watchpoints_one_signal_dwarf
* test_signal_watch_break_dwarf

llvm-svn: 202511

This is related to:
http://llvm.org/bugs/show_bug.cgi?id=16170

This test ran successfully 40 out of 40 times on Ubuntu 12.04 LTS
x86_64.

llvm-svn: 202508

Similar to my previous check-in related to:
http://llvm.org/bugs/show_bug.cgi?id=15037

10 out of 10 runs of this failed.  Mark it XFAIL.

llvm-svn: 202507

Related to this bug:
http://llvm.org/bugs/show_bug.cgi?id=15037

Previously this was marked as skipped. I tried running it 10 times in
a row and it failed every time. Switched it to XFAIL.

llvm-svn: 202506

llvm-svn: 202498

Plumb the EvaluateExpressionOptions::{Set,Get}StopOthers through the SB API, and make it work in RunThreadPlan.
Also remove SetStopOthers from the ThreadPlanCallFunction, because if the value you have doesn't match what is
in the EvaluateExpressionOptions the plan was passed when created it won't work correctly.

llvm-svn: 202464

This is related to:
http://llvm.org/bugs/show_bug.cgi?id=15258

I ran this test 10 times successfully against Ubuntu 12.04 LTS x86_64
with lldb built with gcc 4.8.2 and July 2013 libedit.

llvm-svn: 202456

This is related to:
http://llvm.org/bugs/show_bug.cgi?id=15278

I ran this 20 times in a row without failure at svn r202440 on Ubuntu
12.04 LTS x86_64 using July 2013 libedit and gcc 4.8.2.

llvm-svn: 202448

llvm-svn: 202447

I could not get http://llvm.org/bugs/show_bug.cgi?id=16016)
to fail on my end running 10 times in a row.  Re-enabling
the test.

llvm-svn: 202446

llvm-svn: 202440

1 - There were some outdated options being passed to clang
2 - There were some bad paths being passed as options
3 - The path to the main.cpp file ("/tmp/main.cpp") was wrong when the tests were being run, now we create a temp file
4 - Added a new ActionType::eNone to do nothing (no continue, step, or kill)

llvm-svn: 202431

This change fixes up issues with specifying the size of the i386
register infos for FPU registers.  The bug was that for the i386
register context, the size of the FPU registers were still being
computed based on the x86_64 FXSAVE structure.

This change permits the FPR_SIZE macro to optionally be defined
outside of RegisterInfos_i386.h, which RegisterContextLinux_i386.cpp
does properly. It redefines the FPR_i386 structure with all the
accessible parts that RegisterInfos_i386.h wants to see, which we had
not done before when we made the overall size of the structure
properly sized a recently.

This change also modifies POSIXThread to create a
RegisterContextLinux_i386 only when the host is 32-bit; otherwise, it
uses the RegisterContextLinux_x86_64, which works properly for 32-bit
and 64-bit inferiors on a 64-bit host.

I tested this debugging a Linux x86 exe on an x86 host (Ubuntu 13.10
x86), and debugging a Linux x86 exe and a Linux x86-64 exe on an
x86-64 host (Ubuntu 12.04 LTS).  Those cases all worked.

Thanks to Matthew Gardiner who discoverd may key insights into
tracking down the issue. The motivation for this change and some of
the code originates from him via this thread:

http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20140224/010554.html

llvm-svn: 202428

<rdar://problem/16140277>

llvm-svn: 202426

Changed all "localhost" to "127.0.0.1" to prevent potentially long name lookups.

<rdar://problem/16154630>

llvm-svn: 202424

llvm-svn: 202423

This change converts points to clang::ExternalASTSource from llvm::OwningPtr<> to
llvm::IntrusiveRefCntPtr<>.

llvm-svn: 202411

update the declaration from llvm::OwningPtr to llvm::IntrusiveRefCntPtr to match the clang update (r202346) on ASTContext

llvm-svn: 202376

A better long term fix for stopping the process when it is running by writing to the pipe that was used for cancel. 

We now write a 'q' to indicate to exit the IOHandlerProcessSTDIO::Run(), and a 'i' to interrupt the process. This should make this code safer to use in a signal handler function.

llvm-svn: 202311

llvm-svn: 202309