"self" when those pointers are in registers.
Previously in this case the IRInterpreter would
handle them just as if the user had typed in
"$rdi", which isn't safe because $rdi is passed
in through the argument struct.

Now we correctly break out all three cases (i.e.,
normal variables in registers, $reg, and this/self),
and handle them in a way that's a little bit easier
to read and change.

This results in more accurate printing of "this" and
"self" pointers all around.  I have strengthened the
optimized-code test case for Objective-C to ensure
that we catch regressions in this area reliably in
the future.

<rdar://problem/12693963>

llvm-svn: 169924

<rdar://problem/10976636>

llvm-svn: 169810

Make sure that the user's choice of a format for dumping aggregate types is persisted to child members

llvm-svn: 169809

make it clear that this is the list of callee-saved registers,
add reference to the ABI doc that this comes from.

llvm-svn: 169807

Don't load __LINKEDIT segments when dynamically loading kexts.

llvm-svn: 169806

llvm-svn: 169799

Adding a summary for NSError

llvm-svn: 169792

When there is XPC connection error, we will report it now.

llvm-svn: 169787

When displaying function.name-with-args format will now print "varname=<unavailable>" instead of omitting argument names and values when there is an error reading the value.

llvm-svn: 169781

- gcc does not like -fno-rtti mixed with dynamic_cast<> (in cxa_demangle.cpp)

llvm-svn: 169767

Making MightHaveChildren() always return true regardless for our own data formatters
This is meant to optimize performance for common most-often-not-empty container classes

llvm-svn: 169759

Fix the OptionValueFileSpec option value to correctly get the file path when trailing spaces are on the path. The "settings set" command uses the OptionValueFileSpec class to set file paths and if extra spaces are at the end it will include those in the paths. Now we chop up the value send to to OptionValueFileSpec::SetValueFromCString(...) function with "lldb_private::Args" and give an appropriate error if more than one path is used. It also allows for quotes to be used when specifying the path.

llvm-svn: 169753

Change the wording of NSNumber summary from absurd value to unexpected value when a tagged pointer shows up that does not match our knowledge of the internals

llvm-svn: 169751

Even when we aren’t going to init all the lldb.frame, etc, globals, init lldb.debugger, since each script interpreter is tied to just one debugger.

llvm-svn: 169663

Make sure to check for DW_AT_linkage_name to get the mangled name in the DWARF along with the older DW_AT_MIPS_linkage_name attribute.

llvm-svn: 169657

lldb::SBType
SBType::GetCanonicalType();

llvm-svn: 169655

- remove unused members
- add NO_PEDANTIC to selected Makefiles
- fix return values (removed NULL as needed)
- disable warning about four-char-constants
- remove unneeded const from operator*() declaration
- add missing lambda function return types
- fix printf() with no format string
- change sizeof to use a type name instead of variable name
- fix Linux ProcessMonitor.cpp to be 32/64 bit friendly
- disable warnings emitted by swig-generated C++ code

Patch by Matt Kopec!

llvm-svn: 169645

- as per http://llvm.org/docs/CodingStandards.html#don-t-use-default-labels-in-fully-covered-switches-over-enumerations

Patch by Matt Kopec!

llvm-svn: 169633

Now that we set ThreadPlanCallFunction to private in the constructor, it is confusing that we set it
again in client code after creating the plans.  So remove those unnecessary calls.

llvm-svn: 169625

log enable now resolves the "--file" option in case it contains ~.

llvm-svn: 169623

Set ThreadPlanCallFunction to private in ConstructorSetup.  This fixes a problem on Linux where 'continue' was misfiring after an expression evaluation when stopped at a breakpoint.  The problem was that InferiorCallMmap was not setting its ThreadPlanCallFunction to private and so the completion of that thread plan appeared to be the stop reason and therefore the 'continue' operation failed to step over the breakpoint.  The SetPrivate call is being put in ThreadPlanCallFunction rather than InferiorCallMmap to make the solution more general.

llvm-svn: 169618

Separate initing the stdout/stderr for running the Python Script interpreter from initing the lldb.target/frame/etc globals,
and only do the latter when it makes sense to.

<rdar://problem/12554049>

llvm-svn: 169614

Take the Target API lock before letting the Python code start to work constructing threads, otherwise we will risk a lock-inversion deadlock between the thread list and the API mutex.

<rdar://problem/12554049>

llvm-svn: 169612

When using the same-device optimization for shared cache libraries, if
we have an invalid load address for __LINKEDIT, don't try to read
anything out of lldb's own address space.  Reading it out of the remote
address space will fail gracefully if we have bad addresses but reading
it out of lldb's own address space will result in a crash.

llvm-svn: 169582

Added "--address" as an available option for "source list".

llvm-svn: 169567

Be sure to load dSYM files when the object file is in memory only.

llvm-svn: 169560

I modified the "Args::StringtoAddress(...)" function to be able to evaluate address expressions. This is now used for any command line arguments or options that takes addresses like:

memory read <addr> [<end-addr>]
memory write <addr>
breakpoint set --address <addr>
disassemble --start-address <addr> --end-address <addr>

It calls the expression parser to evaluate the address expression and will also work around the issue where the compiler doesn't like to add offsets to function pointers (which is what happens when you try to evaluate "main + 12"). So there is a temp fix in the Args::StringtoAddress() to work around this until we can get special compiler support for debug expressions with function pointers.

llvm-svn: 169556

llvm-svn: 169515

RegisterIsCalleeSaved.  Add ebp back to the list of registers that
are callee saved.
<rdar://problem/12817918> 

llvm-svn: 169466

Fixed zero sized arrays to work correctly. This will only happen once we get a clang that emits correct debug info for zero sized arrays. For now I have marked the TestStructTypes.py as an expected failure.

llvm-svn: 169465

of the "self"/"this" pointer for the current stack
frame before wrapping expressions in C++ or
Objective-C methods.  This works around bad debug
info where the compiler emits a "this" or "self"
but doesn't give any way to find its location.

<rdar://problem/12809985>

llvm-svn: 169461

- Removed the BitfieldMap class because it is unnecessary.
  We now just track the most recently added field.

- Moved the code that calculates bitfield widths so it
  can also be used to determine whether it's necessary
  to insert anonymous fields.

- Simplified the anonymous field calculation code into
  three cases (two of which are resolved identically).

- Beefed up the bitfield testcase.

llvm-svn: 169449

for target logging.

llvm-svn: 169444

Fixed arrays with a size of 1 to correctly have 1 member when DW_AT_upper_bound was set to zero and no other attributes were set.

llvm-svn: 169431

Always allows getting builtin types by name even if there is no backing debug information.

llvm-svn: 169424

llvm-svn: 169417

Backed out part of the ABI changes that were checked in because it breaks the i386 test suite as it makes backtraces for the first instruction of a function fail. Stepping relies on backtraces being correct, so I am reverting what is causing the breakage.

I filed this to track the fix:

<rdar://problem/12817918> Recent i386 ABI changes break the i386 test suite because stack backtracing is busted when stopped in trampolines

llvm-svn: 169409

llvm-svn: 169394

Update the Target methods which can change the target log to this
channel.

llvm-svn: 169342

- add new header lldb-python.h to be included before other system headers
- short term fix (eventually python dependencies must be cleaned up)

Patch by Matt Kopec!

llvm-svn: 169341