[lldb][NFC] Fix all formatting errors in .cpp file headers
Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp -------------------------------------------------===//
```
However in LLDB most of our source files have arbitrary changes to this format and
these changes are spreading through LLDB as folks usually just use the existing
source files as templates for their new files (most notably the unnecessary
editor language indicator `-*- C++ -*-` is spreading and in every review
someone is pointing out that this is wrong, resulting in people pointing out that this
is done in the same way in other files).
This patch removes most of these inconsistencies including the editor language indicators,
all the different missing/additional '-' characters, files that center the file name, missing
trailing `===//` (mostly caused by clang-format breaking the line).
Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73258
2020-01-24 15:23:27 +08:00
//===-- CommandObject.cpp -------------------------------------------------===//
2010-06-09 00:52:24 +08:00
//
2019-01-19 16:50:56 +08:00
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
2010-06-09 00:52:24 +08:00
//
//===----------------------------------------------------------------------===//
# include "lldb/Interpreter/CommandObject.h"
# include <map>
2015-07-14 13:48:36 +08:00
# include <sstream>
2010-06-09 00:52:24 +08:00
# include <string>
2021-05-26 18:19:37 +08:00
# include <cctype>
# include <cstdlib>
2010-06-09 00:52:24 +08:00
# include "lldb/Core/Address.h"
2010-06-16 03:49:27 +08:00
# include "lldb/Interpreter/Options.h"
2017-11-14 00:16:33 +08:00
# include "lldb/Utility/ArchSpec.h"
2020-05-27 20:04:39 +08:00
# include "llvm/ADT/ScopeExit.h"
2010-06-09 00:52:24 +08:00
// These are for the Sourcename completers.
// FIXME: Make a separate file for the completers.
# include "lldb/Core/FileSpecList.h"
2015-03-04 07:11:11 +08:00
# include "lldb/DataFormatters/FormatManager.h"
2010-06-09 00:52:24 +08:00
# include "lldb/Target/Process.h"
# include "lldb/Target/Target.h"
2017-03-23 02:40:07 +08:00
# include "lldb/Utility/FileSpec.h"
2010-06-09 00:52:24 +08:00
2015-09-02 09:06:46 +08:00
# include "lldb/Target/Language.h"
2010-06-09 00:52:24 +08:00
# include "lldb/Interpreter/CommandInterpreter.h"
# include "lldb/Interpreter/CommandReturnObject.h"
using namespace lldb ;
using namespace lldb_private ;
// CommandObject
2020-01-29 03:23:46 +08:00
CommandObject : : CommandObject ( CommandInterpreter & interpreter ,
llvm : : StringRef name , llvm : : StringRef help ,
llvm : : StringRef syntax , uint32_t flags )
: m_interpreter ( interpreter ) , m_cmd_name ( std : : string ( name ) ) ,
2021-02-20 04:42:42 +08:00
m_flags ( flags ) , m_deprecated_command_override_callback ( nullptr ) ,
2014-04-20 08:31:37 +08:00
m_command_override_callback ( nullptr ) , m_command_override_baton ( nullptr ) {
2020-01-29 03:23:46 +08:00
m_cmd_help_short = std : : string ( help ) ;
m_cmd_syntax = std : : string ( syntax ) ;
2010-06-09 00:52:24 +08:00
}
2019-04-27 06:43:16 +08:00
Debugger & CommandObject : : GetDebugger ( ) { return m_interpreter . GetDebugger ( ) ; }
2016-11-13 04:41:02 +08:00
llvm : : StringRef CommandObject : : GetHelp ( ) { return m_cmd_help_short ; }
llvm : : StringRef CommandObject : : GetHelpLong ( ) { return m_cmd_help_long ; }
llvm : : StringRef CommandObject : : GetSyntax ( ) {
2017-07-25 06:52:39 +08:00
if ( ! m_cmd_syntax . empty ( ) )
2016-11-13 04:41:02 +08:00
return m_cmd_syntax ;
StreamString syntax_str ;
syntax_str . PutCString ( GetCommandName ( ) ) ;
if ( ! IsDashDashCommand ( ) & & GetOptions ( ) ! = nullptr )
syntax_str . PutCString ( " <cmd-options> " ) ;
if ( ! m_arguments . empty ( ) ) {
syntax_str . PutCString ( " " ) ;
if ( ! IsDashDashCommand ( ) & & WantsRawCommandString ( ) & & GetOptions ( ) & &
GetOptions ( ) - > NumCommandOptions ( ) )
syntax_str . PutCString ( " -- " ) ;
GetFormattedCommandArguments ( syntax_str ) ;
2016-09-07 04:57:50 +08:00
}
2020-01-29 03:23:46 +08:00
m_cmd_syntax = std : : string ( syntax_str . GetString ( ) ) ;
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
2016-11-13 04:41:02 +08:00
return m_cmd_syntax ;
2010-06-09 00:52:24 +08:00
}
2016-10-06 05:14:38 +08:00
llvm : : StringRef CommandObject : : GetCommandName ( ) const { return m_cmd_name ; }
2010-06-09 00:52:24 +08:00
2020-01-29 03:23:46 +08:00
void CommandObject : : SetCommandName ( llvm : : StringRef name ) {
m_cmd_name = std : : string ( name ) ;
}
2010-06-09 00:52:24 +08:00
2020-01-29 03:23:46 +08:00
void CommandObject : : SetHelp ( llvm : : StringRef str ) {
m_cmd_help_short = std : : string ( str ) ;
}
2015-03-14 06:22:28 +08:00
2020-01-29 03:23:46 +08:00
void CommandObject : : SetHelpLong ( llvm : : StringRef str ) {
m_cmd_help_long = std : : string ( str ) ;
}
2011-08-17 09:30:04 +08:00
2020-01-29 03:23:46 +08:00
void CommandObject : : SetSyntax ( llvm : : StringRef str ) {
m_cmd_syntax = std : : string ( str ) ;
}
2010-06-09 00:52:24 +08:00
Options * CommandObject : : GetOptions ( ) {
2018-05-01 00:49:04 +08:00
// By default commands don't have options unless this virtual function is
// overridden by base classes.
2014-04-20 08:31:37 +08:00
return nullptr ;
2010-06-09 00:52:24 +08:00
}
bool CommandObject : : ParseOptions ( Args & args , CommandReturnObject & result ) {
// See if the subclass has options?
Options * options = GetOptions ( ) ;
2011-04-13 08:18:08 +08:00
if ( options ! = nullptr ) {
2017-05-12 12:51:55 +08:00
Status error ;
2016-09-07 04:57:50 +08:00
2016-08-12 07:51:28 +08:00
auto exe_ctx = GetCommandInterpreter ( ) . GetExecutionContext ( ) ;
2011-04-13 08:18:08 +08:00
options - > NotifyOptionParsingStarting ( & exe_ctx ) ;
2012-06-09 05:56:10 +08:00
2016-08-12 07:51:28 +08:00
const bool require_validation = true ;
Move option parsing out of the Args class
Summary:
The args class is used in plenty of places (a lot of them in the lower lldb
layers) for representing a list of arguments, and most of these places don't
care about option parsing. Moving the option parsing out of the class removes
the largest external dependency (there are a couple more, but these are in
static functions), and brings us closer to being able to move it to the
Utility module).
The new home for these functions is the Options class, which was already used
as an argument to the parse calls, so this just inverts the dependency between
the two.
The functions are themselves are mainly just copied -- the biggest functional
change I've made to them is to avoid modifying the input Args argument (getopt
likes to permute the argument vector), as it was weird to have another class
reorder the entries in Args class. So now the functions don't modify the input
arguments, and (for those where it makes sense) return a new Args vector
instead. I've also made the addition of a "fake arg0" (required for getopt
compatibility) an implementation detail rather than a part of interface.
While doing that I noticed that ParseForCompletion function was recording the
option indexes in the shuffled vector, but then the consumer was looking up the
entries in the unshuffled one. This manifested itself as us not being able to
complete "watchpoint set variable foo --" (because getopt would move "foo" to
the end). Surprisingly all other completions (e.g. "watchpoint set variable foo
--w") were not affected by this. However, I couldn't find a comprehensive test
for command argument completion, so I consolidated the existing tests and added
a bunch of new ones.
Reviewers: davide, jingham, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D43837
llvm-svn: 327110
2018-03-09 18:39:40 +08:00
llvm : : Expected < Args > args_or = options - > Parse (
args , & exe_ctx , GetCommandInterpreter ( ) . GetPlatform ( true ) ,
require_validation ) ;
2012-06-09 05:56:10 +08:00
Move option parsing out of the Args class
Summary:
The args class is used in plenty of places (a lot of them in the lower lldb
layers) for representing a list of arguments, and most of these places don't
care about option parsing. Moving the option parsing out of the class removes
the largest external dependency (there are a couple more, but these are in
static functions), and brings us closer to being able to move it to the
Utility module).
The new home for these functions is the Options class, which was already used
as an argument to the parse calls, so this just inverts the dependency between
the two.
The functions are themselves are mainly just copied -- the biggest functional
change I've made to them is to avoid modifying the input Args argument (getopt
likes to permute the argument vector), as it was weird to have another class
reorder the entries in Args class. So now the functions don't modify the input
arguments, and (for those where it makes sense) return a new Args vector
instead. I've also made the addition of a "fake arg0" (required for getopt
compatibility) an implementation detail rather than a part of interface.
While doing that I noticed that ParseForCompletion function was recording the
option indexes in the shuffled vector, but then the consumer was looking up the
entries in the unshuffled one. This manifested itself as us not being able to
complete "watchpoint set variable foo --" (because getopt would move "foo" to
the end). Surprisingly all other completions (e.g. "watchpoint set variable foo
--w") were not affected by this. However, I couldn't find a comprehensive test
for command argument completion, so I consolidated the existing tests and added
a bunch of new ones.
Reviewers: davide, jingham, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D43837
llvm-svn: 327110
2018-03-09 18:39:40 +08:00
if ( args_or ) {
args = std : : move ( * args_or ) ;
2016-08-12 07:51:28 +08:00
error = options - > NotifyOptionParsingFinished ( & exe_ctx ) ;
Move option parsing out of the Args class
Summary:
The args class is used in plenty of places (a lot of them in the lower lldb
layers) for representing a list of arguments, and most of these places don't
care about option parsing. Moving the option parsing out of the class removes
the largest external dependency (there are a couple more, but these are in
static functions), and brings us closer to being able to move it to the
Utility module).
The new home for these functions is the Options class, which was already used
as an argument to the parse calls, so this just inverts the dependency between
the two.
The functions are themselves are mainly just copied -- the biggest functional
change I've made to them is to avoid modifying the input Args argument (getopt
likes to permute the argument vector), as it was weird to have another class
reorder the entries in Args class. So now the functions don't modify the input
arguments, and (for those where it makes sense) return a new Args vector
instead. I've also made the addition of a "fake arg0" (required for getopt
compatibility) an implementation detail rather than a part of interface.
While doing that I noticed that ParseForCompletion function was recording the
option indexes in the shuffled vector, but then the consumer was looking up the
entries in the unshuffled one. This manifested itself as us not being able to
complete "watchpoint set variable foo --" (because getopt would move "foo" to
the end). Surprisingly all other completions (e.g. "watchpoint set variable foo
--w") were not affected by this. However, I couldn't find a comprehensive test
for command argument completion, so I consolidated the existing tests and added
a bunch of new ones.
Reviewers: davide, jingham, zturner
Subscribers: lldb-commits
Differential Revision: https://reviews.llvm.org/D43837
llvm-svn: 327110
2018-03-09 18:39:40 +08:00
} else
error = args_or . takeError ( ) ;
2016-09-07 04:57:50 +08:00
2011-04-13 08:18:08 +08:00
if ( error . Success ( ) ) {
if ( options - > VerifyOptions ( result ) )
return true ;
2016-09-07 04:57:50 +08:00
} else {
2010-06-09 00:52:24 +08:00
const char * error_cstr = error . AsCString ( ) ;
Expanded the flags that can be set for a command object in lldb_private::CommandObject. This list of available flags are:
enum
{
//----------------------------------------------------------------------
// eFlagRequiresTarget
//
// Ensures a valid target is contained in m_exe_ctx prior to executing
// the command. If a target doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidTargetDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidTargetDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresTarget = (1u << 0),
//----------------------------------------------------------------------
// eFlagRequiresProcess
//
// Ensures a valid process is contained in m_exe_ctx prior to executing
// the command. If a process doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidProcessDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidProcessDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresProcess = (1u << 1),
//----------------------------------------------------------------------
// eFlagRequiresThread
//
// Ensures a valid thread is contained in m_exe_ctx prior to executing
// the command. If a thread doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidThreadDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidThreadDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresThread = (1u << 2),
//----------------------------------------------------------------------
// eFlagRequiresFrame
//
// Ensures a valid frame is contained in m_exe_ctx prior to executing
// the command. If a frame doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidFrameDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidFrameDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresFrame = (1u << 3),
//----------------------------------------------------------------------
// eFlagRequiresRegContext
//
// Ensures a valid register context (from the selected frame if there
// is a frame in m_exe_ctx, or from the selected thread from m_exe_ctx)
// is availble from m_exe_ctx prior to executing the command. If a
// target doesn't exist or is invalid, the command will fail and
// CommandObject::GetInvalidRegContextDescription() will be returned as
// the error. CommandObject subclasses can override the virtual function
// for GetInvalidRegContextDescription() to provide custom strings when
// needed.
//----------------------------------------------------------------------
eFlagRequiresRegContext = (1u << 4),
//----------------------------------------------------------------------
// eFlagTryTargetAPILock
//
// Attempts to acquire the target lock if a target is selected in the
// command interpreter. If the command object fails to acquire the API
// lock, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagTryTargetAPILock = (1u << 5),
//----------------------------------------------------------------------
// eFlagProcessMustBeLaunched
//
// Verifies that there is a launched process in m_exe_ctx, if there
// isn't, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagProcessMustBeLaunched = (1u << 6),
//----------------------------------------------------------------------
// eFlagProcessMustBePaused
//
// Verifies that there is a paused process in m_exe_ctx, if there
// isn't, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagProcessMustBePaused = (1u << 7)
};
Now each command object contains a "ExecutionContext m_exe_ctx;" member variable that gets initialized prior to running the command. The validity of the target objects in m_exe_ctx are checked to ensure that any target/process/thread/frame/reg context that are required are valid prior to executing the command. Each command object also contains a Mutex::Locker m_api_locker which gets used if eFlagTryTargetAPILock is set. This centralizes a lot of checking code that was previously and inconsistently implemented across many commands.
llvm-svn: 171990
2013-01-10 03:44:40 +08:00
if ( error_cstr ) {
// We got an error string, lets use that
2011-10-26 08:56:27 +08:00
result . AppendError ( error_cstr ) ;
2016-09-07 04:57:50 +08:00
} else {
2010-06-09 00:52:24 +08:00
// No error string, output the usage information into result
2016-08-12 07:51:28 +08:00
options - > GenerateOptionUsage (
result . GetErrorStream ( ) , this ,
2016-03-12 10:45:34 +08:00
GetCommandInterpreter ( ) . GetDebugger ( ) . GetTerminalWidth ( ) ) ;
2016-09-07 04:57:50 +08:00
}
}
2011-07-09 08:55:34 +08:00
result . SetStatus ( eReturnStatusFailed ) ;
2011-04-13 08:18:08 +08:00
return false ;
2016-09-07 04:57:50 +08:00
}
2011-04-13 08:18:08 +08:00
return true ;
2016-09-07 04:57:50 +08:00
}
Expanded the flags that can be set for a command object in lldb_private::CommandObject. This list of available flags are:
enum
{
//----------------------------------------------------------------------
// eFlagRequiresTarget
//
// Ensures a valid target is contained in m_exe_ctx prior to executing
// the command. If a target doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidTargetDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidTargetDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresTarget = (1u << 0),
//----------------------------------------------------------------------
// eFlagRequiresProcess
//
// Ensures a valid process is contained in m_exe_ctx prior to executing
// the command. If a process doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidProcessDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidProcessDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresProcess = (1u << 1),
//----------------------------------------------------------------------
// eFlagRequiresThread
//
// Ensures a valid thread is contained in m_exe_ctx prior to executing
// the command. If a thread doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidThreadDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidThreadDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresThread = (1u << 2),
//----------------------------------------------------------------------
// eFlagRequiresFrame
//
// Ensures a valid frame is contained in m_exe_ctx prior to executing
// the command. If a frame doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidFrameDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidFrameDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresFrame = (1u << 3),
//----------------------------------------------------------------------
// eFlagRequiresRegContext
//
// Ensures a valid register context (from the selected frame if there
// is a frame in m_exe_ctx, or from the selected thread from m_exe_ctx)
// is availble from m_exe_ctx prior to executing the command. If a
// target doesn't exist or is invalid, the command will fail and
// CommandObject::GetInvalidRegContextDescription() will be returned as
// the error. CommandObject subclasses can override the virtual function
// for GetInvalidRegContextDescription() to provide custom strings when
// needed.
//----------------------------------------------------------------------
eFlagRequiresRegContext = (1u << 4),
//----------------------------------------------------------------------
// eFlagTryTargetAPILock
//
// Attempts to acquire the target lock if a target is selected in the
// command interpreter. If the command object fails to acquire the API
// lock, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagTryTargetAPILock = (1u << 5),
//----------------------------------------------------------------------
// eFlagProcessMustBeLaunched
//
// Verifies that there is a launched process in m_exe_ctx, if there
// isn't, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagProcessMustBeLaunched = (1u << 6),
//----------------------------------------------------------------------
// eFlagProcessMustBePaused
//
// Verifies that there is a paused process in m_exe_ctx, if there
// isn't, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagProcessMustBePaused = (1u << 7)
};
Now each command object contains a "ExecutionContext m_exe_ctx;" member variable that gets initialized prior to running the command. The validity of the target objects in m_exe_ctx are checked to ensure that any target/process/thread/frame/reg context that are required are valid prior to executing the command. Each command object also contains a Mutex::Locker m_api_locker which gets used if eFlagTryTargetAPILock is set. This centralizes a lot of checking code that was previously and inconsistently implemented across many commands.
llvm-svn: 171990
2013-01-10 03:44:40 +08:00
bool CommandObject : : CheckRequirements ( CommandReturnObject & result ) {
2018-05-01 00:49:04 +08:00
// Nothing should be stored in m_exe_ctx between running commands as
// m_exe_ctx has shared pointers to the target, process, thread and frame and
// we don't want any CommandObject instances to keep any of these objects
// around longer than for a single command. Every command should call
2019-03-06 09:07:45 +08:00
// CommandObject::Cleanup() after it has completed.
assert ( ! m_exe_ctx . GetTargetPtr ( ) ) ;
assert ( ! m_exe_ctx . GetProcessPtr ( ) ) ;
assert ( ! m_exe_ctx . GetThreadPtr ( ) ) ;
assert ( ! m_exe_ctx . GetFramePtr ( ) ) ;
Expanded the flags that can be set for a command object in lldb_private::CommandObject. This list of available flags are:
enum
{
//----------------------------------------------------------------------
// eFlagRequiresTarget
//
// Ensures a valid target is contained in m_exe_ctx prior to executing
// the command. If a target doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidTargetDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidTargetDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresTarget = (1u << 0),
//----------------------------------------------------------------------
// eFlagRequiresProcess
//
// Ensures a valid process is contained in m_exe_ctx prior to executing
// the command. If a process doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidProcessDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidProcessDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresProcess = (1u << 1),
//----------------------------------------------------------------------
// eFlagRequiresThread
//
// Ensures a valid thread is contained in m_exe_ctx prior to executing
// the command. If a thread doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidThreadDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidThreadDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresThread = (1u << 2),
//----------------------------------------------------------------------
// eFlagRequiresFrame
//
// Ensures a valid frame is contained in m_exe_ctx prior to executing
// the command. If a frame doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidFrameDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidFrameDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresFrame = (1u << 3),
//----------------------------------------------------------------------
// eFlagRequiresRegContext
//
// Ensures a valid register context (from the selected frame if there
// is a frame in m_exe_ctx, or from the selected thread from m_exe_ctx)
// is availble from m_exe_ctx prior to executing the command. If a
// target doesn't exist or is invalid, the command will fail and
// CommandObject::GetInvalidRegContextDescription() will be returned as
// the error. CommandObject subclasses can override the virtual function
// for GetInvalidRegContextDescription() to provide custom strings when
// needed.
//----------------------------------------------------------------------
eFlagRequiresRegContext = (1u << 4),
//----------------------------------------------------------------------
// eFlagTryTargetAPILock
//
// Attempts to acquire the target lock if a target is selected in the
// command interpreter. If the command object fails to acquire the API
// lock, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagTryTargetAPILock = (1u << 5),
//----------------------------------------------------------------------
// eFlagProcessMustBeLaunched
//
// Verifies that there is a launched process in m_exe_ctx, if there
// isn't, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagProcessMustBeLaunched = (1u << 6),
//----------------------------------------------------------------------
// eFlagProcessMustBePaused
//
// Verifies that there is a paused process in m_exe_ctx, if there
// isn't, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagProcessMustBePaused = (1u << 7)
};
Now each command object contains a "ExecutionContext m_exe_ctx;" member variable that gets initialized prior to running the command. The validity of the target objects in m_exe_ctx are checked to ensure that any target/process/thread/frame/reg context that are required are valid prior to executing the command. Each command object also contains a Mutex::Locker m_api_locker which gets used if eFlagTryTargetAPILock is set. This centralizes a lot of checking code that was previously and inconsistently implemented across many commands.
llvm-svn: 171990
2013-01-10 03:44:40 +08:00
2018-05-01 00:49:04 +08:00
// Lock down the interpreter's execution context prior to running the command
// so we guarantee the selected target, process, thread and frame can't go
// away during the execution
2015-05-27 13:04:35 +08:00
m_exe_ctx = m_interpreter . GetExecutionContext ( ) ;
Expanded the flags that can be set for a command object in lldb_private::CommandObject. This list of available flags are:
enum
{
//----------------------------------------------------------------------
// eFlagRequiresTarget
//
// Ensures a valid target is contained in m_exe_ctx prior to executing
// the command. If a target doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidTargetDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidTargetDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresTarget = (1u << 0),
//----------------------------------------------------------------------
// eFlagRequiresProcess
//
// Ensures a valid process is contained in m_exe_ctx prior to executing
// the command. If a process doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidProcessDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidProcessDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresProcess = (1u << 1),
//----------------------------------------------------------------------
// eFlagRequiresThread
//
// Ensures a valid thread is contained in m_exe_ctx prior to executing
// the command. If a thread doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidThreadDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidThreadDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresThread = (1u << 2),
//----------------------------------------------------------------------
// eFlagRequiresFrame
//
// Ensures a valid frame is contained in m_exe_ctx prior to executing
// the command. If a frame doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidFrameDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidFrameDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresFrame = (1u << 3),
//----------------------------------------------------------------------
// eFlagRequiresRegContext
//
// Ensures a valid register context (from the selected frame if there
// is a frame in m_exe_ctx, or from the selected thread from m_exe_ctx)
// is availble from m_exe_ctx prior to executing the command. If a
// target doesn't exist or is invalid, the command will fail and
// CommandObject::GetInvalidRegContextDescription() will be returned as
// the error. CommandObject subclasses can override the virtual function
// for GetInvalidRegContextDescription() to provide custom strings when
// needed.
//----------------------------------------------------------------------
eFlagRequiresRegContext = (1u << 4),
//----------------------------------------------------------------------
// eFlagTryTargetAPILock
//
// Attempts to acquire the target lock if a target is selected in the
// command interpreter. If the command object fails to acquire the API
// lock, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagTryTargetAPILock = (1u << 5),
//----------------------------------------------------------------------
// eFlagProcessMustBeLaunched
//
// Verifies that there is a launched process in m_exe_ctx, if there
// isn't, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagProcessMustBeLaunched = (1u << 6),
//----------------------------------------------------------------------
// eFlagProcessMustBePaused
//
// Verifies that there is a paused process in m_exe_ctx, if there
// isn't, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagProcessMustBePaused = (1u << 7)
};
Now each command object contains a "ExecutionContext m_exe_ctx;" member variable that gets initialized prior to running the command. The validity of the target objects in m_exe_ctx are checked to ensure that any target/process/thread/frame/reg context that are required are valid prior to executing the command. Each command object also contains a Mutex::Locker m_api_locker which gets used if eFlagTryTargetAPILock is set. This centralizes a lot of checking code that was previously and inconsistently implemented across many commands.
llvm-svn: 171990
2013-01-10 03:44:40 +08:00
2014-09-20 17:14:31 +08:00
const uint32_t flags = GetFlags ( ) . Get ( ) ;
2015-05-27 13:04:35 +08:00
if ( flags & ( eCommandRequiresTarget | eCommandRequiresProcess |
eCommandRequiresThread | eCommandRequiresFrame |
eCommandTryTargetAPILock ) ) {
Expanded the flags that can be set for a command object in lldb_private::CommandObject. This list of available flags are:
enum
{
//----------------------------------------------------------------------
// eFlagRequiresTarget
//
// Ensures a valid target is contained in m_exe_ctx prior to executing
// the command. If a target doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidTargetDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidTargetDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresTarget = (1u << 0),
//----------------------------------------------------------------------
// eFlagRequiresProcess
//
// Ensures a valid process is contained in m_exe_ctx prior to executing
// the command. If a process doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidProcessDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidProcessDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresProcess = (1u << 1),
//----------------------------------------------------------------------
// eFlagRequiresThread
//
// Ensures a valid thread is contained in m_exe_ctx prior to executing
// the command. If a thread doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidThreadDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidThreadDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresThread = (1u << 2),
//----------------------------------------------------------------------
// eFlagRequiresFrame
//
// Ensures a valid frame is contained in m_exe_ctx prior to executing
// the command. If a frame doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidFrameDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidFrameDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresFrame = (1u << 3),
//----------------------------------------------------------------------
// eFlagRequiresRegContext
//
// Ensures a valid register context (from the selected frame if there
// is a frame in m_exe_ctx, or from the selected thread from m_exe_ctx)
// is availble from m_exe_ctx prior to executing the command. If a
// target doesn't exist or is invalid, the command will fail and
// CommandObject::GetInvalidRegContextDescription() will be returned as
// the error. CommandObject subclasses can override the virtual function
// for GetInvalidRegContextDescription() to provide custom strings when
// needed.
//----------------------------------------------------------------------
eFlagRequiresRegContext = (1u << 4),
//----------------------------------------------------------------------
// eFlagTryTargetAPILock
//
// Attempts to acquire the target lock if a target is selected in the
// command interpreter. If the command object fails to acquire the API
// lock, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagTryTargetAPILock = (1u << 5),
//----------------------------------------------------------------------
// eFlagProcessMustBeLaunched
//
// Verifies that there is a launched process in m_exe_ctx, if there
// isn't, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagProcessMustBeLaunched = (1u << 6),
//----------------------------------------------------------------------
// eFlagProcessMustBePaused
//
// Verifies that there is a paused process in m_exe_ctx, if there
// isn't, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagProcessMustBePaused = (1u << 7)
};
Now each command object contains a "ExecutionContext m_exe_ctx;" member variable that gets initialized prior to running the command. The validity of the target objects in m_exe_ctx are checked to ensure that any target/process/thread/frame/reg context that are required are valid prior to executing the command. Each command object also contains a Mutex::Locker m_api_locker which gets used if eFlagTryTargetAPILock is set. This centralizes a lot of checking code that was previously and inconsistently implemented across many commands.
llvm-svn: 171990
2013-01-10 03:44:40 +08:00
2015-05-27 13:04:35 +08:00
if ( ( flags & eCommandRequiresTarget ) & & ! m_exe_ctx . HasTargetScope ( ) ) {
2016-05-19 13:13:57 +08:00
result . AppendError ( GetInvalidTargetDescription ( ) ) ;
return false ;
Expanded the flags that can be set for a command object in lldb_private::CommandObject. This list of available flags are:
enum
{
//----------------------------------------------------------------------
// eFlagRequiresTarget
//
// Ensures a valid target is contained in m_exe_ctx prior to executing
// the command. If a target doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidTargetDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidTargetDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresTarget = (1u << 0),
//----------------------------------------------------------------------
// eFlagRequiresProcess
//
// Ensures a valid process is contained in m_exe_ctx prior to executing
// the command. If a process doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidProcessDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidProcessDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresProcess = (1u << 1),
//----------------------------------------------------------------------
// eFlagRequiresThread
//
// Ensures a valid thread is contained in m_exe_ctx prior to executing
// the command. If a thread doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidThreadDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidThreadDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresThread = (1u << 2),
//----------------------------------------------------------------------
// eFlagRequiresFrame
//
// Ensures a valid frame is contained in m_exe_ctx prior to executing
// the command. If a frame doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidFrameDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidFrameDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresFrame = (1u << 3),
//----------------------------------------------------------------------
// eFlagRequiresRegContext
//
// Ensures a valid register context (from the selected frame if there
// is a frame in m_exe_ctx, or from the selected thread from m_exe_ctx)
// is availble from m_exe_ctx prior to executing the command. If a
// target doesn't exist or is invalid, the command will fail and
// CommandObject::GetInvalidRegContextDescription() will be returned as
// the error. CommandObject subclasses can override the virtual function
// for GetInvalidRegContextDescription() to provide custom strings when
// needed.
//----------------------------------------------------------------------
eFlagRequiresRegContext = (1u << 4),
//----------------------------------------------------------------------
// eFlagTryTargetAPILock
//
// Attempts to acquire the target lock if a target is selected in the
// command interpreter. If the command object fails to acquire the API
// lock, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagTryTargetAPILock = (1u << 5),
//----------------------------------------------------------------------
// eFlagProcessMustBeLaunched
//
// Verifies that there is a launched process in m_exe_ctx, if there
// isn't, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagProcessMustBeLaunched = (1u << 6),
//----------------------------------------------------------------------
// eFlagProcessMustBePaused
//
// Verifies that there is a paused process in m_exe_ctx, if there
// isn't, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagProcessMustBePaused = (1u << 7)
};
Now each command object contains a "ExecutionContext m_exe_ctx;" member variable that gets initialized prior to running the command. The validity of the target objects in m_exe_ctx are checked to ensure that any target/process/thread/frame/reg context that are required are valid prior to executing the command. Each command object also contains a Mutex::Locker m_api_locker which gets used if eFlagTryTargetAPILock is set. This centralizes a lot of checking code that was previously and inconsistently implemented across many commands.
llvm-svn: 171990
2013-01-10 03:44:40 +08:00
}
2015-05-27 13:04:35 +08:00
if ( ( flags & eCommandRequiresProcess ) & & ! m_exe_ctx . HasProcessScope ( ) ) {
2014-09-20 17:14:31 +08:00
if ( ! m_exe_ctx . HasTargetScope ( ) )
Expanded the flags that can be set for a command object in lldb_private::CommandObject. This list of available flags are:
enum
{
//----------------------------------------------------------------------
// eFlagRequiresTarget
//
// Ensures a valid target is contained in m_exe_ctx prior to executing
// the command. If a target doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidTargetDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidTargetDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresTarget = (1u << 0),
//----------------------------------------------------------------------
// eFlagRequiresProcess
//
// Ensures a valid process is contained in m_exe_ctx prior to executing
// the command. If a process doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidProcessDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidProcessDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresProcess = (1u << 1),
//----------------------------------------------------------------------
// eFlagRequiresThread
//
// Ensures a valid thread is contained in m_exe_ctx prior to executing
// the command. If a thread doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidThreadDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidThreadDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresThread = (1u << 2),
//----------------------------------------------------------------------
// eFlagRequiresFrame
//
// Ensures a valid frame is contained in m_exe_ctx prior to executing
// the command. If a frame doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidFrameDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidFrameDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresFrame = (1u << 3),
//----------------------------------------------------------------------
// eFlagRequiresRegContext
//
// Ensures a valid register context (from the selected frame if there
// is a frame in m_exe_ctx, or from the selected thread from m_exe_ctx)
// is availble from m_exe_ctx prior to executing the command. If a
// target doesn't exist or is invalid, the command will fail and
// CommandObject::GetInvalidRegContextDescription() will be returned as
// the error. CommandObject subclasses can override the virtual function
// for GetInvalidRegContextDescription() to provide custom strings when
// needed.
//----------------------------------------------------------------------
eFlagRequiresRegContext = (1u << 4),
//----------------------------------------------------------------------
// eFlagTryTargetAPILock
//
// Attempts to acquire the target lock if a target is selected in the
// command interpreter. If the command object fails to acquire the API
// lock, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagTryTargetAPILock = (1u << 5),
//----------------------------------------------------------------------
// eFlagProcessMustBeLaunched
//
// Verifies that there is a launched process in m_exe_ctx, if there
// isn't, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagProcessMustBeLaunched = (1u << 6),
//----------------------------------------------------------------------
// eFlagProcessMustBePaused
//
// Verifies that there is a paused process in m_exe_ctx, if there
// isn't, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagProcessMustBePaused = (1u << 7)
};
Now each command object contains a "ExecutionContext m_exe_ctx;" member variable that gets initialized prior to running the command. The validity of the target objects in m_exe_ctx are checked to ensure that any target/process/thread/frame/reg context that are required are valid prior to executing the command. Each command object also contains a Mutex::Locker m_api_locker which gets used if eFlagTryTargetAPILock is set. This centralizes a lot of checking code that was previously and inconsistently implemented across many commands.
llvm-svn: 171990
2013-01-10 03:44:40 +08:00
result . AppendError ( GetInvalidTargetDescription ( ) ) ;
2015-05-27 13:04:35 +08:00
else
result . AppendError ( GetInvalidProcessDescription ( ) ) ;
2011-04-13 08:18:08 +08:00
return false ;
2016-09-07 04:57:50 +08:00
}
2015-05-27 13:04:35 +08:00
if ( ( flags & eCommandRequiresThread ) & & ! m_exe_ctx . HasThreadScope ( ) ) {
2014-09-20 17:14:31 +08:00
if ( ! m_exe_ctx . HasTargetScope ( ) )
Expanded the flags that can be set for a command object in lldb_private::CommandObject. This list of available flags are:
enum
{
//----------------------------------------------------------------------
// eFlagRequiresTarget
//
// Ensures a valid target is contained in m_exe_ctx prior to executing
// the command. If a target doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidTargetDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidTargetDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresTarget = (1u << 0),
//----------------------------------------------------------------------
// eFlagRequiresProcess
//
// Ensures a valid process is contained in m_exe_ctx prior to executing
// the command. If a process doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidProcessDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidProcessDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresProcess = (1u << 1),
//----------------------------------------------------------------------
// eFlagRequiresThread
//
// Ensures a valid thread is contained in m_exe_ctx prior to executing
// the command. If a thread doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidThreadDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidThreadDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresThread = (1u << 2),
//----------------------------------------------------------------------
// eFlagRequiresFrame
//
// Ensures a valid frame is contained in m_exe_ctx prior to executing
// the command. If a frame doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidFrameDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidFrameDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresFrame = (1u << 3),
//----------------------------------------------------------------------
// eFlagRequiresRegContext
//
// Ensures a valid register context (from the selected frame if there
// is a frame in m_exe_ctx, or from the selected thread from m_exe_ctx)
// is availble from m_exe_ctx prior to executing the command. If a
// target doesn't exist or is invalid, the command will fail and
// CommandObject::GetInvalidRegContextDescription() will be returned as
// the error. CommandObject subclasses can override the virtual function
// for GetInvalidRegContextDescription() to provide custom strings when
// needed.
//----------------------------------------------------------------------
eFlagRequiresRegContext = (1u << 4),
//----------------------------------------------------------------------
// eFlagTryTargetAPILock
//
// Attempts to acquire the target lock if a target is selected in the
// command interpreter. If the command object fails to acquire the API
// lock, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagTryTargetAPILock = (1u << 5),
//----------------------------------------------------------------------
// eFlagProcessMustBeLaunched
//
// Verifies that there is a launched process in m_exe_ctx, if there
// isn't, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagProcessMustBeLaunched = (1u << 6),
//----------------------------------------------------------------------
// eFlagProcessMustBePaused
//
// Verifies that there is a paused process in m_exe_ctx, if there
// isn't, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagProcessMustBePaused = (1u << 7)
};
Now each command object contains a "ExecutionContext m_exe_ctx;" member variable that gets initialized prior to running the command. The validity of the target objects in m_exe_ctx are checked to ensure that any target/process/thread/frame/reg context that are required are valid prior to executing the command. Each command object also contains a Mutex::Locker m_api_locker which gets used if eFlagTryTargetAPILock is set. This centralizes a lot of checking code that was previously and inconsistently implemented across many commands.
llvm-svn: 171990
2013-01-10 03:44:40 +08:00
result . AppendError ( GetInvalidTargetDescription ( ) ) ;
2014-09-20 17:14:31 +08:00
else if ( ! m_exe_ctx . HasProcessScope ( ) )
result . AppendError ( GetInvalidProcessDescription ( ) ) ;
2016-09-07 04:57:50 +08:00
else
2014-09-20 17:14:31 +08:00
result . AppendError ( GetInvalidThreadDescription ( ) ) ;
2011-04-13 08:18:08 +08:00
return false ;
2016-09-07 04:57:50 +08:00
}
2015-05-27 13:04:35 +08:00
if ( ( flags & eCommandRequiresFrame ) & & ! m_exe_ctx . HasFrameScope ( ) ) {
2014-09-20 17:14:31 +08:00
if ( ! m_exe_ctx . HasTargetScope ( ) )
Expanded the flags that can be set for a command object in lldb_private::CommandObject. This list of available flags are:
enum
{
//----------------------------------------------------------------------
// eFlagRequiresTarget
//
// Ensures a valid target is contained in m_exe_ctx prior to executing
// the command. If a target doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidTargetDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidTargetDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresTarget = (1u << 0),
//----------------------------------------------------------------------
// eFlagRequiresProcess
//
// Ensures a valid process is contained in m_exe_ctx prior to executing
// the command. If a process doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidProcessDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidProcessDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresProcess = (1u << 1),
//----------------------------------------------------------------------
// eFlagRequiresThread
//
// Ensures a valid thread is contained in m_exe_ctx prior to executing
// the command. If a thread doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidThreadDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidThreadDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresThread = (1u << 2),
//----------------------------------------------------------------------
// eFlagRequiresFrame
//
// Ensures a valid frame is contained in m_exe_ctx prior to executing
// the command. If a frame doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidFrameDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidFrameDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresFrame = (1u << 3),
//----------------------------------------------------------------------
// eFlagRequiresRegContext
//
// Ensures a valid register context (from the selected frame if there
// is a frame in m_exe_ctx, or from the selected thread from m_exe_ctx)
// is availble from m_exe_ctx prior to executing the command. If a
// target doesn't exist or is invalid, the command will fail and
// CommandObject::GetInvalidRegContextDescription() will be returned as
// the error. CommandObject subclasses can override the virtual function
// for GetInvalidRegContextDescription() to provide custom strings when
// needed.
//----------------------------------------------------------------------
eFlagRequiresRegContext = (1u << 4),
//----------------------------------------------------------------------
// eFlagTryTargetAPILock
//
// Attempts to acquire the target lock if a target is selected in the
// command interpreter. If the command object fails to acquire the API
// lock, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagTryTargetAPILock = (1u << 5),
//----------------------------------------------------------------------
// eFlagProcessMustBeLaunched
//
// Verifies that there is a launched process in m_exe_ctx, if there
// isn't, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagProcessMustBeLaunched = (1u << 6),
//----------------------------------------------------------------------
// eFlagProcessMustBePaused
//
// Verifies that there is a paused process in m_exe_ctx, if there
// isn't, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagProcessMustBePaused = (1u << 7)
};
Now each command object contains a "ExecutionContext m_exe_ctx;" member variable that gets initialized prior to running the command. The validity of the target objects in m_exe_ctx are checked to ensure that any target/process/thread/frame/reg context that are required are valid prior to executing the command. Each command object also contains a Mutex::Locker m_api_locker which gets used if eFlagTryTargetAPILock is set. This centralizes a lot of checking code that was previously and inconsistently implemented across many commands.
llvm-svn: 171990
2013-01-10 03:44:40 +08:00
result . AppendError ( GetInvalidTargetDescription ( ) ) ;
2014-09-20 17:14:31 +08:00
else if ( ! m_exe_ctx . HasProcessScope ( ) )
result . AppendError ( GetInvalidProcessDescription ( ) ) ;
else if ( ! m_exe_ctx . HasThreadScope ( ) )
result . AppendError ( GetInvalidThreadDescription ( ) ) ;
2016-09-07 04:57:50 +08:00
else
2015-05-27 13:04:35 +08:00
result . AppendError ( GetInvalidFrameDescription ( ) ) ;
2011-04-13 08:18:08 +08:00
return false ;
2016-09-07 04:57:50 +08:00
}
2015-05-27 13:04:35 +08:00
if ( ( flags & eCommandRequiresRegContext ) & &
( m_exe_ctx . GetRegisterContext ( ) = = nullptr ) ) {
Expanded the flags that can be set for a command object in lldb_private::CommandObject. This list of available flags are:
enum
{
//----------------------------------------------------------------------
// eFlagRequiresTarget
//
// Ensures a valid target is contained in m_exe_ctx prior to executing
// the command. If a target doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidTargetDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidTargetDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresTarget = (1u << 0),
//----------------------------------------------------------------------
// eFlagRequiresProcess
//
// Ensures a valid process is contained in m_exe_ctx prior to executing
// the command. If a process doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidProcessDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidProcessDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresProcess = (1u << 1),
//----------------------------------------------------------------------
// eFlagRequiresThread
//
// Ensures a valid thread is contained in m_exe_ctx prior to executing
// the command. If a thread doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidThreadDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidThreadDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresThread = (1u << 2),
//----------------------------------------------------------------------
// eFlagRequiresFrame
//
// Ensures a valid frame is contained in m_exe_ctx prior to executing
// the command. If a frame doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidFrameDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidFrameDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresFrame = (1u << 3),
//----------------------------------------------------------------------
// eFlagRequiresRegContext
//
// Ensures a valid register context (from the selected frame if there
// is a frame in m_exe_ctx, or from the selected thread from m_exe_ctx)
// is availble from m_exe_ctx prior to executing the command. If a
// target doesn't exist or is invalid, the command will fail and
// CommandObject::GetInvalidRegContextDescription() will be returned as
// the error. CommandObject subclasses can override the virtual function
// for GetInvalidRegContextDescription() to provide custom strings when
// needed.
//----------------------------------------------------------------------
eFlagRequiresRegContext = (1u << 4),
//----------------------------------------------------------------------
// eFlagTryTargetAPILock
//
// Attempts to acquire the target lock if a target is selected in the
// command interpreter. If the command object fails to acquire the API
// lock, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagTryTargetAPILock = (1u << 5),
//----------------------------------------------------------------------
// eFlagProcessMustBeLaunched
//
// Verifies that there is a launched process in m_exe_ctx, if there
// isn't, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagProcessMustBeLaunched = (1u << 6),
//----------------------------------------------------------------------
// eFlagProcessMustBePaused
//
// Verifies that there is a paused process in m_exe_ctx, if there
// isn't, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagProcessMustBePaused = (1u << 7)
};
Now each command object contains a "ExecutionContext m_exe_ctx;" member variable that gets initialized prior to running the command. The validity of the target objects in m_exe_ctx are checked to ensure that any target/process/thread/frame/reg context that are required are valid prior to executing the command. Each command object also contains a Mutex::Locker m_api_locker which gets used if eFlagTryTargetAPILock is set. This centralizes a lot of checking code that was previously and inconsistently implemented across many commands.
llvm-svn: 171990
2013-01-10 03:44:40 +08:00
result . AppendError ( GetInvalidRegContextDescription ( ) ) ;
2011-04-13 08:18:08 +08:00
return false ;
2016-09-07 04:57:50 +08:00
}
2015-05-27 13:04:35 +08:00
if ( flags & eCommandTryTargetAPILock ) {
Target * target = m_exe_ctx . GetTargetPtr ( ) ;
Expanded the flags that can be set for a command object in lldb_private::CommandObject. This list of available flags are:
enum
{
//----------------------------------------------------------------------
// eFlagRequiresTarget
//
// Ensures a valid target is contained in m_exe_ctx prior to executing
// the command. If a target doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidTargetDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidTargetDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresTarget = (1u << 0),
//----------------------------------------------------------------------
// eFlagRequiresProcess
//
// Ensures a valid process is contained in m_exe_ctx prior to executing
// the command. If a process doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidProcessDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidProcessDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresProcess = (1u << 1),
//----------------------------------------------------------------------
// eFlagRequiresThread
//
// Ensures a valid thread is contained in m_exe_ctx prior to executing
// the command. If a thread doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidThreadDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidThreadDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresThread = (1u << 2),
//----------------------------------------------------------------------
// eFlagRequiresFrame
//
// Ensures a valid frame is contained in m_exe_ctx prior to executing
// the command. If a frame doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidFrameDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidFrameDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresFrame = (1u << 3),
//----------------------------------------------------------------------
// eFlagRequiresRegContext
//
// Ensures a valid register context (from the selected frame if there
// is a frame in m_exe_ctx, or from the selected thread from m_exe_ctx)
// is availble from m_exe_ctx prior to executing the command. If a
// target doesn't exist or is invalid, the command will fail and
// CommandObject::GetInvalidRegContextDescription() will be returned as
// the error. CommandObject subclasses can override the virtual function
// for GetInvalidRegContextDescription() to provide custom strings when
// needed.
//----------------------------------------------------------------------
eFlagRequiresRegContext = (1u << 4),
//----------------------------------------------------------------------
// eFlagTryTargetAPILock
//
// Attempts to acquire the target lock if a target is selected in the
// command interpreter. If the command object fails to acquire the API
// lock, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagTryTargetAPILock = (1u << 5),
//----------------------------------------------------------------------
// eFlagProcessMustBeLaunched
//
// Verifies that there is a launched process in m_exe_ctx, if there
// isn't, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagProcessMustBeLaunched = (1u << 6),
//----------------------------------------------------------------------
// eFlagProcessMustBePaused
//
// Verifies that there is a paused process in m_exe_ctx, if there
// isn't, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagProcessMustBePaused = (1u << 7)
};
Now each command object contains a "ExecutionContext m_exe_ctx;" member variable that gets initialized prior to running the command. The validity of the target objects in m_exe_ctx are checked to ensure that any target/process/thread/frame/reg context that are required are valid prior to executing the command. Each command object also contains a Mutex::Locker m_api_locker which gets used if eFlagTryTargetAPILock is set. This centralizes a lot of checking code that was previously and inconsistently implemented across many commands.
llvm-svn: 171990
2013-01-10 03:44:40 +08:00
if ( target )
2016-05-19 13:13:57 +08:00
m_api_locker =
2015-05-27 13:04:35 +08:00
std : : unique_lock < std : : recursive_mutex > ( target - > GetAPIMutex ( ) ) ;
2016-09-07 04:57:50 +08:00
}
}
2015-05-27 13:04:35 +08:00
if ( GetFlags ( ) . AnySet ( eCommandProcessMustBeLaunched |
eCommandProcessMustBePaused ) ) {
2011-09-22 12:58:26 +08:00
Process * process = m_interpreter . GetExecutionContext ( ) . GetProcessPtr ( ) ;
2014-04-20 08:31:37 +08:00
if ( process = = nullptr ) {
2011-07-09 08:55:34 +08:00
// A process that is not running is considered paused.
2015-05-27 13:04:35 +08:00
if ( GetFlags ( ) . Test ( eCommandProcessMustBeLaunched ) ) {
2011-07-09 08:55:34 +08:00
result . AppendError ( " Process must exist. " ) ;
Expanded the flags that can be set for a command object in lldb_private::CommandObject. This list of available flags are:
enum
{
//----------------------------------------------------------------------
// eFlagRequiresTarget
//
// Ensures a valid target is contained in m_exe_ctx prior to executing
// the command. If a target doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidTargetDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidTargetDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresTarget = (1u << 0),
//----------------------------------------------------------------------
// eFlagRequiresProcess
//
// Ensures a valid process is contained in m_exe_ctx prior to executing
// the command. If a process doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidProcessDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidProcessDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresProcess = (1u << 1),
//----------------------------------------------------------------------
// eFlagRequiresThread
//
// Ensures a valid thread is contained in m_exe_ctx prior to executing
// the command. If a thread doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidThreadDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidThreadDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresThread = (1u << 2),
//----------------------------------------------------------------------
// eFlagRequiresFrame
//
// Ensures a valid frame is contained in m_exe_ctx prior to executing
// the command. If a frame doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidFrameDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidFrameDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresFrame = (1u << 3),
//----------------------------------------------------------------------
// eFlagRequiresRegContext
//
// Ensures a valid register context (from the selected frame if there
// is a frame in m_exe_ctx, or from the selected thread from m_exe_ctx)
// is availble from m_exe_ctx prior to executing the command. If a
// target doesn't exist or is invalid, the command will fail and
// CommandObject::GetInvalidRegContextDescription() will be returned as
// the error. CommandObject subclasses can override the virtual function
// for GetInvalidRegContextDescription() to provide custom strings when
// needed.
//----------------------------------------------------------------------
eFlagRequiresRegContext = (1u << 4),
//----------------------------------------------------------------------
// eFlagTryTargetAPILock
//
// Attempts to acquire the target lock if a target is selected in the
// command interpreter. If the command object fails to acquire the API
// lock, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagTryTargetAPILock = (1u << 5),
//----------------------------------------------------------------------
// eFlagProcessMustBeLaunched
//
// Verifies that there is a launched process in m_exe_ctx, if there
// isn't, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagProcessMustBeLaunched = (1u << 6),
//----------------------------------------------------------------------
// eFlagProcessMustBePaused
//
// Verifies that there is a paused process in m_exe_ctx, if there
// isn't, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagProcessMustBePaused = (1u << 7)
};
Now each command object contains a "ExecutionContext m_exe_ctx;" member variable that gets initialized prior to running the command. The validity of the target objects in m_exe_ctx are checked to ensure that any target/process/thread/frame/reg context that are required are valid prior to executing the command. Each command object also contains a Mutex::Locker m_api_locker which gets used if eFlagTryTargetAPILock is set. This centralizes a lot of checking code that was previously and inconsistently implemented across many commands.
llvm-svn: 171990
2013-01-10 03:44:40 +08:00
return false ;
2016-09-07 04:57:50 +08:00
}
} else {
2011-02-04 09:58:07 +08:00
StateType state = process - > GetState ( ) ;
2011-07-09 08:55:34 +08:00
switch ( state ) {
2011-03-20 12:57:14 +08:00
case eStateInvalid :
2011-02-04 09:58:07 +08:00
case eStateSuspended :
case eStateCrashed :
case eStateStopped :
2016-09-07 04:57:50 +08:00
break ;
2011-02-04 09:58:07 +08:00
case eStateConnected :
case eStateAttaching :
case eStateLaunching :
case eStateDetached :
case eStateExited :
case eStateUnloaded :
2015-05-27 13:04:35 +08:00
if ( GetFlags ( ) . Test ( eCommandProcessMustBeLaunched ) ) {
2011-07-09 08:55:34 +08:00
result . AppendError ( " Process must be launched. " ) ;
return false ;
2010-06-09 00:52:24 +08:00
}
2011-02-04 09:58:07 +08:00
break ;
2016-09-07 04:57:50 +08:00
2011-02-04 09:58:07 +08:00
case eStateRunning :
case eStateStepping :
2015-05-27 13:04:35 +08:00
if ( GetFlags ( ) . Test ( eCommandProcessMustBePaused ) ) {
2011-02-04 09:58:07 +08:00
result . AppendError ( " Process is running. Use 'process interrupt' to "
" pause execution. " ) ;
return false ;
2010-06-09 00:52:24 +08:00
}
2016-09-07 04:57:50 +08:00
}
2010-06-09 00:52:24 +08:00
}
2016-09-07 04:57:50 +08:00
}
2020-10-27 12:22:06 +08:00
if ( GetFlags ( ) . Test ( eCommandProcessMustBeTraced ) ) {
Target * target = m_exe_ctx . GetTargetPtr ( ) ;
if ( target & & ! target - > GetTrace ( ) ) {
2021-06-23 00:12:56 +08:00
result . AppendError ( " Process is not being traced. " ) ;
2020-10-27 12:22:06 +08:00
return false ;
}
}
2012-06-09 05:56:10 +08:00
return true ;
2010-06-09 00:52:24 +08:00
}
Expanded the flags that can be set for a command object in lldb_private::CommandObject. This list of available flags are:
enum
{
//----------------------------------------------------------------------
// eFlagRequiresTarget
//
// Ensures a valid target is contained in m_exe_ctx prior to executing
// the command. If a target doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidTargetDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidTargetDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresTarget = (1u << 0),
//----------------------------------------------------------------------
// eFlagRequiresProcess
//
// Ensures a valid process is contained in m_exe_ctx prior to executing
// the command. If a process doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidProcessDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidProcessDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresProcess = (1u << 1),
//----------------------------------------------------------------------
// eFlagRequiresThread
//
// Ensures a valid thread is contained in m_exe_ctx prior to executing
// the command. If a thread doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidThreadDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidThreadDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresThread = (1u << 2),
//----------------------------------------------------------------------
// eFlagRequiresFrame
//
// Ensures a valid frame is contained in m_exe_ctx prior to executing
// the command. If a frame doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidFrameDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidFrameDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresFrame = (1u << 3),
//----------------------------------------------------------------------
// eFlagRequiresRegContext
//
// Ensures a valid register context (from the selected frame if there
// is a frame in m_exe_ctx, or from the selected thread from m_exe_ctx)
// is availble from m_exe_ctx prior to executing the command. If a
// target doesn't exist or is invalid, the command will fail and
// CommandObject::GetInvalidRegContextDescription() will be returned as
// the error. CommandObject subclasses can override the virtual function
// for GetInvalidRegContextDescription() to provide custom strings when
// needed.
//----------------------------------------------------------------------
eFlagRequiresRegContext = (1u << 4),
//----------------------------------------------------------------------
// eFlagTryTargetAPILock
//
// Attempts to acquire the target lock if a target is selected in the
// command interpreter. If the command object fails to acquire the API
// lock, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagTryTargetAPILock = (1u << 5),
//----------------------------------------------------------------------
// eFlagProcessMustBeLaunched
//
// Verifies that there is a launched process in m_exe_ctx, if there
// isn't, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagProcessMustBeLaunched = (1u << 6),
//----------------------------------------------------------------------
// eFlagProcessMustBePaused
//
// Verifies that there is a paused process in m_exe_ctx, if there
// isn't, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagProcessMustBePaused = (1u << 7)
};
Now each command object contains a "ExecutionContext m_exe_ctx;" member variable that gets initialized prior to running the command. The validity of the target objects in m_exe_ctx are checked to ensure that any target/process/thread/frame/reg context that are required are valid prior to executing the command. Each command object also contains a Mutex::Locker m_api_locker which gets used if eFlagTryTargetAPILock is set. This centralizes a lot of checking code that was previously and inconsistently implemented across many commands.
llvm-svn: 171990
2013-01-10 03:44:40 +08:00
void CommandObject : : Cleanup ( ) {
m_exe_ctx . Clear ( ) ;
2016-05-19 13:13:57 +08:00
if ( m_api_locker . owns_lock ( ) )
m_api_locker . unlock ( ) ;
Expanded the flags that can be set for a command object in lldb_private::CommandObject. This list of available flags are:
enum
{
//----------------------------------------------------------------------
// eFlagRequiresTarget
//
// Ensures a valid target is contained in m_exe_ctx prior to executing
// the command. If a target doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidTargetDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidTargetDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresTarget = (1u << 0),
//----------------------------------------------------------------------
// eFlagRequiresProcess
//
// Ensures a valid process is contained in m_exe_ctx prior to executing
// the command. If a process doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidProcessDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidProcessDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresProcess = (1u << 1),
//----------------------------------------------------------------------
// eFlagRequiresThread
//
// Ensures a valid thread is contained in m_exe_ctx prior to executing
// the command. If a thread doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidThreadDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidThreadDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresThread = (1u << 2),
//----------------------------------------------------------------------
// eFlagRequiresFrame
//
// Ensures a valid frame is contained in m_exe_ctx prior to executing
// the command. If a frame doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidFrameDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidFrameDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresFrame = (1u << 3),
//----------------------------------------------------------------------
// eFlagRequiresRegContext
//
// Ensures a valid register context (from the selected frame if there
// is a frame in m_exe_ctx, or from the selected thread from m_exe_ctx)
// is availble from m_exe_ctx prior to executing the command. If a
// target doesn't exist or is invalid, the command will fail and
// CommandObject::GetInvalidRegContextDescription() will be returned as
// the error. CommandObject subclasses can override the virtual function
// for GetInvalidRegContextDescription() to provide custom strings when
// needed.
//----------------------------------------------------------------------
eFlagRequiresRegContext = (1u << 4),
//----------------------------------------------------------------------
// eFlagTryTargetAPILock
//
// Attempts to acquire the target lock if a target is selected in the
// command interpreter. If the command object fails to acquire the API
// lock, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagTryTargetAPILock = (1u << 5),
//----------------------------------------------------------------------
// eFlagProcessMustBeLaunched
//
// Verifies that there is a launched process in m_exe_ctx, if there
// isn't, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagProcessMustBeLaunched = (1u << 6),
//----------------------------------------------------------------------
// eFlagProcessMustBePaused
//
// Verifies that there is a paused process in m_exe_ctx, if there
// isn't, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagProcessMustBePaused = (1u << 7)
};
Now each command object contains a "ExecutionContext m_exe_ctx;" member variable that gets initialized prior to running the command. The validity of the target objects in m_exe_ctx are checked to ensure that any target/process/thread/frame/reg context that are required are valid prior to executing the command. Each command object also contains a Mutex::Locker m_api_locker which gets used if eFlagTryTargetAPILock is set. This centralizes a lot of checking code that was previously and inconsistently implemented across many commands.
llvm-svn: 171990
2013-01-10 03:44:40 +08:00
}
[lldb][NFC] Remove WordComplete mode, make result array indexed from 0 and remove any undocumented/redundant return values
Summary:
We still have some leftovers of the old completion API in the internals of
LLDB that haven't been replaced by the new CompletionRequest. These leftovers
are:
* The return values (int/size_t) in all completion functions.
* Our result array that starts indexing at 1.
* `WordComplete` mode.
I didn't replace them back then because it's tricky to figure out what exactly they
are used for and the completion code is relatively untested. I finally got around
to writing more tests for the API and understanding the semantics, so I think it's
a good time to get rid of them.
A few words why those things should be removed/replaced:
* The return values are really cryptic, partly redundant and rarely documented.
They are also completely ignored by Xcode, so whatever information they contain will end up
breaking Xcode's completion mechanism. They are also partly impossible to even implement
as we assign negative values special meaning and our completion API sometimes returns size_t.
Completion functions are supposed to return -2 to rewrite the current line. We seem to use this
in some untested code path to expand the history repeat character to the full command, but
I haven't figured out why that doesn't work at the moment.
Completion functions return -1 to 'insert the completion character', but that isn't implemented
(even though we seem to activate this feature in LLDB sometimes).
All positive values have to match the number of results. This is obviously just redundant information
as the user can just look at the result list to get that information (which is what Xcode does).
* The result array that starts indexing at 1 is obviously unexpected. The first element of the array is
reserved for the common prefix of all completions (e.g. "foobar" and "footar" -> "foo"). The idea is
that we calculate this to make the life of the API caller easier, but obviously forcing people to have
1-based indices is not helpful (or even worse, forces them to manually copy the results to make it
0-based like Xcode has to do).
* The `WordComplete` mode indicates that LLDB should enter a space behind the completion. The
idea is that we let the top-level API know that we just provided a full completion. Interestingly we
`WordComplete` is just a single bool that somehow represents all N completions. And we always
provide full completions in LLDB, so in theory it should always be true.
The only use it currently serves is providing redundant information about whether we have a single
definitive completion or not (which we already know from the number of results we get).
This patch essentially removes `WordComplete` mode and makes the result array indexed from 0.
It also removes all return values from all internal completion functions. The only non-redundant information
they contain is about rewriting the current line (which is broken), so that functionality was moved
to the CompletionRequest API. So you can now do `addCompletion("blub", "description", CompletionMode::RewriteLine)`
to do the same.
For the SB API we emulate the old behaviour by making the array indexed from 1 again with the common
prefix at index 0. I didn't keep the special negative return codes as we either never sent them before (e.g. -2) or we
didn't even implement them in the Editline handler (e.g. -1).
I tried to keep this patch minimal and I'm aware we can probably now even further simplify a bunch of related code,
but I would prefer doing this in follow-up NFC commits
Reviewers: JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arphaman, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D66536
llvm-svn: 369624
2019-08-22 15:41:23 +08:00
void CommandObject : : HandleCompletion ( CompletionRequest & request ) {
2020-03-07 02:10:24 +08:00
m_exe_ctx = m_interpreter . GetExecutionContext ( ) ;
2020-05-27 20:04:39 +08:00
auto reset_ctx = llvm : : make_scope_exit ( [ this ] ( ) { Cleanup ( ) ; } ) ;
2020-03-07 02:10:24 +08:00
2015-07-22 08:16:02 +08:00
// Default implementation of WantsCompletion() is !WantsRawCommandString().
2018-05-01 00:49:04 +08:00
// Subclasses who want raw command string but desire, for example, argument
// completion should override WantsCompletion() to return true, instead.
2012-01-20 08:59:19 +08:00
if ( WantsRawCommandString ( ) & & ! WantsCompletion ( ) ) {
// FIXME: Abstract telling the completion to insert the completion
// character.
[lldb][NFC] Remove WordComplete mode, make result array indexed from 0 and remove any undocumented/redundant return values
Summary:
We still have some leftovers of the old completion API in the internals of
LLDB that haven't been replaced by the new CompletionRequest. These leftovers
are:
* The return values (int/size_t) in all completion functions.
* Our result array that starts indexing at 1.
* `WordComplete` mode.
I didn't replace them back then because it's tricky to figure out what exactly they
are used for and the completion code is relatively untested. I finally got around
to writing more tests for the API and understanding the semantics, so I think it's
a good time to get rid of them.
A few words why those things should be removed/replaced:
* The return values are really cryptic, partly redundant and rarely documented.
They are also completely ignored by Xcode, so whatever information they contain will end up
breaking Xcode's completion mechanism. They are also partly impossible to even implement
as we assign negative values special meaning and our completion API sometimes returns size_t.
Completion functions are supposed to return -2 to rewrite the current line. We seem to use this
in some untested code path to expand the history repeat character to the full command, but
I haven't figured out why that doesn't work at the moment.
Completion functions return -1 to 'insert the completion character', but that isn't implemented
(even though we seem to activate this feature in LLDB sometimes).
All positive values have to match the number of results. This is obviously just redundant information
as the user can just look at the result list to get that information (which is what Xcode does).
* The result array that starts indexing at 1 is obviously unexpected. The first element of the array is
reserved for the common prefix of all completions (e.g. "foobar" and "footar" -> "foo"). The idea is
that we calculate this to make the life of the API caller easier, but obviously forcing people to have
1-based indices is not helpful (or even worse, forces them to manually copy the results to make it
0-based like Xcode has to do).
* The `WordComplete` mode indicates that LLDB should enter a space behind the completion. The
idea is that we let the top-level API know that we just provided a full completion. Interestingly we
`WordComplete` is just a single bool that somehow represents all N completions. And we always
provide full completions in LLDB, so in theory it should always be true.
The only use it currently serves is providing redundant information about whether we have a single
definitive completion or not (which we already know from the number of results we get).
This patch essentially removes `WordComplete` mode and makes the result array indexed from 0.
It also removes all return values from all internal completion functions. The only non-redundant information
they contain is about rewriting the current line (which is broken), so that functionality was moved
to the CompletionRequest API. So you can now do `addCompletion("blub", "description", CompletionMode::RewriteLine)`
to do the same.
For the SB API we emulate the old behaviour by making the array indexed from 1 again with the common
prefix at index 0. I didn't keep the special negative return codes as we either never sent them before (e.g. -2) or we
didn't even implement them in the Editline handler (e.g. -1).
I tried to keep this patch minimal and I'm aware we can probably now even further simplify a bunch of related code,
but I would prefer doing this in follow-up NFC commits
Reviewers: JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arphaman, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D66536
llvm-svn: 369624
2019-08-22 15:41:23 +08:00
return ;
2016-09-07 04:57:50 +08:00
} else {
2012-01-20 08:59:19 +08:00
// Can we do anything generic with the options?
2012-01-20 06:16:06 +08:00
Options * cur_options = GetOptions ( ) ;
2020-06-10 01:21:09 +08:00
CommandReturnObject result ( m_interpreter . GetDebugger ( ) . GetUseColor ( ) ) ;
2012-01-20 06:16:06 +08:00
OptionElementVector opt_element_vector ;
2016-09-07 04:57:50 +08:00
2012-01-20 06:16:06 +08:00
if ( cur_options ! = nullptr ) {
Refactoring for for the internal command line completion API (NFC)
Summary:
This patch refactors the internal completion API. It now takes (as far as possible) a single
CompletionRequest object instead o half a dozen in/out/in-out parameters. The CompletionRequest
contains a common superset of the different parameters as far as it makes sense. This includes
the raw command line string and raw cursor position, which should make the `expr` command
possible to implement (at least without hacks that reconstruct the command line from the args).
This patch is not intended to change the observable behavior of lldb in any way. It's also as
minimal as possible and doesn't attempt to fix all the problems the API has.
Some Q&A:
Q: Why is this not fixing all the problems in the completion API?
A: Because is a blocker for the expr command completion which I want to get in ASAP. This is the
smallest patch that unblocks the expr completion patch and which allows trivial refactoring in the future.
The patch also doesn't really change the internal information flow in the API, so that hopefully
saves us from ever having to revert and resubmit this humongous patch.
Q: Can we merge all the copy-pasted code in the completion methods
(like computing the current incomplete arg) into CompletionRequest class?
A: Yes, but it's out of scope for this patch.
Q: Why the `word_complete = request.GetWordComplete(); ... ` pattern?
A: I don't want to add a getter that returns a reference to the internal integer. So we have
to use a temporary variable and the Getter/Setter instead. We don't throw exceptions
from what I can tell, so the behavior doesn't change.
Q: Why are we not owning the list of matches?
A: Because that's how the previous API works. But that should be fixed too (in another patch).
Q: Can we make the constructor simpler and compute some of the values from the plain command?
A: I think this works, but I rather want to have this in a follow up commit. Especially when making nested
request it's a bit awkward that the parsed arguments behave as both input/output (as we should in theory
propagate the changes on the nested request back to the parent request if we don't want to change the
behavior too much).
Q: Can't we pass one const request object and then just return another result object instead of mixing
them together in one in/out parameter?
A: It's hard to get keep the same behavior with that pattern, but I think we can also get a nice API with just
a single request object. If we make all input parameters read-only, we have a clear separation between what
is actually an input and what an output parameter (and hopefully we get rid of the in-out parameters).
Q: Can we throw out the 'match' variables that are not implemented according to the comment?
A: We currently just forward them as in the old code to the different methods, even though I think
they are really not used. We can easily remove and readd them once every single completion method just
takes a CompletionRequest, but for now I prefer NFC behavior from the perspective of the API user.
Reviewers: davide, jingham, labath
Reviewed By: jingham
Subscribers: mgorny, friss, lldb-commits
Differential Revision: https://reviews.llvm.org/D48796
llvm-svn: 336146
2018-07-03 05:29:56 +08:00
opt_element_vector = cur_options - > ParseForCompletion (
request . GetParsedLine ( ) , request . GetCursorIndex ( ) ) ;
2016-09-07 04:57:50 +08:00
2018-07-14 02:28:14 +08:00
bool handled_by_options = cur_options - > HandleOptionCompletion (
request , opt_element_vector , GetCommandInterpreter ( ) ) ;
2010-06-09 00:52:24 +08:00
if ( handled_by_options )
[lldb][NFC] Remove WordComplete mode, make result array indexed from 0 and remove any undocumented/redundant return values
Summary:
We still have some leftovers of the old completion API in the internals of
LLDB that haven't been replaced by the new CompletionRequest. These leftovers
are:
* The return values (int/size_t) in all completion functions.
* Our result array that starts indexing at 1.
* `WordComplete` mode.
I didn't replace them back then because it's tricky to figure out what exactly they
are used for and the completion code is relatively untested. I finally got around
to writing more tests for the API and understanding the semantics, so I think it's
a good time to get rid of them.
A few words why those things should be removed/replaced:
* The return values are really cryptic, partly redundant and rarely documented.
They are also completely ignored by Xcode, so whatever information they contain will end up
breaking Xcode's completion mechanism. They are also partly impossible to even implement
as we assign negative values special meaning and our completion API sometimes returns size_t.
Completion functions are supposed to return -2 to rewrite the current line. We seem to use this
in some untested code path to expand the history repeat character to the full command, but
I haven't figured out why that doesn't work at the moment.
Completion functions return -1 to 'insert the completion character', but that isn't implemented
(even though we seem to activate this feature in LLDB sometimes).
All positive values have to match the number of results. This is obviously just redundant information
as the user can just look at the result list to get that information (which is what Xcode does).
* The result array that starts indexing at 1 is obviously unexpected. The first element of the array is
reserved for the common prefix of all completions (e.g. "foobar" and "footar" -> "foo"). The idea is
that we calculate this to make the life of the API caller easier, but obviously forcing people to have
1-based indices is not helpful (or even worse, forces them to manually copy the results to make it
0-based like Xcode has to do).
* The `WordComplete` mode indicates that LLDB should enter a space behind the completion. The
idea is that we let the top-level API know that we just provided a full completion. Interestingly we
`WordComplete` is just a single bool that somehow represents all N completions. And we always
provide full completions in LLDB, so in theory it should always be true.
The only use it currently serves is providing redundant information about whether we have a single
definitive completion or not (which we already know from the number of results we get).
This patch essentially removes `WordComplete` mode and makes the result array indexed from 0.
It also removes all return values from all internal completion functions. The only non-redundant information
they contain is about rewriting the current line (which is broken), so that functionality was moved
to the CompletionRequest API. So you can now do `addCompletion("blub", "description", CompletionMode::RewriteLine)`
to do the same.
For the SB API we emulate the old behaviour by making the array indexed from 1 again with the common
prefix at index 0. I didn't keep the special negative return codes as we either never sent them before (e.g. -2) or we
didn't even implement them in the Editline handler (e.g. -1).
I tried to keep this patch minimal and I'm aware we can probably now even further simplify a bunch of related code,
but I would prefer doing this in follow-up NFC commits
Reviewers: JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arphaman, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D66536
llvm-svn: 369624
2019-08-22 15:41:23 +08:00
return ;
2010-06-09 00:52:24 +08:00
}
// If we got here, the last word is not an option or an option argument.
[lldb][NFC] Remove WordComplete mode, make result array indexed from 0 and remove any undocumented/redundant return values
Summary:
We still have some leftovers of the old completion API in the internals of
LLDB that haven't been replaced by the new CompletionRequest. These leftovers
are:
* The return values (int/size_t) in all completion functions.
* Our result array that starts indexing at 1.
* `WordComplete` mode.
I didn't replace them back then because it's tricky to figure out what exactly they
are used for and the completion code is relatively untested. I finally got around
to writing more tests for the API and understanding the semantics, so I think it's
a good time to get rid of them.
A few words why those things should be removed/replaced:
* The return values are really cryptic, partly redundant and rarely documented.
They are also completely ignored by Xcode, so whatever information they contain will end up
breaking Xcode's completion mechanism. They are also partly impossible to even implement
as we assign negative values special meaning and our completion API sometimes returns size_t.
Completion functions are supposed to return -2 to rewrite the current line. We seem to use this
in some untested code path to expand the history repeat character to the full command, but
I haven't figured out why that doesn't work at the moment.
Completion functions return -1 to 'insert the completion character', but that isn't implemented
(even though we seem to activate this feature in LLDB sometimes).
All positive values have to match the number of results. This is obviously just redundant information
as the user can just look at the result list to get that information (which is what Xcode does).
* The result array that starts indexing at 1 is obviously unexpected. The first element of the array is
reserved for the common prefix of all completions (e.g. "foobar" and "footar" -> "foo"). The idea is
that we calculate this to make the life of the API caller easier, but obviously forcing people to have
1-based indices is not helpful (or even worse, forces them to manually copy the results to make it
0-based like Xcode has to do).
* The `WordComplete` mode indicates that LLDB should enter a space behind the completion. The
idea is that we let the top-level API know that we just provided a full completion. Interestingly we
`WordComplete` is just a single bool that somehow represents all N completions. And we always
provide full completions in LLDB, so in theory it should always be true.
The only use it currently serves is providing redundant information about whether we have a single
definitive completion or not (which we already know from the number of results we get).
This patch essentially removes `WordComplete` mode and makes the result array indexed from 0.
It also removes all return values from all internal completion functions. The only non-redundant information
they contain is about rewriting the current line (which is broken), so that functionality was moved
to the CompletionRequest API. So you can now do `addCompletion("blub", "description", CompletionMode::RewriteLine)`
to do the same.
For the SB API we emulate the old behaviour by making the array indexed from 1 again with the common
prefix at index 0. I didn't keep the special negative return codes as we either never sent them before (e.g. -2) or we
didn't even implement them in the Editline handler (e.g. -1).
I tried to keep this patch minimal and I'm aware we can probably now even further simplify a bunch of related code,
but I would prefer doing this in follow-up NFC commits
Reviewers: JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arphaman, abidh, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D66536
llvm-svn: 369624
2019-08-22 15:41:23 +08:00
HandleArgumentCompletion ( request , opt_element_vector ) ;
2010-06-09 00:52:24 +08:00
}
}
2016-11-13 10:50:32 +08:00
bool CommandObject : : HelpTextContainsWord ( llvm : : StringRef search_word ,
2016-03-23 09:21:55 +08:00
bool search_short_help ,
bool search_long_help ,
bool search_syntax ,
bool search_options ) {
2010-06-09 00:52:24 +08:00
std : : string options_usage_help ;
2016-09-07 04:57:50 +08:00
2010-06-09 00:52:24 +08:00
bool found_word = false ;
2016-09-07 04:57:50 +08:00
2016-11-13 04:41:02 +08:00
llvm : : StringRef short_help = GetHelp ( ) ;
llvm : : StringRef long_help = GetHelpLong ( ) ;
llvm : : StringRef syntax_help = GetSyntax ( ) ;
2016-09-07 04:57:50 +08:00
2021-06-24 16:06:42 +08:00
if ( search_short_help & & short_help . contains_insensitive ( search_word ) )
2010-06-09 00:52:24 +08:00
found_word = true ;
2021-06-24 16:06:42 +08:00
else if ( search_long_help & & long_help . contains_insensitive ( search_word ) )
2010-06-09 00:52:24 +08:00
found_word = true ;
2021-06-24 16:06:42 +08:00
else if ( search_syntax & & syntax_help . contains_insensitive ( search_word ) )
2010-06-09 00:52:24 +08:00
found_word = true ;
2016-09-07 04:57:50 +08:00
2014-04-20 08:31:37 +08:00
if ( ! found_word & & search_options & & GetOptions ( ) ! = nullptr ) {
2010-06-09 00:52:24 +08:00
StreamString usage_help ;
2016-08-12 07:51:28 +08:00
GetOptions ( ) - > GenerateOptionUsage (
usage_help , this ,
2016-03-12 10:45:34 +08:00
GetCommandInterpreter ( ) . GetDebugger ( ) . GetTerminalWidth ( ) ) ;
2016-11-13 10:50:32 +08:00
if ( ! usage_help . Empty ( ) ) {
llvm : : StringRef usage_text = usage_help . GetString ( ) ;
2021-06-24 16:06:42 +08:00
if ( usage_text . contains_insensitive ( search_word ) )
2010-06-09 00:52:24 +08:00
found_word = true ;
}
2016-09-07 04:57:50 +08:00
}
2010-06-09 00:52:24 +08:00
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
2018-07-11 04:17:38 +08:00
bool CommandObject : : ParseOptionsAndNotify ( Args & args ,
CommandReturnObject & result ,
OptionGroupOptions & group_options ,
ExecutionContext & exe_ctx ) {
if ( ! ParseOptions ( args , result ) )
return false ;
Status error ( group_options . NotifyOptionParsingFinished ( & exe_ctx ) ) ;
if ( error . Fail ( ) ) {
result . AppendError ( error . AsCString ( ) ) ;
return false ;
}
return true ;
}
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 ) {
2014-04-02 11:51:35 +08:00
if ( static_cast < size_t > ( idx ) < m_arguments . size ( ) )
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 & ( m_arguments [ idx ] ) ;
2014-04-20 08:31:37 +08:00
return nullptr ;
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
}
2015-05-13 08:25:54 +08:00
const CommandObject : : ArgumentTableEntry *
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 : : FindArgumentDataByType ( CommandArgumentType arg_type ) {
const ArgumentTableEntry * table = CommandObject : : GetArgumentTable ( ) ;
for ( int i = 0 ; i < eArgTypeLastArg ; + + i )
if ( table [ i ] . arg_type = = arg_type )
2015-05-13 08:25:54 +08:00
return & ( table [ i ] ) ;
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
2014-04-20 08:31:37 +08:00
return nullptr ;
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 : : GetArgumentHelp ( Stream & str , CommandArgumentType arg_type ,
CommandInterpreter & interpreter ) {
const ArgumentTableEntry * table = CommandObject : : GetArgumentTable ( ) ;
2015-05-13 08:25:54 +08:00
const ArgumentTableEntry * entry = & ( table [ arg_type ] ) ;
2016-09-07 04:57:50 +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
// The table is *supposed* to be kept in arg_type order, but someone *could*
// have messed it up...
2016-09-07 04:57:50 +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
if ( entry - > arg_type ! = arg_type )
entry = CommandObject : : FindArgumentDataByType ( arg_type ) ;
2016-09-07 04:57:50 +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
if ( ! entry )
return ;
2016-09-07 04:57:50 +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
StreamString name_str ;
name_str . Printf ( " <%s> " , entry - > arg_name ) ;
2016-09-07 04:57:50 +08:00
2011-07-08 10:51:01 +08:00
if ( entry - > help_function ) {
2016-11-13 10:08:22 +08:00
llvm : : StringRef help_text = entry - > help_function ( ) ;
2011-07-07 08:38:40 +08:00
if ( ! entry - > help_function . self_formatting ) {
2016-11-17 05:15:24 +08:00
interpreter . OutputFormattedHelpText ( str , name_str . GetString ( ) , " -- " ,
2011-07-07 08:38:40 +08:00
help_text , name_str . GetSize ( ) ) ;
} else {
2016-11-17 05:15:24 +08:00
interpreter . OutputHelpText ( str , name_str . GetString ( ) , " -- " , help_text ,
2011-07-07 08:38:40 +08:00
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
2016-11-17 05:15:24 +08:00
interpreter . OutputFormattedHelpText ( str , name_str . GetString ( ) , " -- " ,
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
entry - > help_text , name_str . GetSize ( ) ) ;
}
const char * CommandObject : : GetArgumentName ( CommandArgumentType arg_type ) {
2015-05-13 08:25:54 +08:00
const ArgumentTableEntry * entry =
& ( CommandObject : : GetArgumentTable ( ) [ arg_type ] ) ;
2010-10-02 03:59:14 +08:00
// 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 ;
2016-11-17 05:15:24 +08:00
return nullptr ;
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-25 05:19:54 +08:00
bool CommandObject : : IsPairType ( ArgumentRepetitionType arg_repeat_type ) {
2018-12-15 08:15:33 +08:00
return ( arg_repeat_type = = eArgRepeatPairPlain ) | |
( arg_repeat_type = = eArgRepeatPairOptional ) | |
( arg_repeat_type = = eArgRepeatPairPlus ) | |
( arg_repeat_type = = eArgRepeatPairStar ) | |
( arg_repeat_type = = eArgRepeatPairRange ) | |
( arg_repeat_type = = eArgRepeatPairRangeOptional ) ;
2010-10-05 06:28:36 +08:00
}
2012-02-08 09:13:31 +08:00
static CommandObject : : CommandArgumentEntry
OptSetFiltered ( uint32_t opt_set_mask ,
CommandObject : : CommandArgumentEntry & cmd_arg_entry ) {
CommandObject : : CommandArgumentEntry ret_val ;
for ( unsigned i = 0 ; i < cmd_arg_entry . size ( ) ; + + i )
if ( opt_set_mask & cmd_arg_entry [ i ] . arg_opt_set_association )
ret_val . push_back ( cmd_arg_entry [ i ] ) ;
return ret_val ;
}
2018-05-01 00:49:04 +08:00
// Default parameter value of opt_set_mask is LLDB_OPT_SET_ALL, which means
// take all the argument data into account. On rare cases where some argument
// sticks with certain option sets, this function returns the option set
// filtered args.
2012-02-08 09:13:31 +08:00
void CommandObject : : GetFormattedCommandArguments ( Stream & str ,
uint32_t opt_set_mask ) {
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 num_args = m_arguments . size ( ) ;
for ( int i = 0 ; i < num_args ; + + i ) {
if ( i > 0 )
str . Printf ( " " ) ;
2012-02-08 09:13:31 +08:00
CommandArgumentEntry arg_entry =
opt_set_mask = = LLDB_OPT_SET_ALL
? m_arguments [ i ]
: OptSetFiltered ( opt_set_mask , m_arguments [ i ] ) ;
2021-11-26 18:04:57 +08:00
// This argument is not associated with the current option set, so skip it.
if ( arg_entry . empty ( ) )
continue ;
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 num_alternatives = arg_entry . size ( ) ;
2016-09-07 04:57:50 +08:00
2010-10-05 06:28:36 +08:00
if ( ( num_alternatives = = 2 ) & & IsPairType ( arg_entry [ 0 ] . arg_repetition ) ) {
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
2018-05-01 00:49:04 +08:00
// added we will notice the missing case statement(s).
2011-03-24 06:31:13 +08:00
case eArgRepeatPlain :
case eArgRepeatOptional :
case eArgRepeatPlus :
case eArgRepeatStar :
case eArgRepeatRange :
// These should not be reached, as they should fail the IsPairType test
// above.
break ;
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 {
StreamString names ;
for ( int j = 0 ; j < num_alternatives ; + + j ) {
if ( j > 0 )
names . Printf ( " | " ) ;
names . Printf ( " %s " , GetArgumentName ( arg_entry [ j ] . arg_type ) ) ;
}
2016-11-17 05:15:24 +08:00
2020-01-29 03:23:46 +08:00
std : : string name_str = std : : string ( names . GetString ( ) ) ;
2010-10-05 06:28:36 +08:00
switch ( arg_entry [ 0 ] . arg_repetition ) {
case eArgRepeatPlain :
2016-11-17 05:15:24 +08:00
str . Printf ( " <%s> " , name_str . c_str ( ) ) ;
2010-10-05 06:28:36 +08:00
break ;
case eArgRepeatPlus :
2016-11-17 05:15:24 +08:00
str . Printf ( " <%s> [<%s> [...]] " , name_str . c_str ( ) , name_str . c_str ( ) ) ;
2010-10-05 06:28:36 +08:00
break ;
case eArgRepeatStar :
2016-11-17 05:15:24 +08:00
str . Printf ( " [<%s> [<%s> [...]]] " , name_str . c_str ( ) , name_str . c_str ( ) ) ;
2010-10-05 06:28:36 +08:00
break ;
case eArgRepeatOptional :
2016-11-17 05:15:24 +08:00
str . Printf ( " [<%s>] " , name_str . c_str ( ) ) ;
2010-10-05 06:28:36 +08:00
break ;
case eArgRepeatRange :
2016-11-17 05:15:24 +08:00
str . Printf ( " <%s_1> .. <%s_n> " , name_str . c_str ( ) , name_str . c_str ( ) ) ;
2011-03-24 06:31:13 +08:00
break ;
// Explicitly test for all the rest of the cases, so if new types get
2018-05-01 00:49:04 +08:00
// added we will notice the missing case statement(s).
2011-03-24 06:31:13 +08:00
case eArgRepeatPairPlain :
case eArgRepeatPairOptional :
case eArgRepeatPairPlus :
case eArgRepeatPairStar :
case eArgRepeatPairRange :
case eArgRepeatPairRangeOptional :
// These should not be hit, as they should pass the IsPairType test
2018-05-01 00:49:04 +08:00
// above, and control should have gone into the other branch of the if
// statement.
2011-03-24 06:31:13 +08:00
break ;
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
}
}
2016-09-07 04:57:50 +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
}
2016-12-09 09:08:29 +08:00
CommandArgumentType
CommandObject : : LookupArgumentName ( llvm : : StringRef arg_name ) {
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
CommandArgumentType return_type = eArgTypeLastArg ;
2016-12-09 09:08:29 +08:00
arg_name = arg_name . ltrim ( ' < ' ) . rtrim ( ' > ' ) ;
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-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 )
2016-12-09 09:08:29 +08:00
if ( arg_name = = table [ i ] . arg_name )
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 ;
}
2016-11-13 10:08:22 +08:00
static llvm : : StringRef RegisterNameHelpTextCallback ( ) {
2012-08-24 07:37:31 +08:00
return " Register names can be specified using the architecture specific "
" names. "
2012-08-24 07:47:08 +08:00
" They can also be specified using generic names. Not all generic "
" entities have "
" registers backing them on all architectures. When they don't the "
" generic name "
" will return an error. \n "
2012-08-24 07:37:31 +08:00
" The generic names defined in lldb are: \n "
" \n "
" pc - program counter register \n "
" ra - return address register \n "
" fp - frame pointer register \n "
" sp - stack pointer register \n "
2012-08-24 07:47:08 +08:00
" flags - the flags register \n "
2012-08-24 07:37:31 +08:00
" arg{1-6} - integer argument passing registers. \n " ;
}
2016-11-13 10:08:22 +08:00
static llvm : : StringRef BreakpointIDHelpTextCallback ( ) {
2016-07-15 06:03:10 +08:00
return " Breakpoints are identified using 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 "
" number, or the major number followed by a dot and the location "
" number (e.g. "
" 3 or 3.2 could both be valid breakpoint IDs.) " ;
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
}
2016-11-13 10:08:22 +08:00
static llvm : : StringRef BreakpointIDRangeHelpTextCallback ( ) {
2016-07-15 06:03:10 +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
}
2016-11-13 10:08:22 +08:00
static llvm : : StringRef BreakpointNameHelpTextCallback ( ) {
2014-12-17 07:40:14 +08:00
return " A name that can be added to a breakpoint when it is created, or "
" later "
2016-07-15 06:03:10 +08:00
" on with the \" breakpoint name add \" command. "
" Breakpoint names can be used to specify breakpoints in all the "
" places breakpoint IDs "
" and breakpoint ID ranges can be used. As such they provide a "
" convenient way to group breakpoints, "
" and to operate on breakpoints you create without having to track the "
" breakpoint number. "
" Note, the attributes you set when using a breakpoint name in a "
" breakpoint command don't "
" adhere to the name, but instead are set individually on all the "
" breakpoints currently tagged with that "
" name. Future breakpoints "
" tagged with that name will not pick up the attributes previously "
" given using that name. "
" In order to distinguish breakpoint names from breakpoint IDs and "
" ranges, "
" names must start with a letter from a-z or A-Z and cannot contain "
" spaces, \" . \" or \" - \" . "
" Also, breakpoint names can only be applied to breakpoints, not to "
" breakpoint locations. " ;
2014-12-17 07:40:14 +08:00
}
2016-11-13 10:08:22 +08:00
static llvm : : StringRef GDBFormatHelpTextCallback ( ) {
2011-10-27 02:35:21 +08:00
return " A GDB format consists of a repeat count, a format letter and a size "
" letter. "
" The repeat count is optional and defaults to 1. The format letter is "
" optional "
" and defaults to the previous format that was used. The size letter "
" is optional "
" and defaults to the previous size that was used. \n "
" \n "
" Format letters include: \n "
" o - octal \n "
" x - hexadecimal \n "
" d - decimal \n "
" u - unsigned decimal \n "
" t - binary \n "
" f - float \n "
" a - address \n "
" i - instruction \n "
" c - char \n "
" s - string \n "
" T - OSType \n "
" A - float as hex \n "
2016-09-07 04:57:50 +08:00
" \n "
2011-07-02 08:25:22 +08:00
" Size letters include: \n "
" b - 1 byte (byte) \n "
" h - 2 bytes (halfword) \n "
" w - 4 bytes (word) \n "
" g - 8 bytes (giant) \n "
2016-09-07 04:57:50 +08:00
" \n "
2011-07-02 08:25:22 +08:00
" Example formats: \n "
" 32xb - show 32 1 byte hexadecimal integer values \n "
2011-07-07 08:38:40 +08:00
" 16xh - show 16 2 byte hexadecimal integer values \n "
" 64 - show 64 2 byte hexadecimal integer values (format and size "
" from the last format) \n "
2011-07-02 08:25:22 +08:00
" dw - show 1 4 byte decimal integer value \n " ;
}
2016-11-13 10:08:22 +08:00
static llvm : : StringRef FormatHelpTextCallback ( ) {
static std : : string help_text ;
2016-09-07 04:57:50 +08:00
2016-11-13 10:08:22 +08:00
if ( ! help_text . empty ( ) )
return help_text ;
2012-10-23 08:50:09 +08:00
2011-07-07 08:38:40 +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 ) ) {
if ( f ! = eFormatDefault )
sstr . PutChar ( ' \n ' ) ;
2016-09-07 04:57:50 +08:00
2011-07-07 08:38:40 +08:00
char format_char = FormatManager : : GetFormatAsFormatChar ( f ) ;
if ( format_char )
sstr . Printf ( " '%c' or " , format_char ) ;
2016-09-07 04:57:50 +08:00
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
sstr . Printf ( " \" %s \" " , FormatManager : : GetFormatAsCString ( f ) ) ;
2016-09-07 04:57:50 +08:00
}
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
sstr . Flush ( ) ;
2016-09-07 04:57:50 +08:00
2020-01-29 03:23:46 +08:00
help_text = std : : string ( sstr . GetString ( ) ) ;
2016-09-07 04:57:50 +08:00
2016-11-13 10:08:22 +08:00
return help_text ;
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
}
2016-11-13 10:08:22 +08:00
static llvm : : StringRef LanguageTypeHelpTextCallback ( ) {
static std : : string help_text ;
2016-09-07 04:57:50 +08:00
2016-11-13 10:08:22 +08:00
if ( ! help_text . empty ( ) )
return help_text ;
2016-09-07 04:57:50 +08:00
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
StreamString sstr ;
sstr < < " One of the following languages: \n " ;
2016-09-07 04:57:50 +08:00
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
Language : : PrintAllLanguages ( sstr , " " , " \n " ) ;
2016-09-07 04:57:50 +08:00
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
sstr . Flush ( ) ;
2016-09-07 04:57:50 +08:00
2020-01-29 03:23:46 +08:00
help_text = std : : string ( sstr . GetString ( ) ) ;
2016-09-07 04:57:50 +08:00
2016-11-13 10:08:22 +08:00
return help_text ;
2011-07-02 08:25:22 +08:00
}
2016-11-13 10:08:22 +08:00
static llvm : : StringRef SummaryStringHelpTextCallback ( ) {
2015-07-14 13:48:36 +08:00
return " A summary string is a way to extract information from variables in "
2011-07-07 08:38:40 +08:00
" order to present them using a summary. \n "
" Summary strings contain static text, variables, scopes and control "
" sequences: \n "
2015-07-14 13:48:36 +08:00
" - Static text can be any sequence of non-special characters, i.e. "
" anything but '{', '}', '$', or ' \\ '. \n "
2011-07-07 08:38:40 +08:00
" - Variables are sequences of characters beginning with ${, ending "
2015-07-14 13:48:36 +08:00
" 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 "
2011-07-07 08:38:40 +08:00
" - Control sequences are the usual C/C++ ' \\ a', ' \\ n', ..., plus "
" ' \\ $', ' \\ {' and ' \\ }'. \n "
2015-07-14 13:48:36 +08:00
" 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 "
" ${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. "
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 the object is not a pointer, doing so will cause an error. For "
2015-07-14 13:48:36 +08:00
" additional details on expression paths, you can type 'help "
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
" expr-path'. \n "
2015-07-14 13:48:36 +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 "
2011-07-07 08:38:40 +08:00
" - 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 "
2015-07-14 13:48:36 +08:00
" 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 "
2011-07-07 08:38:40 +08:00
" checking) \n "
2015-07-14 13:48:36 +08:00
" If you are trying to display an array for which the size is known, "
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
" you can also use [] instead of giving an exact range. This has the "
" effect of showing items 0 thru size - 1. \n "
2015-07-14 13:48:36 +08:00
" 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 "
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
" 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 "
2015-07-14 13:48:36 +08:00
" Another variable that you can use in summary strings is ${svar . "
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
" This sequence works exactly like ${var, including the fact that "
2015-07-14 13:48:36 +08:00
" ${*svar is an allowed sequence, but uses "
" the object's synthetic children provider instead of the actual "
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
" objects. For instance, if you are using STL synthetic children "
" providers, the following summary string would "
2015-07-14 13:48:36 +08:00
" count the number of actual elements stored in an std::list: \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
" type summary add -s \" ${svar%#} \" -x \" std::list< \" " ;
2015-07-14 13:48:36 +08:00
}
2016-11-13 10:08:22 +08:00
static llvm : : StringRef ExprPathHelpTextCallback ( ) {
2013-06-12 09:50:57 +08:00
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 "
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
" For instance, given a class: \n "
" class foo { \n "
" int a; \n "
" int b; . \n "
2013-06-12 09:50:57 +08:00
" foo* next; \n "
2016-09-07 04:57:50 +08:00
" }; \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
" the expression to read item b in the item pointed to by next for foo "
" aFoo would be aFoo.next->b. \n "
2013-06-12 09:50:57 +08:00
" Given that aFoo could just be any object of type foo, the string "
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
" '.next->b' is the expression path, because it can be attached to any "
" foo instance to achieve the effect. \n "
2013-06-12 09:50:57 +08:00
" Expression paths in LLDB include dot (.) and arrow (->) operators, "
" and most commands using expression paths have ways to also accept "
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
" the star (*) operator. \n "
2013-06-12 09:50:57 +08:00
" The meaning of these operators is the same as the usual one given to "
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
" 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]' "
2013-06-12 09:50:57 +08:00
" as an expression path (where n and m are any positive integers, e.g. "
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
" [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 "
2013-06-12 09:50:57 +08:00
" 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). " ;
}
void CommandObject : : FormatLongHelpText ( Stream & output_strm ,
2016-11-13 04:41:02 +08:00
llvm : : StringRef long_help ) {
2013-06-12 09:50:57 +08:00
CommandInterpreter & interpreter = GetCommandInterpreter ( ) ;
2020-01-29 03:23:46 +08:00
std : : stringstream lineStream { std : : string ( long_help ) } ;
2016-07-15 06:03:10 +08:00
std : : string line ;
while ( std : : getline ( lineStream , line ) ) {
if ( line . empty ( ) ) {
output_strm < < " \n " ;
2016-08-12 07:51:28 +08:00
continue ;
2013-06-12 09:50:57 +08:00
}
2016-07-15 06:03:10 +08:00
size_t result = line . find_first_not_of ( " \t " ) ;
if ( result = = std : : string : : npos ) {
result = 0 ;
2013-06-12 09:50:57 +08:00
}
2015-07-14 13:48:36 +08:00
std : : string whitespace_prefix = line . substr ( 0 , result ) ;
std : : string remainder = line . substr ( result ) ;
2020-06-13 12:13:20 +08:00
interpreter . OutputFormattedHelpText ( output_strm , whitespace_prefix ,
remainder ) ;
2016-09-07 04:57:50 +08:00
}
2013-06-12 09:50:57 +08:00
}
2011-09-23 06:34:09 +08:00
void CommandObject : : GenerateHelpText ( CommandReturnObject & result ) {
2011-09-21 09:00:02 +08:00
GenerateHelpText ( result . GetOutputStream ( ) ) ;
result . SetStatus ( eReturnStatusSuccessFinishNoResult ) ;
2016-09-07 04:57:50 +08:00
}
2011-09-21 09:00:02 +08:00
void CommandObject : : GenerateHelpText ( Stream & output_strm ) {
CommandInterpreter & interpreter = GetCommandInterpreter ( ) ;
2020-06-16 00:25:33 +08:00
std : : string help_text ( GetHelp ( ) ) ;
2011-09-21 09:00:02 +08:00
if ( WantsRawCommandString ( ) ) {
help_text . append ( " Expects 'raw' input (see 'help raw-input'.) " ) ;
2020-06-16 00:25:33 +08:00
}
interpreter . OutputFormattedHelpText ( output_strm , " " , help_text ) ;
2016-11-15 07:23:31 +08:00
output_strm < < " \n Syntax: " < < GetSyntax ( ) < < " \n " ;
2016-07-15 06:03:10 +08:00
Options * options = GetOptions ( ) ;
if ( options ! = nullptr ) {
2016-08-12 07:51:28 +08:00
options - > GenerateOptionUsage (
2011-09-21 09:00:02 +08:00
output_strm , this ,
2016-03-12 10:45:34 +08:00
GetCommandInterpreter ( ) . GetDebugger ( ) . GetTerminalWidth ( ) ) ;
2016-09-07 04:57:50 +08:00
}
2016-11-13 04:41:02 +08:00
llvm : : StringRef long_help = GetHelpLong ( ) ;
if ( ! long_help . empty ( ) ) {
2011-09-21 09:00:02 +08:00
FormatLongHelpText ( output_strm , long_help ) ;
2016-09-07 04:57:50 +08:00
}
2016-07-15 06:03:10 +08:00
if ( ! IsDashDashCommand ( ) & & options & & options - > NumCommandOptions ( ) > 0 ) {
if ( WantsRawCommandString ( ) & & ! WantsCompletion ( ) ) {
// Emit the message about using ' -- ' between the end of the command
2018-05-01 00:49:04 +08:00
// options and the raw input conditionally, i.e., only if the command
// object does not want completion.
2016-07-15 06:03:10 +08:00
interpreter . OutputFormattedHelpText (
output_strm , " " , " " ,
" \n Important Note: Because this command takes 'raw' input, if you "
" use any command options "
" you must use ' -- ' between the end of the command options and the "
" beginning of the raw input. " ,
2016-09-07 04:57:50 +08:00
1 ) ;
2016-07-15 06:03:10 +08:00
} else if ( GetNumArgumentEntries ( ) > 0 ) {
// Also emit a warning about using "--" in case you are using a command
// that takes options and arguments.
interpreter . OutputFormattedHelpText (
output_strm , " " , " " ,
2011-09-21 09:00:02 +08:00
" \n This command takes options and free-form arguments. If your "
2016-07-15 06:03:10 +08:00
" arguments resemble "
2011-09-21 09:00:02 +08:00
" option specifiers (i.e., they start with a - or --), you must use "
2016-07-15 06:03:10 +08:00
" ' -- ' between "
2011-09-21 09:00:02 +08:00
" the end of the command options and the beginning of the arguments. " ,
1 ) ;
2016-09-07 04:57:50 +08:00
}
}
}
2011-09-21 09:00:02 +08:00
2011-09-23 06:34:09 +08:00
void CommandObject : : AddIDsArgumentData ( CommandArgumentEntry & arg ,
CommandArgumentType ID ,
CommandArgumentType IDRange ) {
2011-09-21 09:00:02 +08:00
CommandArgumentData id_arg ;
2011-09-21 09:04:49 +08:00
CommandArgumentData id_range_arg ;
2016-09-07 04:57:50 +08:00
2011-09-21 09:00:02 +08:00
// Create the first variant for the first (and only) argument for this
2011-09-21 09:04:49 +08:00
// 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 ;
2016-09-07 04:57:50 +08:00
2011-09-21 09:00:02 +08:00
// 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 ;
2016-09-07 04:57:50 +08:00
2011-09-21 09:04:49 +08:00
// The first (and only) argument for this command could be either an id or an
2018-05-01 00:49:04 +08:00
// id_range. Push both variants into the entry for the first argument for
// this command.
2011-09-21 09:00:02 +08:00
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 ) {
2015-04-03 04:57:38 +08:00
assert ( arg_type < eArgTypeLastArg & &
" Invalid argument type passed to GetArgumentTypeAsCString " ) ;
return g_arguments_data [ arg_type ] . arg_name ;
2011-02-20 10:15:07 +08:00
}
const char * CommandObject : : GetArgumentDescriptionAsCString (
const lldb : : CommandArgumentType arg_type ) {
2015-04-03 04:57:38 +08:00
assert ( arg_type < eArgTypeLastArg & &
" Invalid argument type passed to GetArgumentDescriptionAsCString " ) ;
return g_arguments_data [ arg_type ] . help_text ;
2011-02-20 10:15:07 +08:00
}
2019-08-27 02:12:44 +08:00
Target & CommandObject : : GetDummyTarget ( ) {
2020-11-10 07:25:59 +08:00
return m_interpreter . GetDebugger ( ) . GetDummyTarget ( ) ;
2014-11-22 09:42:44 +08:00
}
2019-08-27 02:12:44 +08:00
Target & CommandObject : : GetSelectedOrDummyTarget ( bool prefer_dummy ) {
2020-11-10 07:25:59 +08:00
return m_interpreter . GetDebugger ( ) . GetSelectedOrDummyTarget ( prefer_dummy ) ;
2014-11-22 09:42:44 +08:00
}
2019-08-31 17:41:25 +08:00
Target & CommandObject : : GetSelectedTarget ( ) {
assert ( m_flags . AnySet ( eCommandRequiresTarget | eCommandProcessMustBePaused |
eCommandProcessMustBeLaunched | eCommandRequiresFrame |
eCommandRequiresThread | eCommandRequiresProcess |
eCommandRequiresRegContext ) & &
" GetSelectedTarget called from object that may have no target " ) ;
return * m_interpreter . GetDebugger ( ) . GetSelectedTarget ( ) ;
}
2016-03-12 10:45:34 +08:00
Thread * CommandObject : : GetDefaultThread ( ) {
Thread * thread_to_use = m_exe_ctx . GetThreadPtr ( ) ;
if ( thread_to_use )
return thread_to_use ;
2016-09-07 04:57:50 +08:00
2016-03-12 10:45:34 +08:00
Process * process = m_exe_ctx . GetProcessPtr ( ) ;
if ( ! process ) {
Target * target = m_exe_ctx . GetTargetPtr ( ) ;
if ( ! target ) {
target = m_interpreter . GetDebugger ( ) . GetSelectedTarget ( ) . get ( ) ;
}
if ( target )
process = target - > GetProcessSP ( ) . get ( ) ;
2016-09-07 04:57:50 +08:00
}
2016-03-12 10:45:34 +08:00
if ( process )
return process - > GetThreadList ( ) . GetSelectedThread ( ) . get ( ) ;
else
return nullptr ;
}
2012-06-09 05:56:10 +08:00
bool CommandObjectParsed : : Execute ( const char * args_string ,
CommandReturnObject & result ) {
bool handled = false ;
Args cmd_args ( args_string ) ;
2014-08-06 08:10:12 +08:00
if ( HasOverrideCallback ( ) ) {
2012-06-09 05:56:10 +08:00
Args full_args ( GetCommandName ( ) ) ;
full_args . AppendArguments ( cmd_args ) ;
2014-08-06 08:10:12 +08:00
handled =
InvokeOverrideCallback ( full_args . GetConstArgumentVector ( ) , result ) ;
2016-09-07 04:57:50 +08:00
}
2012-06-09 05:56:10 +08:00
if ( ! handled ) {
2016-10-06 07:40:23 +08:00
for ( auto entry : llvm : : enumerate ( cmd_args . entries ( ) ) ) {
2019-09-13 19:26:48 +08:00
if ( ! entry . value ( ) . ref ( ) . empty ( ) & & entry . value ( ) . ref ( ) . front ( ) = = ' ` ' ) {
2012-06-09 05:56:10 +08:00
cmd_args . ReplaceArgumentAtIndex (
2017-03-14 01:12:12 +08:00
entry . index ( ) ,
m_interpreter . ProcessEmbeddedScriptCommands ( entry . value ( ) . c_str ( ) ) ) ;
2016-10-06 07:40:23 +08:00
}
2012-06-09 05:56:10 +08:00
}
Expanded the flags that can be set for a command object in lldb_private::CommandObject. This list of available flags are:
enum
{
//----------------------------------------------------------------------
// eFlagRequiresTarget
//
// Ensures a valid target is contained in m_exe_ctx prior to executing
// the command. If a target doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidTargetDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidTargetDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresTarget = (1u << 0),
//----------------------------------------------------------------------
// eFlagRequiresProcess
//
// Ensures a valid process is contained in m_exe_ctx prior to executing
// the command. If a process doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidProcessDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidProcessDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresProcess = (1u << 1),
//----------------------------------------------------------------------
// eFlagRequiresThread
//
// Ensures a valid thread is contained in m_exe_ctx prior to executing
// the command. If a thread doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidThreadDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidThreadDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresThread = (1u << 2),
//----------------------------------------------------------------------
// eFlagRequiresFrame
//
// Ensures a valid frame is contained in m_exe_ctx prior to executing
// the command. If a frame doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidFrameDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidFrameDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresFrame = (1u << 3),
//----------------------------------------------------------------------
// eFlagRequiresRegContext
//
// Ensures a valid register context (from the selected frame if there
// is a frame in m_exe_ctx, or from the selected thread from m_exe_ctx)
// is availble from m_exe_ctx prior to executing the command. If a
// target doesn't exist or is invalid, the command will fail and
// CommandObject::GetInvalidRegContextDescription() will be returned as
// the error. CommandObject subclasses can override the virtual function
// for GetInvalidRegContextDescription() to provide custom strings when
// needed.
//----------------------------------------------------------------------
eFlagRequiresRegContext = (1u << 4),
//----------------------------------------------------------------------
// eFlagTryTargetAPILock
//
// Attempts to acquire the target lock if a target is selected in the
// command interpreter. If the command object fails to acquire the API
// lock, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagTryTargetAPILock = (1u << 5),
//----------------------------------------------------------------------
// eFlagProcessMustBeLaunched
//
// Verifies that there is a launched process in m_exe_ctx, if there
// isn't, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagProcessMustBeLaunched = (1u << 6),
//----------------------------------------------------------------------
// eFlagProcessMustBePaused
//
// Verifies that there is a paused process in m_exe_ctx, if there
// isn't, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagProcessMustBePaused = (1u << 7)
};
Now each command object contains a "ExecutionContext m_exe_ctx;" member variable that gets initialized prior to running the command. The validity of the target objects in m_exe_ctx are checked to ensure that any target/process/thread/frame/reg context that are required are valid prior to executing the command. Each command object also contains a Mutex::Locker m_api_locker which gets used if eFlagTryTargetAPILock is set. This centralizes a lot of checking code that was previously and inconsistently implemented across many commands.
llvm-svn: 171990
2013-01-10 03:44:40 +08:00
if ( CheckRequirements ( result ) ) {
if ( ParseOptions ( cmd_args , result ) ) {
// Call the command-specific version of 'Execute', passing it the
// already processed arguments.
handled = DoExecute ( cmd_args , result ) ;
2016-09-07 04:57:50 +08:00
}
2012-06-09 05:56:10 +08:00
}
2016-09-07 04:57:50 +08:00
Expanded the flags that can be set for a command object in lldb_private::CommandObject. This list of available flags are:
enum
{
//----------------------------------------------------------------------
// eFlagRequiresTarget
//
// Ensures a valid target is contained in m_exe_ctx prior to executing
// the command. If a target doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidTargetDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidTargetDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresTarget = (1u << 0),
//----------------------------------------------------------------------
// eFlagRequiresProcess
//
// Ensures a valid process is contained in m_exe_ctx prior to executing
// the command. If a process doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidProcessDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidProcessDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresProcess = (1u << 1),
//----------------------------------------------------------------------
// eFlagRequiresThread
//
// Ensures a valid thread is contained in m_exe_ctx prior to executing
// the command. If a thread doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidThreadDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidThreadDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresThread = (1u << 2),
//----------------------------------------------------------------------
// eFlagRequiresFrame
//
// Ensures a valid frame is contained in m_exe_ctx prior to executing
// the command. If a frame doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidFrameDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidFrameDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresFrame = (1u << 3),
//----------------------------------------------------------------------
// eFlagRequiresRegContext
//
// Ensures a valid register context (from the selected frame if there
// is a frame in m_exe_ctx, or from the selected thread from m_exe_ctx)
// is availble from m_exe_ctx prior to executing the command. If a
// target doesn't exist or is invalid, the command will fail and
// CommandObject::GetInvalidRegContextDescription() will be returned as
// the error. CommandObject subclasses can override the virtual function
// for GetInvalidRegContextDescription() to provide custom strings when
// needed.
//----------------------------------------------------------------------
eFlagRequiresRegContext = (1u << 4),
//----------------------------------------------------------------------
// eFlagTryTargetAPILock
//
// Attempts to acquire the target lock if a target is selected in the
// command interpreter. If the command object fails to acquire the API
// lock, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagTryTargetAPILock = (1u << 5),
//----------------------------------------------------------------------
// eFlagProcessMustBeLaunched
//
// Verifies that there is a launched process in m_exe_ctx, if there
// isn't, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagProcessMustBeLaunched = (1u << 6),
//----------------------------------------------------------------------
// eFlagProcessMustBePaused
//
// Verifies that there is a paused process in m_exe_ctx, if there
// isn't, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagProcessMustBePaused = (1u << 7)
};
Now each command object contains a "ExecutionContext m_exe_ctx;" member variable that gets initialized prior to running the command. The validity of the target objects in m_exe_ctx are checked to ensure that any target/process/thread/frame/reg context that are required are valid prior to executing the command. Each command object also contains a Mutex::Locker m_api_locker which gets used if eFlagTryTargetAPILock is set. This centralizes a lot of checking code that was previously and inconsistently implemented across many commands.
llvm-svn: 171990
2013-01-10 03:44:40 +08:00
Cleanup ( ) ;
2016-09-07 04:57:50 +08:00
}
2012-06-09 05:56:10 +08:00
return handled ;
}
bool CommandObjectRaw : : Execute ( const char * args_string ,
CommandReturnObject & result ) {
bool handled = false ;
2014-08-06 08:10:12 +08:00
if ( HasOverrideCallback ( ) ) {
2012-06-09 05:56:10 +08:00
std : : string full_command ( GetCommandName ( ) ) ;
full_command + = ' ' ;
full_command + = args_string ;
2014-04-20 08:31:37 +08:00
const char * argv [ 2 ] = { nullptr , nullptr } ;
2012-06-09 05:56:10 +08:00
argv [ 0 ] = full_command . c_str ( ) ;
2014-08-06 08:10:12 +08:00
handled = InvokeOverrideCallback ( argv , result ) ;
2012-06-09 05:56:10 +08:00
}
if ( ! handled ) {
Expanded the flags that can be set for a command object in lldb_private::CommandObject. This list of available flags are:
enum
{
//----------------------------------------------------------------------
// eFlagRequiresTarget
//
// Ensures a valid target is contained in m_exe_ctx prior to executing
// the command. If a target doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidTargetDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidTargetDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresTarget = (1u << 0),
//----------------------------------------------------------------------
// eFlagRequiresProcess
//
// Ensures a valid process is contained in m_exe_ctx prior to executing
// the command. If a process doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidProcessDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidProcessDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresProcess = (1u << 1),
//----------------------------------------------------------------------
// eFlagRequiresThread
//
// Ensures a valid thread is contained in m_exe_ctx prior to executing
// the command. If a thread doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidThreadDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidThreadDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresThread = (1u << 2),
//----------------------------------------------------------------------
// eFlagRequiresFrame
//
// Ensures a valid frame is contained in m_exe_ctx prior to executing
// the command. If a frame doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidFrameDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidFrameDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresFrame = (1u << 3),
//----------------------------------------------------------------------
// eFlagRequiresRegContext
//
// Ensures a valid register context (from the selected frame if there
// is a frame in m_exe_ctx, or from the selected thread from m_exe_ctx)
// is availble from m_exe_ctx prior to executing the command. If a
// target doesn't exist or is invalid, the command will fail and
// CommandObject::GetInvalidRegContextDescription() will be returned as
// the error. CommandObject subclasses can override the virtual function
// for GetInvalidRegContextDescription() to provide custom strings when
// needed.
//----------------------------------------------------------------------
eFlagRequiresRegContext = (1u << 4),
//----------------------------------------------------------------------
// eFlagTryTargetAPILock
//
// Attempts to acquire the target lock if a target is selected in the
// command interpreter. If the command object fails to acquire the API
// lock, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagTryTargetAPILock = (1u << 5),
//----------------------------------------------------------------------
// eFlagProcessMustBeLaunched
//
// Verifies that there is a launched process in m_exe_ctx, if there
// isn't, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagProcessMustBeLaunched = (1u << 6),
//----------------------------------------------------------------------
// eFlagProcessMustBePaused
//
// Verifies that there is a paused process in m_exe_ctx, if there
// isn't, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagProcessMustBePaused = (1u << 7)
};
Now each command object contains a "ExecutionContext m_exe_ctx;" member variable that gets initialized prior to running the command. The validity of the target objects in m_exe_ctx are checked to ensure that any target/process/thread/frame/reg context that are required are valid prior to executing the command. Each command object also contains a Mutex::Locker m_api_locker which gets used if eFlagTryTargetAPILock is set. This centralizes a lot of checking code that was previously and inconsistently implemented across many commands.
llvm-svn: 171990
2013-01-10 03:44:40 +08:00
if ( CheckRequirements ( result ) )
2012-06-09 05:56:10 +08:00
handled = DoExecute ( args_string , result ) ;
2016-09-07 04:57:50 +08:00
Expanded the flags that can be set for a command object in lldb_private::CommandObject. This list of available flags are:
enum
{
//----------------------------------------------------------------------
// eFlagRequiresTarget
//
// Ensures a valid target is contained in m_exe_ctx prior to executing
// the command. If a target doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidTargetDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidTargetDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresTarget = (1u << 0),
//----------------------------------------------------------------------
// eFlagRequiresProcess
//
// Ensures a valid process is contained in m_exe_ctx prior to executing
// the command. If a process doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidProcessDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidProcessDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresProcess = (1u << 1),
//----------------------------------------------------------------------
// eFlagRequiresThread
//
// Ensures a valid thread is contained in m_exe_ctx prior to executing
// the command. If a thread doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidThreadDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidThreadDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresThread = (1u << 2),
//----------------------------------------------------------------------
// eFlagRequiresFrame
//
// Ensures a valid frame is contained in m_exe_ctx prior to executing
// the command. If a frame doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidFrameDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidFrameDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresFrame = (1u << 3),
//----------------------------------------------------------------------
// eFlagRequiresRegContext
//
// Ensures a valid register context (from the selected frame if there
// is a frame in m_exe_ctx, or from the selected thread from m_exe_ctx)
// is availble from m_exe_ctx prior to executing the command. If a
// target doesn't exist or is invalid, the command will fail and
// CommandObject::GetInvalidRegContextDescription() will be returned as
// the error. CommandObject subclasses can override the virtual function
// for GetInvalidRegContextDescription() to provide custom strings when
// needed.
//----------------------------------------------------------------------
eFlagRequiresRegContext = (1u << 4),
//----------------------------------------------------------------------
// eFlagTryTargetAPILock
//
// Attempts to acquire the target lock if a target is selected in the
// command interpreter. If the command object fails to acquire the API
// lock, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagTryTargetAPILock = (1u << 5),
//----------------------------------------------------------------------
// eFlagProcessMustBeLaunched
//
// Verifies that there is a launched process in m_exe_ctx, if there
// isn't, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagProcessMustBeLaunched = (1u << 6),
//----------------------------------------------------------------------
// eFlagProcessMustBePaused
//
// Verifies that there is a paused process in m_exe_ctx, if there
// isn't, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagProcessMustBePaused = (1u << 7)
};
Now each command object contains a "ExecutionContext m_exe_ctx;" member variable that gets initialized prior to running the command. The validity of the target objects in m_exe_ctx are checked to ensure that any target/process/thread/frame/reg context that are required are valid prior to executing the command. Each command object also contains a Mutex::Locker m_api_locker which gets used if eFlagTryTargetAPILock is set. This centralizes a lot of checking code that was previously and inconsistently implemented across many commands.
llvm-svn: 171990
2013-01-10 03:44:40 +08:00
Cleanup ( ) ;
2012-06-09 05:56:10 +08:00
}
return handled ;
}
2016-11-13 10:08:22 +08:00
static llvm : : StringRef arch_helper ( ) {
2012-05-27 01:21:14 +08:00
static StreamString g_archs_help ;
2012-05-30 04:04:10 +08:00
if ( g_archs_help . Empty ( ) ) {
2012-05-27 01:21:14 +08:00
StringList archs ;
2018-07-14 02:28:14 +08:00
ArchSpec : : ListSupportedArchNames ( archs ) ;
2012-05-27 01:21:14 +08:00
g_archs_help . Printf ( " These are the supported architecture names: \n " ) ;
2012-05-30 04:04:10 +08:00
archs . Join ( " \n " , g_archs_help ) ;
2012-05-27 01:21:14 +08:00
}
2016-11-13 10:08:22 +08:00
return g_archs_help . GetString ( ) ;
2012-05-26 08:32:39 +08:00
}
2016-07-15 06:03:10 +08:00
CommandObject : : ArgumentTableEntry CommandObject : : g_arguments_data [ ] = {
// clang-format off
2014-04-20 08:31:37 +08:00
{ eArgTypeAddress , " address " , CommandCompletions : : eNoCompletion , { nullptr , false } , " A valid address in the target program's execution space. " } ,
{ eArgTypeAddressOrExpression , " address-expression " , CommandCompletions : : eNoCompletion , { nullptr , false } , " An expression that resolves to an address. " } ,
{ eArgTypeAliasName , " alias-name " , CommandCompletions : : eNoCompletion , { nullptr , false } , " The name of an abbreviation (alias) for a debugger command. " } ,
{ eArgTypeAliasOptions , " options-for-aliased-command " , CommandCompletions : : eNoCompletion , { nullptr , false } , " Command options to be used as part of an alias (abbreviation) definition. (See 'help commands alias' for more information.) " } ,
2012-05-26 08:32:39 +08:00
{ eArgTypeArchitecture , " arch " , CommandCompletions : : eArchitectureCompletion , { arch_helper , true } , " The architecture name, e.g. i386 or x86_64. " } ,
2014-04-20 08:31:37 +08:00
{ eArgTypeBoolean , " boolean " , CommandCompletions : : eNoCompletion , { nullptr , false } , " A Boolean value: 'true' or 'false' " } ,
{ eArgTypeBreakpointID , " breakpt-id " , CommandCompletions : : eNoCompletion , { BreakpointIDHelpTextCallback , false } , nullptr } ,
{ eArgTypeBreakpointIDRange , " breakpt-id-list " , CommandCompletions : : eNoCompletion , { BreakpointIDRangeHelpTextCallback , false } , nullptr } ,
2020-08-21 01:10:34 +08:00
{ eArgTypeBreakpointName , " breakpoint-name " , CommandCompletions : : eBreakpointNameCompletion , { BreakpointNameHelpTextCallback , false } , nullptr } ,
2014-04-20 08:31:37 +08:00
{ eArgTypeByteSize , " byte-size " , CommandCompletions : : eNoCompletion , { nullptr , false } , " Number of bytes to use. " } ,
{ eArgTypeClassName , " class-name " , CommandCompletions : : eNoCompletion , { nullptr , false } , " Then name of a class from the debug information in the program. " } ,
{ eArgTypeCommandName , " cmd-name " , CommandCompletions : : eNoCompletion , { nullptr , false } , " A debugger command (may be multiple words), without any options or arguments. " } ,
{ eArgTypeCount , " count " , CommandCompletions : : eNoCompletion , { nullptr , false } , " An unsigned integer. " } ,
{ eArgTypeDirectoryName , " directory " , CommandCompletions : : eDiskDirectoryCompletion , { nullptr , false } , " A directory name. " } ,
2020-08-11 15:59:30 +08:00
{ eArgTypeDisassemblyFlavor , " disassembly-flavor " , CommandCompletions : : eDisassemblyFlavorCompletion , { nullptr , false } , " A disassembly flavor recognized by your disassembly plugin. Currently the only valid options are \" att \" and \" intel \" for Intel targets " } ,
2014-04-20 08:31:37 +08:00
{ eArgTypeDescriptionVerbosity , " description-verbosity " , CommandCompletions : : eNoCompletion , { nullptr , false } , " How verbose the output of 'po' should be. " } ,
{ eArgTypeEndAddress , " end-address " , CommandCompletions : : eNoCompletion , { nullptr , false } , " Help text goes here. " } ,
{ eArgTypeExpression , " expr " , CommandCompletions : : eNoCompletion , { nullptr , false } , " Help text goes here. " } ,
{ eArgTypeExpressionPath , " expr-path " , CommandCompletions : : eNoCompletion , { ExprPathHelpTextCallback , true } , nullptr } ,
{ eArgTypeExprFormat , " expression-format " , CommandCompletions : : eNoCompletion , { nullptr , false } , " [ [bool|b] | [bin] | [char|c] | [oct|o] | [dec|i|d|u] | [hex|x] | [float|f] | [cstr|s] ] " } ,
{ eArgTypeFilename , " filename " , CommandCompletions : : eDiskFileCompletion , { nullptr , false } , " The name of a file (can include path). " } ,
{ eArgTypeFormat , " format " , CommandCompletions : : eNoCompletion , { FormatHelpTextCallback , true } , nullptr } ,
2020-08-11 18:20:43 +08:00
{ eArgTypeFrameIndex , " frame-index " , CommandCompletions : : eFrameIndexCompletion , { nullptr , false } , " Index into a thread's list of frames. " } ,
2014-04-20 08:31:37 +08:00
{ eArgTypeFullName , " fullname " , CommandCompletions : : eNoCompletion , { nullptr , false } , " Help text goes here. " } ,
{ eArgTypeFunctionName , " function-name " , CommandCompletions : : eNoCompletion , { nullptr , false } , " The name of a function. " } ,
{ eArgTypeFunctionOrSymbol , " function-or-symbol " , CommandCompletions : : eNoCompletion , { nullptr , false } , " The name of a function or symbol. " } ,
{ eArgTypeGDBFormat , " gdb-format " , CommandCompletions : : eNoCompletion , { GDBFormatHelpTextCallback , true } , nullptr } ,
2014-09-16 01:52:44 +08:00
{ eArgTypeHelpText , " help-text " , CommandCompletions : : eNoCompletion , { nullptr , false } , " Text to be used as help for some other entity in LLDB " } ,
2014-04-20 08:31:37 +08:00
{ eArgTypeIndex , " index " , CommandCompletions : : eNoCompletion , { nullptr , false } , " An index into a list. " } ,
2020-08-11 16:32:55 +08:00
{ eArgTypeLanguage , " source-language " , CommandCompletions : : eTypeLanguageCompletion , { LanguageTypeHelpTextCallback , true } , nullptr } ,
2014-04-20 08:31:37 +08:00
{ eArgTypeLineNum , " linenum " , CommandCompletions : : eNoCompletion , { nullptr , false } , " Line number in a source file. " } ,
2020-07-17 02:34:50 +08:00
{ eArgTypeFileLineColumn , " linespec " , CommandCompletions : : eNoCompletion , { nullptr , false } , " A source specifier in the form file:line[:column] " } ,
2014-04-20 08:31:37 +08:00
{ eArgTypeLogCategory , " log-category " , CommandCompletions : : eNoCompletion , { nullptr , 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 , { nullptr , 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 , { nullptr , false } , " A C++ method name. " } ,
2020-08-25 00:58:17 +08:00
{ eArgTypeName , " name " , CommandCompletions : : eTypeCategoryNameCompletion , { nullptr , false } , " Help text goes here. " } ,
2014-04-20 08:31:37 +08:00
{ eArgTypeNewPathPrefix , " new-path-prefix " , CommandCompletions : : eNoCompletion , { nullptr , false } , " Help text goes here. " } ,
{ eArgTypeNumLines , " num-lines " , CommandCompletions : : eNoCompletion , { nullptr , false } , " The number of lines to use. " } ,
{ eArgTypeNumberPerLine , " number-per-line " , CommandCompletions : : eNoCompletion , { nullptr , false } , " The number of items per line to display. " } ,
{ eArgTypeOffset , " offset " , CommandCompletions : : eNoCompletion , { nullptr , false } , " Help text goes here. " } ,
{ eArgTypeOldPathPrefix , " old-path-prefix " , CommandCompletions : : eNoCompletion , { nullptr , false } , " Help text goes here. " } ,
{ eArgTypeOneLiner , " one-line-command " , CommandCompletions : : eNoCompletion , { nullptr , false } , " A command that is entered as a single line of text. " } ,
{ eArgTypePath , " path " , CommandCompletions : : eDiskFileCompletion , { nullptr , false } , " Path. " } ,
{ eArgTypePermissionsNumber , " perms-numeric " , CommandCompletions : : eNoCompletion , { nullptr , false } , " Permissions given as an octal number (e.g. 755). " } ,
{ eArgTypePermissionsString , " perms=string " , CommandCompletions : : eNoCompletion , { nullptr , false } , " Permissions given as a string value (e.g. rw-r-xr--). " } ,
2020-08-24 20:23:23 +08:00
{ eArgTypePid , " pid " , CommandCompletions : : eProcessIDCompletion , { nullptr , false } , " The process ID number. " } ,
2020-05-27 20:06:28 +08:00
{ eArgTypePlugin , " plugin " , CommandCompletions : : eProcessPluginCompletion , { nullptr , false } , " Help text goes here. " } ,
2020-08-24 20:23:23 +08:00
{ eArgTypeProcessName , " process-name " , CommandCompletions : : eProcessNameCompletion , { nullptr , false } , " The name of the process. " } ,
2014-04-20 08:31:37 +08:00
{ eArgTypePythonClass , " python-class " , CommandCompletions : : eNoCompletion , { nullptr , false } , " The name of a Python class. " } ,
{ eArgTypePythonFunction , " python-function " , CommandCompletions : : eNoCompletion , { nullptr , false } , " The name of a Python function. " } ,
{ eArgTypePythonScript , " python-script " , CommandCompletions : : eNoCompletion , { nullptr , false } , " Source code written in Python. " } ,
{ eArgTypeQueueName , " queue-name " , CommandCompletions : : eNoCompletion , { nullptr , false } , " The name of the thread queue. " } ,
{ eArgTypeRegisterName , " register-name " , CommandCompletions : : eNoCompletion , { RegisterNameHelpTextCallback , true } , nullptr } ,
2019-08-17 05:25:36 +08:00
{ eArgTypeRegularExpression , " regular-expression " , CommandCompletions : : eNoCompletion , { nullptr , false } , " A POSIX-compliant extended regular expression. " } ,
2014-04-20 08:31:37 +08:00
{ eArgTypeRunArgs , " run-args " , CommandCompletions : : eNoCompletion , { nullptr , false } , " Arguments to be passed to the target program when it starts executing. " } ,
{ eArgTypeRunMode , " run-mode " , CommandCompletions : : eNoCompletion , { nullptr , false } , " Help text goes here. " } ,
{ eArgTypeScriptedCommandSynchronicity , " script-cmd-synchronicity " , CommandCompletions : : eNoCompletion , { nullptr , false } , " The synchronicity to use to run scripted commands with regard to LLDB event system. " } ,
2020-04-02 12:12:01 +08:00
{ eArgTypeScriptLang , " script-language " , CommandCompletions : : eNoCompletion , { nullptr , false } , " The scripting language to be used for script-based commands. Supported languages are python and lua. " } ,
2016-07-15 06:03:10 +08:00
{ eArgTypeSearchWord , " search-word " , CommandCompletions : : eNoCompletion , { nullptr , false } , " Any word of interest for search purposes. " } ,
2014-04-20 08:31:37 +08:00
{ eArgTypeSelector , " selector " , CommandCompletions : : eNoCompletion , { nullptr , false } , " An Objective-C selector name. " } ,
{ eArgTypeSettingIndex , " setting-index " , CommandCompletions : : eNoCompletion , { nullptr , 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 , { nullptr , 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 , { nullptr , false } , " The name of a settable internal debugger variable up to a dot ('.'), e.g. 'target.process.' " } ,
{ eArgTypeSettingVariableName , " setting-variable-name " , CommandCompletions : : eNoCompletion , { nullptr , 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 , { nullptr , false } , " The name of a shared library. " } ,
{ eArgTypeSourceFile , " source-file " , CommandCompletions : : eSourceFileCompletion , { nullptr , false } , " The name of a source file.. " } ,
{ eArgTypeSortOrder , " sort-order " , CommandCompletions : : eNoCompletion , { nullptr , false } , " Specify a sort order when dumping lists. " } ,
{ eArgTypeStartAddress , " start-address " , CommandCompletions : : eNoCompletion , { nullptr , false } , " Help text goes here. " } ,
{ eArgTypeSummaryString , " summary-string " , CommandCompletions : : eNoCompletion , { SummaryStringHelpTextCallback , true } , nullptr } ,
{ eArgTypeSymbol , " symbol " , CommandCompletions : : eSymbolCompletion , { nullptr , false } , " Any symbol name (function name, variable, argument, etc.) " } ,
{ eArgTypeThreadID , " thread-id " , CommandCompletions : : eNoCompletion , { nullptr , false } , " Thread ID number. " } ,
{ eArgTypeThreadIndex , " thread-index " , CommandCompletions : : eNoCompletion , { nullptr , false } , " Index into the process' list of threads. " } ,
{ eArgTypeThreadName , " thread-name " , CommandCompletions : : eNoCompletion , { nullptr , false } , " The thread's name. " } ,
2015-04-23 03:42:18 +08:00
{ eArgTypeTypeName , " type-name " , CommandCompletions : : eNoCompletion , { nullptr , false } , " A type name. " } ,
2014-04-20 08:31:37 +08:00
{ eArgTypeUnsignedInteger , " unsigned-integer " , CommandCompletions : : eNoCompletion , { nullptr , false } , " An unsigned integer. " } ,
{ eArgTypeUnixSignal , " unix-signal " , CommandCompletions : : eNoCompletion , { nullptr , false } , " A valid Unix signal name or number (e.g. SIGKILL, KILL or 9). " } ,
{ eArgTypeVarName , " variable-name " , CommandCompletions : : eNoCompletion , { nullptr , false } , " The name of a variable in your program. " } ,
{ eArgTypeValue , " value " , CommandCompletions : : eNoCompletion , { nullptr , false } , " A value could be anything, depending on where and how it is used. " } ,
{ eArgTypeWidth , " width " , CommandCompletions : : eNoCompletion , { nullptr , false } , " Help text goes here. " } ,
{ eArgTypeNone , " none " , CommandCompletions : : eNoCompletion , { nullptr , false } , " No help available for this. " } ,
{ eArgTypePlatform , " platform-name " , CommandCompletions : : ePlatformPluginCompletion , { nullptr , false } , " The name of an installed platform plug-in . Type 'platform list' to see a complete list of installed platforms. " } ,
{ eArgTypeWatchpointID , " watchpt-id " , CommandCompletions : : eNoCompletion , { nullptr , false } , " Watchpoint IDs are positive integers. " } ,
{ eArgTypeWatchpointIDRange , " watchpt-id-list " , CommandCompletions : : eNoCompletion , { nullptr , false } , " For example, '1-3' or '1 to 3'. " } ,
2016-07-15 06:03:10 +08:00
{ eArgTypeWatchType , " watch-type " , CommandCompletions : : eNoCompletion , { nullptr , false } , " Specify the type for a watchpoint. " } ,
2017-09-15 04:22:49 +08:00
{ eArgRawInput , " raw-input " , CommandCompletions : : eNoCompletion , { nullptr , false } , " Free-form text passed to a command without prior interpretation, allowing spaces without requiring quotes. To pass arguments and free form text put two dashes ' -- ' between the last argument and any raw input. " } ,
2021-10-13 01:55:24 +08:00
{ eArgTypeCommand , " command " , CommandCompletions : : eNoCompletion , { nullptr , false } , " An LLDB Command line command element. " } ,
2020-08-11 18:29:25 +08:00
{ eArgTypeColumnNum , " column " , CommandCompletions : : eNoCompletion , { nullptr , false } , " Column number in a source file. " } ,
2021-06-21 03:19:50 +08:00
{ eArgTypeModuleUUID , " module-uuid " , CommandCompletions : : eModuleUUIDCompletion , { nullptr , false } , " A module UUID value. " } ,
{ eArgTypeSaveCoreStyle , " corefile-style " , CommandCompletions : : eNoCompletion , { nullptr , false } , " The type of corefile that lldb will try to create, dependant on this target's capabilities. " }
2016-07-15 06:03:10 +08:00
// clang-format on
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
2019-05-15 13:39:41 +08:00
static_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 ;
}