Commit Graph

12 Commits

Author SHA1 Message Date
Caroline Tice 12cecd741d Make GetInstanceSettingsValue methods take an Error * rather than an Error &,
and have them return a bool to indicate success or not.

llvm-svn: 114361
2010-09-20 21:37:42 +00:00
Caroline Tice daccaa9e83 Add UserSettings to Target class, making Target settings
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
2010-09-20 20:44:43 +00:00
Greg Clayton 1b65488229 Added code that will allow completely customizable prompts for use in
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
2010-09-19 02:33:57 +00:00
Caroline Tice 9e41c15d84 Fix issues with CreateInstanceName, a virtual function, being called
in an initializer.

llvm-svn: 114107
2010-09-16 19:05:55 +00:00
Caroline Tice 7d9edf670b Modify "settings list" so you can specify a particular instance setting name,
or a settings prefix, and it will list information about the subset of settings
you requested.  Also added tab-completion (now that it takes an optional argument).

llvm-svn: 113952
2010-09-15 06:56:39 +00:00
Caroline Tice ded2fa3991 Remove all visible uses of "[DEFAULT]" instance name.
Add ability to rename UserSettingsInstances after they have been created
(via UserSettingsController::RenameInstanceSettings.

llvm-svn: 113950
2010-09-15 05:35:14 +00:00
Caroline Tice 101c7c2060 Make all debugger-level user settable variables into instance variables.
Make get/set variable at the debugger level always set the particular debugger's instance variables rather than
the default variables.

llvm-svn: 113474
2010-09-09 06:25:08 +00:00
Caroline Tice 91123da2d1 Make sure creating a pending instance doesn't also trigger creating a live instance; also make sure creating a
pending instance uses the specified instance name rather than creating a new one; add brackets to instance names
when searching for and removing pending instances.

llvm-svn: 113370
2010-09-08 17:48:55 +00:00
Jim Ingham a767c9a3ae The settings mutexes get used recursively, and deadlock if they are normal mutexes.
llvm-svn: 113309
2010-09-07 23:31:30 +00:00
Jim Ingham 95852755a8 Move common code from GetSettingsController in Process & Debugger into static functions
in UserSettingsController.cpp.

llvm-svn: 113268
2010-09-07 20:27:09 +00:00
Caroline Tice 49e2737eb4 Fix various minor bugs in the Settings stuff.
llvm-svn: 113245
2010-09-07 18:35:40 +00:00
Caroline Tice 3df9a8dfd7 This is a very large commit that completely re-does the way lldb
handles user settable internal variables (the equivalent of set/show
variables in gdb).  In addition to the basic infrastructure (most of
which is defined in UserSettingsController.{h,cpp}, there are examples
of two classes that have been set up to contain user settable
variables (the Debugger and Process classes).  The 'settings' command
has been modified to be a command-subcommand structure, and the 'set',
'show' and 'append' commands have been moved into this sub-commabnd
structure.  The old StateVariable class has been completely replaced
by this, and the state variable dictionary has been removed from the
Command Interpreter.  Places that formerly accessed the state variable
mechanism have been modified to access the variables in this new
structure instead (checking the term-width; getting/checking the
prompt; etc.)

Variables are attached to classes; there are two basic "flavors" of
variables that can be set: "global" variables (static/class-wide), and
"instance" variables (one per instance of the class).  The whole thing
has been set up so that any global or instance variable can be set at
any time (e.g. on start up, in your .lldbinit file), whether or not
any instances actually exist (there's a whole pending and default
values mechanism to help deal with that).

llvm-svn: 113041
2010-09-04 00:03:46 +00:00