Fix wrong test logic in test_modules_search_paths().  Add additional exercising of 'target modules search-paths list/query".
There is a reproducible crash if 'target modules search-paths clear' is exercised during test teardown.
So we currently comment out the stmt as follows:

        # Add teardown hook to clear image-search-paths after the test.
        # rdar://problem/10501020
        # Uncomment the following to reproduce 10501020.
        #self.addTearDownHook(lambda: self.runCmd("target modules search-paths clear"))

llvm-svn: 145466

llvm-svn: 145417

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

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

llvm-svn: 145225

llvm-svn: 144958

llvm-svn: 144945

llvm-svn: 144940

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

llvm-svn: 144915

llvm-svn: 144848

This helps track down possible zombie processes.

llvm-svn: 144846

llvm-svn: 144807

While we are at it, verify that 'my_int_ptr' points to 'g_my_int', using the SBTarget.ResolveLoadAddress() to get its SBAddress,
and SBAddress.GetSymbol() to get the corresponding symbol.

llvm-svn: 144728

llvm-svn: 144717

llvm-svn: 144697

llvm-svn: 144693

of problems with Objective-C object completion.  To go
along with the LLVM/Clang-side fixes, we have a variety
of Objective-C improvements.

Fixes include:

- It is now possible to run expressions when stopped in
  an Objective-C class method and have "self" act just
  like "self" would act in the class method itself (i.e.,
  [self classMethod] works without casting the return
  type if debug info is present).  To accomplish this,
  the expression masquerades as a class method added by
  a category.

- Objective-C objects can now provide methods and
  properties and methods to Clang on demand (i.e., the
  ASTImporter sets hasExternalVisibleDecls on Objective-C
  interface objects).

- Objective-C built-in types, which had long been a bone
  of contention (should we be using "id"?  "id*"?), are
  now fetched correctly using accessor functions on
  ClangASTContext.  We inhibit searches for them in the
  debug information.

There are also a variety of logging fixes, and I made two
changes to the test suite:

- Enabled a test case for Objective-C properties in the
  current translation unit.

- Added a test case for calling Objective-C class methods
  when stopped in a class method.

llvm-svn: 144607

llvm-svn: 144584

llvm-svn: 144546

llvm-svn: 144545

llvm-svn: 144539

This is the actual fix for the above radar where global variables that weren't
initialized were not being shown correctly when leaving the DWARF in the .o 
files. Global variables that aren't intialized have symbols in the .o files
that specify they are undefined and external to the .o file, yet document the
size of the variable. This allows the compiler to emit a single copy, but makes
it harder for our DWARF in .o files with the executable having a debug map
because the symbol for the global in the .o file doesn't exist in a section
that we can assign a fixed up linked address to, and also the DWARF contains
an invalid address in the "DW_OP_addr" location (always zero). This means that
the DWARF is incorrect and actually maps all such global varaibles to the
first file address in the .o file which is usually the first function. So we
can fix this in either of two ways: make a new fake section in the .o file
so that we have a file address in the .o file that we can relink, or fix the 
the variable as it is created in the .o file DWARF parser and actually give it
the file address from the executable. Each variable contains a 
SymbolContextScope, or a single pointer that helps us to recreate where the
variables came from (which module, file, function, etc). This context helps
us to resolve any file addresses that might be in the location description of
the variable by pointing us to which file the file address comes from, so we
can just replace the SymbolContextScope and also fix up the location, which we
would have had to do for the other case as well, and update the file address.
Now globals display correctly.

The above changes made it possible to determine if a variable is a global
or static variable when parsing DWARF. The DWARF emits a DW_TAG_variable tag
for each variable (local, global, or static), yet DWARF provides no way for
us to classify these variables into these categories. We can now detect when
a variable has a simple address expressions as its location and this will help
us classify these correctly.

While making the above changes I also noticed that we had two symbol types:
eSymbolTypeExtern and eSymbolTypeUndefined which mean essentially the same
thing: the symbol is not defined in the current object file. Symbol objects
also have a bit that specifies if a symbol is externally visible, so I got
rid of the eSymbolTypeExtern symbol type and moved all code locations that
used it to use the eSymbolTypeUndefined type.
 

llvm-svn: 144489

llvm-svn: 144450

llvm-svn: 144440

Do a better job of detecting when a breakpoint command has set the target running again (except you have to ignore
cases where the breakpoint runs expressions, those don't count as really "running again").

llvm-svn: 144064

be in the target. All of the environment, args, stdin/out/err files, etc have
all been moved. Also re-enabled the ability to launch a process in a separate
terminal on MacOSX.

llvm-svn: 144061

Fix the test suite failure.  The particular line in the test case was there since the initial version
dated 2010-21-15.  The test started failure recently probably due to work done on the command parsing.
Anyway, the specific test sequence is invalid and is fixed now.

llvm-svn: 144039

 a) adds a new --synchronicity (-s) setting for "command script add" that allows the user to decide if scripted commands should run synchronously or asynchronously (which can make a difference in how events are handled)
 b) clears up several error messages
 c) adds a new --allow-reload (-r) setting for "command script import" that allows the user to reload a module even if it has already been imported before
 d) allows filename completion for "command script import" (much like what happens for "target create")
 e) prevents "command script add" from replacing built-in commands with scripted commands
 f) changes AddUserCommand() to take an std::string instead of a const char* (for performance reasons)
plus, it fixes an issue in "type summary add" command handling which caused several test suite errors

llvm-svn: 144035

correctly, and added a testcase to check that it works.

The main problem here is that Objective-C class method
selectors are external references stored in a special
data structure in the LLVM IR module for an expression.
I just had to extract them and ensure that the real
class object locations were properly resolved.

llvm-svn: 143520

llvm-svn: 143476

    '::my_uint_t', 'anon_uint = 0'

from:

    '(my_uint_t) anon_uint = 0'

to make the test suite clean with ToT.

llvm-svn: 143474

"object borked"...  Also made the error when the checker fails reflect this fact rather than
report a crash at 0x0.

Also a little cleanup:
- StopInfoMachException had a redundant copy of the description string.
- ThreadPlanCallFunction had a redundant copy of the thread, and had a 
copy of the process that it didn't really need.

llvm-svn: 143419

rdar://problem/10373783

llvm-svn: 143396

Radar to be filed soon.

llvm-svn: 143395

tests.

llvm-svn: 143394

llvm-svn: 143372

llvm-svn: 143361

Example:

[11:33:09] johnny:/Volumes/data/lldb/svn/trunk/test $ ./dosep.ty -o "-v -n"
dotest.py options: -v -n
Running /Volumes/data/lldb/svn/trunk/test/dotest.py -v -n -p TestPublicAPIHeaders.py /Volumes/data/lldb/svn/trunk/test/api/check_public_api_headers
1: test_sb_api_directory (TestPublicAPIHeaders.SBDirCheckerCase)
   Test the SB API directory and make sure there's no unwanted stuff. ... ok

----------------------------------------------------------------------
Ran 1 test in 4.404s

OK
Running /Volumes/data/lldb/svn/trunk/test/dotest.py -v -n -p TestEmulations.py /Volumes/data/lldb/svn/trunk/test/arm_emulation
1: test_arm_emulations (TestEmulations.ARMEmulationTestCase) ... ok
2: test_thumb_emulations (TestEmulations.ARMEmulationTestCase) ... ok

----------------------------------------------------------------------
Ran 2 tests in 1.399s

OK

...

llvm-svn: 143355

instead of replacing it.

llvm-svn: 143323

CommandInterpreter::PreprocessCommand() should not infinite loop
when a target has not been specified yet.

llvm-svn: 143274