- use macros from inttypes.h for format strings instead of OS-specific types

Patch from Matt Kopec!

llvm-svn: 168945

Be sure to resolve the file path for the "target.process.python-os-plugin-path" setting.

llvm-svn: 168916

Make stack frames fix up their line table entries when the target has source remappings. Also rearranged how the m_sc.target_sp was filled in so it can be used during the StackFrame::GetSymbolContext(...) function.

llvm-svn: 168845

Add an example of using the target.process.extra-startup-command to turn on debugserver logging since
we always forget how to do this...

llvm-svn: 168840

The Function calling thread plan was replacing the stored stop info too soon, causing recursive entry into the
breakpoint StopInfo's PerformAction, which is bad.  Reworked this so that it is now correct.

<rdar://problem/12501259>

llvm-svn: 168634

llvm-svn: 168343

in the source files.  Expand to spaces.  No content changes,
just whitespace.

llvm-svn: 168238

llvm-svn: 168232

This allows client to query profiling states on the inferior.

llvm-svn: 168228

much work for this to make sense.  Just copy the current thread list and
operate on that.  Prevents some deadlocks.

llvm-svn: 168106

Thread::ResetFrameZeroRegisters() clear the UnwindLLDB object when
resetting the thread's register state.

llvm-svn: 167910

llvm-svn: 167656

Minor cleanups to the new ModuleList notification APIs: passing in the ModuleList as part of the callbacks, and not copying the notifier as part of copy constructing and assigning

llvm-svn: 167592

This commit does three things:
(a) introduces a new notification model for adding/removing/changing modules to a ModuleList, and applies it to the Target's ModuleList, so that we make sure to always trigger the right set of actions
whenever modules come and go in a target. Certain spots in the code still need to "manually" notify the Target for several reasons, so this is a work in progress
(b) adds a new capability to the Platforms: locating a scripting resources associated to a module. A scripting resource is a Python file that can load commands, formatters, ... and any other action
of interest corresponding to the loading of a module. At the moment, this is only implemented on Mac OS X and only for files inside .dSYM bundles - the next step is going to be letting
the frameworks themselves hold their scripting resources. Implementors of platforms for other systems are free to implement "the right thing" for their own worlds
(c) hooking up items (a) and (b) so that targets auto-load the scripting resources as the corresponding modules get loaded in a target. This has a few caveats at the moment:
 - the user needs to manually add the .py file to the dSYM (soon, it will also work in the framework itself)
 - if two modules with the same name show up during the lifetime of an LLDB session, the second one won't be able to load its scripting resource, but will otherwise work just fine

llvm-svn: 167569

inlined subroutine ranges.

<rdar://problem/12588579>

llvm-svn: 167430

the runtime if we have complete debug information
for a class.

Also made the Objective-C language runtime return
NULL when asked for the complete debug information
(i.e., information from DWARF, not information from
the runtime) if that information isn't present.  It
used to return a non-authoritative version, which
made it hard for clients to determine whether
complete debug information was available.

<rdar://problem/12608895>

llvm-svn: 167299

Carlo Kok found an issue where default parameters were causing the wrong argument to be passed. I got rid of the default args so we don't run into this.

llvm-svn: 167167

llvm-svn: 167065

I tracked down a leak that could happen when detaching from a process where the lldb_private::Process objects would stay around forever. This was caused by a eStateDetached event that was queued up on the lldb_private::Process private state thread listener. Since process events contain shared pointers to the process, this is dangerous if they don't get consume or cleared as having the lldb_private::Process class contain a collection of things that have a shared pointer to yourself is obviously bad. 

To fix this I modified the Process::Finalize() function to clear this list. The actual thing that was holding onto the ModuleSP and thus the static archive, was a stack frame. Since the process wasn't going away, it still had thread objects and they still had frames. I modified the Thread::Destroy() to clear the stack frames to ensure this further doesn't happen.

llvm-svn: 166964

TOT lldb broke finding App in app bundles when launching with shell.

llvm-svn: 166733

llvm-svn: 166732

Changed the V1 and V2 runtimes to be able to detect when the ISA hash table has changed, and auto update as needed.

llvm-svn: 166693

There was a generic catch-all type for path arguments
called "eArgTypePath," and a specialized version
called "eArgTypeFilename."  It turns out all the
cases where we used eArgTypePath we could have
used Filename or we explicitly meant a directory.

I changed Path to DirectoryName, made it use the
directory completer, and rationalized the uses of
Path.

<rdar://problem/12559915>

llvm-svn: 166533

Objective C cleanup. Removed an cache that was no longer needed and changes the code that gets the dynamic type and class name to use our new Objective C cache.

llvm-svn: 166512

it to print the old and new values.
Temporarily disable the "out of scope" checking since it didn't work correctly, and was
not what people generally expected watchpoints to be doing.  

llvm-svn: 166472

