ValueObjects when creating variables referring to
live data rather than constructing
ValueObjectConstResults.

llvm-svn: 145437

llvm-svn: 145435

llvm-svn: 145434

implementation of the linux platform.

llvm-svn: 145433

llvm-svn: 145417

Fixed an issue where if we are debugging on a remote platform and set a
platform path for our executable, it was not being honored by the new
launch functions that used the ProcessLaunchInfo.

llvm-svn: 145371

as well as attached a new priority description as to why and when you would
want to implement each packet.

Also documented the additions we have made to the stop reply packet and why
the extra information is necessary.

llvm-svn: 145357

Patch from Daniel Dunbar for future-proof against http://llvm.org/viewvc/llvm-project?view=rev&revision=145331.

llvm-svn: 145345

management of what allocations remain after an
expression finishes executing.  This saves around
2.5KiB per expression for simple expressions.

llvm-svn: 145342

in LLDB.

llvm-svn: 145314

so that we can do Python scripting like this:

        target = self.dbg.CreateTarget(self.exe)

        self.dbg.SetAsync(True)
        process = target.LaunchSimple(None, None, os.getcwd())

        process.PutSTDIN("Line 1 Entered.\n")
        process.PutSTDIN("Line 2 Entered.\n")
        process.PutSTDIN("Line 3 Entered.\n")

Add TestProcessIO.py to exercise the process IO API: PutSTDIN()/GetSTDOUT()/GetSTDERR().

llvm-svn: 145282

the C++ API due to swig typemapping.

llvm-svn: 145260

Fixed a potential crasher where we weren't checking we got a valid DIE in
a compile unit.

llvm-svn: 145226

concatenating a string with "None" in python. Using a python format string
gets us around this by handling it gracefully.

llvm-svn: 145225

debugging.

llvm-svn: 145221

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:

    bool
    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:

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

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

    void
    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

llvm-svn: 145219

arguments were quietly masked as the code changed (modified version of a path
from Dawn).

llvm-svn: 145216

patch from Dawn).

llvm-svn: 145212

to 30% of memory. The size doubling was killing us and we ended up with up to
just under 50% of empty capacity. Cleaning this up saves us a ton of memory.

llvm-svn: 145086

having the enumeration take up 32 bits for the type and by putting it into the
bitfields that were already being used.

llvm-svn: 145084

making sure we perfectly size our vector of symbols on the symbol table.

llvm-svn: 145069

Fixed an issue with the options for memory read where --count couldn't be used
with the --binary option when writing data to a file.

Also removed the GDB format option from the --binary version of memory read.

llvm-svn: 145067

easily be used in the next run.

llvm-svn: 145051

something like "display/4i $pc" (or something like this). With LLDB we already
were showing 3 lines of source before and 3 lines of source after the current
source line when showing a stop context. We now improve this by allowing the
user to control the number of lines with the new "stop-line-count-before" and
"stop-line-count-after" settings. Also, there is a new setting for how many
disassembly lines to show: "stop-disassembly-count". This will control how many
source lines are shown when there is no source or when we have no source line
info. 

settings set stop-line-count-before 3
settings set stop-line-count-after 3
settings set stop-disassembly-count 4
settings set stop-disassembly-display no-source

The default values are set as shown above and allow 3 lines of source before 
and after (what we used to do) the current stop location, and will display 4 
lines of disassembly if the source is not available or if we have no debug
info. If both "stop-source-context-before" and "stop-source-context-after" are
set to zero, this will disable showing any source when stopped. The 
"stop-disassembly-display" setting is an enumeration that allows you to control
when to display disassembly. It has 3 possible values:

"never" - never show disassembly no matter what
"no-source" - only show disassembly when there is no source line info or the source files are missing
"always" - always show disassembly.

llvm-svn: 145050

llvm-svn: 145021

llvm-svn: 145020

several patches.  These patches fix a problem
where templated types were not being completed the
first time they were used, and fix a variety of
minor issues I discovered while fixing that problem.

One of the previous local patches was resolved in
the most recent Clang, so I removed it.  The others
will be removed in due course.

llvm-svn: 144984

1 - the DIE collections no longer have the NULL tags which saves up to 25%
    of the memory on typical C++ code
2 - faster parsing by not having to run the SetDIERelations() function anymore
    it is done when parsing the DWARF very efficiently.

llvm-svn: 144983

templates is properly complete (though still
empty).

llvm-svn: 144982

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.

llvm-svn: 144981

from a process and hooked it up to the new packet that was recently added
to our GDB remote executable named debugserver. Now Process has the following
new calls:

virtual Error
Process::GetMemoryRegionInfo (lldb::addr_t load_addr, MemoryRegionInfo &range_info);

virtual uint32_t
GetLoadAddressPermissions (lldb::addr_t load_addr);

Only the first one needs to be implemented by subclasses that can add this
support.

Cleaned up the way the new packet was implemented in debugserver to be more
useful as an API inside debugserver. Also found an error where finding a region
for an address actually will pick up the next region that follows the address
in the query so we also need ot make sure that the address we requested the
region for falls into the region that gets returned.

llvm-svn: 144976

we say that the vectors of DWARFDebugInfoEntry objects were the highest on the
the list. 

With these changes we cut our memory usage by 40%!!! I did this by reducing
the size of the DWARFDebugInfoEntry from a previous:

uint32_t offset
uint32_t parent_idx
uint32_t sibling_idx
Abbrev * abbrev_ptr

