History log of /external/lldb/source/Core/ModuleList.cpp
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
0c4c43c8a598e9c37dcdd00bb77c6d59e083b904 11-Jul-2013 Michael Sartain <mikesart@valvesoftware.com> Fix "source list -n printf" on Linux (printf is symbol alias for __printf)

Differential Revision: http://llvm-reviews.chandlerc.com/D1109

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@186104 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Core/ModuleList.cpp
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
/external/lldb/source/Core/ModuleList.cpp
37c43e4d6611770f531ee9ca2d4037b02cfe39d9 21-May-2013 Enrico Granata <egranata@apple.com> Forgot to check for empty error strings in the previous checkin



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@182325 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Core/ModuleList.cpp
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
/external/lldb/source/Core/ModuleList.cpp
42b336cd509cad89be08f78775d3b1c8c7656a1b 04-May-2013 Jason Molenda <jmolenda@apple.com> Remove the UUID::GetAsCString() method which required a buffer to save the
UUID string in; added UUID::GetAsString() which returns the uuid string in
a std::string. Updated callers to use the new method.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@181078 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Core/ModuleList.cpp
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:

std::string
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
/external/lldb/source/Core/ModuleList.cpp
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
/external/lldb/source/Core/ModuleList.cpp
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
/external/lldb/source/Core/ModuleList.cpp
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
/external/lldb/source/Core/ModuleList.cpp
0b2f5cc32d01cf48d6216a232ec87afab1466315 08-Nov-2012 Enrico Granata <egranata@apple.com> Minor cleanups to the new ModuleList notification APIs: passing in the ModuleList as part of the callbacks, and not copying the notifier as part of copy constructing and assigning


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@167592 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Core/ModuleList.cpp
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
/external/lldb/source/Core/ModuleList.cpp
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
/external/lldb/source/Core/ModuleList.cpp
d9c3769158d08ba21bbcad164099c5a86982c543 03-Oct-2012 Enrico Granata <egranata@apple.com> <rdar://problem/12408181> Fixing a bug where we would try to look for types in a module, and then fail to look for them anywhere else because the same SymbolContext was being passed everywhere

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@165169 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Core/ModuleList.cpp
af059721e3e2ef1762b04c71f9f6466dd447a943 19-Sep-2012 Greg Clayton <gclayton@apple.com> <rdar://problem/12125274>

Intentionally leak the module list to avoid unnecessary freeing of modules + object files + symbol files when the program is exiting.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@164184 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Core/ModuleList.cpp
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
/external/lldb/source/Core/ModuleList.cpp
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
/external/lldb/source/Core/ModuleList.cpp
bcaf99a74367d464dd38011e26b9b4be56b503ba 12-Jul-2012 Greg Clayton <gclayton@apple.com> <rdar://problem/11791234>

Fixed a case where the python interpreter could end up holding onto a previous lldb::SBProcess (probably in lldb.process) when run under Xcode. Prior to this fix, the lldb::SBProcess held onto a shared pointer to a lldb_private::Process. This in turn could cause the process to still have a thread list with stack frames. The stack frames would have module shared pointers in the lldb_private::SymbolContext objects.

