History log of /external/lldb/source/Core/Module.cpp
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
7980d35608225dc71b3dd946d4c3aea85bc24e85 13-Jul-2013 Greg Clayton <gclayton@apple.com> Fixed GetModuleSpecifications() to work better overall:
- MachO files now correctly extract the UUID all the time
- More file size and offset verification done for universal mach-o files to watch for truncated files
- ObjectContainerBSDArchive now supports enumerating all objects in BSD archives (.a files)
- lldb_private::Module() can not be properly constructed using a ModuleSpec for a .o file in a .a file
- The BSD archive plug-in shares its cache for GetModuleSpecifications() and the create callback
- Improved printing for ModuleSpec objects

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@186211 91177308-0d34-0410-b5e6-96231b3b80d8
7940069905bee0b2e5f0661bf37c9f906ddf8603 10-Jul-2013 Greg Clayton <gclayton@apple.com> Cleanup on the unified section list changes. Main changes are:
- ObjectFile::GetSymtab() and ObjectFile::ClearSymtab() no longer takes any flags
- Module coordinates with the object files and contain a unified section list so that object file and symbol file can share sections when they need to, yet contain their own sections.

Other cleanups:
- Fixed Symbol::GetByteSize() to not have the symbol table compute the byte sizes on the fly
- Modified the ObjectFileMachO class to compute symbol sizes all at once efficiently
- Modified the Symtab class to store a file address lookup table for more efficient lookups
- Removed Section::Finalize() and SectionList::Finalize() as they did nothing
- Improved performance of the detection of symbol files that have debug maps by excluding stripped files and core files, debug files, object files and stubs
- Added the ability to tell if an ObjectFile has been stripped with ObjectFile::IsStripped() (used this for the above performance improvement)

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@185990 91177308-0d34-0410-b5e6-96231b3b80d8
a807ceef5dad2b24e5bae5c5a193ff03aa7ec8d9 01-Jul-2013 Michael Sartain <mikesart@valvesoftware.com> Split symbol support for ELF and Linux.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@185366 91177308-0d34-0410-b5e6-96231b3b80d8
b54b7dc48289727220869d25eb6f4362bf3169ec 01-Jul-2013 Jim Ingham <jingham@apple.com> Formatting cleanup.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@185357 91177308-0d34-0410-b5e6-96231b3b80d8
ac94caa68a4a5fa4bd939d7656a6a12d8fc06a33 12-Jun-2013 Greg Clayton <gclayton@apple.com> Huge performance improvements when one breakpoint contains many locations.

325,000 breakpoints for running "breakpoint set --func-regex ." on lldb itself (after hitting a breakpoint at main so that LLDB.framework is loaded) used to take up to an hour to set, now we are down under a minute. With warm file caches, we are at 40 seconds, and that is with setting 325,000 breakpoint through the GDB remote API. Linux and the native debuggers might be faster. I haven't timed what how much is debug info parsing and how much is the protocol traffic to/from GDB remote.

That there were many performance issues. Most of them were due to storing breakpoints in the wrong data structures, or using the wrong iterators to traverse the lists, traversing the lists in inefficient ways, and not optimizing certain function name lookups/symbol merges correctly.

Debugging after that is also now very efficient. There were issues with replacing the breakpoint opcodes in memory that was read, and those routines were also fixed.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@183820 91177308-0d34-0410-b5e6-96231b3b80d8
66068824402d94de2abe81c7e4472a4754572489 31-May-2013 Enrico Granata <egranata@apple.com> <rdar://problem/11109316>

command script import now does reloads - for real
If you invoke command script import foo and it detects that foo has already been imported, it will
- invoke reload(foo) to reload the module in Python
- re-invoke foo.__lldb_init_module
This second step is necessary to ensure that LLDB does not keep cached copies of any formatter, command, ... that the module is providing

Usual caveats with Python imports persist. Among these:
- if you have objects lurking around, reloading the module won't magically update them to reflect changes
- if module A imports module B, reloading A won't reload B
These are Python-specific issues independent of LLDB that would require more extensive design work

The --allow-reload (-r) option is maintained for compatibility with existing scripts, but is clearly documented as redundant - reloading is always enabled whether you use it or not

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@182977 91177308-0d34-0410-b5e6-96231b3b80d8
a8aa5aba2497ba4e49295b6c2acb68975ed8406e 22-May-2013 Greg Clayton <gclayton@apple.com> <rdar://problem/13880690>

Lock the lldb_private::Module mutex while tearing down the module to make sure we don't get clients accessing the contents on a module as it is going away.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@182511 91177308-0d34-0410-b5e6-96231b3b80d8
be0aaf8824384ce895f80c6a1525ef6ba5b9ef17 22-May-2013 Enrico Granata <egranata@apple.com> Adding a newline for better overall readability

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@182434 91177308-0d34-0410-b5e6-96231b3b80d8
07e3124bfa7b1b8d782689a625e13f95402c389a 21-May-2013 Enrico Granata <egranata@apple.com> <rdar://problem/13878726>

Yet another implementation of the python in dSYM autoload :)
This time we are going with a ternary setting:
true - load, do not warn
false - do not load, do not warn
warn - do not load, warn (default)

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@182414 91177308-0d34-0410-b5e6-96231b3b80d8
9eedc23e233b539351031bf99476d6b7a57ee28e 21-May-2013 Enrico Granata <egranata@apple.com> s/to override/To override/

Thanks to Greg Clayton for catching this

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@182339 91177308-0d34-0410-b5e6-96231b3b80d8
02af494c397d62f22bea65d36ad47080b6adc8af 21-May-2013 Enrico Granata <egranata@apple.com> Improving the previous checkin about target.load-script-from-symbol-file

There are two settings:
target.load-script-from-symbol-file is a boolean that says load or no load (default: false)
target.warn-on-script-from-symbol-file is also a boolean, it says whether you want to be warned when a script file is not loaded due to security (default: true)

the auto loading on change for target.load-script-from-symbol-file is preserved

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@182336 91177308-0d34-0410-b5e6-96231b3b80d8
2e7f2db1b0c4c6d904811fba7d7877b19288c874 21-May-2013 Enrico Granata <egranata@apple.com> <rdar://problem/13878726>

This changes the setting target.load-script-from-symbol-file to be a ternary enum value:
default (the default value) will NOT load the script files but will issue a warning suggesting workarounds
yes will load the script files
no will not load the script files AND will NOT issue any warning

