all of the calls inlined in the header file for better performance.

Fixed the summary for C string types (array of chars (with any combo if
modifiers), and pointers to chars) work in all cases.

Fixed an issue where a forward declaration to a clang type could cause itself
to resolve itself more than once if, during the resolving of the type itself
it caused something to try and resolve itself again. We now remove the clang
type from the forward declaration map in the DWARF parser when we start to 
resolve it and avoid this additional call. This should stop any duplicate
members from appearing and throwing all the alignment of structs, unions and
classes.

llvm-svn: 117437

After a recent fix to not set the default architecture to "x86_64", the string value for the default arch was coming out as a value that shouldn't be user visible. Now we don't show any value when it isn't set.

llvm-svn: 117432

Also made type lookup lazy for types that are
hidden behind pointers.

llvm-svn: 117430

      - Try to reduce logging to one line per function call instead of tw
      - Put all arguments & their values into log for calls
      - Add 'this' parameter information to function call logging, making it show the appropriate
        internal pointer (this.obj, this.sp, this.ap...)
      - Clean up some return values
      - Remove logging of constructors that construct empty objects
      - Change '==>' to '=>'  for showing result values...
      - Fix various minor bugs
      - Add some protected 'get' functions to help getting the internal pointers for the 'this' arguments...      

llvm-svn: 117417

causing modules that haven't already been parsed from being searched.

llvm-svn: 117383

loaded/parsed.  Should add timers to this eventually.

Delay getting a full UnwindPlan if it's possible to unwind with
just a fast UnwindPlan.  This keeps us from reading the eh_frame
section unless we hit something built -fomit-frame pointer or we
hit a frame with no symbol (read: no start address) available.

It doesn't look like it is correctly falling back to using the
full UnwindPlan to provide additional registers that the fast
UnwindPlan doesn't supply; e.g. go to the middle of a stack and
ask for r12 and it will show you the value of r12 in frame 0.
That's a bug for tomorrow.

llvm-svn: 117361

gets to be a problem if you have a unbounded stack walk.

Fix the CFA sanity checks.  Add one to the arch default UnwindPlan run which was giving
one extra stack frame on the main thread.  Fix a couple of logging lines that had their
argument order incorrect.

llvm-svn: 117350

it logs the function calls, their arguments and the return values.  This is not
complete or polished, but I am committing it now, at the request of someone who
really wants to use it, even though it's not really done.  It currently does not
attempt to log all the functions, just the most important ones.  I will be 
making further adjustments to the API logging code over the next few days/weeks.
(Suggestions for improvements are welcome).


Update the Python build scripts to re-build the swig C++ file whenever 
the python-extensions.swig file is modified.

Correct the help for 'log enable' command (give it the correct number & type of
arguments).

llvm-svn: 117349

prologue profiling.

Change the log print statements to elide the thread number, make
some of them only print when IsLogVerbose().

Add a couple of sanity checks for impossible CFA values so backtraces
don't go too far off into the weeds.

llvm-svn: 117343

being generated correctly.

Also added a messy way to single-step through expressions
that I will improve soon.

llvm-svn: 117342

in mid-expression evaluation when we hit a breakpoint/signal work.

llvm-svn: 117341

llvm-svn: 117330

Don't set the default architecture to x86_64. Leave it NULL so that it isn't set to anything and so that any single architecture binary will adopt that architecture instead of posting an error stating the binary doesn't contain "x86_64".

llvm-svn: 117292

Not yet enabled as the default unwinder but there are no known
backtrace problems with the code at this point.

Added 'log enable lldb unwind' to help diagnose backtrace problems;
this output needs a little refining but it's a good first step.

eh_frame information is currently read unconditionally - the code
is structured to allow this to be delayed until it's actually needed.
There is a performance hit when you have to parse the eh_frame
information for any largeish executable/library so it's necessary
to avoid if possible.

It's confusing having both the UnwindPlan::RegisterLocation struct
and the RegisterConextLLDB::RegisterLocation struct, I need to rename
one of them.

The writing of registers isn't done in the RegisterConextLLDB subclass
yet; neither is the running of complex DWARF expressions from eh_frame
(e.g. used for _sigtramp on Mac OS X).

llvm-svn: 117256

Specifically, we fixed handling of the objc_class
built-in type, which allowed us to pass
named Objective-C objects to functions,
call variable list -t on objects safely, etc.

llvm-svn: 117249

"unsigned short."  As discussed in the comments,
this is pending a better solution to the problem
of types not in the debug information but readily
available through headers.

llvm-svn: 117247

informative message when they have no description.

llvm-svn: 117190

