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.

llvm-svn: 165438

llvm-svn: 155639

Also add SB API's to set this callback, and to enable the log channels.

llvm-svn: 151018

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

llvm-svn: 149207

information generated for it. Say we have a concrete function "foo" which
has inlined function "a" which calls another inlined function "b":

    foo
1   {
2       {
            a ()
3           {
                b ()
4               {
                
                }
            }
        }
    }
    
Sometimes we see the compiler generate an address range in the DWARF for "foo"
(block 1 above) as say [0x1000-0x1100). Then the range for "a" is something
like [0x1050-0x1060) (note that it is correctly scoped within the "foo" 
address range). And then we get "b" which is a child of "a", yet the debug
info says it has a range of [0x1060-0x1080) (not contained within "a"). We now
detect this issue when making our blocks and add an extra range to "a".

Also added a new "lldb" logging category named "symbol" where we can find out
about symbol file errors and warnings.

llvm-svn: 140822

Added a new log category for DWARF called "aranges" to log the parsing
of address ranges.

llvm-svn: 139489

'log list' output.

Remove an extraneous \n from one of the lldb/commands
log line.

Add an lldb/commands log indicating whether the command
was successful or not.

llvm-svn: 138530

debugging printfs() for data visualization turned into a meaningful log:
 - introduced a new log category `types' in channel `lldb'

llvm-svn: 135773

llvm-svn: 131041

Make the log message & setter match for "dyld/shlib".  The "ListLogCategories" output should really be auto-generated from the settings so you can't make this sort of mistake...

llvm-svn: 131003

strncasecmp equivalents from Kirk Beitz.

llvm-svn: 124889

Thanks Bruce!

llvm-svn: 123083

- Fix alias-building & resolving to properly handle optional arguments for command options.
- Add logging for command resolution ('log enable lldb commands')
- Fix alias resolution to properly handle commands that take raw input (resolve the alias, but
  don't muck up the raw arguments).

Net result:  Among other things, 'expr' command can now take strings with escaped characters and
not have the command handling & alias resolution code muck up the escaped characters. E.g.
 'expr printf ("\n\n\tHello there!")' should now work properly.


Not working yet:  Creating aliases with raw input for commands that take raw input.  Working on that.
e.g. 'command alias print_hi expr printf ("\n\tHi!")' does not work yet.

llvm-svn: 121171

changing it to use it. There was an extra parameter added to the static
accessor global user settings controllers that wasn't needed. A bool was being
used as a parameter to the accessor just so it could be used to clean up 
the global user settings controller which is now fixed by splitting up the
initialization into the "static void Class::Initialize()", access into the
"static UserSettingsControllerSP & Class::GetSettingsController()", and
cleanup into "static void Class::Terminate()".

Also added initialize and terminate calls to the logging code to avoid issues
when LLDB is shutting down. There were cases after the logging was switched
over to use shared pointers where we could crash if the global destructor
chain was being run and it causes the log to be destroyed and any any logging
occurred.

llvm-svn: 119757

main thread from having to wait on it (which was causing some I/O 
hangs).

llvm-svn: 118700

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.

llvm-svn: 118319

llvm-svn: 118283

the end of the list. We had an issue in the MacOSX dynamic loader where if
we had shlibs:
1 - a.out
2 - a.dylib
3 - b.dylib

And then a.dylib got unloaded, we would unload b.dylib due to the assumption
that only shared libraries could come off the end of the list. We now properly
search and find which ones get loaded.

Added a new internal logging category for the "lldb" log channel named "dyld".
This should allow all dynamic loaders to use this as a generic log channel so
we can track shared library loads and unloads in the logs without having to 
have each plug-in make up its own logging channel.

llvm-svn: 118147

than just the entire log channel.

Add checks, where appropriate, to make sure a log channel/category has 
not been disabled before attempting to write to it.

llvm-svn: 117715

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

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

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

llvm-svn: 117437

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


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

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

llvm-svn: 117349

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

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

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

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

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

llvm-svn: 117256

llvm-svn: 112614

llvm-svn: 106034

llvm-svn: 105781

llvm-svn: 105619