2010-06-09 00:52:24 +08:00
//===-- CommandObject.cpp ---------------------------------------*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
# include "lldb/Interpreter/CommandObject.h"
# include <string>
# include <map>
# include <getopt.h>
# include <stdlib.h>
# include <ctype.h>
# include "lldb/Core/Address.h"
2010-06-16 03:49:27 +08:00
# include "lldb/Interpreter/Options.h"
2010-06-09 00:52:24 +08:00
// These are for the Sourcename completers.
// FIXME: Make a separate file for the completers.
2011-02-08 13:05:52 +08:00
# include "lldb/Host/FileSpec.h"
2010-06-09 00:52:24 +08:00
# include "lldb/Core/FileSpecList.h"
# include "lldb/Target/Process.h"
# include "lldb/Target/Target.h"
# include "lldb/Interpreter/CommandInterpreter.h"
# include "lldb/Interpreter/CommandReturnObject.h"
# include "lldb/Interpreter/ScriptInterpreter.h"
# include "lldb/Interpreter/ScriptInterpreterPython.h"
using namespace lldb ;
using namespace lldb_private ;
//-------------------------------------------------------------------------
// CommandObject
//-------------------------------------------------------------------------
2010-09-18 09:14:36 +08:00
CommandObject : : CommandObject
(
CommandInterpreter & interpreter ,
const char * name ,
const char * help ,
const char * syntax ,
uint32_t flags
) :
m_interpreter ( interpreter ) ,
2010-06-09 00:52:24 +08:00
m_cmd_name ( name ) ,
m_cmd_help_short ( ) ,
m_cmd_help_long ( ) ,
m_cmd_syntax ( ) ,
2010-07-07 06:46:59 +08:00
m_is_alias ( false ) ,
Add infrastructure for standardizing arguments for commands and
command options; makes it easier to ensure that the same type of
argument will have the same name everywhere, hooks up help for command
arguments, so that users can ask for help when they are confused about
what an argument should be; puts in the beginnings of the ability to
do tab-completion for certain types of arguments, allows automatic
syntax help generation for commands with arguments, and adds command
arguments into command options help correctly.
Currently only the breakpoint-id and breakpoint-id-range arguments, in
the breakpoint commands, have been hooked up to use the new mechanism.
The next steps will be to fix the command options arguments to use
this mechanism, and to fix the rest of the regular command arguments
to use this mechanism. Most of the help text is currently missing or
dummy text; this will need to be filled in, and the existing argument
help text will need to be cleaned up a bit (it was thrown in quickly,
mostly for testing purposes).
Help command now works for all argument types, although the help may not
be very helpful yet.
Those commands that take "raw" command strings now indicate it in their
help text.
llvm-svn: 115318
2010-10-02 01:46:38 +08:00
m_flags ( flags ) ,
m_arguments ( )
2010-06-09 00:52:24 +08:00
{
if ( help & & help [ 0 ] )
m_cmd_help_short = help ;
if ( syntax & & syntax [ 0 ] )
m_cmd_syntax = syntax ;
}
CommandObject : : ~ CommandObject ( )
{
}
const char *
CommandObject : : GetHelp ( )
{
return m_cmd_help_short . c_str ( ) ;
}
const char *
CommandObject : : GetHelpLong ( )
{
return m_cmd_help_long . c_str ( ) ;
}
const char *
CommandObject : : GetSyntax ( )
{
Add infrastructure for standardizing arguments for commands and
command options; makes it easier to ensure that the same type of
argument will have the same name everywhere, hooks up help for command
arguments, so that users can ask for help when they are confused about
what an argument should be; puts in the beginnings of the ability to
do tab-completion for certain types of arguments, allows automatic
syntax help generation for commands with arguments, and adds command
arguments into command options help correctly.
Currently only the breakpoint-id and breakpoint-id-range arguments, in
the breakpoint commands, have been hooked up to use the new mechanism.
The next steps will be to fix the command options arguments to use
this mechanism, and to fix the rest of the regular command arguments
to use this mechanism. Most of the help text is currently missing or
dummy text; this will need to be filled in, and the existing argument
help text will need to be cleaned up a bit (it was thrown in quickly,
mostly for testing purposes).
Help command now works for all argument types, although the help may not
be very helpful yet.
Those commands that take "raw" command strings now indicate it in their
help text.
llvm-svn: 115318
2010-10-02 01:46:38 +08:00
if ( m_cmd_syntax . length ( ) = = 0 )
{
StreamString syntax_str ;
syntax_str . Printf ( " %s " , GetCommandName ( ) ) ;
if ( GetOptions ( ) ! = NULL )
2010-10-05 06:28:36 +08:00
syntax_str . Printf ( " <cmd-options> " ) ;
Add infrastructure for standardizing arguments for commands and
command options; makes it easier to ensure that the same type of
argument will have the same name everywhere, hooks up help for command
arguments, so that users can ask for help when they are confused about
what an argument should be; puts in the beginnings of the ability to
do tab-completion for certain types of arguments, allows automatic
syntax help generation for commands with arguments, and adds command
arguments into command options help correctly.
Currently only the breakpoint-id and breakpoint-id-range arguments, in
the breakpoint commands, have been hooked up to use the new mechanism.
The next steps will be to fix the command options arguments to use
this mechanism, and to fix the rest of the regular command arguments
to use this mechanism. Most of the help text is currently missing or
dummy text; this will need to be filled in, and the existing argument
help text will need to be cleaned up a bit (it was thrown in quickly,
mostly for testing purposes).
Help command now works for all argument types, although the help may not
be very helpful yet.
Those commands that take "raw" command strings now indicate it in their
help text.
llvm-svn: 115318
2010-10-02 01:46:38 +08:00
if ( m_arguments . size ( ) > 0 )
{
syntax_str . Printf ( " " ) ;
GetFormattedCommandArguments ( syntax_str ) ;
}
m_cmd_syntax = syntax_str . GetData ( ) ;
}
2010-06-09 00:52:24 +08:00
return m_cmd_syntax . c_str ( ) ;
}
const char *
CommandObject : : Translate ( )
{
//return m_cmd_func_name.c_str();
return " This function is currently not implemented. " ;
}
const char *
CommandObject : : GetCommandName ( )
{
return m_cmd_name . c_str ( ) ;
}
void
CommandObject : : SetCommandName ( const char * name )
{
m_cmd_name = name ;
}
void
CommandObject : : SetHelp ( const char * cstr )
{
m_cmd_help_short = cstr ;
}
void
CommandObject : : SetHelpLong ( const char * cstr )
{
m_cmd_help_long = cstr ;
}
2011-08-17 09:30:04 +08:00
void
CommandObject : : SetHelpLong ( std : : string str )
{
m_cmd_help_long = str ;
}
2010-06-09 00:52:24 +08:00
void
CommandObject : : SetSyntax ( const char * cstr )
{
m_cmd_syntax = cstr ;
}
Options *
CommandObject : : GetOptions ( )
{
// By default commands don't have options unless this virtual function
// is overridden by base classes.
return NULL ;
}
Flags &
CommandObject : : GetFlags ( )
{
return m_flags ;
}
const Flags &
CommandObject : : GetFlags ( ) const
{
return m_flags ;
}
bool
CommandObject : : ExecuteCommandString
(
const char * command_line ,
CommandReturnObject & result
)
{
Args command_args ( command_line ) ;
2010-09-18 09:14:36 +08:00
return ExecuteWithOptions ( command_args , result ) ;
2010-06-09 00:52:24 +08:00
}
bool
CommandObject : : ParseOptions
(
Args & args ,
CommandReturnObject & result
)
{
// See if the subclass has options?
Options * options = GetOptions ( ) ;
if ( options ! = NULL )
{
Error error ;
2011-04-13 08:18:08 +08:00
options - > NotifyOptionParsingStarting ( ) ;
2010-06-09 00:52:24 +08:00
// ParseOptions calls getopt_long, which always skips the zero'th item in the array and starts at position 1,
// so we need to push a dummy value into position zero.
args . Unshift ( " dummy_string " ) ;
error = args . ParseOptions ( * options ) ;
// The "dummy_string" will have already been removed by ParseOptions,
// so no need to remove it.
2011-04-13 08:18:08 +08:00
if ( error . Success ( ) )
error = options - > NotifyOptionParsingFinished ( ) ;
if ( error . Success ( ) )
{
if ( options - > VerifyOptions ( result ) )
return true ;
}
else
2010-06-09 00:52:24 +08:00
{
const char * error_cstr = error . AsCString ( ) ;
if ( error_cstr )
{
// We got an error string, lets use that
result . GetErrorStream ( ) . PutCString ( error_cstr ) ;
}
else
{
// No error string, output the usage information into result
2011-04-08 06:46:35 +08:00
options - > GenerateOptionUsage ( result . GetErrorStream ( ) , this ) ;
2010-06-09 00:52:24 +08:00
}
}
2011-04-13 08:18:08 +08:00
result . SetStatus ( eReturnStatusFailed ) ;
return false ;
2010-06-09 00:52:24 +08:00
}
return true ;
}
bool
2010-09-18 09:14:36 +08:00
CommandObject : : ExecuteWithOptions ( Args & args , CommandReturnObject & result )
2010-06-09 00:52:24 +08:00
{
for ( size_t i = 0 ; i < args . GetArgumentCount ( ) ; + + i )
{
const char * tmp_str = args . GetArgumentAtIndex ( i ) ;
if ( tmp_str [ 0 ] = = ' ` ' ) // back-quote
2010-09-18 09:14:36 +08:00
args . ReplaceArgumentAtIndex ( i , m_interpreter . ProcessEmbeddedScriptCommands ( tmp_str ) ) ;
2010-06-09 00:52:24 +08:00
}
2011-02-04 09:58:07 +08:00
if ( GetFlags ( ) . AnySet ( CommandObject : : eFlagProcessMustBeLaunched | CommandObject : : eFlagProcessMustBePaused ) )
2010-06-09 00:52:24 +08:00
{
2011-09-22 12:58:26 +08:00
Process * process = m_interpreter . GetExecutionContext ( ) . GetProcessPtr ( ) ;
2011-02-04 09:58:07 +08:00
if ( process = = NULL )
2010-06-09 00:52:24 +08:00
{
2011-07-09 08:55:34 +08:00
// A process that is not running is considered paused.
if ( GetFlags ( ) . Test ( CommandObject : : eFlagProcessMustBeLaunched ) )
{
result . AppendError ( " Process must exist. " ) ;
result . SetStatus ( eReturnStatusFailed ) ;
return false ;
}
2010-06-09 00:52:24 +08:00
}
2011-02-04 09:58:07 +08:00
else
2010-06-09 00:52:24 +08:00
{
2011-02-04 09:58:07 +08:00
StateType state = process - > GetState ( ) ;
switch ( state )
2010-06-09 00:52:24 +08:00
{
2011-03-20 12:57:14 +08:00
case eStateInvalid :
2011-02-04 09:58:07 +08:00
case eStateSuspended :
case eStateCrashed :
case eStateStopped :
break ;
case eStateConnected :
case eStateAttaching :
case eStateLaunching :
case eStateDetached :
case eStateExited :
case eStateUnloaded :
if ( GetFlags ( ) . Test ( CommandObject : : eFlagProcessMustBeLaunched ) )
{
result . AppendError ( " Process must be launched. " ) ;
result . SetStatus ( eReturnStatusFailed ) ;
return false ;
}
break ;
case eStateRunning :
case eStateStepping :
if ( GetFlags ( ) . Test ( CommandObject : : eFlagProcessMustBePaused ) )
{
result . AppendError ( " Process is running. Use 'process interrupt' to pause execution. " ) ;
result . SetStatus ( eReturnStatusFailed ) ;
return false ;
}
2010-06-09 00:52:24 +08:00
}
}
}
2010-09-18 09:14:36 +08:00
if ( ! ParseOptions ( args , result ) )
2010-06-09 00:52:24 +08:00
return false ;
// Call the command-specific version of 'Execute', passing it the already processed arguments.
2010-09-18 09:14:36 +08:00
return Execute ( args , result ) ;
2010-06-09 00:52:24 +08:00
}
class CommandDictCommandPartialMatch
{
public :
CommandDictCommandPartialMatch ( const char * match_str )
{
m_match_str = match_str ;
}
bool operator ( ) ( const std : : pair < std : : string , lldb : : CommandObjectSP > map_element ) const
{
// A NULL or empty string matches everything.
if ( m_match_str = = NULL | | * m_match_str = = ' \0 ' )
return 1 ;
size_t found = map_element . first . find ( m_match_str , 0 ) ;
if ( found = = std : : string : : npos )
return 0 ;
else
return found = = 0 ;
}
private :
const char * m_match_str ;
} ;
int
CommandObject : : AddNamesMatchingPartialString ( CommandObject : : CommandMap & in_map , const char * cmd_str ,
StringList & matches )
{
int number_added = 0 ;
CommandDictCommandPartialMatch matcher ( cmd_str ) ;
CommandObject : : CommandMap : : iterator matching_cmds = std : : find_if ( in_map . begin ( ) , in_map . end ( ) , matcher ) ;
while ( matching_cmds ! = in_map . end ( ) )
{
+ + number_added ;
matches . AppendString ( ( * matching_cmds ) . first . c_str ( ) ) ;
matching_cmds = std : : find_if ( + + matching_cmds , in_map . end ( ) , matcher ) ; ;
}
return number_added ;
}
int
CommandObject : : HandleCompletion
(
Args & input ,
int & cursor_index ,
int & cursor_char_position ,
int match_start_point ,
int max_return_elements ,
2010-06-30 13:02:46 +08:00
bool & word_complete ,
2010-06-09 00:52:24 +08:00
StringList & matches
)
{
if ( WantsRawCommandString ( ) )
{
// FIXME: Abstract telling the completion to insert the completion character.
matches . Clear ( ) ;
return - 1 ;
}
else
{
// Can we do anything generic with the options?
Options * cur_options = GetOptions ( ) ;
CommandReturnObject result ;
OptionElementVector opt_element_vector ;
if ( cur_options ! = NULL )
{
// Re-insert the dummy command name string which will have been
// stripped off:
input . Unshift ( " dummy-string " ) ;
cursor_index + + ;
// I stick an element on the end of the input, because if the last element is
// option that requires an argument, getopt_long will freak out.
input . AppendArgument ( " <FAKE-VALUE> " ) ;
2010-06-25 04:31:04 +08:00
input . ParseArgsForCompletion ( * cur_options , opt_element_vector , cursor_index ) ;
2010-06-09 00:52:24 +08:00
input . DeleteArgumentAtIndex ( input . GetArgumentCount ( ) - 1 ) ;
bool handled_by_options ;
2011-04-08 06:46:35 +08:00
handled_by_options = cur_options - > HandleOptionCompletion ( input ,
2010-06-23 09:19:29 +08:00
opt_element_vector ,
cursor_index ,
cursor_char_position ,
match_start_point ,
max_return_elements ,
2010-06-30 13:02:46 +08:00
word_complete ,
2010-06-23 09:19:29 +08:00
matches ) ;
2010-06-09 00:52:24 +08:00
if ( handled_by_options )
return matches . GetSize ( ) ;
}
// If we got here, the last word is not an option or an option argument.
2010-09-18 09:14:36 +08:00
return HandleArgumentCompletion ( input ,
2010-06-23 09:19:29 +08:00
cursor_index ,
cursor_char_position ,
opt_element_vector ,
match_start_point ,
max_return_elements ,
2010-06-30 13:02:46 +08:00
word_complete ,
2010-06-23 09:19:29 +08:00
matches ) ;
2010-06-09 00:52:24 +08:00
}
}
bool
2010-09-18 09:14:36 +08:00
CommandObject : : HelpTextContainsWord ( const char * search_word )
2010-06-09 00:52:24 +08:00
{
const char * short_help ;
const char * long_help ;
const char * syntax_help ;
std : : string options_usage_help ;
bool found_word = false ;
short_help = GetHelp ( ) ;
long_help = GetHelpLong ( ) ;
syntax_help = GetSyntax ( ) ;
2010-10-13 06:16:53 +08:00
if ( strcasestr ( short_help , search_word ) )
2010-06-09 00:52:24 +08:00
found_word = true ;
2010-10-13 06:16:53 +08:00
else if ( strcasestr ( long_help , search_word ) )
2010-06-09 00:52:24 +08:00
found_word = true ;
2010-10-13 06:16:53 +08:00
else if ( strcasestr ( syntax_help , search_word ) )
2010-06-09 00:52:24 +08:00
found_word = true ;
if ( ! found_word
& & GetOptions ( ) ! = NULL )
{
StreamString usage_help ;
2011-04-08 06:46:35 +08:00
GetOptions ( ) - > GenerateOptionUsage ( usage_help , this ) ;
2010-06-09 00:52:24 +08:00
if ( usage_help . GetSize ( ) > 0 )
{
const char * usage_text = usage_help . GetData ( ) ;
2010-10-13 06:16:53 +08:00
if ( strcasestr ( usage_text , search_word ) )
2010-06-09 00:52:24 +08:00
found_word = true ;
}
}
return found_word ;
}
Add infrastructure for standardizing arguments for commands and
command options; makes it easier to ensure that the same type of
argument will have the same name everywhere, hooks up help for command
arguments, so that users can ask for help when they are confused about
what an argument should be; puts in the beginnings of the ability to
do tab-completion for certain types of arguments, allows automatic
syntax help generation for commands with arguments, and adds command
arguments into command options help correctly.
Currently only the breakpoint-id and breakpoint-id-range arguments, in
the breakpoint commands, have been hooked up to use the new mechanism.
The next steps will be to fix the command options arguments to use
this mechanism, and to fix the rest of the regular command arguments
to use this mechanism. Most of the help text is currently missing or
dummy text; this will need to be filled in, and the existing argument
help text will need to be cleaned up a bit (it was thrown in quickly,
mostly for testing purposes).
Help command now works for all argument types, although the help may not
be very helpful yet.
Those commands that take "raw" command strings now indicate it in their
help text.
llvm-svn: 115318
2010-10-02 01:46:38 +08:00
int
CommandObject : : GetNumArgumentEntries ( )
{
return m_arguments . size ( ) ;
}
CommandObject : : CommandArgumentEntry *
CommandObject : : GetArgumentEntryAtIndex ( int idx )
{
if ( idx < m_arguments . size ( ) )
return & ( m_arguments [ idx ] ) ;
return NULL ;
}
CommandObject : : ArgumentTableEntry *
CommandObject : : FindArgumentDataByType ( CommandArgumentType arg_type )
{
const ArgumentTableEntry * table = CommandObject : : GetArgumentTable ( ) ;
for ( int i = 0 ; i < eArgTypeLastArg ; + + i )
if ( table [ i ] . arg_type = = arg_type )
return ( ArgumentTableEntry * ) & ( table [ i ] ) ;
return NULL ;
}
void
CommandObject : : GetArgumentHelp ( Stream & str , CommandArgumentType arg_type , CommandInterpreter & interpreter )
{
const ArgumentTableEntry * table = CommandObject : : GetArgumentTable ( ) ;
ArgumentTableEntry * entry = ( ArgumentTableEntry * ) & ( table [ arg_type ] ) ;
// The table is *supposed* to be kept in arg_type order, but someone *could* have messed it up...
if ( entry - > arg_type ! = arg_type )
entry = CommandObject : : FindArgumentDataByType ( arg_type ) ;
if ( ! entry )
return ;
StreamString name_str ;
name_str . Printf ( " <%s> " , entry - > arg_name ) ;
2011-07-08 10:51:01 +08:00
if ( entry - > help_function )
2011-07-07 08:38:40 +08:00
{
2011-07-08 10:51:01 +08:00
const char * help_text = entry - > help_function ( ) ;
2011-07-07 08:38:40 +08:00
if ( ! entry - > help_function . self_formatting )
{
interpreter . OutputFormattedHelpText ( str , name_str . GetData ( ) , " -- " , help_text ,
name_str . GetSize ( ) ) ;
}
else
{
interpreter . OutputHelpText ( str , name_str . GetData ( ) , " -- " , help_text ,
name_str . GetSize ( ) ) ;
}
}
Add infrastructure for standardizing arguments for commands and
command options; makes it easier to ensure that the same type of
argument will have the same name everywhere, hooks up help for command
arguments, so that users can ask for help when they are confused about
what an argument should be; puts in the beginnings of the ability to
do tab-completion for certain types of arguments, allows automatic
syntax help generation for commands with arguments, and adds command
arguments into command options help correctly.
Currently only the breakpoint-id and breakpoint-id-range arguments, in
the breakpoint commands, have been hooked up to use the new mechanism.
The next steps will be to fix the command options arguments to use
this mechanism, and to fix the rest of the regular command arguments
to use this mechanism. Most of the help text is currently missing or
dummy text; this will need to be filled in, and the existing argument
help text will need to be cleaned up a bit (it was thrown in quickly,
mostly for testing purposes).
Help command now works for all argument types, although the help may not
be very helpful yet.
Those commands that take "raw" command strings now indicate it in their
help text.
llvm-svn: 115318
2010-10-02 01:46:38 +08:00
else
interpreter . OutputFormattedHelpText ( str , name_str . GetData ( ) , " -- " , entry - > help_text , name_str . GetSize ( ) ) ;
}
const char *
CommandObject : : GetArgumentName ( CommandArgumentType arg_type )
{
2010-10-02 03:59:14 +08:00
ArgumentTableEntry * entry = ( ArgumentTableEntry * ) & ( CommandObject : : GetArgumentTable ( ) [ arg_type ] ) ;
// The table is *supposed* to be kept in arg_type order, but someone *could* have messed it up...
if ( entry - > arg_type ! = arg_type )
entry = CommandObject : : FindArgumentDataByType ( arg_type ) ;
2010-10-09 06:01:52 +08:00
if ( entry )
return entry - > arg_name ;
StreamString str ;
str < < " Arg name for type ( " < < arg_type < < " ) not in arg table! " ;
return str . GetData ( ) ;
Add infrastructure for standardizing arguments for commands and
command options; makes it easier to ensure that the same type of
argument will have the same name everywhere, hooks up help for command
arguments, so that users can ask for help when they are confused about
what an argument should be; puts in the beginnings of the ability to
do tab-completion for certain types of arguments, allows automatic
syntax help generation for commands with arguments, and adds command
arguments into command options help correctly.
Currently only the breakpoint-id and breakpoint-id-range arguments, in
the breakpoint commands, have been hooked up to use the new mechanism.
The next steps will be to fix the command options arguments to use
this mechanism, and to fix the rest of the regular command arguments
to use this mechanism. Most of the help text is currently missing or
dummy text; this will need to be filled in, and the existing argument
help text will need to be cleaned up a bit (it was thrown in quickly,
mostly for testing purposes).
Help command now works for all argument types, although the help may not
be very helpful yet.
Those commands that take "raw" command strings now indicate it in their
help text.
llvm-svn: 115318
2010-10-02 01:46:38 +08:00
}
2010-10-05 06:28:36 +08:00
bool
2011-03-25 05:19:54 +08:00
CommandObject : : IsPairType ( ArgumentRepetitionType arg_repeat_type )
2010-10-05 06:28:36 +08:00
{
if ( ( arg_repeat_type = = eArgRepeatPairPlain )
| | ( arg_repeat_type = = eArgRepeatPairOptional )
| | ( arg_repeat_type = = eArgRepeatPairPlus )
| | ( arg_repeat_type = = eArgRepeatPairStar )
| | ( arg_repeat_type = = eArgRepeatPairRange )
| | ( arg_repeat_type = = eArgRepeatPairRangeOptional ) )
return true ;
return false ;
}
Add infrastructure for standardizing arguments for commands and
command options; makes it easier to ensure that the same type of
argument will have the same name everywhere, hooks up help for command
arguments, so that users can ask for help when they are confused about
what an argument should be; puts in the beginnings of the ability to
do tab-completion for certain types of arguments, allows automatic
syntax help generation for commands with arguments, and adds command
arguments into command options help correctly.
Currently only the breakpoint-id and breakpoint-id-range arguments, in
the breakpoint commands, have been hooked up to use the new mechanism.
The next steps will be to fix the command options arguments to use
this mechanism, and to fix the rest of the regular command arguments
to use this mechanism. Most of the help text is currently missing or
dummy text; this will need to be filled in, and the existing argument
help text will need to be cleaned up a bit (it was thrown in quickly,
mostly for testing purposes).
Help command now works for all argument types, although the help may not
be very helpful yet.
Those commands that take "raw" command strings now indicate it in their
help text.
llvm-svn: 115318
2010-10-02 01:46:38 +08:00
void
CommandObject : : GetFormattedCommandArguments ( Stream & str )
{
int num_args = m_arguments . size ( ) ;
for ( int i = 0 ; i < num_args ; + + i )
{
if ( i > 0 )
str . Printf ( " " ) ;
CommandArgumentEntry arg_entry = m_arguments [ i ] ;
int num_alternatives = arg_entry . size ( ) ;
2010-10-05 06:28:36 +08:00
if ( ( num_alternatives = = 2 )
& & IsPairType ( arg_entry [ 0 ] . arg_repetition ) )
Add infrastructure for standardizing arguments for commands and
command options; makes it easier to ensure that the same type of
argument will have the same name everywhere, hooks up help for command
arguments, so that users can ask for help when they are confused about
what an argument should be; puts in the beginnings of the ability to
do tab-completion for certain types of arguments, allows automatic
syntax help generation for commands with arguments, and adds command
arguments into command options help correctly.
Currently only the breakpoint-id and breakpoint-id-range arguments, in
the breakpoint commands, have been hooked up to use the new mechanism.
The next steps will be to fix the command options arguments to use
this mechanism, and to fix the rest of the regular command arguments
to use this mechanism. Most of the help text is currently missing or
dummy text; this will need to be filled in, and the existing argument
help text will need to be cleaned up a bit (it was thrown in quickly,
mostly for testing purposes).
Help command now works for all argument types, although the help may not
be very helpful yet.
Those commands that take "raw" command strings now indicate it in their
help text.
llvm-svn: 115318
2010-10-02 01:46:38 +08:00
{
2010-10-05 06:28:36 +08:00
const char * first_name = GetArgumentName ( arg_entry [ 0 ] . arg_type ) ;
const char * second_name = GetArgumentName ( arg_entry [ 1 ] . arg_type ) ;
switch ( arg_entry [ 0 ] . arg_repetition )
{
case eArgRepeatPairPlain :
str . Printf ( " <%s> <%s> " , first_name , second_name ) ;
break ;
case eArgRepeatPairOptional :
str . Printf ( " [<%s> <%s>] " , first_name , second_name ) ;
break ;
case eArgRepeatPairPlus :
str . Printf ( " <%s> <%s> [<%s> <%s> [...]] " , first_name , second_name , first_name , second_name ) ;
break ;
case eArgRepeatPairStar :
str . Printf ( " [<%s> <%s> [<%s> <%s> [...]]] " , first_name , second_name , first_name , second_name ) ;
break ;
case eArgRepeatPairRange :
str . Printf ( " <%s_1> <%s_1> ... <%s_n> <%s_n> " , first_name , second_name , first_name , second_name ) ;
break ;
case eArgRepeatPairRangeOptional :
str . Printf ( " [<%s_1> <%s_1> ... <%s_n> <%s_n>] " , first_name , second_name , first_name , second_name ) ;
break ;
2011-03-24 06:31:13 +08:00
// Explicitly test for all the rest of the cases, so if new types get added we will notice the
// missing case statement(s).
case eArgRepeatPlain :
case eArgRepeatOptional :
case eArgRepeatPlus :
case eArgRepeatStar :
case eArgRepeatRange :
// These should not be reached, as they should fail the IsPairType test above.
break ;
2010-10-05 06:28:36 +08:00
}
Add infrastructure for standardizing arguments for commands and
command options; makes it easier to ensure that the same type of
argument will have the same name everywhere, hooks up help for command
arguments, so that users can ask for help when they are confused about
what an argument should be; puts in the beginnings of the ability to
do tab-completion for certain types of arguments, allows automatic
syntax help generation for commands with arguments, and adds command
arguments into command options help correctly.
Currently only the breakpoint-id and breakpoint-id-range arguments, in
the breakpoint commands, have been hooked up to use the new mechanism.
The next steps will be to fix the command options arguments to use
this mechanism, and to fix the rest of the regular command arguments
to use this mechanism. Most of the help text is currently missing or
dummy text; this will need to be filled in, and the existing argument
help text will need to be cleaned up a bit (it was thrown in quickly,
mostly for testing purposes).
Help command now works for all argument types, although the help may not
be very helpful yet.
Those commands that take "raw" command strings now indicate it in their
help text.
llvm-svn: 115318
2010-10-02 01:46:38 +08:00
}
2010-10-05 06:28:36 +08:00
else
Add infrastructure for standardizing arguments for commands and
command options; makes it easier to ensure that the same type of
argument will have the same name everywhere, hooks up help for command
arguments, so that users can ask for help when they are confused about
what an argument should be; puts in the beginnings of the ability to
do tab-completion for certain types of arguments, allows automatic
syntax help generation for commands with arguments, and adds command
arguments into command options help correctly.
Currently only the breakpoint-id and breakpoint-id-range arguments, in
the breakpoint commands, have been hooked up to use the new mechanism.
The next steps will be to fix the command options arguments to use
this mechanism, and to fix the rest of the regular command arguments
to use this mechanism. Most of the help text is currently missing or
dummy text; this will need to be filled in, and the existing argument
help text will need to be cleaned up a bit (it was thrown in quickly,
mostly for testing purposes).
Help command now works for all argument types, although the help may not
be very helpful yet.
Those commands that take "raw" command strings now indicate it in their
help text.
llvm-svn: 115318
2010-10-02 01:46:38 +08:00
{
2010-10-05 06:28:36 +08:00
StreamString names ;
for ( int j = 0 ; j < num_alternatives ; + + j )
{
if ( j > 0 )
names . Printf ( " | " ) ;
names . Printf ( " %s " , GetArgumentName ( arg_entry [ j ] . arg_type ) ) ;
}
switch ( arg_entry [ 0 ] . arg_repetition )
{
case eArgRepeatPlain :
str . Printf ( " <%s> " , names . GetData ( ) ) ;
break ;
case eArgRepeatPlus :
str . Printf ( " <%s> [<%s> [...]] " , names . GetData ( ) , names . GetData ( ) ) ;
break ;
case eArgRepeatStar :
str . Printf ( " [<%s> [<%s> [...]]] " , names . GetData ( ) , names . GetData ( ) ) ;
break ;
case eArgRepeatOptional :
str . Printf ( " [<%s>] " , names . GetData ( ) ) ;
break ;
case eArgRepeatRange :
2011-09-21 05:44:10 +08:00
str . Printf ( " <%s_1> .. <%s_n> " , names . GetData ( ) , names . GetData ( ) ) ;
2011-03-24 06:31:13 +08:00
break ;
// Explicitly test for all the rest of the cases, so if new types get added we will notice the
// missing case statement(s).
case eArgRepeatPairPlain :
case eArgRepeatPairOptional :
case eArgRepeatPairPlus :
case eArgRepeatPairStar :
case eArgRepeatPairRange :
case eArgRepeatPairRangeOptional :
// These should not be hit, as they should pass the IsPairType test above, and control should
// have gone into the other branch of the if statement.
break ;
2010-10-05 06:28:36 +08:00
}
Add infrastructure for standardizing arguments for commands and
command options; makes it easier to ensure that the same type of
argument will have the same name everywhere, hooks up help for command
arguments, so that users can ask for help when they are confused about
what an argument should be; puts in the beginnings of the ability to
do tab-completion for certain types of arguments, allows automatic
syntax help generation for commands with arguments, and adds command
arguments into command options help correctly.
Currently only the breakpoint-id and breakpoint-id-range arguments, in
the breakpoint commands, have been hooked up to use the new mechanism.
The next steps will be to fix the command options arguments to use
this mechanism, and to fix the rest of the regular command arguments
to use this mechanism. Most of the help text is currently missing or
dummy text; this will need to be filled in, and the existing argument
help text will need to be cleaned up a bit (it was thrown in quickly,
mostly for testing purposes).
Help command now works for all argument types, although the help may not
be very helpful yet.
Those commands that take "raw" command strings now indicate it in their
help text.
llvm-svn: 115318
2010-10-02 01:46:38 +08:00
}
}
}
2011-03-23 10:12:10 +08:00
CommandArgumentType
Add infrastructure for standardizing arguments for commands and
command options; makes it easier to ensure that the same type of
argument will have the same name everywhere, hooks up help for command
arguments, so that users can ask for help when they are confused about
what an argument should be; puts in the beginnings of the ability to
do tab-completion for certain types of arguments, allows automatic
syntax help generation for commands with arguments, and adds command
arguments into command options help correctly.
Currently only the breakpoint-id and breakpoint-id-range arguments, in
the breakpoint commands, have been hooked up to use the new mechanism.
The next steps will be to fix the command options arguments to use
this mechanism, and to fix the rest of the regular command arguments
to use this mechanism. Most of the help text is currently missing or
dummy text; this will need to be filled in, and the existing argument
help text will need to be cleaned up a bit (it was thrown in quickly,
mostly for testing purposes).
Help command now works for all argument types, although the help may not
be very helpful yet.
Those commands that take "raw" command strings now indicate it in their
help text.
llvm-svn: 115318
2010-10-02 01:46:38 +08:00
CommandObject : : LookupArgumentName ( const char * arg_name )
{
CommandArgumentType return_type = eArgTypeLastArg ;
std : : string arg_name_str ( arg_name ) ;
size_t len = arg_name_str . length ( ) ;
if ( arg_name [ 0 ] = = ' < '
& & arg_name [ len - 1 ] = = ' > ' )
arg_name_str = arg_name_str . substr ( 1 , len - 2 ) ;
2011-07-15 06:20:12 +08:00
const ArgumentTableEntry * table = GetArgumentTable ( ) ;
Add infrastructure for standardizing arguments for commands and
command options; makes it easier to ensure that the same type of
argument will have the same name everywhere, hooks up help for command
arguments, so that users can ask for help when they are confused about
what an argument should be; puts in the beginnings of the ability to
do tab-completion for certain types of arguments, allows automatic
syntax help generation for commands with arguments, and adds command
arguments into command options help correctly.
Currently only the breakpoint-id and breakpoint-id-range arguments, in
the breakpoint commands, have been hooked up to use the new mechanism.
The next steps will be to fix the command options arguments to use
this mechanism, and to fix the rest of the regular command arguments
to use this mechanism. Most of the help text is currently missing or
dummy text; this will need to be filled in, and the existing argument
help text will need to be cleaned up a bit (it was thrown in quickly,
mostly for testing purposes).
Help command now works for all argument types, although the help may not
be very helpful yet.
Those commands that take "raw" command strings now indicate it in their
help text.
llvm-svn: 115318
2010-10-02 01:46:38 +08:00
for ( int i = 0 ; i < eArgTypeLastArg ; + + i )
2011-07-15 06:20:12 +08:00
if ( arg_name_str . compare ( table [ i ] . arg_name ) = = 0 )
Add infrastructure for standardizing arguments for commands and
command options; makes it easier to ensure that the same type of
argument will have the same name everywhere, hooks up help for command
arguments, so that users can ask for help when they are confused about
what an argument should be; puts in the beginnings of the ability to
do tab-completion for certain types of arguments, allows automatic
syntax help generation for commands with arguments, and adds command
arguments into command options help correctly.
Currently only the breakpoint-id and breakpoint-id-range arguments, in
the breakpoint commands, have been hooked up to use the new mechanism.
The next steps will be to fix the command options arguments to use
this mechanism, and to fix the rest of the regular command arguments
to use this mechanism. Most of the help text is currently missing or
dummy text; this will need to be filled in, and the existing argument
help text will need to be cleaned up a bit (it was thrown in quickly,
mostly for testing purposes).
Help command now works for all argument types, although the help may not
be very helpful yet.
Those commands that take "raw" command strings now indicate it in their
help text.
llvm-svn: 115318
2010-10-02 01:46:38 +08:00
return_type = g_arguments_data [ i ] . arg_type ;
return return_type ;
}
static const char *
BreakpointIDHelpTextCallback ( )
{
return " Breakpoint ID's consist major and minor numbers; the major number corresponds to the single entity that was created with a 'breakpoint set' command; the minor numbers correspond to all the locations that were actually found/set based on the major breakpoint. A full breakpoint ID might look like 3.14, meaning the 14th location set for the 3rd breakpoint. You can specify all the locations of a breakpoint by just indicating the major breakpoint number. A valid breakpoint id consists either of just the major id number, or the major number, a dot, and the location number (e.g. 3 or 3.2 could both be valid breakpoint ids). " ;
}
static const char *
BreakpointIDRangeHelpTextCallback ( )
{
2010-10-05 06:28:36 +08:00
return " A 'breakpoint id list' is a manner of specifying multiple breakpoints. This can be done through several mechanisms. The easiest way is to just enter a space-separated list of breakpoint ids. To specify all the breakpoint locations under a major breakpoint, you can use the major breakpoint number followed by '.*', eg. '5.*' means all the locations under breakpoint 5. You can also indicate a range of breakpoints by using <start-bp-id> - <end-bp-id>. The start-bp-id and end-bp-id for a range can be any valid breakpoint ids. It is not legal, however, to specify a range using specific locations that cross major breakpoint numbers. I.e. 3.2 - 3.7 is legal; 2 - 5 is legal; but 3.2 - 4.4 is not legal. " ;
Add infrastructure for standardizing arguments for commands and
command options; makes it easier to ensure that the same type of
argument will have the same name everywhere, hooks up help for command
arguments, so that users can ask for help when they are confused about
what an argument should be; puts in the beginnings of the ability to
do tab-completion for certain types of arguments, allows automatic
syntax help generation for commands with arguments, and adds command
arguments into command options help correctly.
Currently only the breakpoint-id and breakpoint-id-range arguments, in
the breakpoint commands, have been hooked up to use the new mechanism.
The next steps will be to fix the command options arguments to use
this mechanism, and to fix the rest of the regular command arguments
to use this mechanism. Most of the help text is currently missing or
dummy text; this will need to be filled in, and the existing argument
help text will need to be cleaned up a bit (it was thrown in quickly,
mostly for testing purposes).
Help command now works for all argument types, although the help may not
be very helpful yet.
Those commands that take "raw" command strings now indicate it in their
help text.
llvm-svn: 115318
2010-10-02 01:46:38 +08:00
}
2011-07-02 08:25:22 +08:00
static const char *
FormatHelpTextCallback ( )
{
2011-07-07 08:38:40 +08:00
static char * help_text_ptr = NULL ;
if ( help_text_ptr )
return help_text_ptr ;
2011-07-02 08:25:22 +08:00
StreamString sstr ;
sstr < < " One of the format names (or one-character names) that can be used to show a variable's value: \n " ;
for ( Format f = eFormatDefault ; f < kNumFormats ; f = Format ( f + 1 ) )
{
2011-07-07 08:38:40 +08:00
if ( f ! = eFormatDefault )
sstr . PutChar ( ' \n ' ) ;
2011-07-02 08:25:22 +08:00
char format_char = FormatManager : : GetFormatAsFormatChar ( f ) ;
if ( format_char )
sstr . Printf ( " '%c' or " , format_char ) ;
2011-07-07 08:38:40 +08:00
sstr . Printf ( " \" %s \" " , FormatManager : : GetFormatAsCString ( f ) ) ;
2011-07-02 08:25:22 +08:00
}
sstr . Flush ( ) ;
std : : string data = sstr . GetString ( ) ;
2011-07-07 08:38:40 +08:00
help_text_ptr = new char [ data . length ( ) + 1 ] ;
2011-07-02 08:25:22 +08:00
2011-07-07 08:38:40 +08:00
data . copy ( help_text_ptr , data . length ( ) ) ;
2011-07-02 08:25:22 +08:00
2011-07-07 08:38:40 +08:00
return help_text_ptr ;
2011-07-02 08:25:22 +08:00
}
static const char *
2011-07-07 08:38:40 +08:00
SummaryStringHelpTextCallback ( )
{
return
" A summary string is a way to extract information from variables in order to present them using a summary. \n "
" Summary strings contain static text, variables, scopes and control sequences: \n "
" - Static text can be any sequence of non-special characters, i.e. anything but '{', '}', '$', or ' \\ '. \n "
" - Variables are sequences of characters beginning with ${, ending with } and that contain symbols in the format described below. \n "
" - Scopes are any sequence of text between { and }. Anything included in a scope will only appear in the output summary if there were no errors. \n "
" - Control sequences are the usual C/C++ ' \\ a', ' \\ n', ..., plus ' \\ $', ' \\ {' and ' \\ }'. \n "
" A summary string works by copying static text verbatim, turning control sequences into their character counterpart, expanding variables and trying to expand scopes. \n "
" A variable is expanded by giving it a value other than its textual representation, and the way this is done depends on what comes after the ${ marker. \n "
" The most common sequence if ${var followed by an expression path, which is the text one would type to access a member of an aggregate types, given a variable of that type "
" (e.g. if type T has a member named x, which has a member named y, and if t is of type T, the expression path would be .x.y and the way to fit that into a summary string would be "
Redesign of the interaction between Python and frozen objects:
- introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from
a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored
in frozen objects ; now such reads transparently move from host to target as required
- as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also
removed code that enabled to recognize an expression result VO as such
- introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO
representing a T* or T[], and doing dereferences transparently
in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData
- as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it
en lieu of doing the raw read itself
- introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers,
this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory)
in public layer this returns an SBData, just like GetPointeeData()
- introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData
the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any
of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values
- added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing
Solved a bug where global pointers to global variables were not dereferenced correctly for display
New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128
Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command
Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type
of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file
addresses that generate file address children UNLESS we have a live process)
Updated help text for summary-string
Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers
Edited the syntax and help for some commands to have proper argument types
llvm-svn: 139160
2011-09-07 03:20:51 +08:00
" ${var.x.y}). You can also use ${*var followed by an expression path and in that case the object referred by the path will be dereferenced before being displayed. "
" If the object is not a pointer, doing so will cause an error. For additional details on expression paths, you can type 'help expr-path'. \n "
2011-07-07 08:38:40 +08:00
" By default, summary strings attempt to display the summary for any variable they reference, and if that fails the value. If neither can be shown, nothing is displayed. "
" In a summary string, you can also use an array index [n], or a slice-like range [n-m]. This can have two different meanings depending on what kind of object the expression "
" path refers to: \n "
" - if it is a scalar type (any basic type like int, float, ...) the expression is a bitfield, i.e. the bits indicated by the indexing operator are extracted out of the number "
" and displayed as an individual variable \n "
" - if it is an array or pointer the array items indicated by the indexing operator are shown as the result of the variable. if the expression is an array, real array items are "
" printed; if it is a pointer, the pointer-as-array syntax is used to obtain the values (this means, the latter case can have no range checking) \n "
Redesign of the interaction between Python and frozen objects:
- introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from
a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored
in frozen objects ; now such reads transparently move from host to target as required
- as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also
removed code that enabled to recognize an expression result VO as such
- introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO
representing a T* or T[], and doing dereferences transparently
in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData
- as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it
en lieu of doing the raw read itself
- introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers,
this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory)
in public layer this returns an SBData, just like GetPointeeData()
- introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData
the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any
of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values
- added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing
Solved a bug where global pointers to global variables were not dereferenced correctly for display
New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128
Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command
Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type
of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file
addresses that generate file address children UNLESS we have a live process)
Updated help text for summary-string
Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers
Edited the syntax and help for some commands to have proper argument types
llvm-svn: 139160
2011-09-07 03:20:51 +08:00
" If you are trying to display an array for which the size is known, you can also use [] instead of giving an exact range. This has the effect of showing items 0 thru size - 1. \n "
" Additionally, a variable can contain an (optional) format code, as in ${var.x.y%code}, where code can be any of the valid formats described in 'help format', or one of the "
" special symbols only allowed as part of a variable: \n "
" %V: show the value of the object by default \n "
" %S: show the summary of the object by default \n "
" %@: show the runtime-provided object description (for Objective-C, it calls NSPrintForDebugger; for C/C++ it does nothing) \n "
" %L: show the location of the object (memory address or a register name) \n "
" %#: show the number of children of the object \n "
" %T: show the type of the object \n "
" Another variable that you can use in summary strings is ${svar . This sequence works exactly like ${var, including the fact that ${*svar is an allowed sequence, but uses "
" the object's synthetic children provider instead of the actual objects. For instance, if you are using STL synthetic children providers, the following summary string would "
" count the number of actual elements stored in an std::list: \n "
" type summary add -s \" ${svar%#} \" -x \" std::list< \" " ;
}
static const char *
ExprPathHelpTextCallback ( )
{
return
" An expression path is the sequence of symbols that is used in C/C++ to access a member variable of an aggregate object (class). \n "
" For instance, given a class: \n "
" class foo { \n "
" int a; \n "
" int b; . \n "
" foo* next; \n "
" }; \n "
" the expression to read item b in the item pointed to by next for foo aFoo would be aFoo.next->b. \n "
" Given that aFoo could just be any object of type foo, the string '.next->b' is the expression path, because it can be attached to any foo instance to achieve the effect. \n "
" Expression paths in LLDB include dot (.) and arrow (->) operators, and most commands using expression paths have ways to also accept the star (*) operator. \n "
" The meaning of these operators is the same as the usual one given to them by the C/C++ standards. \n "
" LLDB also has support for indexing ([ ]) in expression paths, and extends the traditional meaning of the square brackets operator to allow bitfield extraction: \n "
" for objects of native types (int, float, char, ...) saying '[n-m]' as an expression path (where n and m are any positive integers, e.g. [3-5]) causes LLDB to extract "
" bits n thru m from the value of the variable. If n == m, [n] is also allowed as a shortcut syntax. For arrays and pointers, expression paths can only contain one index "
" and the meaning of the operation is the same as the one defined by C/C++ (item extraction). Some commands extend bitfield-like syntax for arrays and pointers with the "
" meaning of array slicing (taking elements n thru m inside the array or pointed-to memory). " ;
2011-07-02 08:25:22 +08:00
}
2011-09-21 09:00:02 +08:00
void
2011-09-23 06:34:09 +08:00
CommandObject : : AddIDsArgumentData ( CommandArgumentEntry & arg , CommandArgumentType ID , CommandArgumentType IDRange )
2011-09-21 09:00:02 +08:00
{
CommandArgumentData id_arg ;
CommandArgumentData id_range_arg ;
// Create the first variant for the first (and only) argument for this command.
2011-09-23 06:34:09 +08:00
id_arg . arg_type = ID ;
2011-09-21 09:00:02 +08:00
id_arg . arg_repetition = eArgRepeatOptional ;
// Create the second variant for the first (and only) argument for this command.
2011-09-23 06:34:09 +08:00
id_range_arg . arg_type = IDRange ;
2011-09-21 09:00:02 +08:00
id_range_arg . arg_repetition = eArgRepeatOptional ;
2011-09-21 09:04:49 +08:00
// The first (and only) argument for this command could be either an id or an id_range.
2011-09-21 09:00:02 +08:00
// Push both variants into the entry for the first argument for this command.
arg . push_back ( id_arg ) ;
arg . push_back ( id_range_arg ) ;
}
2011-02-20 10:15:07 +08:00
const char *
CommandObject : : GetArgumentTypeAsCString ( const lldb : : CommandArgumentType arg_type )
{
if ( arg_type > = 0 & & arg_type < eArgTypeLastArg )
return g_arguments_data [ arg_type ] . arg_name ;
return NULL ;
}
const char *
CommandObject : : GetArgumentDescriptionAsCString ( const lldb : : CommandArgumentType arg_type )
{
if ( arg_type > = 0 & & arg_type < eArgTypeLastArg )
return g_arguments_data [ arg_type ] . help_text ;
return NULL ;
}
Add infrastructure for standardizing arguments for commands and
command options; makes it easier to ensure that the same type of
argument will have the same name everywhere, hooks up help for command
arguments, so that users can ask for help when they are confused about
what an argument should be; puts in the beginnings of the ability to
do tab-completion for certain types of arguments, allows automatic
syntax help generation for commands with arguments, and adds command
arguments into command options help correctly.
Currently only the breakpoint-id and breakpoint-id-range arguments, in
the breakpoint commands, have been hooked up to use the new mechanism.
The next steps will be to fix the command options arguments to use
this mechanism, and to fix the rest of the regular command arguments
to use this mechanism. Most of the help text is currently missing or
dummy text; this will need to be filled in, and the existing argument
help text will need to be cleaned up a bit (it was thrown in quickly,
mostly for testing purposes).
Help command now works for all argument types, although the help may not
be very helpful yet.
Those commands that take "raw" command strings now indicate it in their
help text.
llvm-svn: 115318
2010-10-02 01:46:38 +08:00
CommandObject : : ArgumentTableEntry
CommandObject : : g_arguments_data [ ] =
{
2011-07-07 23:49:54 +08:00
{ eArgTypeAddress , " address " , CommandCompletions : : eNoCompletion , { NULL , false } , " A valid address in the target program's execution space. " } ,
{ eArgTypeAliasName , " alias-name " , CommandCompletions : : eNoCompletion , { NULL , false } , " The name of an abbreviation (alias) for a debugger command. " } ,
{ eArgTypeAliasOptions , " options-for-aliased-command " , CommandCompletions : : eNoCompletion , { NULL , false } , " Command options to be used as part of an alias (abbreviation) definition. (See 'help commands alias' for more information.) " } ,
{ eArgTypeArchitecture , " arch " , CommandCompletions : : eArchitectureCompletion , { NULL , false } , " The architecture name, e.g. i386 or x86_64. " } ,
{ eArgTypeBoolean , " boolean " , CommandCompletions : : eNoCompletion , { NULL , false } , " A Boolean value: 'true' or 'false' " } ,
{ eArgTypeBreakpointID , " breakpt-id " , CommandCompletions : : eNoCompletion , { BreakpointIDHelpTextCallback , false } , NULL } ,
{ eArgTypeBreakpointIDRange , " breakpt-id-list " , CommandCompletions : : eNoCompletion , { BreakpointIDRangeHelpTextCallback , false } , NULL } ,
{ eArgTypeByteSize , " byte-size " , CommandCompletions : : eNoCompletion , { NULL , false } , " Number of bytes to use. " } ,
{ eArgTypeClassName , " class-name " , CommandCompletions : : eNoCompletion , { NULL , false } , " Then name of a class from the debug information in the program. " } ,
{ eArgTypeCommandName , " cmd-name " , CommandCompletions : : eNoCompletion , { NULL , false } , " A debugger command (may be multiple words), without any options or arguments. " } ,
{ eArgTypeCount , " count " , CommandCompletions : : eNoCompletion , { NULL , false } , " An unsigned integer. " } ,
{ eArgTypeEndAddress , " end-address " , CommandCompletions : : eNoCompletion , { NULL , false } , " Help text goes here. " } ,
{ eArgTypeExpression , " expr " , CommandCompletions : : eNoCompletion , { NULL , false } , " Help text goes here. " } ,
Redesign of the interaction between Python and frozen objects:
- introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from
a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored
in frozen objects ; now such reads transparently move from host to target as required
- as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also
removed code that enabled to recognize an expression result VO as such
- introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO
representing a T* or T[], and doing dereferences transparently
in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData
- as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it
en lieu of doing the raw read itself
- introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers,
this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory)
in public layer this returns an SBData, just like GetPointeeData()
- introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData
the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any
of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values
- added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing
Solved a bug where global pointers to global variables were not dereferenced correctly for display
New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128
Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command
Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type
of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file
addresses that generate file address children UNLESS we have a live process)
Updated help text for summary-string
Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers
Edited the syntax and help for some commands to have proper argument types
llvm-svn: 139160
2011-09-07 03:20:51 +08:00
{ eArgTypeExpressionPath , " expr-path " , CommandCompletions : : eNoCompletion , { ExprPathHelpTextCallback , true } , NULL } ,
2011-07-07 23:49:54 +08:00
{ eArgTypeExprFormat , " expression-format " , CommandCompletions : : eNoCompletion , { NULL , false } , " [ [bool|b] | [bin] | [char|c] | [oct|o] | [dec|i|d|u] | [hex|x] | [float|f] | [cstr|s] ] " } ,
{ eArgTypeFilename , " filename " , CommandCompletions : : eDiskFileCompletion , { NULL , false } , " The name of a file (can include path). " } ,
{ eArgTypeFormat , " format " , CommandCompletions : : eNoCompletion , { FormatHelpTextCallback , true } , NULL } ,
{ eArgTypeFrameIndex , " frame-index " , CommandCompletions : : eNoCompletion , { NULL , false } , " Index into a thread's list of frames. " } ,
{ eArgTypeFullName , " fullname " , CommandCompletions : : eNoCompletion , { NULL , false } , " Help text goes here. " } ,
{ eArgTypeFunctionName , " function-name " , CommandCompletions : : eNoCompletion , { NULL , false } , " The name of a function. " } ,
{ eArgTypeIndex , " index " , CommandCompletions : : eNoCompletion , { NULL , false } , " An index into a list. " } ,
{ eArgTypeLineNum , " linenum " , CommandCompletions : : eNoCompletion , { NULL , false } , " Line number in a source file. " } ,
{ eArgTypeLogCategory , " log-category " , CommandCompletions : : eNoCompletion , { NULL , false } , " The name of a category within a log channel, e.g. all (try \" log list \" to see a list of all channels and their categories. " } ,
{ eArgTypeLogChannel , " log-channel " , CommandCompletions : : eNoCompletion , { NULL , false } , " The name of a log channel, e.g. process.gdb-remote (try \" log list \" to see a list of all channels and their categories). " } ,
{ eArgTypeMethod , " method " , CommandCompletions : : eNoCompletion , { NULL , false } , " A C++ method name. " } ,
{ eArgTypeName , " name " , CommandCompletions : : eNoCompletion , { NULL , false } , " Help text goes here. " } ,
{ eArgTypeNewPathPrefix , " new-path-prefix " , CommandCompletions : : eNoCompletion , { NULL , false } , " Help text goes here. " } ,
{ eArgTypeNumLines , " num-lines " , CommandCompletions : : eNoCompletion , { NULL , false } , " The number of lines to use. " } ,
{ eArgTypeNumberPerLine , " number-per-line " , CommandCompletions : : eNoCompletion , { NULL , false } , " The number of items per line to display. " } ,
{ eArgTypeOffset , " offset " , CommandCompletions : : eNoCompletion , { NULL , false } , " Help text goes here. " } ,
{ eArgTypeOldPathPrefix , " old-path-prefix " , CommandCompletions : : eNoCompletion , { NULL , false } , " Help text goes here. " } ,
{ eArgTypeOneLiner , " one-line-command " , CommandCompletions : : eNoCompletion , { NULL , false } , " A command that is entered as a single line of text. " } ,
{ eArgTypePath , " path " , CommandCompletions : : eNoCompletion , { NULL , false } , " Help text goes here. " } ,
{ eArgTypePid , " pid " , CommandCompletions : : eNoCompletion , { NULL , false } , " The process ID number. " } ,
{ eArgTypePlugin , " plugin " , CommandCompletions : : eNoCompletion , { NULL , false } , " Help text goes here. " } ,
{ eArgTypeProcessName , " process-name " , CommandCompletions : : eNoCompletion , { NULL , false } , " The name of the process. " } ,
Redesign of the interaction between Python and frozen objects:
- introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from
a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored
in frozen objects ; now such reads transparently move from host to target as required
- as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also
removed code that enabled to recognize an expression result VO as such
- introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO
representing a T* or T[], and doing dereferences transparently
in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData
- as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it
en lieu of doing the raw read itself
- introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers,
this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory)
in public layer this returns an SBData, just like GetPointeeData()
- introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData
the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any
of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values
- added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing
Solved a bug where global pointers to global variables were not dereferenced correctly for display
New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128
Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command
Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type
of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file
addresses that generate file address children UNLESS we have a live process)
Updated help text for summary-string
Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers
Edited the syntax and help for some commands to have proper argument types
llvm-svn: 139160
2011-09-07 03:20:51 +08:00
{ eArgTypePythonClass , " python-class " , CommandCompletions : : eNoCompletion , { NULL , false } , " The name of a Python class. " } ,
{ eArgTypePythonFunction , " python-function " , CommandCompletions : : eNoCompletion , { NULL , false } , " The name of a Python function. " } ,
{ eArgTypePythonScript , " python-script " , CommandCompletions : : eNoCompletion , { NULL , false } , " Source code written in Python. " } ,
2011-07-07 23:49:54 +08:00
{ eArgTypeQueueName , " queue-name " , CommandCompletions : : eNoCompletion , { NULL , false } , " The name of the thread queue. " } ,
{ eArgTypeRegisterName , " register-name " , CommandCompletions : : eNoCompletion , { NULL , false } , " A register name. " } ,
{ eArgTypeRegularExpression , " regular-expression " , CommandCompletions : : eNoCompletion , { NULL , false } , " A regular expression. " } ,
{ eArgTypeRunArgs , " run-args " , CommandCompletions : : eNoCompletion , { NULL , false } , " Arguments to be passed to the target program when it starts executing. " } ,
{ eArgTypeRunMode , " run-mode " , CommandCompletions : : eNoCompletion , { NULL , false } , " Help text goes here. " } ,
{ eArgTypeScriptLang , " script-language " , CommandCompletions : : eNoCompletion , { NULL , false } , " The scripting language to be used for script-based commands. Currently only Python is valid. " } ,
{ eArgTypeSearchWord , " search-word " , CommandCompletions : : eNoCompletion , { NULL , false } , " The word for which you wish to search for information about. " } ,
{ eArgTypeSelector , " selector " , CommandCompletions : : eNoCompletion , { NULL , false } , " An Objective-C selector name. " } ,
{ eArgTypeSettingIndex , " setting-index " , CommandCompletions : : eNoCompletion , { NULL , false } , " An index into a settings variable that is an array (try 'settings list' to see all the possible settings variables and their types). " } ,
{ eArgTypeSettingKey , " setting-key " , CommandCompletions : : eNoCompletion , { NULL , false } , " A key into a settings variables that is a dictionary (try 'settings list' to see all the possible settings variables and their types). " } ,
{ eArgTypeSettingPrefix , " setting-prefix " , CommandCompletions : : eNoCompletion , { NULL , false } , " The name of a settable internal debugger variable up to a dot ('.'), e.g. 'target.process.' " } ,
{ eArgTypeSettingVariableName , " setting-variable-name " , CommandCompletions : : eNoCompletion , { NULL , false } , " The name of a settable internal debugger variable. Type 'settings list' to see a complete list of such variables. " } ,
{ eArgTypeShlibName , " shlib-name " , CommandCompletions : : eNoCompletion , { NULL , false } , " The name of a shared library. " } ,
{ eArgTypeSourceFile , " source-file " , CommandCompletions : : eSourceFileCompletion , { NULL , false } , " The name of a source file.. " } ,
{ eArgTypeSortOrder , " sort-order " , CommandCompletions : : eNoCompletion , { NULL , false } , " Specify a sort order when dumping lists. " } ,
{ eArgTypeStartAddress , " start-address " , CommandCompletions : : eNoCompletion , { NULL , false } , " Help text goes here. " } ,
{ eArgTypeSummaryString , " summary-string " , CommandCompletions : : eNoCompletion , { SummaryStringHelpTextCallback , true } , NULL } ,
{ eArgTypeSymbol , " symbol " , CommandCompletions : : eSymbolCompletion , { NULL , false } , " Any symbol name (function name, variable, argument, etc.) " } ,
{ eArgTypeThreadID , " thread-id " , CommandCompletions : : eNoCompletion , { NULL , false } , " Thread ID number. " } ,
{ eArgTypeThreadIndex , " thread-index " , CommandCompletions : : eNoCompletion , { NULL , false } , " Index into the process' list of threads. " } ,
{ eArgTypeThreadName , " thread-name " , CommandCompletions : : eNoCompletion , { NULL , false } , " The thread's name. " } ,
2011-07-15 06:20:12 +08:00
{ eArgTypeUnsignedInteger , " unsigned-integer " , CommandCompletions : : eNoCompletion , { NULL , false } , " An unsigned integer. " } ,
2011-07-07 23:49:54 +08:00
{ eArgTypeUnixSignal , " unix-signal " , CommandCompletions : : eNoCompletion , { NULL , false } , " A valid Unix signal name or number (e.g. SIGKILL, KILL or 9). " } ,
{ eArgTypeVarName , " variable-name " , CommandCompletions : : eNoCompletion , { NULL , false } , " The name of a variable in your program. " } ,
{ eArgTypeValue , " value " , CommandCompletions : : eNoCompletion , { NULL , false } , " A value could be anything, depending on where and how it is used. " } ,
{ eArgTypeWidth , " width " , CommandCompletions : : eNoCompletion , { NULL , false } , " Help text goes here. " } ,
{ eArgTypeNone , " none " , CommandCompletions : : eNoCompletion , { NULL , false } , " No help available for this. " } ,
2011-09-10 07:25:26 +08:00
{ eArgTypePlatform , " platform-name " , CommandCompletions : : ePlatformPluginCompletion , { NULL , false } , " The name of an installed platform plug-in . Type 'platform list' to see a complete list of installed platforms. " } ,
2011-09-23 06:34:09 +08:00
{ eArgTypeWatchpointID , " watchpt-id " , CommandCompletions : : eNoCompletion , { NULL , false } , " Watchpoint IDs are positive integers. " } ,
{ eArgTypeWatchpointIDRange , " watchpt-id-list " , CommandCompletions : : eNoCompletion , { NULL , false } , " For example, '1-3' or '1 to 3'. " } ,
2011-09-13 07:38:44 +08:00
{ eArgTypeWatchType , " watch-type " , CommandCompletions : : eNoCompletion , { NULL , false } , " Specify the type for a watchpoint. " }
Add infrastructure for standardizing arguments for commands and
command options; makes it easier to ensure that the same type of
argument will have the same name everywhere, hooks up help for command
arguments, so that users can ask for help when they are confused about
what an argument should be; puts in the beginnings of the ability to
do tab-completion for certain types of arguments, allows automatic
syntax help generation for commands with arguments, and adds command
arguments into command options help correctly.
Currently only the breakpoint-id and breakpoint-id-range arguments, in
the breakpoint commands, have been hooked up to use the new mechanism.
The next steps will be to fix the command options arguments to use
this mechanism, and to fix the rest of the regular command arguments
to use this mechanism. Most of the help text is currently missing or
dummy text; this will need to be filled in, and the existing argument
help text will need to be cleaned up a bit (it was thrown in quickly,
mostly for testing purposes).
Help command now works for all argument types, although the help may not
be very helpful yet.
Those commands that take "raw" command strings now indicate it in their
help text.
llvm-svn: 115318
2010-10-02 01:46:38 +08:00
} ;
const CommandObject : : ArgumentTableEntry *
CommandObject : : GetArgumentTable ( )
{
2011-02-20 10:15:07 +08:00
// If this assertion fires, then the table above is out of date with the CommandArgumentType enumeration
assert ( ( sizeof ( CommandObject : : g_arguments_data ) / sizeof ( CommandObject : : ArgumentTableEntry ) ) = = eArgTypeLastArg ) ;
Add infrastructure for standardizing arguments for commands and
command options; makes it easier to ensure that the same type of
argument will have the same name everywhere, hooks up help for command
arguments, so that users can ask for help when they are confused about
what an argument should be; puts in the beginnings of the ability to
do tab-completion for certain types of arguments, allows automatic
syntax help generation for commands with arguments, and adds command
arguments into command options help correctly.
Currently only the breakpoint-id and breakpoint-id-range arguments, in
the breakpoint commands, have been hooked up to use the new mechanism.
The next steps will be to fix the command options arguments to use
this mechanism, and to fix the rest of the regular command arguments
to use this mechanism. Most of the help text is currently missing or
dummy text; this will need to be filled in, and the existing argument
help text will need to be cleaned up a bit (it was thrown in quickly,
mostly for testing purposes).
Help command now works for all argument types, although the help may not
be very helpful yet.
Those commands that take "raw" command strings now indicate it in their
help text.
llvm-svn: 115318
2010-10-02 01:46:38 +08:00
return CommandObject : : g_arguments_data ;
}