of whatever we were using before...

llvm-svn: 113631

llvm-svn: 113630

llvm-svn: 113629

llvm-svn: 113628

llvm-svn: 113627

Make 'setProperty()', 'setBase()', and 'setLocation()' private in ObjCPropertyRefExpr, and friend ASTStmtReader so that it is the only class that can use them.

llvm-svn: 113626

llvm-svn: 113625

llvm-svn: 113624

llvm-svn: 113623

llvm-svn: 113622

llvm-svn: 113621

llvm-svn: 113620

llvm-svn: 113619

(The Ada bindings probably need it too, but all the
obvious places to change say "do not edit this file".)

llvm-svn: 113618

llvm-svn: 113616

string.

llvm-svn: 113615

llvm-svn: 113614

Polish diagnostics for null dereferences via ObjC ivar accesses.  Finishes up <rdar://problem/6352035>.

llvm-svn: 113612

There was a check to make sure that the frame had a valid function before the expression parser would allow decl lookups which was not needed. After removing this you can evaluate expressions correctly when stopped in a frame that only has a symbol or has no symbol context at all.

llvm-svn: 113611

llvm-svn: 113610

pointed out by Jim Ingham.  The convenient one-liner specification should only
apply when there is only one breakpoint id being specified for the time being.

llvm-svn: 113609

llvm-svn: 113608

llvm-svn: 113607

understand (the log file was no help).

llvm-svn: 113605

llvm-svn: 113603

reference object to a c++ member function.
fixes radar 8409336.

llvm-svn: 113602

"llvm.eh.catch.all.value". Only the name needs to be changed.

llvm-svn: 113600

up a seciton offset address (SBAddress) within a module that returns a
symbol context (SBSymbolContext). Also added a SBSymbolContextList in 
preparation for adding find/lookup APIs that can return multiple results.

Added a lookup example code that shows how to do address lookups.

llvm-svn: 113599

llvm-svn: 113598

fixed operands from the total number of operands (including the variadic ones).

llvm-svn: 113597

command for a breakpoint, for example:

(lldb) breakpoint command add -p 1 "conditional_break.stop_if_called_from_a()"

The ScriptInterpreter interface has an extra method:

    /// Set a one-liner as the callback for the breakpoint command.
    virtual void 
    SetBreakpointCommandCallback (CommandInterpreter &interpreter,
                                  BreakpointOptions *bp_options,
                                  const char *oneliner);

to accomplish the above.

Also added a test case to demonstrate lldb's use of breakpoint callback command
to stop at function c() only when its immediate caller is function a().  The
following session shows the user entering the following commands:

1) command source .lldb (set up executable, breakpoint, and breakpoint command)
2) run (the callback mechanism will skip two breakpoints where c()'s immeidate caller is not a())
3) bt (to see that indeed c()'s immediate caller is a())
4) c (to continue and finish the program)

test/conditional_break $ ../../build/Debug/lldb
(lldb) command source .lldb
Executing commands in '.lldb'.
(lldb) file a.out
Current executable set to 'a.out' (x86_64).
(lldb) breakpoint set -n c
Breakpoint created: 1: name = 'c', locations = 1
(lldb) script import sys, os
(lldb) script sys.path.append(os.path.join(os.getcwd(), os.pardir))
(lldb) script import conditional_break
(lldb) breakpoint command add -p 1 "conditional_break.stop_if_called_from_a()"
(lldb) run
run
Launching '/Volumes/data/lldb/svn/trunk/test/conditional_break/a.out'  (x86_64)
(lldb) Checking call frames...
Stack trace for thread id=0x2e03 name=None queue=com.apple.main-thread:
  frame #0: a.out`c at main.c:39
  frame #1: a.out`b at main.c:34
  frame #2: a.out`a at main.c:25
  frame #3: a.out`main at main.c:44
  frame #4: a.out`start
c called from b
Continuing...
Checking call frames...
Stack trace for thread id=0x2e03 name=None queue=com.apple.main-thread:
  frame #0: a.out`c at main.c:39
  frame #1: a.out`b at main.c:34
  frame #2: a.out`main at main.c:47
  frame #3: a.out`start
