rdar://problem/8464339 test/types directory: b basic_type.cpp:171 does not work, while gdb does work.

llvm-svn: 114557

Add SBValueList.h & SBStream.h to build-swig-Python.sh; add SBValueList.h to lldb.swig

llvm-svn: 114549

whether a given register number is treated as volatile
or not for a given architecture/platform.

approx 450 lines of boilerplate, 50 lines of actual code. :)

llvm-svn: 114537

variety of ways they can be displayed in variable views.

llvm-svn: 114530

Added some comments explaining why we currently have to manually set CXXRecordDecl variables. This is because SEMA is actually calling the accessors that should be built into the CXXRecordDecl class. We have an internal bug tracking this change and will remove the affected work around code when a solution is available.

llvm-svn: 114516

expression parser's behalf so that now we see the
full TranslationUnitDecl instead of just the
FunctionDecl.

llvm-svn: 114514

llvm-svn: 114513

or not.

llvm-svn: 114512

llvm-svn: 114511

llvm-svn: 114505

themselves.  Right now, it tests a breakpoint both before and after it has been
resolved.

Updated lldbtest.TestBase.expect() with an additional keyword argument 'exe' (
default to True), which if set to False, will treat the mandatory first argument
as just the string to be matched/or not-matched against the golden input.

llvm-svn: 114501

Update help text for breakpoint command one-liners.

Fix minor bug in 'commands alias'; alias commands can now handle command options 
and arguments in the same alias.  Also fixes problem that disallowed "process launch --" as
an alias.

Fix typo in comment in Python script interpreter.

llvm-svn: 114499

And removed the informational output from the conditional_break test case.

llvm-svn: 114493

Fixed an issue with the clang type creation code for C++ classes where we wouldn't set a CXXRecordDecl to be NOT empty if we had base classes that were not empty or had virtual functions.

llvm-svn: 114484

of 'breakpoint command add/list/remove' commands to set breakpoint callbacks,
list them, and then remove one.

Modified the lldbtest.TestBase.expect() method to add two additional keyword
arguments:

o matching (default to True), which, if set to False, reverses the semantics of
  'expect' to 'expect not'

o patterns (default to None), which specifies a list of regexp patterns to match
  against the output from running the command

TestBreakpointCommand.py uses the matching=False and the patterns=[...] expect()
API.

llvm-svn: 114480

Add a warning if no command was attached to the breakpoint.
Update the help slightly.

llvm-svn: 114467

@expectedFailure as of r114384.

llvm-svn: 114466

for C++ classes.  Replaced it with a less hacky approach:

 - If an expression is defined in the context of a
   method of class A, then that expression is wrapped as
   ___clang_class::___clang_expr(void*) { ... }
   instead of ___clang_expr(void*) { ... }.

 - ___clang_class is resolved as the type of the target
   of the "this" pointer in the method the expression
   is defined in.

 - When reporting the type of ___clang_class, a method
   with the signature ___clang_expr(void*) is added to
   that class, so that Clang doesn't complain about a
   method being defined without a corresponding
   declaration.

 - Whenever the expression gets called, "this" gets
   looked up, type-checked, and then passed in as the
   first argument.

This required the following changes:

 - The ABIs were changed to support passing of the "this"
   pointer as part of trivial calls.

 - ThreadPlanCallFunction and ClangFunction were changed
   to support passing of an optional "this" pointer.

 - ClangUserExpression was extended to perform the
   wrapping described above.

 - ClangASTSource was changed to revert the changes
   required by the hack.

 - ClangExpressionParser, IRForTarget, and
   ClangExpressionDeclMap were changed to handle
   different manglings of ___clang_expr flexibly.  This
   meant no longer searching for a function called
   ___clang_expr, but rather looking for a function whose
   name *contains* ___clang_expr.

 - ClangExpressionParser and ClangExpressionDeclMap now
   remember whether "this" is required, and know how to
   look it up as necessary.

A few inheritance bugs remain, and I'm trying to resolve
these.  But it is now possible to use "this" as well as
refer implicitly to member variables, when in the proper
context.

llvm-svn: 114384

llvm-svn: 114381

order to customize the running of the test suite.  For the time being, the
supported customizations are:

o redirecting stdout and/or stderr
o specifying a list of compilers to build the test programs
o specifying a list of architectures to build the test programs for

Also checked into the examples/test directory some example files which
demonstrate the usage for the above customizations.

$ ./dotest.py -v -c ~/.lldbtest-config persistent_variables
$ cat ~/.lldbtest-config
sys.stderr = open("/tmp/lldbtest-stderr", "w")
sys.stdout = open("/tmp/lldbtest-stdout", "w")
compilers = ["gcc", "llvm-gcc"]
archs = ["x86_64", "i386"]
$ cat /tmp/lldbtest-stderr
----------------------------------------------------------------------
Collected 1 test


Configuration: arch=x86_64 compiler=gcc
test_persistent_variables (TestPersistentVariables.PersistentVariablesTestCase)
Test that lldb persistent variables works correctly. ... ok

----------------------------------------------------------------------
Ran 1 test in 1.397s

OK

Configuration: arch=x86_64 compiler=llvm-gcc
test_persistent_variables (TestPersistentVariables.PersistentVariablesTestCase)
Test that lldb persistent variables works correctly. ... ok

----------------------------------------------------------------------
Ran 1 test in 1.282s

OK

Configuration: arch=i386 compiler=gcc
test_persistent_variables (TestPersistentVariables.PersistentVariablesTestCase)
Test that lldb persistent variables works correctly. ... ok

