llvm-svn: 201024

llvm-svn: 201023

clang -O1.

<rdar://problem/15767528>

llvm-svn: 201005

ObjectFile::SetLoadAddress (Target &target,
                            lldb::addr_t value,
                            bool value_is_offset);

Now "value" is a slide if "value_is_offset" is true, and "value" is an image base address otherwise. All previous usage of this API was using slides.

Updated the ObjectFileELF and ObjectFileMachO SetLoadAddress methods to do the right thing.

Also updated the ObjectFileMachO::SetLoadAddress() function to not load __LINKEDIT when it isn't needed and to only load sections that belong to the executable object file.

llvm-svn: 201003

Now that the command interpreter runs in a separate thread in Xcode, we need to lock the target API lock instead of trying to lock it.

What was happening was:
1 - Xcode ran and stopped and was doing work on thread 2
2 - Users would type something in Xcode console on thread 1
3 - thread 3 would be running command interpreter thread and try to execute command but get "failed to get API lock" error for any command that wanted the target API lock (like "expression")

<rdar://problem/15775016>

llvm-svn: 200997

When a user says

type formatter add ... unsigned int

he most probably means to deal with the "unsigned int" type. However, given how the LLDB command parser works, that command will try to add the formatter to the TWO types 'unsigned' AND 'int'

Since this is unlikely to be what the user wants, warn about it, and suggest they can use quotes to override the debugger's understanding

llvm-svn: 200996

llvm-svn: 200995

values whose size differs from the register's
size.

llvm-svn: 200991

Fix a bug where we will crash if we have a class "B" that is contained inside a class "A" in the DWARF where "A" is a forward declaration.

<rdar://problem/14673945>
<rdar://problem/15682781>

llvm-svn: 200985

Provide a filter for libc++ std::atomic<T>
This just hides some implementation clutter and promotes the actual content to only child status

llvm-svn: 200984

<rdar://problem/15958296>

llvm-svn: 200951

selector when compiling an expression in an
Objective-C context.

<rdar://problem/15797390>

llvm-svn: 200950

llvm-svn: 200943

Move some code that was in DynamicLoaderPOSIXDLYD into the
base class DynamicLoader.  In the case of UpdateLoadedSections(),
the test to see whether a file is loadable (its address is zero)
is not generally applicable so that test is changed to a more
universally applicable check for the SHF_ALLOC flag on the section.

Also make it explicit that the reading of the module_id in
DynamicLoaderPOSIXDYLD::GetThreadLocalData() is using a hardcoded
size (of module_id) of 4, which might not be appropriate on
big-endian 64-bit systems, leaving a FIXME comment in place.

llvm-svn: 200939

The "-n" and "-p" options to the lldb driver no longer worked after recent IOHandler changes, this is now fixed.

<rdar://problem/15962763>

llvm-svn: 200930

We now properly detect when a result object has an immediate output stream and don't echo the results a second time.

<rdar://problem/15954906>

llvm-svn: 200882

An example summary provider for PyObject and the LLDB wrapper PythonObject hierarchy - this would have probably helped track down those refcount bugs..

llvm-svn: 200879

output a bit.

llvm-svn: 200878

Also emit the "Executing commands" message so it properly only comes out when desired and so it comes out in the right place.

<rdar://problem/15992208>

llvm-svn: 200875

llvm-svn: 200871

llvm-svn: 200870

llvm-svn: 200866

It passes basic sanity tests so we might as well enable it.

llvm-svn: 200865

- empty lines in init files would repeat previous command and cause errors to be displayed
- all options to control showing the command, its output, if it should stop on error or continue, weren't being obeyed.

llvm-svn: 200860

llvm-svn: 200859

libldi library to collect extended backtrace information; switch
to the libBacktraceRecording library and its APIs.  Complete the
work of adding QueueItems to Queues and allow for the QueueItems
to be interrogated about their extended backtraces in turn.

There's still cleanup and documentation to do on this code but the
code is functional and I it's a good time to get the work-in-progress 
checked in.  
<rdar://problem/15314027> 

llvm-svn: 200822

ScriptInterpreterPython caches the lldb.embedded_interpreter module, and since it caches it in a refcounting-safe PythonObject, the refcount will appropriately go down 1 every time a ScriptInterpreterPython is deallocated
However, we were only importing the module once - in InitializePrivate(). In a handful of interpreter creations, the refcount on the run_one_line function would end up at 0, causing LLDB to crash
This fixes it by also importing the module for every interpreter, which ensures correct refcounting

llvm-svn: 200816

llvm-svn: 200799

This is SVN r191618 by Sylvestre Ledru applied to the FreeBSD
ProcessMonitor.

llvm-svn: 200791

LLDB exits the command interpreter and thus LLDB when using a pty or file as the input handle and a blank line is entered (like when running under emacs). This is now fixed.

<rdar://problem/15976187>

llvm-svn: 200790

llvm-svn: 200784

of sending the error packet.

llvm-svn: 200732

llvm-svn: 200725

Move a couple formatters from category AppKit to CoreFoundation

llvm-svn: 200713

The issue described in llvm.org/pr18065 is actually due to FreeBSD bug
theads/186309 [1], which is now fixed in FreeBSD SVN r261354 [2] and will
be merged to release branches shortly.

Diagnosed and fixed by John Wolfe.

[1] http://www.freebsd.org/cgi/query-pr.cgi?pr=186309
[2] http://svnweb.freebsd.org/base?view=revision&revision=261354

llvm-svn: 200648

llvm-svn: 200647

This could use some refinement still, but the previous behaviour of adding
-stdlib=libstc++ on FreeBSD w/ Clang is the least likely case to work.

llvm.org/pr17910

llvm-svn: 200646

llvm-svn: 200637

Fixes http://llvm.org/bugs/show_bug.cgi?id=18656.

Note this exposes a failure on Linux of
TestInferiorAssert.test_inferior_asserting_disassemble, similar to how
it fails on FreeBSD. I'll file a bug for this next. We're now getting
another frame beyond where we used to prior to this fix, so the fix is
exposing failures in previosly not-reachable frames.

Much thanks to Jason Molenda, who had much to do with helping figure
out where unwinding was breaking.

llvm-svn: 200600

llvm-svn: 200565