If we hit a thread specific breakpoint for another thread, don't report the Exception as the stop reason, you have to report no stop reason.

llvm-svn: 117179

method results to int.  This will only last until we
get accurate type information for Objective-C methods
or some way of making their types inferred by the
parser.

llvm-svn: 117178

llvm-svn: 117150

Added "po" alias for "expression -o --"

llvm-svn: 117125

Fixed a error formatting output issue when dumping variables where the error had no space before it and was missing a newline.

llvm-svn: 117086

llvm-svn: 117082

as persistent variables.  These are special markers
used by LLDB.

llvm-svn: 117078

versa.

llvm-svn: 116963

llvm-svn: 116948

So the issue here was that we have lldb_private::FileSpec that by default was 
always resolving a path when using the:

FileSpec::FileSpec (const char *path);

and in the:

void FileSpec::SetFile(const char *pathname, bool resolve = true);

This isn't what we want in many many cases. One example is you have "/tmp" on
your file system which is really "/private/tmp". You compile code in that
directory and end up with debug info that mentions "/tmp/file.c". Then you 
type:

(lldb) breakpoint set --file file.c --line 5

If your current working directory is "/tmp", then "file.c" would be turned 
into "/private/tmp/file.c" which won't match anything in the debug info.
Also, it should have been just a FileSpec with no directory and a filename
of "file.c" which could (and should) potentially match any instances of "file.c"
in the debug info.

So I removed the constructor that just takes a path:

FileSpec::FileSpec (const char *path); // REMOVED

You must now use the other constructor that has a "bool resolve" parameter that you must always supply:

FileSpec::FileSpec (const char *path, bool resolve);

I also removed the default parameter to SetFile():

void FileSpec::SetFile(const char *pathname, bool resolve);

And fixed all of the code to use the right settings.

llvm-svn: 116944

llvm-svn: 116908

if passed in a NULL new_value and the operation intended is eVarSetOperationAssign.
This fixed a bug where in TestSettings.py:

        # Set the run-args and the env-vars.
        self.runCmd('settings set target.process.run-args A B C')
        self.runCmd('settings set target.process.env-vars ["MY_ENV_VAR"]=YES')
        # And add hooks to restore the settings during tearDown().
        self.addTearDownHook(
            lambda: self.runCmd("settings set -r target.process.run-args"))
        self.addTearDownHook(
            lambda: self.runCmd("settings set -r target.process.env-vars"))

"settings set -r target.process.env-vars" was not restoring the original env-vars
setting.

llvm-svn: 116895

Don't cache the public stop reason, since it can change as plan completion gets processed.  That means GetStopReason needs to return a shared pointer, not a pointer to the thread's cached version.  Also allow the thread plans to get and set the thread private stop reason - that is usually more appropriate for the logic the thread plans need to do.

llvm-svn: 116892

to be passed improperly to expressions in certain
cases.

llvm-svn: 116884

optionally specify the tty you want to use if you want to use an existing
terminal window by giving a partial or full path name:

(lldb) process launch --tty=ttys002

This would find the terminal window (or tab on MacOSX) that has ttys002 in its
tty path and use it. If it isn't found, it will use a new terminal window.

llvm-svn: 116878

Christopher for pointing it out.

llvm-svn: 116871

that occur while they run.  This means that they
clean up after themselves even when they crash.

llvm-svn: 116870

did not return a result.  The result is nonexistent
(or void), not NULL.

llvm-svn: 116855

We now spawn a thread to accept a unix socket connection from the inferior
when it spawns in the terminal, then we launch the process, then we get
the pid back through the unix socket, and then wait for it to SIGSTOP.

darwin-debug now clears the terminal screen and prints out the program and
arguments that are about to be launched.

llvm-svn: 116841

is being run is visible in the terminal as opposed to just seeing a path
to a .command file.

llvm-svn: 116814

sockets so the driver doesn't just crash.

Added support for connecting to named sockets (unix IPC sockets) in
ConnectionFileDescriptor.

Modified the Host::LaunchInNewTerminal() for MacOSX to return the process
ID of the inferior process instead of the process ID of the Terminal.app. This
was done by modifying the "darwin-debug" executable to connect to lldb through
a named unix socket which is passed down as an argument. This allows a quick
handshake between "lldb" and "darwin-debug" so we can get the process ID
of the inferior and then attach by process ID and avoid attaching to the 
inferior by process name since there could be more than one process with 
that name. This still has possible race conditions, those will be fixed
in the near future. This fixes the SIGPIPE issues that were sometimes being
seen when task_for_pid was failing.

llvm-svn: 116792

argument type, eArgTypeUnixSignal.

llvm-svn: 116764

take raw input).

llvm-svn: 116760