if you change the setting value from default to yes, that will then cause the script files to be loaded
(the assumption is you didn't know about the setting, got a warning, and quickly want to remedy it)

if you have a settings set command for this in your lldbinit file, be sure to change "true" or "false" into an appropriate "yes" or "no" value

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@182323 91177308-0d34-0410-b5e6-96231b3b80d8
83d90c5e68f4a977150c6791a49ade7a23c92177 18-May-2013 Greg Clayton <gclayton@apple.com> <rdar://problem/11398407>

Name matching was working inconsistently across many places in LLDB. Anyone doing name lookups where you want to look for all types of names should used "eFunctionNameTypeAuto" as the sole name type mask. This will ensure that we get consistent "lookup function by name" results. We had many function calls using as mask like "eFunctionNameTypeBase | eFunctionNameTypeFull | eFunctionNameTypeMethod | eFunctionNameTypeSelector". This was due to the function lookup by name evolving over time, but as it stands today, use eFunctionNameTypeAuto when you want general name lookups. Either ModuleList::FindFunctions() or Module::FindFunctions() will figure out the right kinds of names to lookup and remove the "eFunctionNameTypeAuto" and replace it with the exact subset of what the name can be.

This checkin also changes eFunctionNameTypeAny over to use eFunctionNameTypeAuto to reflect this.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@182179 91177308-0d34-0410-b5e6-96231b3b80d8
1d3db0a71f507df5158eb160aaceefb6dd5f38c2 13-May-2013 Enrico Granata <egranata@apple.com> <rdar://problem/13183720>

Provide a mechanism through which users can disable loading the Python scripts from dSYM files
This relies on a target setting: target.load-script-from-symbol-file which defaults to false ("do NOT load the script")
You need to set it to true before creating your target (or in your lldbinit file if you constantly rely on this feature) to allow the scripts to load

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@181709 91177308-0d34-0410-b5e6-96231b3b80d8
0e191607adcb0ea8ebd06c278be648a7f5c0097f 10-May-2013 Greg Clayton <gclayton@apple.com> <rdar://problem/13854277>

Main changes in this patch include:
- cleanup plug-in interface and use ConstStrings for plug-in names
- Modfiied the BSD Archive plug-in to be able to pick out the correct .o file when .a files contain multiple .o files with the same name by using the timestamp
- Modified SymbolFileDWARFDebugMap to properly verify the timestamp on .o files it loads to ensure we don't load updated .o files and cause problems when debugging

The plug-in interface changes:

Modified the lldb_private::PluginInterface class that all plug-ins inherit from:


virtual const char * GetPluginName() = 0;


virtual ConstString GetPluginName() = 0;


virtual const char * GetShortPluginName() = 0;

- Fixed up all plug-in to adhere to the new interface and to return lldb_private::ConstString values for the plug-in names.
- Fixed all plug-ins to return simple names with no prefixes. Some plug-ins had prefixes and most ones didn't, so now they all don't have prefixed names, just simple names like "linux", "gdb-remote", etc.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@181631 91177308-0d34-0410-b5e6-96231b3b80d8
97a19b21dacd9063bb5475812df7781777262198 29-Apr-2013 Greg Clayton <gclayton@apple.com> Cleanup logging to use the new "std::string FileSpec::GetPath()" function. Also added a similar function for modules:

Module::GetSpecificationDescription () const;

This returns the module as "/usr/lib/libfoo.dylib" for normal files (calls "std::string FileSpec::GetPath()" on m_file) but it also might include the object name in case the module is for a .o file in a BSD archive ("/usr/lib/libfoo.a(bar.o)"). Cleaned up necessary logging code to use it.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@180717 91177308-0d34-0410-b5e6-96231b3b80d8
102b2c2681c9a830afe25bfea35557421905e42c 19-Apr-2013 Greg Clayton <gclayton@apple.com> After discussing with Chris Lattner, we require C++11, so lets get rid of the macros and just use C++11.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179805 91177308-0d34-0410-b5e6-96231b3b80d8
81a96aa6242f7b559770f5dc62316253cb8cb0d4 18-Apr-2013 Greg Clayton <gclayton@apple.com> Since we use C++11, we should switch over to using std::unique_ptr when C++11 is being used. To do this, we follow what we have done for shared pointers and we define a STD_UNIQUE_PTR macro that can be used and it will "do the right thing". Due to some API differences in std::unique_ptr and due to the fact that we need to be able to compile without C++11, we can't use move semantics so some code needed to change so that it can compile with either C++.

Anyone wanting to use a unique_ptr or auto_ptr should now use the "STD_UNIQUE_PTR(TYPE)" macro.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179779 91177308-0d34-0410-b5e6-96231b3b80d8
296b06d325413723f5aac5988eed977b278a7807 03-Apr-2013 Greg Clayton <gclayton@apple.com> <rdar://problem/13506727>

Symbol table function names should support lookups like symbols with debug info.

To fix this I:
- Gutted the way FindFunctions is used, there used to be way too much smarts only in the DWARF plug-in
- Made it more efficient by chopping the name up once and using simpler queries so that SymbolFile and Symtab plug-ins don't need to do as much
- Filter the results at a higher level
- Make the lldb_private::Symtab able to chop up C++ mangled names and make as much sense out of them as possible and also be able to search by basename, fullname, method name, and selector name.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@178608 91177308-0d34-0410-b5e6-96231b3b80d8
952e9dc874944fcdbbb224f3ec4fc2c859376f64 28-Mar-2013 Greg Clayton <gclayton@apple.com> <rdar://problem/13521159>

LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down.

All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@178191 91177308-0d34-0410-b5e6-96231b3b80d8
986a750709cb17e56d7f4ddddaae2b87af4eb311 23-Mar-2013 Greg Clayton <gclayton@apple.com> Only get the script interpreter if we find scripting resources in the symbol file. This helps us avoid initializing python when it isn't needed.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@177793 91177308-0d34-0410-b5e6-96231b3b80d8
4f9103faba72fdfc4b4299d6d459bc820ee597b2 27-Feb-2013 Matt Kopec <Matt.Kopec@intel.com> Add GNU indirect function support in expressions for Linux.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@176206 91177308-0d34-0410-b5e6-96231b3b80d8
a7e864cb0a450c7ef65b6f9f6c9bae839c405906 23-Feb-2013 Greg Clayton <gclayton@apple.com> <rdar://problem/13265297>

StackFrame assumes m_sc is additive, but m_sc can lose its target. So now the SymbolContext::Clear() method takes a bool that indicates if the target should be cleared. Modified all existing code to properly set the bool argument.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@175953 91177308-0d34-0410-b5e6-96231b3b80d8
cbe61bd26db663fa3036866dc33315c6ffc37910 06-Feb-2013 Greg Clayton <gclayton@apple.com> <rdar://problem/13159777>

lldb was mmap'ing archive files once per .o file it loads, now it correctly shares the archive between modules.

LLDB was also always mapping entire contents of universal mach-o files, now it maps just the slice that is required.

Added a new logging channel for "lldb" called "mmap" to help track future regressions.

Modified the ObjectFile and ObjectContainer plugin interfaces to take a data offset along with the file offset and size so we can implement the correct caching and efficient reading of parts of files without mmap'ing the entire file like we used to.

The current implementation still keeps entire .a files mmaped (once) and entire slices from universal files mmaped to ensure that if a client builds their binaries during a debug session we don't lose our data and get corrupt object file info and debug info.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@174524 91177308-0d34-0410-b5e6-96231b3b80d8
36da2aa6dc5ad9994b638ed09eb81c44cc05540b 25-Jan-2013 Greg Clayton <gclayton@apple.com> <rdar://problem/13069948>

Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary.

So I defined a new "lldb::offset_t" which should be used for all file offsets.

After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed.

Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@173463 91177308-0d34-0410-b5e6-96231b3b80d8
d9735a1b6ba4b5ff85551bf19045504e03eb3603 12-Jan-2013 Greg Clayton <gclayton@apple.com> <rdar://problem/12973809>

Fixed an issue with the auto loading of script resources in debug info files. Any platform can add support for this, and on MacOSX we allow dSYM files to contain python modules that get automatically loaded when a dSYM file is associated with an executable or shared library.

The modifications will now:
- Let the module locate the symbol file naturally instead of using a function that only works in certain cases. This helps us to locate the script resources as long as the dSYM file can be found.
- Don't try and do any of this if the script interpreter has scripting disabled.
- Allow more than one scripting resource to be found in a symbol file by returning the list
- Load the scripting resources when a symbol file is added via the "target symbols add" command.
- Be smarter about matching the dSYM mach-o file to an existing executable in the target images by stripping extensions on the symfile basname if needed.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@172275 91177308-0d34-0410-b5e6-96231b3b80d8
2fcbf6e3d86ac0e6a95e11e5e232a9f72bd612d2 08-Jan-2013 Greg Clayton <gclayton@apple.com> <rdar://problem/12953853>

Setting breakpoints using "breakpoint set --selector <SEL>" previously didn't when there was no dSYM file.

Also fixed issues in the test suite that arose after fixing the bug.

Also fixed the log channels to properly ref count the log streams using weak pointers to the streams. This fixes a test suite problem that would happen when you specified a full path to the compiler with the "--compiler" option.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@171816 91177308-0d34-0410-b5e6-96231b3b80d8
188091899842b140313b54e097f16efbe165c998 14-Dec-2012 Greg Clayton <gclayton@apple.com> Cleaned up the UUID mismatch just printing itself whenever it wants to by allowing an optional feedback stream to be passed along when getting the symbol vendor.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@170174 91177308-0d34-0410-b5e6-96231b3b80d8
40e278caddf5442776f9408f20d757cc85fe630a 13-Dec-2012 Sean Callanan <scallanan@apple.com> Removed the == and != operators from ArchSpec, since
equality can be strict or loose and we want code to
explicitly choose one or the other.

Also renamed the Compare function to IsEqualTo, to
avoid confusion.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@170152 91177308-0d34-0410-b5e6-96231b3b80d8
14e71ecd9b05d3dff6e7dc3bf3148b4ad5e3989a 07-Dec-2012 Jim Ingham <jingham@apple.com> 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.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@169614 91177308-0d34-0410-b5e6-96231b3b80d8
0b93a7546473b15fb14dbc129f1fe5ed6ee14976 05-Dec-2012 Greg Clayton <gclayton@apple.com> <rdar://problem/12749733>

Always allows getting builtin types by name even if there is no backing debug information.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@169424 91177308-0d34-0410-b5e6-96231b3b80d8
d891f9b872103235cfd2ed452c6f14a4394d9b3a 05-Dec-2012 Daniel Malea <daniel.malea@intel.com> Fix Linux build warnings due to redefinition of macros:
- 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!

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@169341 91177308-0d34-0410-b5e6-96231b3b80d8
5f35a4be95aed0e5b2cb36f7d785bcbfc67284ae 29-Nov-2012 Daniel Malea <daniel.malea@intel.com> Resolve printf formatting warnings on Linux:
- use macros from inttypes.h for format strings instead of OS-specific types

Patch from Matt Kopec!

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@168945 91177308-0d34-0410-b5e6-96231b3b80d8
146d9522c95c0c8c5409539813b55e08b99196ee 08-Nov-2012 Enrico Granata <egranata@apple.com> <rdar://problem/12586350>

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

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@167569 91177308-0d34-0410-b5e6-96231b3b80d8
b9bd4eeeb21dc4d634a61d00fa68f62c630bd38c 22-Oct-2012 Greg Clayton <gclayton@apple.com> <rdar://problem/12473003>

Allow type searches to specify a type keyword when searching for type. Currently supported type keywords are: struct, class, union, enum, and typedef.

So now you can search for types with a string like "struct foo".

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@166420 91177308-0d34-0410-b5e6-96231b3b80d8
1b97a65e6ad77d797316a2f4b0aa3a1a793ec36f 16-Oct-2012 Jason Molenda <jmolenda@apple.com> llvm needs the OS to be set to either iOS or Mac OS X
to work properly; when doing bare-boards rom debugging
force the OS to be one of those when initializing llvm.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@166057 91177308-0d34-0410-b5e6-96231b3b80d8
f737d372a9672c9feaedf4b2cd7b16e31357d38e 09-Oct-2012 Greg Clayton <gclayton@apple.com> Added a new "module" log channel which covers module creation, deletion, and common module list actions.

Also added a new option for "log enable" which is "--stack" which will print out a stack backtrace for each log line.

This was used to track down the leaking module issue I fixed last week.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@165438 91177308-0d34-0410-b5e6-96231b3b80d8
58aa7152a7df8c9825c63026ec35c24759de948b 02-Oct-2012 Greg Clayton <gclayton@apple.com> <rdar://problem/11791234>

Shared libraries on MacOSX were not properly being removed from the shared
module list when re-running a debug session due to an error in:


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@164991 91177308-0d34-0410-b5e6-96231b3b80d8
851e30ec6a1b1d2c154bb7d69ed0d05b5fd14705 18-Sep-2012 Greg Clayton <gclayton@apple.com> Stop using the "%z" size_t modifier and cast all size_t values to uint64_t. Some platforms don't support this modification.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@164148 91177308-0d34-0410-b5e6-96231b3b80d8
ae2ae94bd72daf435204e99a0e03ccc64470a843 04-Sep-2012 Enrico Granata <egranata@apple.com> <rdar://problem/11485744> Implement important data formatters in C++. Have the Objective-C language runtime plugin expose class descriptors objects akin to the objc_runtime.py Pythonic implementation. Rewrite the data formatters for some core Cocoa classes in C++ instead of Python.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@163155 91177308-0d34-0410-b5e6-96231b3b80d8
49ce8969d3154e1560106cfe530444c09410f217 29-Aug-2012 Greg Clayton <gclayton@apple.com> <rdar://problem/11757916>

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.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@162860 91177308-0d34-0410-b5e6-96231b3b80d8
cbacba1f223ee4819a4b99924dd994c7e52fdf04 13-Jul-2012 Greg Clayton <gclayton@apple.com> <rdar://problem/11740973>

Fixed issues that could happen when the UUID doesn't change in a binary and old stale debug info could end up being used.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@160145 91177308-0d34-0410-b5e6-96231b3b80d8
545762f7780bece4e9255e052c0a50a1ea66ce57 07-Jul-2012 Greg Clayton <gclayton@apple.com> <rdar://problem/11357711>

Fixed a crasher where the section load list was not thread safe.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@159884 91177308-0d34-0410-b5e6-96231b3b80d8
e82d8eda82b0807c2a8ef50667d48d8da41612b3 06-Jul-2012 Greg Clayton <gclayton@apple.com> <rdar://problem/11819635>

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@159844 91177308-0d34-0410-b5e6-96231b3b80d8
73a35715708b65b1d96c1c8f439548bb0990df08 24-Apr-2012 Greg Clayton <gclayton@apple.com> Added the ability to log a message with a backtrace when verbose logging is enabled to the Module class. Used this new function in the DWARF parser.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@155404 91177308-0d34-0410-b5e6-96231b3b80d8
c705730b96ede40118fc7b06d2807e9a4e503139 24-Apr-2012 Greg Clayton <gclayton@apple.com> <rdar://problem/11282938>

Fixed an issue where we get NULL compile units back from the symbol vendor. We need symbol vendors to be able to quickly give an estimate of the compile units that they have without having to fully vette them first, so anyone getting compile units from a module should be able to deal with a NULL compile unit being returned for a given index.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@155398 91177308-0d34-0410-b5e6-96231b3b80d8
808e92a12cf2b15ed5cb75e63de4ae0cbe997998 20-Apr-2012 Greg Clayton <gclayton@apple.com> Don't put the address of the module in the module basename as this hoses up our ability to find shared libraries by name. We now put it into the Module object name.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@155223 91177308-0d34-0410-b5e6-96231b3b80d8
860b9ea0038cdcea2dda00b1657f945363c96d00 09-Apr-2012 Greg Clayton <gclayton@apple.com> <rdar://problem/11202426>

Work around a deadlocking issue where "SBDebugger::MemoryPressureDetected ()" is being called and is causing a deadlock. We now just try and get the lock when trying to trim down the unique modules so we don't deadlock debugger GUI programs until we can find the root cause.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@154339 91177308-0d34-0410-b5e6-96231b3b80d8
9ab696e40530fa966e08cab7af77ea62e4fff1c0 27-Mar-2012 Greg Clayton <gclayton@apple.com> lldb_private::Section objects have a boolean flag that can be set that
indicates that the section is thread specific. Any functions the load a module
given a slide, will currently ignore any sections that are thread specific.

lldb_private::Section now has:

Section::IsThreadSpecific () const
return m_thread_specific;

Section::SetIsThreadSpecific (bool b)
m_thread_specific = b;

The ELF plug-in has been modified to set this for the ".tdata" and the ".tbss"

Eventually we need to have each lldb_private::Thread subclass be able to
resolve a thread specific section, but for now they will just not resolve. The
code for that should be trivual to add, but the address resolving functions
will need to be changed to take a "ExecutionContext" object instead of just
a target so that thread specific sections can be resolved.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@153537 91177308-0d34-0410-b5e6-96231b3b80d8
dc0a38c5a727cae5362b218a3180d0f4265a619d 27-Mar-2012 Greg Clayton <gclayton@apple.com> <rdar://problem/11113279>

Fixed type lookups to "do the right thing". Prior to this fix, looking up a type using "foo::bar" would result in a type list that contains all types that had "bar" as a basename unless the symbol file was able to match fully qualified names (which our DWARF parser does not).

This fix will allow type matches to be made based on the basename and then have the types that don't match filtered out. Types by name can be fully qualified, or partially qualified with the new "bool exact_match" parameter to the Module::FindTypes() method.

This fixes some issue that we discovered with dynamic type resolution as well as improves the overall type lookups in LLDB.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@153482 91177308-0d34-0410-b5e6-96231b3b80d8
2418fddf2e200c827da5bc6c855f3d4971b2d867 19-Mar-2012 Greg Clayton <gclayton@apple.com> <rdar://problem/11072382>

Fixed a case where the source path remappings on the module were too expensive to
use when we try to verify (stat the file system) that the remapped path points to
a valid file. Now we will use the lldb_private::Module path remappings (if any) when
parsing the debug info without verifying that the paths exist so we don't slow down
line table parsing speeds.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@153059 91177308-0d34-0410-b5e6-96231b3b80d8
964deba8853eb794e59263322b59b09b43669618 15-Mar-2012 Greg Clayton <gclayton@apple.com> <rdar://problem/8196933>

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

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@152836 91177308-0d34-0410-b5e6-96231b3b80d8
444fe998bf707bd076a70c3a779db8575533695e 26-Feb-2012 Greg Clayton <gclayton@apple.com> Made a ModuleSpec class in Module.h which can specify a module using one or
more of the local path, platform path, associated symbol file, UUID, arch,
object name and object offset. This allows many of the calls that were
GetSharedModule to reduce the number of arguments that were used in a call
to these functions. It also allows a module to be created with a ModuleSpec
which allows many things to be specified prior to any accessors being called
on the Module class itself.

I was running into problems when adding support for "target symbol add"
where you can specify a stand alone debug info file after debugging has started
where I needed to specify the associated symbol file path and if I waited until
after construction, the wrong symbol file had already been located. By using
the ModuleSpec it allows us to construct a module with as little or as much
information as needed and not have to change the parameter list.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@151476 91177308-0d34-0410-b5e6-96231b3b80d8
6c5438bf1d7af0f0ef1e81a30ad53e3fe93c35a8 24-Feb-2012 Greg Clayton <gclayton@apple.com> Fixed a crasher that was happening after making ObjectFile objects have a
weak reference back to the Module. We were crashing when trying to make a
memory object file since it was trying to get the object in the Module
constructor before the "Module *" had been put into a shared pointer, and the
module was trying to initialize a weak pointer back to it.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@151397 91177308-0d34-0410-b5e6-96231b3b80d8
3508c387c3f0c9ecc439d98048fd7694d41bab1b 24-Feb-2012 Greg Clayton <gclayton@apple.com> <rdar://problem/10103468>

I started work on being able to add symbol files after a debug session
had started with a new "target symfile add" command and quickly ran into
problems with stale Address objects in breakpoint locations that had
lldb_private::Section pointers into modules that had been removed or
replaced. This also let to grabbing stale modules from those sections.
So I needed to thread harded the Address, Section and related objects.

To do this I modified the ModuleChild class to now require a ModuleSP
on initialization so that a weak reference can created. I also changed
all places that were handing out "Section *" to have them hand out SectionSP.
All ObjectFile, SymbolFile and SymbolVendors were inheriting from ModuleChild
so all of the find plug-in, static creation function and constructors now
require ModuleSP references instead of Module *.

Address objects now have weak references to their sections which can
safely go stale when a module gets destructed.

This checkin doesn't complete the "target symfile add" command, but it
does get us a lot clioser to being able to do such things without a high
risk of crashing or memory corruption.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@151336 91177308-0d34-0410-b5e6-96231b3b80d8
302d78c71902398ce1f422bd09216dd53a6abb88 10-Feb-2012 Sean Callanan <scallanan@apple.com> Extended function lookup to allow the user to
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.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@150279 91177308-0d34-0410-b5e6-96231b3b80d8
b5a8f1498e1ddaeed5187a878d57ea0b74af9c26 05-Feb-2012 Greg Clayton <gclayton@apple.com> <rdar://problem/10560053>

Fixed "target modules list" (aliased to "image list") to output more information
by default. Modified the "target modules list" to have a few new options:

"--header" or "-h" => show the image header address
"--offset" or "-o" => show the image header address offset from the address in the file (the slide applied to the shared library)

Removed the "--symfile-basename" or "-S" option, and repurposed it to
"--symfile-unique" "-S" which will show the symbol file if it differs from
the executable file.

ObjectFile's can now be loaded from memory for cases where we don't have the
files cached locally in an SDK or net mounted root. ObjectFileMachO can now
read mach files from memory.

Moved the section data reading code into the ObjectFile so that the object
file can get the section data from Process memory if the file is only in

lldb_private::Module can now load its object file in a target with a rigid
slide (very common operation for most dynamic linkers) by using:

Module::SetLoadAddress (Target &target, lldb::addr_t offset, bool &changed)

lldb::SBModule() now has a new constructor in the public interface:

SBModule::SBModule (lldb::SBProcess &process, lldb::addr_t header_addr);

This will find an appropriate ObjectFile plug-in to load an image from memory
where the object file header is at "header_addr".

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@149804 91177308-0d34-0410-b5e6-96231b3b80d8
13d24fb1817faa7ccc4cfd799113ba1a2b8968eb 29-Jan-2012 Greg Clayton <gclayton@apple.com> Switching back to using std::tr1::shared_ptr. We originally switched away
due to RTTI worries since llvm and clang don't use RTTI, but I was able to
switch back with no issues as far as I can tell. Once the RTTI issue wasn't
an issue, we were looking for a way to properly track weak pointers to objects
to solve some of the threading issues we have been running into which naturally
led us back to std::tr1::weak_ptr. We also wanted the ability to make a shared
pointer from just a pointer, which is also easily solved using the
std::tr1::enable_shared_from_this class.

The main reason for this move back is so we can start properly having weak
references to objects. Currently a lldb_private::Thread class has a refrence
to its parent lldb_private::Process. This doesn't work well when we now hand
out a SBThread object that contains a shared pointer to a lldb_private::Thread
as this SBThread can be held onto by external clients and if they end up
using one of these objects we can easily crash.

So the next task is to start adopting std::tr1::weak_ptr where ever it makes
sense which we can do with lldb_private::Debugger, lldb_private::Target,
lldb_private::Process, lldb_private::Thread, lldb_private::StackFrame, and
many more objects now that they are no longer using intrusive ref counted
pointer objects (you can't do std::tr1::weak_ptr functionality with intrusive

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@149207 91177308-0d34-0410-b5e6-96231b3b80d8
08205a649cf8a94477f7f9ab8e42dd95ebfc9626 27-Jan-2012 Greg Clayton <gclayton@apple.com> Added a ModuleList::Destroy() method which will reclaim the std::vector
memory by doing a swap.

Also added a few utilty functions that can be enabled for debugging issues
with modules staying around too long when external clients still have references
to them.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@149138 91177308-0d34-0410-b5e6-96231b3b80d8
c149c8b3a88e5c8a94febdf956551e378c531797 27-Jan-2012 Greg Clayton <gclayton@apple.com> Fixed an issue that could happen during global object destruction in our
map that tracks all live Module classes. We must leak our mutex for our
collection class as it might be destroyed in an order we can't control.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@149131 91177308-0d34-0410-b5e6-96231b3b80d8
a334c9d5f5a563bb55b424173c5c52b9295c11ba 12-Jan-2012 Jim Ingham <jingham@apple.com> Let the Module FindType do the stripping of namespace components, that's not expensive
and doing it both at the ModuleList and Module levels means we look 4 times for a negative
search. Also, don't do the search for the stripped name if that is the same as the original

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@148054 91177308-0d34-0410-b5e6-96231b3b80d8
db2dc2b824b61ef7578dc8cdad7b338aa82b1f17 12-Jan-2012 Greg Clayton <gclayton@apple.com> Big change in the way ObjectFile file contents are managed. We now
mmap() the entire object file contents into memory with MAP_PRIVATE.
We do this because object file contents can change on us and currently
this helps alleviate this situation. It also make the code for accessing
object file data much easier to manage and we don't end up opening the
file, reading some data and closing the file over and over.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@148017 91177308-0d34-0410-b5e6-96231b3b80d8
7129913a93594dc4d7b4e417212a366768337852 11-Jan-2012 Greg Clayton <gclayton@apple.com> Fixed a missing space when reporting errors and warning through the module
and also print out the full path and architecture.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@147908 91177308-0d34-0410-b5e6-96231b3b80d8
df6dc88322f103b263092d752db4490e628a1cbd 05-Jan-2012 Greg Clayton <gclayton@apple.com> Added code in the Host layer that can report system log messages
so that we don't have "fprintf (stderr, ...)" calls sprinkled everywhere.
Changed all needed locations over to using this.

For non-darwin, we log to stderr only. On darwin, we log to stderr _and_
to ASL (Apple System Log facility). This will allow GUI apps to have a place
for these error and warning messages to go, and also allows the command line
apps to log directly to the terminal.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@147596 91177308-0d34-0410-b5e6-96231b3b80d8
cd186e5ef6dacca7bd4914e99ef6b7551b5e79e4 14-Dec-2011 Johnny Chen <johnny.chen@apple.com> http://llvm.org/bugs/show_bug.cgi?id=11560 lldb::SBTarget::FindFirstType crashes when passed None

Add null checks to several functions. Plus add test scenario for passing None to SBTarget.FindFirstType(None) and friends.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@146540 91177308-0d34-0410-b5e6-96231b3b80d8
75d8c2591f6c56a09338bf4967a41510165a907e 28-Nov-2011 Greg Clayton <gclayton@apple.com> CommandObjectProcess was recently changed to automatically use the platform
to launch a process for debugging. Since this isn't supported on all platforms,
we need to do what we used to do if this isn't supported. I added:

Platform::CanDebugProcess ();

This will get checked before trying to launch a process for debugging and then
fall back to launching the process through the current host debugger. This
should solve the issue for linux and keep the platform code clean.

Centralized logging code for logging errors, warnings and logs when reporting
things for modules or symbol files. Both lldb_private::Module and
lldb_private::SymbolFile now have the following member functions:

LogMessage (Log *log, const char *format, ...);

ReportWarning (const char *format, ...);

ReportError (const char *format, ...);

These will all output the module name and object (if any) such as:

"error: lldb.so ...."
"warning: my_archive.a(foo.o) ...."

This will keep the output consistent and stop a lot of logging calls from
having to try and output all of the information that uniquely identifies
a module or symbol file. Many places in the code were grabbing the path to the
object file manually and if the module represented a .o file in an archive, we
would see log messages like:

error: foo.a - some error happened

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@145219 91177308-0d34-0410-b5e6-96231b3b80d8
b67c2a2f2a75fdba552a0eda0bf80df2095caa05 01-Nov-2011 Jim Ingham <jingham@apple.com> We can't have the global vector of modules be a static object, or it might get destroyed
before all the modules, which will then crash when the next modules tries to take itself off it.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@143402 91177308-0d34-0410-b5e6-96231b3b80d8
aa4a553d4b8cd37f13bd4946f504265000a7bcc4 13-Oct-2011 Sean Callanan <scallanan@apple.com> Removed namespace qualification from symbol queries.

git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@141866 91177308-0d34-0410-b5e6-96231b3b80d8
0fcec13c6639ab49216fa9447b25888b7bc9ff59 13-Oct-2011 Sean Callanan <scallanan@apple.com> Completed the glue that passes a ClangNamespaceDecl *
down through Module and SymbolVendor into SymbolFile.
Added checks to SymbolFileDWARF that restrict symbol
searches when a namespace is passed in.

git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@141847 91177308-0d34-0410-b5e6-96231b3b80d8
3e80cd9c9e6ae50ff54537551e2fe3ed5319b9b4 12-Oct-2011 Sean Callanan <scallanan@apple.com> Added ClangNamespaceDecl * parameters to several
core Module functions that the expression parser
will soon be using.

git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@141766 91177308-0d34-0410-b5e6-96231b3b80d8
6a64bbf41006e1184315b6593d7ec9d81c1c4654 21-Sep-2011 Greg Clayton <gclayton@apple.com> The first part of a fix for being able to select an architecture slice from
a file when the target has a triple with an unknown vendor and/or OS and the
slice of the file itself has a valid vendor and/or OS.

The Module now adopts the ObjectFile's architecture after a valid architecture
has been loaded to make sure the module matches the object file.

git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@140236 91177308-0d34-0410-b5e6-96231b3b80d8
7e5fa7fc1f8efd24c078e063b2c4b5e13ba5be20 20-Sep-2011 Jason Molenda <jmolenda@apple.com> Update declarations for all functions/methods that accept printf-style
stdarg formats to use __attribute__ format so the compiler can flag
incorrect uses. Fix all incorrect uses. Most of these are innocuous,
a few were resulting in crashes.

git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@140185 91177308-0d34-0410-b5e6-96231b3b80d8
e40b6424d9e49306392bec4b44060da36414c382 18-Sep-2011 Greg Clayton <gclayton@apple.com> Don't put modules for .o files into the global shared module list. We
used to do this because we needed to find the shared pointer for a .o
file when the .o file's module was needed in a SymbolContext since the
module in a symbol context was a shared pointer. Now that we are using
intrusive pointers we don't have this limitation anymore since any
instrusive shared pointer can be made from a pointer to an object
all on its own.

Also switched over to having the Module and SymbolVendor use shared
pointers to their object files as had a leak on MacOSX when the
SymbolVendor's object file wasn't the same as the Module's (debug info
in a stand along file (dSYM file)). Now everything will correctly clean
itself up when the module goes away after an executable gets rebuilt.

Now we correctly get rid of .o files that are used with the DWARF with
debug map executables on subsequent runs since the only shared pointer
to the object files in from the DWARF symbol file debug map parser, and
when the module gets replaced, it destroys to old one along with all .o

Also added a small optimization when using BSD archives where we will
remove old BSD containers from the shared list when they are outdated.

git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@140002 91177308-0d34-0410-b5e6-96231b3b80d8
02e210cad27e36108bef493b798c2c1eb3b04cb8 17-Sep-2011 Greg Clayton <gclayton@apple.com> Removed the function:


Since we are now using intrusive ref counts, we can easily turn any
pointer to a module into a shared pointer just by assigning it.

git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@139984 91177308-0d34-0410-b5e6-96231b3b80d8
6e0101c86555a06b3bd4cb6104b35abfae0b0057 17-Sep-2011 Greg Clayton <gclayton@apple.com> Convert lldb::ModuleSP to use an instrusive ref counted pointer.
We had some cases where getting the shared pointer for a module from
the global module list was causing a performance issue when debugging
with DWARF in .o files. Now that the module uses intrusive ref counts,
we can easily convert any pointer to a shared pointer.

git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@139983 91177308-0d34-0410-b5e6-96231b3b80d8
c51ffbf896e398ada5f7e89b2fa5aec6f2224f09 12-Aug-2011 Greg Clayton <gclayton@apple.com> We were leaking a stack frame in StackFrameList in Thread.cpp which could
cause extra shared pointer references to one or more modules to be leaked.
This would cause many object files to stay around the life of LLDB, so after
a recompile and rexecution, we would keep adding more and more memory. After
fixing the leak, we found many cases where leaked stack frames were still
being used and causing crashes in the test suite. These are now all resolved.

git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@137516 91177308-0d34-0410-b5e6-96231b3b80d8
899025fb72c0430e3b02746ca11c9070e9ede951 09-Aug-2011 Greg Clayton <gclayton@apple.com> Added a "--global" option to the "target modules list"
command that allows us to see all modules that exist and
their corresponding global shared pointer count. This will
help us track down memory issues when modules aren't being
removed and cleaned up from the module list.

git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@137078 91177308-0d34-0410-b5e6-96231b3b80d8
433c64a5a9aefb9551b739a4450016b51cfbec62 03-Aug-2011 Enrico Granata <granata.enrico@gmail.com> testing for a previous issue where formats in summaries where not enforced in all cases ; removed an unused local variable

git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@136785 91177308-0d34-0410-b5e6-96231b3b80d8
51b11e06de746667396f56b303d1867f007baf8b 03-Aug-2011 Jim Ingham <jingham@apple.com> Add method Module::IsLoadedInTarget, and then in the MacOS X dynamic loader, after we
have initialized our shared library state, discard all the modules that didn't make
it into the running process.

git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@136755 91177308-0d34-0410-b5e6-96231b3b80d8
979e20d127335143ffc89c2e37ec3a8b717ff22d 29-Jul-2011 Enrico Granata <granata.enrico@gmail.com> Public API changes:
- Completely new implementation of SBType
- Various enhancements in several other classes
Python synthetic children providers for std::vector<T>, std::list<T> and std::map<K,V>:
- these return the actual elements into the container as the children of the container
- basic template name parsing that works (hopefully) on both Clang and GCC
- find them in examples/synthetic and in the test suite in functionalities/data-formatter/data-formatter-python-synth
New summary string token ${svar :
- the syntax is just the same as in ${var but this new token lets you read the values
coming from the synthetic children provider instead of the actual children
- Python providers above provide a synthetic child len that returns the number of elements
into the container
Full bug fix for the issue in which getting byte size for a non-complete type would crash LLDB
Several other fixes, including:
- inverted the order of arguments in the ClangASTType constructor
- EvaluationPoint now only returns SharedPointer's to Target and Process
- the help text for several type subcommands now correctly indicates argument-less options as such

git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@136504 91177308-0d34-0410-b5e6-96231b3b80d8
801417e453f8531ac176cd952200587bf15d9ccf 07-Jul-2011 Greg Clayton <gclayton@apple.com> Added "target variable" command that allows introspection of global
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

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.

git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@134579 91177308-0d34-0410-b5e6-96231b3b80d8
9935a860350721f6bb32e841d89e1c25c07b98a7 18-May-2011 Jim Ingham <jingham@apple.com> FindFunctions was skipping the include_symbols section if it found a SymbolVendor.

git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@131526 91177308-0d34-0410-b5e6-96231b3b80d8
b72d0f098e45936fa72e26b1a026c603e17e2d6c 12-Apr-2011 Greg Clayton <gclayton@apple.com> Moved the execution context that was in the Debugger into
the CommandInterpreter where it was always being used.

Make sure that Modules can track their object file offsets correctly to
allow opening of sub object files (like the "__commpage" on darwin).

Modified the Platforms to be able to launch processes. The first part of this
move is the platform soon will become the entity that launches your program
and when it does, it uses a new ProcessLaunchInfo class which encapsulates
all process launching settings. This simplifies the internal APIs needed for
launching. I want to slowly phase out process launching from the process
classes, so for now we can still launch just as we used to, but eventually
the platform is the object that should do the launching.

Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able
to launch processes with all of the new eLaunchFlag settings. Modified any
code that was manually launching processes to use the Host::LaunchProcess

Fixed an issue where lldb_private::Args had implicitly defined copy
constructors that could do the wrong thing. This has now been fixed by adding
an appropriate copy constructor and assignment operator.

Make sure we don't add empty ModuleSP entries to a module list.

Fixed the commpage module creation on MacOSX, but we still need to train
the MacOSX dynamic loader to not get rid of it when it doesn't have an entry
in the all image infos.

Abstracted many more calls from in ProcessGDBRemote down into the
GDBRemoteCommunicationClient subclass to make the classes cleaner and more

Fixed the default iOS ARM register context to be correct and also added support
for targets that don't support the qThreadStopInfo packet by selecting the
current thread (only if needed) and then sending a stop reply packet.

Debugserver can now start up with a --unix-socket (-u for short) and can
then bind to port zero and send the port it bound to to a listening process
on the other end. This allows the GDB remote platform to spawn new GDB server
instances (debugserver) to allow platform debugging.

git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@129351 91177308-0d34-0410-b5e6-96231b3b80d8
b0e68d996b28cf81a28aeceefd69f7ed8d4aba99 31-Mar-2011 Greg Clayton <gclayton@apple.com> Added some functions to our API related to classifying symbols as code, data,
const data, etc, and also for SBAddress objects to classify their type of
section they are in and also getting the module for a section offset address.

lldb::SymbolType SBSymbol::GetType();

lldb::SectionType SBAddress::GetSectionType ();
lldb::SBModule SBAddress::GetModule ();

git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@128602 91177308-0d34-0410-b5e6-96231b3b80d8
24bc5d9bfad2a1c562c27e7cf37e1c56d85c45e7 30-Mar-2011 Greg Clayton <gclayton@apple.com> Many improvements to the Platform base class and subclasses. The base Platform
class now implements the Host functionality for a lot of things that make
sense by default so that subclasses can check:

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
====== ====== ========== ========== ========== ========== ======================== ============================
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
====== ====== ========== ========== ========== ========== ======================== ============================
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
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

(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;

git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@128563 91177308-0d34-0410-b5e6-96231b3b80d8
889fbd0581c24523642e0a04d659cc8f3dcdb4ed 26-Mar-2011 Greg Clayton <gclayton@apple.com> Added the ability to get the min and max instruction byte size for
an architecture into ArchSpec:

ArchSpec::GetMinimumOpcodeByteSize() const;

ArchSpec::GetMaximumOpcodeByteSize() const;

Added an AddressClass to the Instruction class in Disassembler.h.
This allows decoded instructions to know know if they are code,
code with alternate ISA (thumb), or even data which can be mixed
into code. The instruction does have an address, but it is a good
idea to cache this value so we don't have to look it up more than

Fixed an issue in Opcode::SetOpcodeBytes() where the length wasn't
getting set.


SymbolContextList::AppendIfUnique (const SymbolContext& sc);

SymbolContextList::AppendIfUnique (const SymbolContext& sc,
bool merge_symbol_into_function);

This function was typically being used when looking up functions
and symbols. Now if you lookup a function, then find the symbol,
they can be merged into the same symbol context and not cause
multiple symbol contexts to appear in a symbol context list that
describes the same function.

Fixed the SymbolContext not equal operator which was causing mixed
mode disassembly to not work ("disassembler --mixed --name main").

Modified the disassembler classes to know about the fact we know,
for a given architecture, what the min and max opcode byte sizes
are. The InstructionList class was modified to return the max
opcode byte size for all of the instructions in its list.
These two fixes means when disassemble a list of instructions and dump
them and show the opcode bytes, we can format the output more
intelligently when showing opcode bytes. This affects any architectures
that have varying opcode byte sizes (x86_64 and i386). Knowing the max
opcode byte size also helps us to be able to disassemble N instructions
without having to re-read data if we didn't read enough bytes.

Added the ability to set the architecture for the disassemble command.
This means you can easily cross disassemble data for any supported
architecture. I also added the ability to specify "thumb" as an
architecture so that we can force disassembly into thumb mode when
needed. In GDB this was done using a hack of specifying an odd
address when disassembling. I don't want to repeat this hack in LLDB,
so the auto detection between ARM and thumb is failing, just specify
thumb when disassembling:

(lldb) disassemble --arch thumb --name main

You can also have data in say an x86_64 file executable and disassemble
data as any other supported architecture:
% lldb a.out
Current executable set to 'a.out' (x86_64).
(lldb) b main
(lldb) run
(lldb) disassemble --arch thumb --count 2 --start-address 0x0000000100001080 --bytes
0x100001080: 0xb580 push {r7, lr}
0x100001082: 0xaf00 add r7, sp, #0

Fixed Target::ReadMemory(...) to be able to deal with Address argument object
that isn't section offset. When an address object was supplied that was
out on the heap or stack, target read memory would fail. Disassembly uses
Target::ReadMemory(...), and the example above where we disassembler thumb
opcodes in an x86 binary was failing do to this bug.

git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@128347 91177308-0d34-0410-b5e6-96231b3b80d8
940b103224f3062578c7a7e6e76d8bf4a7956f2a 23-Feb-2011 Greg Clayton <gclayton@apple.com> Abtracted all mach-o and ELF out of ArchSpec. This patch is a modified form
of Stephen Wilson's idea (thanks for the input Stephen!). What I ended up
doing was:
- Got rid of ArchSpec::CPU (which was a generic CPU enumeration that mimics
the contents of llvm::Triple::ArchType). We now rely upon the llvm::Triple
to give us the machine type from llvm::Triple::ArchType.
- There is a new ArchSpec::Core definition which further qualifies the CPU
core we are dealing with into a single enumeration. If you need support for
a new Core and want to debug it in LLDB, it must be added to this list. In
the future we can allow for dynamic core registration, but for now it is
hard coded.
- The ArchSpec can now be initialized with a llvm::Triple or with a C string
that represents the triple (it can just be an arch still like "i386").
- The ArchSpec can still initialize itself with a architecture type -- mach-o
with cpu type and subtype, or ELF with e_machine + e_flags -- and this will
then get translated into the internal llvm::Triple::ArchSpec + ArchSpec::Core.
The mach-o cpu type and subtype can be accessed using the getter functions:

ArchSpec::GetMachOCPUType () const;

ArchSpec::GetMachOCPUSubType () const;

But these functions are just converting out internal llvm::Triple::ArchSpec
+ ArchSpec::Core back into mach-o. Same goes for ELF.

All code has been updated to deal with the changes.

This should abstract us until later when the llvm::TargetSpec stuff gets
finalized and we can then adopt it.

git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@126278 91177308-0d34-0410-b5e6-96231b3b80d8
395fc33dc4b06c048ed35047ec461bc092ef2df3 15-Feb-2011 Greg Clayton <gclayton@apple.com> Made lldb_private::ArchSpec contain much more than just an architecture. It
now, in addition to cpu type/subtype and architecture flavor, contains:
- byte order (big endian, little endian)
- address size in bytes
- llvm::Triple for true target triple support and for more powerful plug-in

git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@125602 91177308-0d34-0410-b5e6-96231b3b80d8
0467c78e9a75eff9ec33d3c1f39fa83e1c5d9241 04-Feb-2011 Greg Clayton <gclayton@apple.com> Applied a fix to qualify "UUID" with the lldb_private namespace to fix
build issues on MinGW.

git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@124888 91177308-0d34-0410-b5e6-96231b3b80d8
28d5fcc3158aebf543e0f3d0a3608c1746f5ef15 27-Jan-2011 Greg Clayton <gclayton@apple.com> Changed the SymbolFile::FindFunction() function calls to only return
lldb_private::Function objects. Previously the SymbolFileSymtab subclass
would return lldb_private::Symbol objects when it was asked to find functions.

The Module::FindFunctions (...) now take a boolean "bool include_symbols" so
that the module can track down functions and symbols, yet functions are found
by the SymbolFile plug-ins (through the SymbolVendor class), and symbols are
gotten through the ObjectFile plug-ins.

Fixed and issue where the DWARF parser might run into incomplete class member
function defintions which would make clang mad when we tried to make certain
member functions with invalid number of parameters (such as an operator=
operator that had no parameters). Now we just avoid and don't complete these
incomplete functions.

git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@124359 91177308-0d34-0410-b5e6-96231b3b80d8
b01000fd063629facd45044f137446fb748ee179 17-Jan-2011 Greg Clayton <gclayton@apple.com> A few of the issue I have been trying to track down and fix have been due to
the way LLDB lazily gets complete definitions for types within the debug info.
When we run across a class/struct/union definition in the DWARF, we will only
parse the full definition if we need to. This works fine for top level types
that are assigned directly to variables and arguments, but when we have a
variable with a class, lets say "A" for this example, that has a member:
"B *m_b". Initially we don't need to hunt down a definition for this class
unless we are ever asked to do something with it ("expr m_b->getDecl()" for
example). With my previous approach to lazy type completion, we would be able
to take a "A *a" and get a complete type for it, but we wouldn't be able to
then do an "a->m_b->getDecl()" unless we always expanded all types within a
class prior to handing out the type. Expanding everything is very costly and
it would be great if there were a better way.

A few months ago I worked with the llvm/clang folks to have the
ExternalASTSource class be able to complete classes if there weren't completed

class ExternalASTSource {

virtual void
CompleteType (clang::TagDecl *Tag);

virtual void
CompleteType (clang::ObjCInterfaceDecl *Class);

This was great, because we can now have the class that is producing the AST
(SymbolFileDWARF and SymbolFileDWARFDebugMap) sign up as external AST sources
and the object that creates the forward declaration types can now also
complete them anywhere within the clang type system.

This patch makes a few major changes:
- lldb_private::Module classes now own the AST context. Previously the TypeList
objects did.
- The DWARF parsers now sign up as an external AST sources so they can complete
- All of the pure clang type system wrapper code we have in LLDB (ClangASTContext,
ClangASTType, and more) can now be iterating through children of any type,
and if a class/union/struct type (clang::RecordType or ObjC interface)
is found that is incomplete, we can ask the AST to get the definition.
- The SymbolFileDWARFDebugMap class now will create and use a single AST that
all child SymbolFileDWARF classes will share (much like what happens when
we have a complete linked DWARF for an executable).

We will need to modify some of the ClangUserExpression code to take more
advantage of this completion ability in the near future. Meanwhile we should
be better off now that we can be accessing any children of variables through
pointers and always be able to resolve the clang type if needed.

git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@123613 91177308-0d34-0410-b5e6-96231b3b80d8
e005f2ce03c489ebde9110678a29cbfe8488d5b4 06-Nov-2010 Greg Clayton <gclayton@apple.com> Modified all logging calls to hand out shared pointers to make sure we
don't crash if we disable logging when some code already has a copy of the
logger. Prior to this fix, logs were handed out as pointers and if they were
held onto while a log got disabled, then it could cause a crash. Now all logs
are handed out as shared pointers so this problem shouldn't happen anymore.
We are also using our new shared pointers that put the shared pointer count
and the object into the same allocation for a tad better performance.

git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@118319 91177308-0d34-0410-b5e6-96231b3b80d8
49ce682dfa7993d31206cea19ce7006cd3f3077e 31-Oct-2010 Greg Clayton <gclayton@apple.com> Cleaned up the API logging a lot more to reduce redundant information and
keep the file size a bit smaller.

Exposed SBValue::GetExpressionPath() so SBValue users can get an expression
path for their values.

git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@117851 91177308-0d34-0410-b5e6-96231b3b80d8
7826c8894803dc729f29789ebc038956a94d3e7a 26-Oct-2010 Caroline Tice <ctice@apple.com> First pass at adding logging capabilities for the API functions. At the moment
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

git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@117349 91177308-0d34-0410-b5e6-96231b3b80d8
537a7a86687683fd403ce652d178fbc89e06ef9f 20-Oct-2010 Greg Clayton <gclayton@apple.com> Fixed an issue where we were resolving paths when we should have been.

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

(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.

git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@116944 91177308-0d34-0410-b5e6-96231b3b80d8
3fed8b9b2696fc2ea78005c8f9b1c621d5748042 08-Oct-2010 Greg Clayton <gclayton@apple.com> Hooked up ability to look up data symbols so they show up in disassembly
if the address comes from a data section.

Fixed an issue that could occur when looking up a symbol that has a zero
byte size where no match would be returned even if there was an exact symbol

Cleaned up the section dump output and added the section type into the output.

git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@116017 91177308-0d34-0410-b5e6-96231b3b80d8
7c36fa07bc2c2c7efc4a28ad540f7711491f379d 11-Sep-2010 Greg Clayton <gclayton@apple.com> Remove the eSymbolTypeFunction, eSymbolTypeGlobal, and eSymbolTypeStatic.
They will now be represented as:
eSymbolTypeFunction: eSymbolTypeCode with IsDebug() == true
eSymbolTypeGlobal: eSymbolTypeData with IsDebug() == true and IsExternal() == true
eSymbolTypeStatic: eSymbolTypeData with IsDebug() == true and IsExternal() == false

This simplifies the logic when dealing with symbols and allows for symbols
to be coalesced into a single symbol most of the time.

Enabled the minimal symbol table for mach-o again after working out all the
kinks. We now get nice concise symbol tables and debugging with DWARF in the
.o files with a debug map in the binary works well again. There were issues
where the SymbolFileDWARFDebugMap symbol file parser was using symbol IDs and
symbol indexes interchangeably. Now that all those issues are resolved
debugging is working nicely.

git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@113678 91177308-0d34-0410-b5e6-96231b3b80d8
236c1c71fab5d56a4dbebaabb969a238f11d142e 08-Sep-2010 Greg Clayton <gclayton@apple.com> Remove the Flags member in lldb_private::Module in favor of bitfield boolean
member variables.

Modified lldb_private::Module to have an accessor that can be used to tell if
a module is a dynamic link editor (dyld) as there are functions in dyld on
darwin that mirror functions in libc (malloc, free, etc) that should not
be used when doing function lookups by name in expressions if there are more
than one match when looking up functions by name.

git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@113313 91177308-0d34-0410-b5e6-96231b3b80d8
bddb78944a140c3ca1324d356aa83495331ff50d 01-Sep-2010 Jim Ingham <jingham@apple.com> Don't re-look up the symbol in ResolveSymbolContextForAddress.

git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@112679 91177308-0d34-0410-b5e6-96231b3b80d8
7508e732818c32e1cfeaaf7d1d507fe3834ce9d2 10-Aug-2010 Jim Ingham <jingham@apple.com> Change Target & Process so they can really be initialized with an invalid architecture.
Arrange that this then gets properly set on attach, or when a "file" is set.
Add a completer for "process attach -n".

Caveats: there isn't currently a way to handle multiple processes with the same name. That
will have to wait on a way to pass annotations along with the completion strings.

git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@110624 91177308-0d34-0410-b5e6-96231b3b80d8
7aff9ffaec7ffc44dec3c64557dfadcc8a0833a6 03-Aug-2010 Greg Clayton <gclayton@apple.com> Added FindTypes to Module and ModuleList.

git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@110093 91177308-0d34-0410-b5e6-96231b3b80d8
12bec71b323dc520f0e985a86e09c4712559e115 28-Jun-2010 Greg Clayton <gclayton@apple.com> Added function name types to allow us to set breakpoints by name more
intelligently. The four name types we currently have are:

eFunctionNameTypeFull = (1 << 1), // The function name.
// For C this is the same as just the name of the function
// For C++ this is the demangled version of the mangled name.
// For ObjC this is the full function signature with the + or
// - and the square brackets and the class and selector
eFunctionNameTypeBase = (1 << 2), // The function name only, no namespaces or arguments and no class
// methods or selectors will be searched.
eFunctionNameTypeMethod = (1 << 3), // Find function by method name (C++) with no namespace or arguments
eFunctionNameTypeSelector = (1 << 4) // Find function by selector name (ObjC) names

this allows much more flexibility when setting breakoints:

(lldb) breakpoint set --name main --basename
(lldb) breakpoint set --name main --fullname
(lldb) breakpoint set --name main --method
(lldb) breakpoint set --name main --selector

The default:

(lldb) breakpoint set --name main

will inspect the name "main" and look for any parens, or if the name starts
with "-[" or "+[" and if any are found then a full name search will happen.
Else a basename search will be the default.

Fixed some command option structures so not all options are required when they
shouldn't be.

Cleaned up the breakpoint output summary.

Made the "image lookup --address <addr>" output much more verbose so it shows
all the important symbol context results. Added a GetDescription method to
many of the SymbolContext objects for the more verbose output.

git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@107075 91177308-0d34-0410-b5e6-96231b3b80d8
24943d2ee8bfaa7cf5893e4709143924157a5c1e 08-Jun-2010 Chris Lattner <sabre@nondot.org> Initial checkin of lldb code from internal Apple repo.

git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@105619 91177308-0d34-0410-b5e6-96231b3b80d8