lldb.target
    lldb.process
    lldb.thread
    lldb.frame

are initialized to at least contain empty lldb classes in case some python gets imported that uses them.

llvm-svn: 169750

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

llvm-svn: 169661

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

Fix Test11588.py on Linux.  The test was failing because the synthetic type fields were resolving to int instead of long.  A similar change was made in r155144 to eliminate the type specification for an earlier check in this test, so it seemed appropriate here too.

llvm-svn: 169615

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: 169552

llvm-svn: 169549

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

llvm-svn: 169454

- 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

Added the ability to debug through your process exec'ing itself to the same architecture.

llvm-svn: 169340

these are the *non-volatile* registers on Darwin/i386, not the
volatile registers.
Recognize the sp, pc, fp generic reg names as well.

llvm-svn: 169316

type of an Objective-C selector, don't bother
making the expression parser resolve it all over
again.  Just send the message straight to the
object pointer as if it were an id, and cast the
result.

<rdar://problem/12799087>

llvm-svn: 169300

them while making our initial run through the
Objective-C runtime's class tables.

<rdar://problem/12799087>

llvm-svn: 169299

llvm-svn: 169295

Add the ability to get a symbol or symbols by name and type from a SBModule, and also the ability to get all symbols by name and type from SBTarget objects.

llvm-svn: 169205

llvm-svn: 169203