which was 20 bytes, but rounded up to 24 bytes due to alignment. Now we have:

uint32_t offset
uint32_t parent_idx
uint32_t sibling_idx
uint32_t abbr_idx:15,       // 32767 possible abbreviation codes
         has_children:1,    // 0 = no children, 1 = has children
         tag:16;            // DW_TAG_XXX value

This gets us down to 16 bytes per DIE. I tested some VERY large DWARF files
(900MB) and found there were only ~700 unique abbreviations, so 32767 should
be enough for any sane compiler. If it isn't there are built in assertions
that will fire off and tell us.

llvm-svn: 144975

to allow variables in the persistent variable store to know
how to complete themselves from debug information.  That
fixes a variety of bugs during dematerialization of 
expression results and also makes persistent variable and
result variables ($foo, $4, ...) more useful.

I have also added logging improvements that make it much
easier to figure out how types are moving from place to 
place, and made some checking a little more aggressive.

The commit includes patches to Clang which are currently being
integrated into Clang proper; once these fixes are in Clang
top-of-tree, these patches will be removed.  The patches don't
fix API; rather, they fix some internal bugs in Clang's 
ASTImporter that were exposed when LLDB was moving types from
place to place multiple times.

llvm-svn: 144969

llvm-svn: 144958

llvm-svn: 144945

llvm-svn: 144940

file actions have been specified.

llvm-svn: 144922

Use this option with care as you would need to build the inferior(s) by hand
and build the executable(s) with the correct name(s).  This option can be used
with '-# n' to stress test certain test cases for n number of times.

An example:

[11:55:11] johnny:/Volumes/data/lldb/svn/trunk/test/python_api/value $ ls
Makefile		TestValueAPI.pyc	linked_list
TestValueAPI.py		change_values		main.c
[11:55:14] johnny:/Volumes/data/lldb/svn/trunk/test/python_api/value $ make EXE=test_with_dsym
clang -gdwarf-2 -O0  -arch x86_64   -c -o main.o main.c
clang -gdwarf-2 -O0  -arch x86_64   main.o -o "test_with_dsym"
/usr/bin/dsymutil  -o "test_with_dsym.dSYM" "test_with_dsym"
[11:55:20] johnny:/Volumes/data/lldb/svn/trunk/test/python_api/value $ cd ../..
[11:55:24] johnny:/Volumes/data/lldb/svn/trunk/test $ ./dotest.py -v -# 10 -S -f ValueAPITestCase.test_with_dsym
LLDB build dir: /Volumes/data/lldb/svn/trunk/build/Debug
LLDB-89
Path: /Volumes/data/lldb/svn/trunk
URL: https://johnny@llvm.org/svn/llvm-project/lldb/trunk
Repository Root: https://johnny@llvm.org/svn/llvm-project
Repository UUID: 91177308-0d34-0410-b5e6-96231b3b80d8
Revision: 144914
Node Kind: directory
Schedule: normal
Last Changed Author: gclayton
Last Changed Rev: 144911
Last Changed Date: 2011-11-17 09:22:31 -0800 (Thu, 17 Nov 2011)



Session logs for test failures/errors/unexpected successes will go into directory '2011-11-17-11_55_29'
Command invoked: python ./dotest.py -v -# 10 -S -f ValueAPITestCase.test_with_dsym
----------------------------------------------------------------------
Collected 1 test

1: test_with_dsym (TestValueAPI.ValueAPITestCase)
   Exercise some SBValue APIs. ... ok

----------------------------------------------------------------------
Ran 1 test in 1.163s

OK
1: test_with_dsym (TestValueAPI.ValueAPITestCase)
   Exercise some SBValue APIs. ... ok

----------------------------------------------------------------------
Ran 1 test in 0.200s

OK
1: test_with_dsym (TestValueAPI.ValueAPITestCase)
   Exercise some SBValue APIs. ... ok

----------------------------------------------------------------------
Ran 1 test in 0.198s

OK
1: test_with_dsym (TestValueAPI.ValueAPITestCase)
   Exercise some SBValue APIs. ... ok

----------------------------------------------------------------------
Ran 1 test in 0.199s

OK
1: test_with_dsym (TestValueAPI.ValueAPITestCase)
   Exercise some SBValue APIs. ... ok

----------------------------------------------------------------------
Ran 1 test in 0.239s

OK
1: test_with_dsym (TestValueAPI.ValueAPITestCase)
   Exercise some SBValue APIs. ... ok

----------------------------------------------------------------------
Ran 1 test in 1.215s

OK
1: test_with_dsym (TestValueAPI.ValueAPITestCase)
   Exercise some SBValue APIs. ... ok

----------------------------------------------------------------------
Ran 1 test in 0.105s

OK
1: test_with_dsym (TestValueAPI.ValueAPITestCase)
   Exercise some SBValue APIs. ... ok

----------------------------------------------------------------------
Ran 1 test in 0.098s

OK
1: test_with_dsym (TestValueAPI.ValueAPITestCase)
   Exercise some SBValue APIs. ... ok

----------------------------------------------------------------------
Ran 1 test in 0.195s

OK
1: test_with_dsym (TestValueAPI.ValueAPITestCase)
   Exercise some SBValue APIs. ... ok

----------------------------------------------------------------------
Ran 1 test in 1.197s

OK
[11:55:34] johnny:/Volumes/data/lldb/svn/trunk/test $ 

llvm-svn: 144919

monitoring on darwin in the host layer.

llvm-svn: 144918

llvm-svn: 144915