----------------------------------------------------------------------
Ran 1 test in 1.297s

OK

Configuration: arch=i386 compiler=llvm-gcc
test_persistent_variables (TestPersistentVariables.PersistentVariablesTestCase)
Test that lldb persistent variables works correctly. ... ok

----------------------------------------------------------------------
Ran 1 test in 1.269s

OK
$ cat /tmp/lldbtest-stdout
$ 

llvm-svn: 114380

stderr so as not to disrupt the information emitted by the unittest framework.

llvm-svn: 114377

command options detailed help section (since it's sorted by short option).

llvm-svn: 114364

and have them return a bool to indicate success or not.

llvm-svn: 114361

the parent of Process settings;   add 'default-arch' as a
class-wide setting for Target.    Replace            lldb::GetDefaultArchitecture
with Target::GetDefaultArchitecture & Target::SetDefaultArchitecture.

Add 'use-external-editor' as user setting to Debugger class & update
code appropriately.

Add Error parameter to methods that get user settings, for easier
reporting of bad requests.

Fix various other minor related bugs.

Fix test cases to work with new changes.

llvm-svn: 114352

llvm-svn: 114333

llvm-svn: 114332

llvm-svn: 114330

rdar://problem/8449849

llvm-svn: 114328

llvm-svn: 114326

Add GetDescription() and __repr__ () methods to most API classes, to allow
"print" from inside Python to print out the objects in a more useful
manner.

llvm-svn: 114321

llvm-svn: 114307

replacing the "(lldb)" prompt, the "frame #1..." displays when doing
stack backtracing and the "thread #1....". This will allow you to see 
exactly the information that you want to see where you want to see it.
This currently isn't hookup up to the prompts yet, but it will be soon.

So what is the format of the prompts? Prompts can contain variables that
have access to the current program state. Variables are text that appears
in between a prefix of "${" and ends with a "}". Some of the interesting
variables include:

// The frame index (0, 1, 2, 3...)
${frame.index}

// common frame registers with generic names
${frame.pc}
${frame.sp}
${frame.fp}
${frame.ra}
${frame.flags}

// Access to any frame registers by name where REGNAME is any register name:
${frame.reg.REGNAME}

// The current compile unit file where the frame is located
${file.basename}
${file.fullpath}

// Function information
${function.name}
${function.pc-offset}

// Process info
${process.file.basename}
${process.file.fullpath}
${process.id}
${process.name}

// Thread info
${thread.id}
${thread.index}
${thread.name}
${thread.queue}
${thread.stop-reason}

// Target information
${target.arch}

// The current module for the current frame (the shared library or executable
// that contains the current frame PC value):
${module.file.basename}
${module.file.fullpath}

// Access to the line entry for where the current frame is when your thread
// is stopped:
${line.file.basename}
${line.file.fullpath}
${line.number}
${line.start-addr}
${line.end-addr}

Many times the information that you might have in your prompt might not be
available and you won't want it to print out if it isn't valid. To take care
of this you can enclose everything that must resolve into a scope. A scope
is starts with '{' and ends with '}'. For example in order to only display
the current file and line number when the information is available the format
would be:

"{ at {$line.file.basename}:${line.number}}"

Broken down this is:

start the scope: "{"

format whose content will only be displayed if all information is available:
        "at {$line.file.basename}:${line.number}"

end the scope: "}"

We currently can represent the infomration we see when stopped at a frame:

frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19

with the following format:

"frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n"

This breaks down to always print:

        "frame #${frame.index}: ${frame.pc} "

only print the module followed by a tick if we have a valid module:

        "{${module.file.basename}`}"
        
print the function name with optional offset:
        "{${function.name}{${function.pc-offset}}"

print the line info if it is available:
        
        "{ at ${line.file.basename}:${line.number}}"

then finish off with a newline:

        "\n"

Notice you can also put newlines ("\n") and tabs and everything else you
are used to putting in a format string when desensitized with the \ character.

Cleaned up some of the user settings controller subclasses. All of them 
do not have any global settings variables and were all implementing stubs
for the get/set global settings variable. Now there is a default version
in UserSettingsController that will do nothing.

llvm-svn: 114306

llvm-svn: 114305

frame variables and are not stopped in a valid frame.

llvm-svn: 114267

(lldb) frame variable --location

Where the address of variables wasn't being formatted consistently.

llvm-svn: 114266

- All single character options will now be printed together
- Changed all options that contains underscores to contain '-' instead
- Made the help come out a little flatter by showing the long and short
  option on the same line.
- Modified the short character for "--ignore-count" options to "-i"

llvm-svn: 114265

Fixed an issue with ClangASTContext::GetIndexOfChildMemberWithName() 
where objective C ivars were not being found correctly if they were
the second or higher child.

llvm-svn: 114258

accessed by the objects that own the settings. The previous approach wasn't
very usable and made for a lot of unnecessary code just to access variables
that were already owned by the objects.

While I fixed those things, I saw that CommandObject objects should really
have a reference to their command interpreter so they can access the terminal
with if they want to output usaage. Fixed up all CommandObjects to take
an interpreter and cleaned up the API to not need the interpreter to be
passed in.

Fixed the disassemble command to output the usage if no options are passed
down and arguments are passed (all disassebmle variants take options, there
are no "args only").

llvm-svn: 114252

the running of the test suite.  Right now, it doesn't do anything with the
config file.

Pass "-c myConfigFile" to specify the config file.

llvm-svn: 114245

llvm-svn: 114232