Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes:
- Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file". 
- modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly
- Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was.
- modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile()

Cleaned up header includes a bit as well.

llvm-svn: 162860

Use the metadata in the dSYM bundle Info.plist to remap source paths when they keys are available.

llvm-svn: 152836

indicate whether inline functions are desired.
This allows the expression parser, for instance,
to filter out inlined functions when looking for
functions it can call.

llvm-svn: 150279

There were two problems associated with this radar:
1. "settings show target.source-map" failed to show the source-map after, for example,
   "settings set target.source-map /Volumes/data/lldb/svn/trunk/test/source-manager /Volumes/data/lldb/svn/trunk/test/source-manager/hidden"
   has been executed to set the source-map.
2. "list -n main" failed to display the source of the main() function after we properly set the source-map.

The first was fixed by adding the missing functionality to TargetInstanceSettings::GetInstanceSettingsValue (Target.cpp)
and updating the support files PathMappingList.h/.cpp; the second by modifying SourceManager.cpp to fix several places
with incorrect logic.

Also added a test case test_move_and_then_display_source() to TestSourceManager.py, which moves main.c to hidden/main.c,
sets target.source-map to perform the directory mapping, and then verifies that "list -n main" can still show the main()
function.

llvm-svn: 146422

<rdar://problem/10561406>

Stopped the SymbolFileDWARF::FindFunctions (...) from always calculating
the line table entry for all functions that were found. This can slow down
the expression parser if it ends up finding a bunch of matches. Fixed the 
places that were relying on the line table entry being filled in.

Discovered a recursive stack blowout that happened when "main" didn't have
line info for it and there was no line information for "main"

llvm-svn: 146330

core Module functions that the expression parser
will soon be using.

llvm-svn: 141766

llvm-svn: 141422

Fix the RegularExpression class so it has a real copy constructor.
Fix the breakpoint setting with multiple shared libraries so it makes
  one breakpoint not one per shared library.
Add SBFileSpecList, to be used to expose the above to the SB interface (not done yet.)

llvm-svn: 140225

SBSourceManager now gets the real source manager either from the Debugger or Target.  Also, move the SourceManager file cache into the debugger
so it can be shared amongst the targets.

llvm-svn: 139564

Move the SourceManager from the Debugger to the Target.  That way it can store the per-Target default Source File & Line.
Set the default Source File & line to main (if it can be found.) at startup.  Selecting the current thread & or frame resets 
the current source file & line, and "source list" as well as the breakpoint command "break set -l <NUM>" will use the 
current source file.

llvm-svn: 139323

variables prior to running your binary. Zero filled sections now get
section data correctly filled with zeroes when Target::ReadMemory
reads from the object file section data.

Added new option groups and option values for file lists. I still need
to hook up all of the options to "target variable" to allow more complete
introspection by file and shlib.

Added the ability for ValueObjectVariable objects to be created with
only the target as the execution context. This allows them to be read
from the object files through Target::ReadMemory(...). 

Added a "virtual Module * GetModule()" function to the ValueObject
class. By default it will look to the parent variable object and
return its module. The module is needed when we have global variables
that have file addresses (virtual addresses that are specific to
module object files) and in turn allows global variables to be displayed
prior to running.

Removed all of the unused proxy object support that bit rotted in 
lldb_private::Value.

Replaced a lot of places that used "FileSpec::Compare (lhs, rhs) == 0" code
with the more efficient "FileSpec::Equal (lhs, rhs)".

Improved logging in GDB remote plug-in.

llvm-svn: 134579

inline contexts when the deepest most block is not inlined.

Added source path remappings to the lldb_private::Target class that allow it
to remap paths found in debug info so we can find source files that are elsewhere
on the current system.

Fixed disassembly by function name to disassemble inline functions that are
inside other functions much better and to show enough context before the
disassembly output so you can tell where things came from.

Added the ability to get more than one address range from a SymbolContext 
class for the case where a block or function has discontiguous address ranges.

llvm-svn: 130044

line tables specify breakpoints can be set in the source. When dumping the
source, the number of breakpoints that can be set on a source line are shown
as a prefix:

(lldb) source list -f test.c -l1 -c222 -b
       1   	#include <stdio.h>
       2   	#include <sys/fcntl.h>
       3   	#include <unistd.h>
       4   	int
       5   	sleep_loop (const int num_secs)
[2]    6   	{
       7   	    int i;
[1]    8   	    for (i=0; i<num_secs; ++i)
       9   	    {
[1]    10  	        printf("%d of %i - sleep(1);\n", i, num_secs);
[1]    11  	        sleep(1);       
       12  	    }
       13  	    return 0;
[1]    14  	}
       15  	
       16  	int 
       17  	main (int argc, char const* argv[])
[1]    18  	{
[1]    19  	    printf("Process: %i\n\n", getpid());
[1]    20  	    puts("Press any key to continue..."); getchar();
[1]    21  	    sleep_loop (20);
       22  	    return 12;
[1]    23  	}

Above we can see there are two breakpoints for line 6 and one breakpoint for
lines 8, 10, 11, 14, 18, 19, 20, 21 and 23. All other lines have no line table
entries for them. This helps visualize the data provided in the debug 
information without having to manually dump all line tables. It also includes
all inline breakpoint that may result for a given file which can also be very
handy to see.

llvm-svn: 129747

class now implements the Host functionality for a lot of things that make 
sense by default so that subclasses can check:

int
PlatformSubclass::Foo ()
{
    if (IsHost())
        return Platform::Foo (); // Let the platform base class do the host specific stuff
    
    // Platform subclass specific code...
    int result = ...
    return result;
}