c called from b
Continuing...
Checking call frames...
Stack trace for thread id=0x2e03 name=None queue=com.apple.main-thread:
  frame #0: a.out`c at main.c:39
  frame #1: a.out`a at main.c:27
  frame #2: a.out`main at main.c:50
  frame #3: a.out`start
c called from a
Stopped at c() with immediate caller as a().
a(1) returns 4
b(2) returns 5
Process 20420 Stopped
* thread #1: tid = 0x2e03, 0x0000000100000de8 a.out`c + 7 at main.c:39, stop reason = breakpoint 1.1, queue = com.apple.main-thread
  36   	
  37   	int c(int val)
  38   	{
  39 ->	    return val + 3;
  40   	}
  41   	
  42   	int main (int argc, char const *argv[])
(lldb) bt
bt
thread #1: tid = 0x2e03, stop reason = breakpoint 1.1, queue = com.apple.main-thread
  frame #0: 0x0000000100000de8 a.out`c + 7 at main.c:39
  frame #1: 0x0000000100000dbc a.out`a + 44 at main.c:27
  frame #2: 0x0000000100000e4b a.out`main + 91 at main.c:50
  frame #3: 0x0000000100000d88 a.out`start + 52
(lldb) c
c
Resuming process 20420
Process 20420 Exited
a(3) returns 6
(lldb) 

llvm-svn: 113596

Lower the unrolling theshold to 150.  Empirical tests indicate that this is a sweet spot in the performance per
code size increase curve.

llvm-svn: 113595

llvm-svn: 113594

reserved regs and that register allocators need to explicitly check for
them.

llvm-svn: 113593

I am experimenting with putting visibility-default attributes on all struct/classes in libc++.  This checkin decorates only basic_string and vector as an experiment, and for review by those in this audience that might know more about visibilty than I do.  If I get no negative feedback on this procedure I will begin to decorate the entire library in this way.

llvm-svn: 113590

set the debugger_unique_id with the lldb prefix.

llvm-svn: 113589

that the memoperands are properly set after DAG building and general mucking
about.

llvm-svn: 113585

llvm-svn: 113584

llvm-svn: 113582

The Unwind and RegisterContext subclasses still need
to be finished; none of this code is used by lldb at
this point (unless you call into it by hand).

The ObjectFile class now has an UnwindTable object.

The UnwindTable object has a series of FuncUnwinders
objects (Function Unwinders) -- one for each function
in that ObjectFile we've backtraced through during this
debug session.

The FuncUnwinders object has a few different UnwindPlans.
UnwindPlans are a generic way of describing how to find
the canonical address of a given function's stack frame
(the CFA idea from DWARF/eh_frame) and how to restore the
caller frame's register values, if they have been saved
by this function.

UnwindPlans are created from different sources.  One source is the
eh_frame exception handling information generated by the compiler
for unwinding an exception throw.  Another source is an assembly
language inspection class (UnwindAssemblyProfiler, uses the Plugin
architecture) which looks at the instructions in the funciton
prologue and describes the stack movements/register saves that are
done.

Two additional types of UnwindPlans that are worth noting are
the "fast" stack UnwindPlan which is useful for making a first
pass over a thread's stack, determining how many stack frames there
are and retrieving the pc and CFA values for each frame (enough
to create StackFrameIDs).  Only a minimal set of registers is
recovered during a fast stack walk.  

The final UnwindPlan is an architectural default unwind plan.
These are provided by the ArchDefaultUnwindPlan class (which uses
the plugin architecture).  When no symbol/function address range can
be found for a given pc value -- when we have no eh_frame information
and when we don't have a start address so we can't examine the assembly
language instrucitons -- we have to make a best guess about how to 
unwind.  That's when we use the architectural default UnwindPlan.
On x86_64, this would be to assume that rbp is used as a stack pointer
and we can use that to find the caller's frame pointer and pc value.
It's a last-ditch best guess about how to unwind out of a frame.

There are heuristics about when to use one UnwindPlan versues the other --
this will all happen in the still-begin-written UnwindLLDB subclass of
Unwind which runs the UnwindPlans.

llvm-svn: 113581