We also had issues with things staying in the shared module list too long when we found things by UUID (we didn't remove the out of date ModuleSP from the global module cache).

Now all of this is fixed and everything goes away between runs.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@160140 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Core/ModuleList.cpp
e8fc036c09dcf1cf2e9f1b580638619451a79201 27-Jun-2012 Greg Clayton <gclayton@apple.com> Fix the copy constructor and assignement operator for ModuleList to be thread safe.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@159285 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Core/ModuleList.cpp
9336790a758b8f8b87d95e6658bb8fdb34766c2f 30-May-2012 Jim Ingham <jingham@apple.com> We were accessing the ModuleList in the target without locking it for tasks like
setting breakpoints. That's dangerous, since while we are setting a breakpoint,
the target might hit the dyld load notification, and start removing modules from
the list. This change adds a GetMutex accessor to the ModuleList class, and
uses it whenever we are accessing the target's ModuleList (as returned by GetImages().)

<rdar://problem/11552372>


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@157668 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Core/ModuleList.cpp
03e5e512252fc7971430027d8ea05f64576bcbb3 17-May-2012 Jim Ingham <jingham@apple.com> If we notice that a module with a given file path is replaced by another with the same file
path on rerunning, evict the old module from the target module list, inform the breakpoints
about this so they can do something intelligent as well.

rdar://problem/11273043


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@157008 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Core/ModuleList.cpp
1b584ebc1de8b50fe375cffb5fb33ad13be10046 05-May-2012 Jim Ingham <jingham@apple.com> Don't expose the pthread_mutex_t underlying the Mutex & Mutex::Locker classes.
No one was using it and Locker(pthread_mutex_t *) immediately asserts for
pthread_mutex_t's that don't come from a Mutex anyway. Rather than try to make
that work, we should maintain the Mutex abstraction and not pass around the
platform implementation...

Make Mutex::Locker::Lock take a Mutex & or a Mutex *, and remove the constructor
taking a pthread_mutex_t *. You no longer need to call Mutex::GetMutex to pass
your mutex to a Locker (you can't in fact, since I made it private.)


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@156221 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Core/ModuleList.cpp
516f0849819d094d4eab39a1f27b770259103ff8 11-Apr-2012 Greg Clayton <gclayton@apple.com> No functionality changes, mostly cleanup.

Cleaned up the Mutex::Locker and the ReadWriteLock classes a bit.

Also cleaned up the GDBRemoteCommunication class to not have so many packet functions. Used the "NoLock" versions of send/receive packet functions when possible for a bit of performance.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@154458 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Core/ModuleList.cpp
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
/external/lldb/source/Core/ModuleList.cpp
72c17bfa5bb4ee37dd23f98a78e6b35d50b030f8 06-Apr-2012 Greg Clayton <gclayton@apple.com> Fixed ModuleList::FindTypes() so that when a symbol context is supplied that contains a valid module, it will search that module first, then if we are still looking for matches (we have found less that "max_matches"), search in all of the other modules as well.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@154186 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Core/ModuleList.cpp
9f95fb63a492b53206d578f46e73899d60d70321 06-Apr-2012 Greg Clayton <gclayton@apple.com> In a prior commit, I changed the parameters around on a ModuleList::FindTypes where the old parameters that existing clients were using would have been compatible, so I renamed ModuleList::FindTypes to ModuleList::FindTypes2. Then I made fixes and verified I updated and fixed all client code, but I forgot to rename the function back to ModuleList::FindTypes(). I am doing that now and also cleaning up the C++ dynamic type code a bit.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@154182 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Core/ModuleList.cpp
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
/external/lldb/source/Core/ModuleList.cpp
aa2063089f2397bd21cff2dab2e7c316ae5ff12c 21-Mar-2012 Greg Clayton <gclayton@apple.com> Fixed the ability to load a module from a path by using just a UUID. After
the migration to ModuleSpec objects this broke and is now fixed.

Also fixed a case in the darwin kernel dynamic loader where we just need to
trust the load address of the kernel if we can't read it from memory.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@153164 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Core/ModuleList.cpp
12f588a2ee9a48d365b06be3b9d1627948fc5d05 20-Mar-2012 Greg Clayton <gclayton@apple.com> Make sure that if a UUID was passed in, and we found a match, that should be enough for us.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@153076 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Core/ModuleList.cpp
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
/external/lldb/source/Core/ModuleList.cpp
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
/external/lldb/source/Core/ModuleList.cpp
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
/external/lldb/source/Core/ModuleList.cpp
9ce953807eb814a93b449dc243de4f7bf32c3115 14-Feb-2012 Greg Clayton <gclayton@apple.com> Full core file support has been added for mach-o core files.

Tracking modules down when you have a UUID and a path has been improved.

DynamicLoaderDarwinKernel no longer parses mach-o load commands and it
now uses the memory based modules now that we can load modules from memory.

Added a target setting named "target.exec-search-paths" which can be used
to supply a list of directories to use when trying to look for executables.
This allows one or more directories to be used when searching for modules
that may not exist in the SDK/PDK. The target automatically adds the directory
for the main executable to this list so this should help us in tracking down
shared libraries and other binaries.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@150426 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Core/ModuleList.cpp
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
/external/lldb/source/Core/ModuleList.cpp
46c9a355af9b39db78c006b2a5cbf97d3c58d947 09-Feb-2012 Greg Clayton <gclayton@apple.com> First pass at mach-o core file support is in. It currently works for x86_64
user space programs. The core file support is implemented by making a process
plug-in that will dress up the threads and stack frames by using the core file
memory.

Added many default implementations for the lldb_private::Process functions so
that plug-ins like the ProcessMachCore don't need to override many many
functions only to have to return an error.

Added new virtual functions to the ObjectFile class for extracting the frozen
thread states that might be stored in object files. The default implementations
return no thread information, but any platforms that support core files that
contain frozen thread states (like mach-o) can make a module using the core
file and then extract the information. The object files can enumerate the
threads and also provide the register state for each thread. Since each object
file knows how the thread registers are stored, they are responsible for
creating a suitable register context that can be used by the core file threads.

Changed the process CreateInstace callbacks to return a shared pointer and
to also take an "const FileSpec *core_file" parameter to allow for core file
support. This will also allow for lldb_private::Process subclasses to be made
that could load crash logs. This should be possible on darwin where the crash
logs contain all of the stack frames for all of the threads, yet the crash
logs only contain the registers for the crashed thrad. It should also allow
some variables to be viewed for the thread that crashed.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@150154 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Core/ModuleList.cpp
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
memory.

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:

bool
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
/external/lldb/source/Core/ModuleList.cpp
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
pointers).



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@149207 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Core/ModuleList.cpp
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
/external/lldb/source/Core/ModuleList.cpp
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
one.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@148054 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Core/ModuleList.cpp
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
/external/lldb/source/Core/ModuleList.cpp
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
/external/lldb/source/Core/ModuleList.cpp
323ce42219c4b036e21212ce7d1398253a91e9db 19-Nov-2011 Jim Ingham <jingham@apple.com> Handle stepping through a trampoline where the jump target is calculated a runtime - and so doesn't match
the name of the PLT entry. This solution assumes a naming convention agreed upon by us and the system folks,
and isn't general. The general solution requires actually finding & calling the resolver function if it
hasn't been called yet. That's more tricky.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@144981 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Core/ModuleList.cpp
9c236733d43e6250c8a5671a438f4a2afeb9c0b2 26-Oct-2011 Greg Clayton <gclayton@apple.com> Cleaned up many error codes. For any who is filling in error strings into
lldb_private::Error objects the rules are:
- short strings that don't start with a capitol letter unless the name is a
class or anything else that is always capitolized
- no trailing newline character
- should be one line if possible

Implemented a first pass at adding "--gdb-format" support to anything that
accepts format with optional size/count.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@142999 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Core/ModuleList.cpp
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
/external/lldb/source/Core/ModuleList.cpp
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
/external/lldb/source/Core/ModuleList.cpp
3e8c25f62f92145b6fb699b379cbfe72b1245d4a 24-Sep-2011 Greg Clayton <gclayton@apple.com> Added to the public API to allow symbolication:
- New SBSection objects that are object file sections which can be accessed
through the SBModule classes. You can get the number of sections, get a
section at index, and find a section by name.
- SBSections can contain subsections (first find "__TEXT" on darwin, then
us the resulting SBSection to find "__text" sub section).
- Set load addresses for a SBSection in the SBTarget interface
- Set the load addresses of all SBSection in a SBModule in the SBTarget interface
- Add a new module the an existing target in the SBTarget interface
- Get a SBSection from a SBAddress object

This should get us a lot closer to being able to symbolicate using LLDB through
the public API.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@140437 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Core/ModuleList.cpp
95b7b4362ca7135be088e4fbf04c2bd15767a104 20-Sep-2011 Jason Molenda <jmolenda@apple.com> Change Error::SetErrorStringWithFormat() prototype to use an
__attribute__ format so the compiler knows that this method takes
printf style formatter arguments and checks that it's being used
correctly. Fix a couple dozen incorrect SetErrorStringWithFormat()
calls throughout the sources.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@140115 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Core/ModuleList.cpp
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
/external/lldb/source/Core/ModuleList.cpp
b01760c1bc2b35c1e54cd4c95bda066023f361d8 11-Aug-2011 Greg Clayton <gclayton@apple.com> Fix the broken build that happened with my last checkin.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@137300 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Core/ModuleList.cpp
5beb99d65c72cd4a4f7529c4ff8cc04a1a40769d 11-Aug-2011 Greg Clayton <gclayton@apple.com> Added the ability to remove orphaned module shared pointers from a ModuleList.
This is helping us track down some extra references to ModuleSP objects that
are causing things to get kept around for too long.

Added a module pointer accessor to target and change a lot of code to use
it where it would be more efficient.

"taret delete" can now specify "--clean=1" which will cleanup the global module
list for any orphaned module in the shared module cache which can save memory
and also help track down module reference leaks like we have now.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@137294 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Core/ModuleList.cpp
153ccd72f52a6cc3595d7614558e2954f67833eb 10-Aug-2011 Greg Clayton <gclayton@apple.com> While tracking down memory consumption issue a few things were needed: the
ability to dump more information about modules in "target modules list". We
can now dump the shared pointer reference count for modules, the pointer to
the module itself (in case performance tools can help track down who has
references to said pointer), and the modification time.

Added "target delete [target-idx ...]" to be able to delete targets when they
are no longer needed. This will help track down memory usage issues and help
to resolve when module ref counts keep getting incremented. If the command gets
no arguments, the currently selected target will be deleted. If any arguments
are given, they must all be valid target indexes (use the "target list"
command to get the current target indexes).

Took care of a bunch of "no newline at end of file" warnings.

TimeValue objects can now dump their time to a lldb_private::Stream object.

Modified the "target modules list --global" command to not error out if there
are no targets since it doesn't require a target.

Fixed an issue in the MacOSX DYLD dynamic loader plug-in where if a shared
library was updated on disk, we would keep using the older one, even if it was
updated.

Don't allow the ModuleList::GetSharedModule(...) to return an empty module.
Previously we could specify a valid path on disc to a module, and specify an
architecture that wasn't contained in that module and get a shared pointer to
a module that wouldn't be able to return an object file or a symbol file. We
now make sure an object file can be extracted prior to adding the shared pointer
to the module to get added to the shared list.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@137196 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Core/ModuleList.cpp
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
/external/lldb/source/Core/ModuleList.cpp
0fa512447e00da09d300fbabd18b5ce94f52fdaa 19-Jul-2011 Greg Clayton <gclayton@apple.com> Modified the LocateMacOSXFilesUsingDebugSymbols(...) function to locate
an executable file if it is right next to a dSYM file that is found using
DebugSymbols. The code also looks into a bundle if the dSYM file is right
next to a bundle.

Modified the MacOSX kernel dynamic loader plug-in to correctly set the load
address for kext sections. This is a tad tricky because of how LLDB chooses
to treat mach-o segments with no name. Also modified the loader to properly
handle the older version 1 kext summary info.

Fixed a crasher in the Mach-o object file parser when it is trying to set
the section size correctly for dSYM sections.

Added packet dumpers to the CommunicationKDP class. We now also properly
detect address byte sizes based on the cpu type and subtype that is provided.
Added a read memory and read register support to CommunicationKDP. Added a
ThreadKDP class that now uses subclasses of the RegisterContextDarwin_XXX for
arm, i386 and x86_64.

Fixed some register numbering issues in the RegisterContextDarwin_arm class
and added ARM GDB numbers to the ARM_GCC_Registers.h file.

Change the RegisterContextMach_XXX classes over to subclassing their
RegisterContextDarwin_XXX counterparts so we can share the mach register
contexts between the user and kernel plug-ins.




git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@135466 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Core/ModuleList.cpp
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
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.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@134579 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Core/ModuleList.cpp
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
functions.

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

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
/external/lldb/source/Core/ModuleList.cpp
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:

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;





git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@128563 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Core/ModuleList.cpp
dd506e1674073ea3eaec680d5a87d5589ea08362 15-Mar-2011 Greg Clayton <gclayton@apple.com> Added a fix to not re-use object files when doing DWARF with debug map.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@127659 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Core/ModuleList.cpp
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:

uint32_t
ArchSpec::GetMachOCPUType () const;

uint32_t
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
/external/lldb/source/Core/ModuleList.cpp
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
/external/lldb/source/Core/ModuleList.cpp
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
/external/lldb/source/Core/ModuleList.cpp
f5c9ffb037443a26ef0d28891347aa9ca7cd9e19 21-Dec-2010 Greg Clayton <gclayton@apple.com> Remove an assertion that is causing crashes. We do need to find a way to reproduce when this assertion asserts, but we should crash our debug session because of it. For now we log to stderr in hope of tracking it down.

git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@122290 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Core/ModuleList.cpp
427f290ff96f3ab9f2cf3a1af7001d2c560424c7 14-Dec-2010 Greg Clayton <gclayton@apple.com> Modified LLDB expressions to not have to JIT and run code just to see variable
values or persistent expression variables. Now if an expression consists of
a value that is a child of a variable, or of a persistent variable only, we
will create a value object for it and make a ValueObjectConstResult from it to
freeze the value (for program variables only, not persistent variables) and
avoid running JITed code. For everything else we still parse up and JIT code
and run it in the inferior.

There was also a lot of clean up in the expression code. I made the
ClangExpressionVariables be stored in collections of shared pointers instead
of in collections of objects. This will help stop a lot of copy constructors on
these large objects and also cleans up the code considerably. The persistent
clang expression variables were moved over to the Target to ensure they persist
across process executions.

Added the ability for lldb_private::Target objects to evaluate expressions.
We want to evaluate expressions at the target level in case we aren't running
yet, or we have just completed running. We still want to be able to access the
persistent expression variables between runs, and also evaluate constant
expressions.

Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects
can now dump their contents with the UUID, arch and full paths being logged with
appropriate prefix values.

Thread hardened the Communication class a bit by making the connection auto_ptr
member into a shared pointer member and then making a local copy of the shared
pointer in each method that uses it to make sure another thread can't nuke the
connection object while it is being used by another thread.

Added a new file to the lldb/test/load_unload test that causes the test a.out file
to link to the libd.dylib file all the time. This will allow us to test using
the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@121745 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Core/ModuleList.cpp
ab429022ca0f47e4bd2ae1dc70f315e4824d5ae1 12-Dec-2010 Greg Clayton <gclayton@apple.com> Fixed an issue where the macosx dynamic loader, on the first shared library loaded notification, wasn't properly removing shared libraries from the target that didn't get loaded. This usually happens when a different shared library is loaded in place of another due to DYLD_LIBRARY_PATH or DYLD_FRAMEWORK_PATH environment variables. We now properly remove any images that didn't make it into the executable.

git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@121641 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Core/ModuleList.cpp
58e844b3561848e73e69d6d98746d4851e78306e 08-Dec-2010 Greg Clayton <gclayton@apple.com> Added the ability to dump sections to a certain depth (for when sections
have children sections).

Modified SectionLoadList to do it's own multi-threaded protected on its map.
The ThreadSafeSTLMap class was difficult to deal with and wasn't providing
much utility, it was only getting in the way.

Make sure when the communication read thread is about to exit, it clears the
thread in the main class.

Fixed the ModuleList to correctly ignore architectures and UUIDs if they aren't
valid when searching for a matching module. If we specified a file with no arch,
and then modified the file and loaded it again, it would not match on subsequent
searches if the arch was invalid since it would compare an invalid architecture
to the one that was found or selected within the shared library or executable.
This was causing stale modules to stay around in the global module list when they
should have been removed.

Removed deprecated functions from the DynamicLoaderMacOSXDYLD class.

Modified "ProcessGDBRemote::IsAlive" to check if we are connected to a gdb
server and also make sure our process hasn't exited.





git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@121236 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Core/ModuleList.cpp
7b9fcc06843d624787a9115d14285a6d6a6cca53 07-Dec-2010 Greg Clayton <gclayton@apple.com> When shared libraries are unloaded, they are now removed from the target
ModuleList so they don't show up in the images. Breakpoint locations that are
in shared libraries that get unloaded will persist though so that if you
have plug-ins that load/unload and you have a breakpoint set on functions
in the plug-ins, the hit counts will persist between loads/unloads.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@121069 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Core/ModuleList.cpp
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
type:

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

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

So I removed the constructor that just takes a path:

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

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

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

I also removed the default parameter to SetFile():

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

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



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@116944 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Core/ModuleList.cpp
b04e7a805310f2f2cc77947a8b263de9061617ae 24-Aug-2010 Greg Clayton <gclayton@apple.com> Got a lot of the kinks worked out in the inline support after debugging more
complex inlined examples.

StackFrame classes don't have a "GetPC" anymore, they have "GetFrameCodeAddress()".
This is because inlined frames will have a PC value that is the same as the
concrete frame that owns the inlined frame, yet the code locations for the
frame can be different. We also need to be able to get the real PC value for
a given frame so that variables evaluate correctly. To get the actual PC
value for a frame you can use:

addr_t pc = frame->GetRegisterContext()->GetPC();

Some issues with the StackFrame stomping on its own symbol context were
resolved which were causing the information to change for a frame when the
stack ID was calculated. Also the StackFrame will now correctly store the
symbol context resolve flags for any extra bits of information that were
looked up (if you ask for a block only and you find one, you will alwasy have
the compile unit and function).



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@111964 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Core/ModuleList.cpp
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
/external/lldb/source/Core/ModuleList.cpp
0fc7358d61218ba5d5abb5c2ea489a9ef936bbf7 27-Jul-2010 Sean Callanan <scallanan@apple.com> Changed SymbolContext so when you search for functions
it returns a list of functions as a SymbolContextList.

Rewrote the clients of SymbolContext to use this
SymbolContextList.

Rewrote some of the providers of the data to SymbolContext
to make them respect preferences as to whether the list
should be cleared first; propagated that change out.

ClangExpressionDeclMap and ClangASTSource use this new
function list to properly generate function definitions -
even for functions that don't have a prototype in the
debug information.


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@109476 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Core/ModuleList.cpp
661825b68e95abdfab2c7242c0d515e8260d1431 29-Jun-2010 Greg Clayton <gclayton@apple.com> Fixed debug map in executable + DWARF in .o debugging on Mac OS X.

Added the ability to dump any file in the global module cache using any of
the "image dump" commands. This allows us to dump the .o files that are used
with DWARF + .o since they don't belong the the target list for the current
target.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@107100 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Core/ModuleList.cpp
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
/external/lldb/source/Core/ModuleList.cpp
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
/external/lldb/source/Core/ModuleList.cpp