options:

- added help ("help language") listing the
  possible options;

- added the possibility of synonyms for language
  names, in this case "ObjC" for "Objective-C";
  and

- made matching against language names case
  insensitive.

This should improve discoverability.

<rdar://problem/12552359>

llvm-svn: 166457

Added the infrastructure necessary for plug-ins to be able to add their own settings instead of having settings added to existing ones. In particular "target.disable-kext-loading" was added to "target" where it should actually be specific to the the dynamic loader plugin. Now the plug-in manager has the ability to create settings at the root level starting with "plugin". Each plug-in type can add new sub dictionaries, and then each plug-in can register a setting dictionary under its own short name. For example the DynamicLoaderDarwinKernel plug-in now registers a setting dictionary at:

plugin
    dynamic-loader
        macosx-kernel
            (bool) disable-kext-loading
            
To settings can be set using:

(lldb) settings set plugin.dynamic-loader.macosx-kernel.disable-kext-loading true

I currently only hooked up the DynamicLoader plug-ins, but the code is very easy to duplicate when and if we need settings for other plug-ins.

llvm-svn: 166294

in a kernel debug session:

settings set target.disable-kext-loading true

<rdar://problem/12490623>

llvm-svn: 166262

Added a new setting that allows a python OS plug-in to detect threads and provide registers for memory threads. To enable this you set the setting:

settings set target.process.python-os-plugin-path lldb/examples/python/operating_system.py

Then run your program and see the extra threads. 

llvm-svn: 166244

<rdar://problem/12068650>

More fixes to how we handle paths that are used to create a target.

This modification centralizes the location where and how what the user specifies gets resolved. Prior to this fix, the TargetList::CreateTarget variants took a FileSpec object which meant everyone had the opportunity to resolve the path their own way. Now both CreateTarget variants take a "const char *use_exe_path" which allows the TargetList::CreateTarget to centralize where the resolving happens and "do the right thing".

llvm-svn: 166186

LLDB changes argv[0] when debugging a symlink. Now we have the notion of argv0 in the target settings:

target.arg0 (string) = 

There is also the program argument that are separate from the first argument that have existed for a while:

target.run-args (arguments) =

When running "target create <exe>", we will place the untouched "<exe>" into target.arg0 to ensure when we run, we run with what the user typed. This has been added to the ProcessLaunchInfo and all other needed places so we always carry around the:
- resolved executable path
- argv0
- program args

Some systems may not support separating argv0 from the resolved executable path and the ProcessLaunchInfo needs to carry all of this information along so that each platform can make that decision.

llvm-svn: 166137

the SB API's that evaluate expressions.

<rdar://problem/12457211>

llvm-svn: 166062

Patch from Matt Kopec <matt.kopec@intel.com> to fix the problem that if two breakpoints were set on consecutive addresses, the continue from the 
first breakpoint would skip the second.

llvm-svn: 166000

llvm-svn: 165808

Modified patch from Matt Kopec that makes sure the run lock is acquired when attaching and makes sure the pid is being set on linux in the process info.

llvm-svn: 165804

Dynamic type code must be efficient and fast. Now it is.

Added ObjC v1 support for getting the complete list of ISA values.

The main flow of the AppleObjCRuntime subclasses is now they must override "virtual bool UpdateISAToDescriptorMap_Impl();". This function will update the complete list of ISA values and create ClassDescriptorSP objects for each one. Now we have the complete list of valid ISA values which we can use for verification when doing dynamic typing.

Refactored a bunch of stuff so that the AppleObjCRuntime subclasses don't have to implement as many functions as they used to.

llvm-svn: 165730

Change the Thread constructor over to take a Process& rather than a ProcessSP.  We can't create Threads with a NULL ProcessSP, so it makes no sense to use the SP.
Then make the Thread a Broadcaster, and get it to broadcast when the selected frame is changed (but only from the Command Line) and when Thread::ReturnFromFrame 
changes the stack.
Made the Driver use this notification to print the new thread status rather than doing it in the command.
Fixed a few places where people were setting their broadcaster class by hand rather than using the static broadcaster class call.

<rdar://problem/12383087>

llvm-svn: 165640

llvm-svn: 165516

llvm-svn: 165328

enabled after we'd found a few bugs that were caused by shadowed
local variables; the most important issue this turned up was
a common mistake of trying to obtain a mutex lock for the scope
of a code block by doing

        Mutex::Locker(m_map_mutex);

This doesn't assign the lock object to a local variable; it is
a temporary that has its dtor called immediately.  Instead,

        Mutex::Locker locker(m_map_mutex);

does what is intended.  For some reason -Wshadow happened to
highlight these as shadowed variables.

I also fixed a few obivous and easy shadowed variable issues
across the code base but there are a couple dozen more that
should be fixed when someone has a free minute.
<rdar://problem/12437585>

llvm-svn: 165269