Added new functions to the platform:

    virtual const char *Platform::GetUserName (uint32_t uid);
    virtual const char *Platform::GetGroupName (uint32_t gid);

The user and group names are cached locally so that remote platforms can avoid
sending packets multiple times to resolve this information.

Added the parent process ID to the ProcessInfo class. 

Added a new ProcessInfoMatch class which helps us to match processes up
and changed the Host layer over to using this new class. The new class allows
us to search for processs:
1 - by name (equal to, starts with, ends with, contains, and regex)
2 - by pid
3 - And further check for parent pid == value, uid == value, gid == value, 
    euid == value, egid == value, arch == value, parent == value.
    
This is all hookup up to the "platform process list" command which required
adding dumping routines to dump process information. If the Host class 
implements the process lookup routines, you can now lists processes on 
your local machine:

machine1.foo.com % lldb
(lldb) platform process list 
PID    PARENT USER       GROUP      EFF USER   EFF GROUP  TRIPLE                   NAME
====== ====== ========== ========== ========== ========== ======================== ============================
99538  1      username   usergroup  username   usergroup  x86_64-apple-darwin      FileMerge
94943  1      username   usergroup  username   usergroup  x86_64-apple-darwin      mdworker
94852  244    username   usergroup  username   usergroup  x86_64-apple-darwin      Safari
94727  244    username   usergroup  username   usergroup  x86_64-apple-darwin      Xcode
92742  92710  username   usergroup  username   usergroup  i386-apple-darwin        debugserver


This of course also works remotely with the lldb-platform:

machine1.foo.com % lldb-platform --listen 1234

machine2.foo.com % lldb
(lldb) platform create remote-macosx
  Platform: remote-macosx
 Connected: no
(lldb) platform connect connect://localhost:1444
  Platform: remote-macosx
    Triple: x86_64-apple-darwin
OS Version: 10.6.7 (10J869)
    Kernel: Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386
  Hostname: machine1.foo.com
 Connected: yes
(lldb) platform process list 
PID    PARENT USER       GROUP      EFF USER   EFF GROUP  TRIPLE                   NAME
====== ====== ========== ========== ========== ========== ======================== ============================
99556  244    username   usergroup  username   usergroup  x86_64-apple-darwin      trustevaluation
99548  65539  username   usergroup  username   usergroup  x86_64-apple-darwin      lldb
99538  1      username   usergroup  username   usergroup  x86_64-apple-darwin      FileMerge
94943  1      username   usergroup  username   usergroup  x86_64-apple-darwin      mdworker
94852  244    username   usergroup  username   usergroup  x86_64-apple-darwin      Safari

The lldb-platform implements everything with the Host:: layer, so this should
"just work" for linux. I will probably be adding more stuff to the Host layer
for launching processes and attaching to processes so that this support should
eventually just work as well.

Modified the target to be able to be created with an architecture that differs
from the main executable. This is needed for iOS debugging since we can have
an "armv6" binary which can run on an "armv7" machine, so we want to be able
to do:

% lldb
(lldb) platform create remote-ios
(lldb) file --arch armv7 a.out

Where "a.out" is an armv6 executable. The platform then can correctly decide
to open all "armv7" images for all dependent shared libraries.

Modified the disassembly to show the current PC value. Example output:

(lldb) disassemble --frame
a.out`main:
   0x1eb7:  pushl  %ebp
   0x1eb8:  movl   %esp, %ebp
   0x1eba:  pushl  %ebx
   0x1ebb:  subl   $20, %esp
   0x1ebe:  calll  0x1ec3                   ; main + 12 at test.c:18
   0x1ec3:  popl   %ebx
-> 0x1ec4:  calll  0x1f12                   ; getpid
   0x1ec9:  movl   %eax, 4(%esp)
   0x1ecd:  leal   199(%ebx), %eax
   0x1ed3:  movl   %eax, (%esp)
   0x1ed6:  calll  0x1f18                   ; printf
   0x1edb:  leal   213(%ebx), %eax
   0x1ee1:  movl   %eax, (%esp)
   0x1ee4:  calll  0x1f1e                   ; puts
   0x1ee9:  calll  0x1f0c                   ; getchar
   0x1eee:  movl   $20, (%esp)
   0x1ef5:  calll  0x1e6a                   ; sleep_loop at test.c:6
   0x1efa:  movl   $12, %eax
   0x1eff:  addl   $20, %esp
   0x1f02:  popl   %ebx
   0x1f03:  leave
   0x1f04:  ret
   
This can be handy when dealing with the new --line options that was recently
added:

(lldb) disassemble --line
a.out`main + 13 at test.c:19
   18  	{
-> 19  		printf("Process: %i\n\n", getpid());
   20  	    puts("Press any key to continue..."); getchar();
-> 0x1ec4:  calll  0x1f12                   ; getpid
   0x1ec9:  movl   %eax, 4(%esp)
   0x1ecd:  leal   199(%ebx), %eax
   0x1ed3:  movl   %eax, (%esp)
   0x1ed6:  calll  0x1f18                   ; printf

Modified the ModuleList to have a lookup based solely on a UUID. Since the
UUID is typically the MD5 checksum of a binary image, there is no need
to give the path and architecture when searching for a pre-existing
image in an image list.

Now that we support remote debugging a bit better, our lldb_private::Module
needs to be able to track what the original path for file was as the platform
knows it, as well as where the file is locally. The module has the two 
following functions to retrieve both paths:

const FileSpec &Module::GetFileSpec () const;
const FileSpec &Module::GetPlatformFileSpec () const;

llvm-svn: 128563

file data, so if a source file was modified, we would always show the first
cached copy of the source data. We now check file modification times when
displaying source info so we can show the update source info.

llvm-svn: 121278

llvm-svn: 105619