llvm-project/lldb/source/Commands/CommandObjectThread.cpp

1285 lines
49 KiB
C++
Raw Normal View History

//===-- CommandObjectThread.cpp ---------------------------------*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
#include "CommandObjectThread.h"
// C Includes
// C++ Includes
// Other libraries and framework includes
// Project includes
#include "lldb/Interpreter/Options.h"
#include "lldb/Core/State.h"
#include "lldb/Core/SourceManager.h"
#include "lldb/Host/Host.h"
#include "lldb/Interpreter/CommandInterpreter.h"
#include "lldb/Interpreter/CommandReturnObject.h"
#include "lldb/Target/Process.h"
#include "lldb/Target/RegisterContext.h"
#include "lldb/Target/Target.h"
#include "lldb/Target/Thread.h"
#include "lldb/Target/ThreadPlan.h"
#include "lldb/Target/ThreadPlanStepInstruction.h"
#include "lldb/Target/ThreadPlanStepOut.h"
#include "lldb/Target/ThreadPlanStepRange.h"
#include "lldb/Target/ThreadPlanStepInRange.h"
#include "lldb/Symbol/LineTable.h"
#include "lldb/Symbol/LineEntry.h"
using namespace lldb;
using namespace lldb_private;
//-------------------------------------------------------------------------
// CommandObjectThreadBacktrace
//-------------------------------------------------------------------------
class CommandObjectThreadBacktrace : public CommandObject
{
public:
class CommandOptions : public Options
{
public:
CommandOptions (CommandInterpreter &interpreter) :
Options(interpreter)
{
Added two new classes for command options: lldb_private::OptionGroup lldb_private::OptionGroupOptions OptionGroup lets you define a class that encapsulates settings that you want to reuse in multiple commands. It contains only the option definitions and the ability to set the option values, but it doesn't directly interface with the lldb_private::Options class that is the front end to all of the CommandObject option parsing. For that the OptionGroupOptions class can be used. It aggregates one or more OptionGroup objects and directs the option setting to the appropriate OptionGroup class. For an example of this, take a look at the CommandObjectFile and how it uses its "m_option_group" object shown below to be able to set values in both the FileOptionGroup and PlatformOptionGroup classes. The members used in CommandObjectFile are: OptionGroupOptions m_option_group; FileOptionGroup m_file_options; PlatformOptionGroup m_platform_options; Then in the constructor for CommandObjectFile you can combine the option settings. The code below shows a simplified version of the constructor: CommandObjectFile::CommandObjectFile(CommandInterpreter &interpreter) : CommandObject (...), m_option_group (interpreter), m_file_options (), m_platform_options(true) { m_option_group.Append (&m_file_options); m_option_group.Append (&m_platform_options); m_option_group.Finalize(); } We append the m_file_options and then the m_platform_options and then tell the option group the finalize the results. This allows the m_option_group to become the organizer of our prefs and after option parsing we end up with valid preference settings in both the m_file_options and m_platform_options objects. This also allows any other commands to use the FileOptionGroup and PlatformOptionGroup classes to implement options for their commands. Renamed: virtual void Options::ResetOptionValues(); to: virtual void Options::OptionParsingStarting(); And implemented a new callback named: virtual Error Options::OptionParsingFinished(); This allows Options subclasses to verify that the options all go together after all of the options have been specified and gives the chance for the command object to return an error. It also gives a chance to take all of the option values and produce or initialize objects after all options have completed parsing. Modfied: virtual Error SetOptionValue (int option_idx, const char *option_arg) = 0; to be: virtual Error SetOptionValue (uint32_t option_idx, const char *option_arg) = 0; (option_idx is now unsigned). llvm-svn: 129415
2011-04-13 08:18:08 +08:00
// Keep default values of all options in one place: OptionParsingStarting ()
OptionParsingStarting ();
}
virtual
~CommandOptions ()
{
}
virtual Error
Added two new classes for command options: lldb_private::OptionGroup lldb_private::OptionGroupOptions OptionGroup lets you define a class that encapsulates settings that you want to reuse in multiple commands. It contains only the option definitions and the ability to set the option values, but it doesn't directly interface with the lldb_private::Options class that is the front end to all of the CommandObject option parsing. For that the OptionGroupOptions class can be used. It aggregates one or more OptionGroup objects and directs the option setting to the appropriate OptionGroup class. For an example of this, take a look at the CommandObjectFile and how it uses its "m_option_group" object shown below to be able to set values in both the FileOptionGroup and PlatformOptionGroup classes. The members used in CommandObjectFile are: OptionGroupOptions m_option_group; FileOptionGroup m_file_options; PlatformOptionGroup m_platform_options; Then in the constructor for CommandObjectFile you can combine the option settings. The code below shows a simplified version of the constructor: CommandObjectFile::CommandObjectFile(CommandInterpreter &interpreter) : CommandObject (...), m_option_group (interpreter), m_file_options (), m_platform_options(true) { m_option_group.Append (&m_file_options); m_option_group.Append (&m_platform_options); m_option_group.Finalize(); } We append the m_file_options and then the m_platform_options and then tell the option group the finalize the results. This allows the m_option_group to become the organizer of our prefs and after option parsing we end up with valid preference settings in both the m_file_options and m_platform_options objects. This also allows any other commands to use the FileOptionGroup and PlatformOptionGroup classes to implement options for their commands. Renamed: virtual void Options::ResetOptionValues(); to: virtual void Options::OptionParsingStarting(); And implemented a new callback named: virtual Error Options::OptionParsingFinished(); This allows Options subclasses to verify that the options all go together after all of the options have been specified and gives the chance for the command object to return an error. It also gives a chance to take all of the option values and produce or initialize objects after all options have completed parsing. Modfied: virtual Error SetOptionValue (int option_idx, const char *option_arg) = 0; to be: virtual Error SetOptionValue (uint32_t option_idx, const char *option_arg) = 0; (option_idx is now unsigned). llvm-svn: 129415
2011-04-13 08:18:08 +08:00
SetOptionValue (uint32_t option_idx, const char *option_arg)
{
Error error;
char short_option = (char) m_getopt_table[option_idx].val;
switch (short_option)
{
case 'c':
{
bool success;
int32_t input_count = Args::StringToSInt32 (option_arg, -1, 0, &success);
if (!success)
error.SetErrorStringWithFormat("Invalid integer value for option '%c'.\n", short_option);
if (input_count < -1)
m_count = UINT32_MAX;
else
m_count = input_count;
}
break;
case 's':
{
bool success;
m_start = Args::StringToUInt32 (option_arg, 0, 0, &success);
if (!success)
error.SetErrorStringWithFormat("Invalid integer value for option '%c'.\n", short_option);
}
break;
default:
error.SetErrorStringWithFormat("Invalid short option character '%c'.\n", short_option);
break;
}
return error;
}
void
Added two new classes for command options: lldb_private::OptionGroup lldb_private::OptionGroupOptions OptionGroup lets you define a class that encapsulates settings that you want to reuse in multiple commands. It contains only the option definitions and the ability to set the option values, but it doesn't directly interface with the lldb_private::Options class that is the front end to all of the CommandObject option parsing. For that the OptionGroupOptions class can be used. It aggregates one or more OptionGroup objects and directs the option setting to the appropriate OptionGroup class. For an example of this, take a look at the CommandObjectFile and how it uses its "m_option_group" object shown below to be able to set values in both the FileOptionGroup and PlatformOptionGroup classes. The members used in CommandObjectFile are: OptionGroupOptions m_option_group; FileOptionGroup m_file_options; PlatformOptionGroup m_platform_options; Then in the constructor for CommandObjectFile you can combine the option settings. The code below shows a simplified version of the constructor: CommandObjectFile::CommandObjectFile(CommandInterpreter &interpreter) : CommandObject (...), m_option_group (interpreter), m_file_options (), m_platform_options(true) { m_option_group.Append (&m_file_options); m_option_group.Append (&m_platform_options); m_option_group.Finalize(); } We append the m_file_options and then the m_platform_options and then tell the option group the finalize the results. This allows the m_option_group to become the organizer of our prefs and after option parsing we end up with valid preference settings in both the m_file_options and m_platform_options objects. This also allows any other commands to use the FileOptionGroup and PlatformOptionGroup classes to implement options for their commands. Renamed: virtual void Options::ResetOptionValues(); to: virtual void Options::OptionParsingStarting(); And implemented a new callback named: virtual Error Options::OptionParsingFinished(); This allows Options subclasses to verify that the options all go together after all of the options have been specified and gives the chance for the command object to return an error. It also gives a chance to take all of the option values and produce or initialize objects after all options have completed parsing. Modfied: virtual Error SetOptionValue (int option_idx, const char *option_arg) = 0; to be: virtual Error SetOptionValue (uint32_t option_idx, const char *option_arg) = 0; (option_idx is now unsigned). llvm-svn: 129415
2011-04-13 08:18:08 +08:00
OptionParsingStarting ()
{
Centralized a lot of the status information for processes, threads, and stack frame down in the lldb_private::Process, lldb_private::Thread, lldb_private::StackFrameList and the lldb_private::StackFrame classes. We had some command line commands that had duplicate versions of the process status output ("thread list" and "process status" for example). Removed the "file" command and placed it where it should have been: "target create". Made an alias for "file" to "target create" so we stay compatible with GDB commands. We can now have multple usable targets in lldb at the same time. This is nice for comparing two runs of a program or debugging more than one binary at the same time. The new command is "target select <target-idx>" and also to see a list of the current targets you can use the new "target list" command. The flow in a debug session can be: (lldb) target create /path/to/exe/a.out (lldb) breakpoint set --name main (lldb) run ... hit breakpoint (lldb) target create /bin/ls (lldb) run /tmp Process 36001 exited with status = 0 (0x00000000) (lldb) target list Current targets: target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) * target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) target select 0 Current targets: * target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) bt * thread #1: tid = 0x2d03, 0x0000000100000b9a a.out`main + 42 at main.c:16, stop reason = breakpoint 1.1 frame #0: 0x0000000100000b9a a.out`main + 42 at main.c:16 frame #1: 0x0000000100000b64 a.out`start + 52 Above we created a target for "a.out" and ran and hit a breakpoint at "main". Then we created a new target for /bin/ls and ran it. Then we listed the targest and selected our original "a.out" program, so we showed two concurent debug sessions going on at the same time. llvm-svn: 129695
2011-04-18 16:33:37 +08:00
m_count = UINT32_MAX;
m_start = 0;
}
const OptionDefinition*
GetDefinitions ()
{
return g_option_table;
}
// Options table: Required for subclasses of Options.
static OptionDefinition g_option_table[];
// Instance variables to hold the values for command options.
uint32_t m_count;
uint32_t m_start;
};
CommandObjectThreadBacktrace (CommandInterpreter &interpreter) :
CommandObject (interpreter,
"thread backtrace",
2010-09-09 06:08:58 +08:00
"Show the stack for one or more threads. If no threads are specified, show the currently selected thread. Use the thread-index \"all\" to see all threads.",
NULL,
eFlagProcessMustBeLaunched | eFlagProcessMustBePaused),
m_options(interpreter)
{
CommandArgumentEntry arg;
CommandArgumentData thread_idx_arg;
// Define the first (and only) variant of this arg.
thread_idx_arg.arg_type = eArgTypeThreadIndex;
thread_idx_arg.arg_repetition = eArgRepeatStar;
// There is only one variant this argument could be; put it into the argument entry.
arg.push_back (thread_idx_arg);
// Push the data for the first argument into the m_arguments vector.
m_arguments.push_back (arg);
}
~CommandObjectThreadBacktrace()
{
}
virtual Options *
GetOptions ()
{
return &m_options;
}
virtual bool
Execute (Args& command, CommandReturnObject &result)
Centralized a lot of the status information for processes, threads, and stack frame down in the lldb_private::Process, lldb_private::Thread, lldb_private::StackFrameList and the lldb_private::StackFrame classes. We had some command line commands that had duplicate versions of the process status output ("thread list" and "process status" for example). Removed the "file" command and placed it where it should have been: "target create". Made an alias for "file" to "target create" so we stay compatible with GDB commands. We can now have multple usable targets in lldb at the same time. This is nice for comparing two runs of a program or debugging more than one binary at the same time. The new command is "target select <target-idx>" and also to see a list of the current targets you can use the new "target list" command. The flow in a debug session can be: (lldb) target create /path/to/exe/a.out (lldb) breakpoint set --name main (lldb) run ... hit breakpoint (lldb) target create /bin/ls (lldb) run /tmp Process 36001 exited with status = 0 (0x00000000) (lldb) target list Current targets: target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) * target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) target select 0 Current targets: * target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) bt * thread #1: tid = 0x2d03, 0x0000000100000b9a a.out`main + 42 at main.c:16, stop reason = breakpoint 1.1 frame #0: 0x0000000100000b9a a.out`main + 42 at main.c:16 frame #1: 0x0000000100000b64 a.out`start + 52 Above we created a target for "a.out" and ran and hit a breakpoint at "main". Then we created a new target for /bin/ls and ran it. Then we listed the targest and selected our original "a.out" program, so we showed two concurent debug sessions going on at the same time. llvm-svn: 129695
2011-04-18 16:33:37 +08:00
{
result.SetStatus (eReturnStatusSuccessFinishResult);
Centralized a lot of the status information for processes, threads, and stack frame down in the lldb_private::Process, lldb_private::Thread, lldb_private::StackFrameList and the lldb_private::StackFrame classes. We had some command line commands that had duplicate versions of the process status output ("thread list" and "process status" for example). Removed the "file" command and placed it where it should have been: "target create". Made an alias for "file" to "target create" so we stay compatible with GDB commands. We can now have multple usable targets in lldb at the same time. This is nice for comparing two runs of a program or debugging more than one binary at the same time. The new command is "target select <target-idx>" and also to see a list of the current targets you can use the new "target list" command. The flow in a debug session can be: (lldb) target create /path/to/exe/a.out (lldb) breakpoint set --name main (lldb) run ... hit breakpoint (lldb) target create /bin/ls (lldb) run /tmp Process 36001 exited with status = 0 (0x00000000) (lldb) target list Current targets: target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) * target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) target select 0 Current targets: * target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) bt * thread #1: tid = 0x2d03, 0x0000000100000b9a a.out`main + 42 at main.c:16, stop reason = breakpoint 1.1 frame #0: 0x0000000100000b9a a.out`main + 42 at main.c:16 frame #1: 0x0000000100000b64 a.out`start + 52 Above we created a target for "a.out" and ran and hit a breakpoint at "main". Then we created a new target for /bin/ls and ran it. Then we listed the targest and selected our original "a.out" program, so we showed two concurent debug sessions going on at the same time. llvm-svn: 129695
2011-04-18 16:33:37 +08:00
Stream &strm = result.GetOutputStream();
// Don't show source context when doing backtraces.
const uint32_t num_frames_with_source = 0;
if (command.GetArgumentCount() == 0)
{
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
ExecutionContext exe_ctx(m_interpreter.GetExecutionContext());
if (exe_ctx.thread)
{
Centralized a lot of the status information for processes, threads, and stack frame down in the lldb_private::Process, lldb_private::Thread, lldb_private::StackFrameList and the lldb_private::StackFrame classes. We had some command line commands that had duplicate versions of the process status output ("thread list" and "process status" for example). Removed the "file" command and placed it where it should have been: "target create". Made an alias for "file" to "target create" so we stay compatible with GDB commands. We can now have multple usable targets in lldb at the same time. This is nice for comparing two runs of a program or debugging more than one binary at the same time. The new command is "target select <target-idx>" and also to see a list of the current targets you can use the new "target list" command. The flow in a debug session can be: (lldb) target create /path/to/exe/a.out (lldb) breakpoint set --name main (lldb) run ... hit breakpoint (lldb) target create /bin/ls (lldb) run /tmp Process 36001 exited with status = 0 (0x00000000) (lldb) target list Current targets: target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) * target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) target select 0 Current targets: * target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) bt * thread #1: tid = 0x2d03, 0x0000000100000b9a a.out`main + 42 at main.c:16, stop reason = breakpoint 1.1 frame #0: 0x0000000100000b9a a.out`main + 42 at main.c:16 frame #1: 0x0000000100000b64 a.out`start + 52 Above we created a target for "a.out" and ran and hit a breakpoint at "main". Then we created a new target for /bin/ls and ran it. Then we listed the targest and selected our original "a.out" program, so we showed two concurent debug sessions going on at the same time. llvm-svn: 129695
2011-04-18 16:33:37 +08:00
if (exe_ctx.thread->GetStatus (strm,
m_options.m_start,
m_options.m_count,
num_frames_with_source))
{
result.SetStatus (eReturnStatusSuccessFinishResult);
}
}
else
{
result.AppendError ("invalid thread");
result.SetStatus (eReturnStatusFailed);
}
}
else if (command.GetArgumentCount() == 1 && ::strcmp (command.GetArgumentAtIndex(0), "all") == 0)
{
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
Process *process = m_interpreter.GetExecutionContext().process;
uint32_t num_threads = process->GetThreadList().GetSize();
for (uint32_t i = 0; i < num_threads; i++)
{
ThreadSP thread_sp = process->GetThreadList().GetThreadAtIndex(i);
Centralized a lot of the status information for processes, threads, and stack frame down in the lldb_private::Process, lldb_private::Thread, lldb_private::StackFrameList and the lldb_private::StackFrame classes. We had some command line commands that had duplicate versions of the process status output ("thread list" and "process status" for example). Removed the "file" command and placed it where it should have been: "target create". Made an alias for "file" to "target create" so we stay compatible with GDB commands. We can now have multple usable targets in lldb at the same time. This is nice for comparing two runs of a program or debugging more than one binary at the same time. The new command is "target select <target-idx>" and also to see a list of the current targets you can use the new "target list" command. The flow in a debug session can be: (lldb) target create /path/to/exe/a.out (lldb) breakpoint set --name main (lldb) run ... hit breakpoint (lldb) target create /bin/ls (lldb) run /tmp Process 36001 exited with status = 0 (0x00000000) (lldb) target list Current targets: target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) * target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) target select 0 Current targets: * target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) bt * thread #1: tid = 0x2d03, 0x0000000100000b9a a.out`main + 42 at main.c:16, stop reason = breakpoint 1.1 frame #0: 0x0000000100000b9a a.out`main + 42 at main.c:16 frame #1: 0x0000000100000b64 a.out`start + 52 Above we created a target for "a.out" and ran and hit a breakpoint at "main". Then we created a new target for /bin/ls and ran it. Then we listed the targest and selected our original "a.out" program, so we showed two concurent debug sessions going on at the same time. llvm-svn: 129695
2011-04-18 16:33:37 +08:00
if (thread_sp->GetStatus (strm,
m_options.m_start,
m_options.m_count,
num_frames_with_source))
{
result.AppendErrorWithFormat ("error displaying backtrace for thread: \"0x%4.4x\"\n", i);
result.SetStatus (eReturnStatusFailed);
return false;
}
}
}
else
{
uint32_t num_args = command.GetArgumentCount();
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
Process *process = m_interpreter.GetExecutionContext().process;
std::vector<ThreadSP> thread_sps;
for (uint32_t i = 0; i < num_args; i++)
{
bool success;
uint32_t thread_idx = Args::StringToUInt32(command.GetArgumentAtIndex(i), 0, 0, &success);
if (!success)
{
result.AppendErrorWithFormat ("invalid thread specification: \"%s\"\n", command.GetArgumentAtIndex(i));
result.SetStatus (eReturnStatusFailed);
return false;
}
thread_sps.push_back(process->GetThreadList().FindThreadByIndexID(thread_idx));
if (!thread_sps[i])
{
result.AppendErrorWithFormat ("no thread with index: \"%s\"\n", command.GetArgumentAtIndex(i));
result.SetStatus (eReturnStatusFailed);
return false;
}
}
for (uint32_t i = 0; i < num_args; i++)
{
Centralized a lot of the status information for processes, threads, and stack frame down in the lldb_private::Process, lldb_private::Thread, lldb_private::StackFrameList and the lldb_private::StackFrame classes. We had some command line commands that had duplicate versions of the process status output ("thread list" and "process status" for example). Removed the "file" command and placed it where it should have been: "target create". Made an alias for "file" to "target create" so we stay compatible with GDB commands. We can now have multple usable targets in lldb at the same time. This is nice for comparing two runs of a program or debugging more than one binary at the same time. The new command is "target select <target-idx>" and also to see a list of the current targets you can use the new "target list" command. The flow in a debug session can be: (lldb) target create /path/to/exe/a.out (lldb) breakpoint set --name main (lldb) run ... hit breakpoint (lldb) target create /bin/ls (lldb) run /tmp Process 36001 exited with status = 0 (0x00000000) (lldb) target list Current targets: target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) * target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) target select 0 Current targets: * target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) bt * thread #1: tid = 0x2d03, 0x0000000100000b9a a.out`main + 42 at main.c:16, stop reason = breakpoint 1.1 frame #0: 0x0000000100000b9a a.out`main + 42 at main.c:16 frame #1: 0x0000000100000b64 a.out`start + 52 Above we created a target for "a.out" and ran and hit a breakpoint at "main". Then we created a new target for /bin/ls and ran it. Then we listed the targest and selected our original "a.out" program, so we showed two concurent debug sessions going on at the same time. llvm-svn: 129695
2011-04-18 16:33:37 +08:00
if (!thread_sps[i]->GetStatus (strm,
m_options.m_start,
m_options.m_count,
num_frames_with_source))
{
result.AppendErrorWithFormat ("error displaying backtrace for thread: \"%s\"\n", command.GetArgumentAtIndex(i));
result.SetStatus (eReturnStatusFailed);
return false;
}
if (i < num_args - 1)
result.AppendMessage("");
}
}
return result.Succeeded();
}
protected:
CommandOptions m_options;
};
OptionDefinition
CommandObjectThreadBacktrace::CommandOptions::g_option_table[] =
{
{ LLDB_OPT_SET_1, false, "count", 'c', required_argument, NULL, 0, eArgTypeCount, "How many frames to display (-1 for all)"},
{ LLDB_OPT_SET_1, false, "start", 's', required_argument, NULL, 0, eArgTypeFrameIndex, "Frame in which to start the backtrace"},
{ 0, false, NULL, 0, 0, NULL, 0, eArgTypeNone, NULL }
};
enum StepScope
{
eStepScopeSource,
eStepScopeInstruction
};
class CommandObjectThreadStepWithTypeAndScope : public CommandObject
{
public:
class CommandOptions : public Options
{
public:
CommandOptions (CommandInterpreter &interpreter) :
Options (interpreter)
{
Added two new classes for command options: lldb_private::OptionGroup lldb_private::OptionGroupOptions OptionGroup lets you define a class that encapsulates settings that you want to reuse in multiple commands. It contains only the option definitions and the ability to set the option values, but it doesn't directly interface with the lldb_private::Options class that is the front end to all of the CommandObject option parsing. For that the OptionGroupOptions class can be used. It aggregates one or more OptionGroup objects and directs the option setting to the appropriate OptionGroup class. For an example of this, take a look at the CommandObjectFile and how it uses its "m_option_group" object shown below to be able to set values in both the FileOptionGroup and PlatformOptionGroup classes. The members used in CommandObjectFile are: OptionGroupOptions m_option_group; FileOptionGroup m_file_options; PlatformOptionGroup m_platform_options; Then in the constructor for CommandObjectFile you can combine the option settings. The code below shows a simplified version of the constructor: CommandObjectFile::CommandObjectFile(CommandInterpreter &interpreter) : CommandObject (...), m_option_group (interpreter), m_file_options (), m_platform_options(true) { m_option_group.Append (&m_file_options); m_option_group.Append (&m_platform_options); m_option_group.Finalize(); } We append the m_file_options and then the m_platform_options and then tell the option group the finalize the results. This allows the m_option_group to become the organizer of our prefs and after option parsing we end up with valid preference settings in both the m_file_options and m_platform_options objects. This also allows any other commands to use the FileOptionGroup and PlatformOptionGroup classes to implement options for their commands. Renamed: virtual void Options::ResetOptionValues(); to: virtual void Options::OptionParsingStarting(); And implemented a new callback named: virtual Error Options::OptionParsingFinished(); This allows Options subclasses to verify that the options all go together after all of the options have been specified and gives the chance for the command object to return an error. It also gives a chance to take all of the option values and produce or initialize objects after all options have completed parsing. Modfied: virtual Error SetOptionValue (int option_idx, const char *option_arg) = 0; to be: virtual Error SetOptionValue (uint32_t option_idx, const char *option_arg) = 0; (option_idx is now unsigned). llvm-svn: 129415
2011-04-13 08:18:08 +08:00
// Keep default values of all options in one place: OptionParsingStarting ()
OptionParsingStarting ();
}
virtual
~CommandOptions ()
{
}
virtual Error
Added two new classes for command options: lldb_private::OptionGroup lldb_private::OptionGroupOptions OptionGroup lets you define a class that encapsulates settings that you want to reuse in multiple commands. It contains only the option definitions and the ability to set the option values, but it doesn't directly interface with the lldb_private::Options class that is the front end to all of the CommandObject option parsing. For that the OptionGroupOptions class can be used. It aggregates one or more OptionGroup objects and directs the option setting to the appropriate OptionGroup class. For an example of this, take a look at the CommandObjectFile and how it uses its "m_option_group" object shown below to be able to set values in both the FileOptionGroup and PlatformOptionGroup classes. The members used in CommandObjectFile are: OptionGroupOptions m_option_group; FileOptionGroup m_file_options; PlatformOptionGroup m_platform_options; Then in the constructor for CommandObjectFile you can combine the option settings. The code below shows a simplified version of the constructor: CommandObjectFile::CommandObjectFile(CommandInterpreter &interpreter) : CommandObject (...), m_option_group (interpreter), m_file_options (), m_platform_options(true) { m_option_group.Append (&m_file_options); m_option_group.Append (&m_platform_options); m_option_group.Finalize(); } We append the m_file_options and then the m_platform_options and then tell the option group the finalize the results. This allows the m_option_group to become the organizer of our prefs and after option parsing we end up with valid preference settings in both the m_file_options and m_platform_options objects. This also allows any other commands to use the FileOptionGroup and PlatformOptionGroup classes to implement options for their commands. Renamed: virtual void Options::ResetOptionValues(); to: virtual void Options::OptionParsingStarting(); And implemented a new callback named: virtual Error Options::OptionParsingFinished(); This allows Options subclasses to verify that the options all go together after all of the options have been specified and gives the chance for the command object to return an error. It also gives a chance to take all of the option values and produce or initialize objects after all options have completed parsing. Modfied: virtual Error SetOptionValue (int option_idx, const char *option_arg) = 0; to be: virtual Error SetOptionValue (uint32_t option_idx, const char *option_arg) = 0; (option_idx is now unsigned). llvm-svn: 129415
2011-04-13 08:18:08 +08:00
SetOptionValue (uint32_t option_idx, const char *option_arg)
{
Error error;
char short_option = (char) m_getopt_table[option_idx].val;
switch (short_option)
{
case 'a':
{
bool success;
m_avoid_no_debug = Args::StringToBoolean (option_arg, true, &success);
if (!success)
error.SetErrorStringWithFormat("Invalid boolean value for option '%c'.\n", short_option);
}
break;
case 'm':
{
bool found_one = false;
OptionEnumValueElement *enum_values = g_option_table[option_idx].enum_values;
m_run_mode = (lldb::RunMode) Args::StringToOptionEnum(option_arg, enum_values, eOnlyDuringStepping, &found_one);
if (!found_one)
error.SetErrorStringWithFormat("Invalid enumeration value for option '%c'.\n", short_option);
}
break;
case 'r':
{
m_avoid_regexp.clear();
m_avoid_regexp.assign(option_arg);
}
break;
default:
error.SetErrorStringWithFormat("Invalid short option character '%c'.\n", short_option);
break;
}
return error;
}
void
Added two new classes for command options: lldb_private::OptionGroup lldb_private::OptionGroupOptions OptionGroup lets you define a class that encapsulates settings that you want to reuse in multiple commands. It contains only the option definitions and the ability to set the option values, but it doesn't directly interface with the lldb_private::Options class that is the front end to all of the CommandObject option parsing. For that the OptionGroupOptions class can be used. It aggregates one or more OptionGroup objects and directs the option setting to the appropriate OptionGroup class. For an example of this, take a look at the CommandObjectFile and how it uses its "m_option_group" object shown below to be able to set values in both the FileOptionGroup and PlatformOptionGroup classes. The members used in CommandObjectFile are: OptionGroupOptions m_option_group; FileOptionGroup m_file_options; PlatformOptionGroup m_platform_options; Then in the constructor for CommandObjectFile you can combine the option settings. The code below shows a simplified version of the constructor: CommandObjectFile::CommandObjectFile(CommandInterpreter &interpreter) : CommandObject (...), m_option_group (interpreter), m_file_options (), m_platform_options(true) { m_option_group.Append (&m_file_options); m_option_group.Append (&m_platform_options); m_option_group.Finalize(); } We append the m_file_options and then the m_platform_options and then tell the option group the finalize the results. This allows the m_option_group to become the organizer of our prefs and after option parsing we end up with valid preference settings in both the m_file_options and m_platform_options objects. This also allows any other commands to use the FileOptionGroup and PlatformOptionGroup classes to implement options for their commands. Renamed: virtual void Options::ResetOptionValues(); to: virtual void Options::OptionParsingStarting(); And implemented a new callback named: virtual Error Options::OptionParsingFinished(); This allows Options subclasses to verify that the options all go together after all of the options have been specified and gives the chance for the command object to return an error. It also gives a chance to take all of the option values and produce or initialize objects after all options have completed parsing. Modfied: virtual Error SetOptionValue (int option_idx, const char *option_arg) = 0; to be: virtual Error SetOptionValue (uint32_t option_idx, const char *option_arg) = 0; (option_idx is now unsigned). llvm-svn: 129415
2011-04-13 08:18:08 +08:00
OptionParsingStarting ()
{
m_avoid_no_debug = true;
m_run_mode = eOnlyDuringStepping;
m_avoid_regexp.clear();
}
const OptionDefinition*
GetDefinitions ()
{
return g_option_table;
}
// Options table: Required for subclasses of Options.
static OptionDefinition g_option_table[];
// Instance variables to hold the values for command options.
bool m_avoid_no_debug;
RunMode m_run_mode;
std::string m_avoid_regexp;
};
CommandObjectThreadStepWithTypeAndScope (CommandInterpreter &interpreter,
const char *name,
const char *help,
const char *syntax,
uint32_t flags,
StepType step_type,
StepScope step_scope) :
CommandObject (interpreter, name, help, syntax, flags),
m_step_type (step_type),
m_step_scope (step_scope),
m_options (interpreter)
{
CommandArgumentEntry arg;
CommandArgumentData thread_id_arg;
// Define the first (and only) variant of this arg.
thread_id_arg.arg_type = eArgTypeThreadID;
thread_id_arg.arg_repetition = eArgRepeatOptional;
// There is only one variant this argument could be; put it into the argument entry.
arg.push_back (thread_id_arg);
// Push the data for the first argument into the m_arguments vector.
m_arguments.push_back (arg);
}
virtual
~CommandObjectThreadStepWithTypeAndScope ()
{
}
virtual
Options *
GetOptions ()
{
return &m_options;
}
virtual bool
Execute
(
Args& command,
CommandReturnObject &result
)
{
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
Process *process = m_interpreter.GetExecutionContext().process;
bool synchronous_execution = m_interpreter.GetSynchronous();
if (process == NULL)
{
result.AppendError ("need a valid process to step");
result.SetStatus (eReturnStatusFailed);
}
else
{
const uint32_t num_threads = process->GetThreadList().GetSize();
Thread *thread = NULL;
if (command.GetArgumentCount() == 0)
{
thread = process->GetThreadList().GetSelectedThread().get();
if (thread == NULL)
{
result.AppendError ("no selected thread in process");
result.SetStatus (eReturnStatusFailed);
return false;
}
}
else
{
const char *thread_idx_cstr = command.GetArgumentAtIndex(0);
uint32_t step_thread_idx = Args::StringToUInt32 (thread_idx_cstr, LLDB_INVALID_INDEX32);
if (step_thread_idx == LLDB_INVALID_INDEX32)
{
result.AppendErrorWithFormat ("Invalid thread index '%s'.\n", thread_idx_cstr);
result.SetStatus (eReturnStatusFailed);
return false;
}
thread = process->GetThreadList().FindThreadByIndexID(step_thread_idx).get();
if (thread == NULL)
{
result.AppendErrorWithFormat ("Thread index %u is out of range (valid values are 0 - %u).\n",
step_thread_idx, 0, num_threads);
result.SetStatus (eReturnStatusFailed);
return false;
}
}
const bool abort_other_plans = false;
const lldb::RunMode stop_other_threads = m_options.m_run_mode;
// This is a bit unfortunate, but not all the commands in this command object support
// only while stepping, so I use the bool for them.
bool bool_stop_other_threads;
if (m_options.m_run_mode == eAllThreads)
bool_stop_other_threads = false;
else
bool_stop_other_threads = true;
if (m_step_type == eStepTypeInto)
{
StackFrame *frame = thread->GetStackFrameAtIndex(0).get();
ThreadPlan *new_plan;
if (frame->HasDebugInformation ())
{
new_plan = thread->QueueThreadPlanForStepRange (abort_other_plans, m_step_type,
frame->GetSymbolContext(eSymbolContextEverything).line_entry.range,
frame->GetSymbolContext(eSymbolContextEverything),
stop_other_threads,
m_options.m_avoid_no_debug);
if (new_plan && !m_options.m_avoid_regexp.empty())
{
ThreadPlanStepInRange *step_in_range_plan = static_cast<ThreadPlanStepInRange *> (new_plan);
step_in_range_plan->SetAvoidRegexp(m_options.m_avoid_regexp.c_str());
}
}
else
new_plan = thread->QueueThreadPlanForStepSingleInstruction (false, abort_other_plans, bool_stop_other_threads);
process->GetThreadList().SetSelectedThreadByID (thread->GetID());
process->Resume ();
}
else if (m_step_type == eStepTypeOver)
{
StackFrame *frame = thread->GetStackFrameAtIndex(0).get();
ThreadPlan *new_plan;
if (frame->HasDebugInformation())
new_plan = thread->QueueThreadPlanForStepRange (abort_other_plans,
m_step_type,
frame->GetSymbolContext(eSymbolContextEverything).line_entry.range,
frame->GetSymbolContext(eSymbolContextEverything),
stop_other_threads,
false);
else
new_plan = thread->QueueThreadPlanForStepSingleInstruction (true,
abort_other_plans,
bool_stop_other_threads);
// FIXME: This will keep the step plan on the thread stack when we hit a breakpoint while stepping over.
// Maybe there should be a parameter to control this.
new_plan->SetOkayToDiscard(false);
process->GetThreadList().SetSelectedThreadByID (thread->GetID());
process->Resume ();
}
else if (m_step_type == eStepTypeTrace)
{
thread->QueueThreadPlanForStepSingleInstruction (false, abort_other_plans, bool_stop_other_threads);
process->GetThreadList().SetSelectedThreadByID (thread->GetID());
process->Resume ();
}
else if (m_step_type == eStepTypeTraceOver)
{
thread->QueueThreadPlanForStepSingleInstruction (true, abort_other_plans, bool_stop_other_threads);
process->GetThreadList().SetSelectedThreadByID (thread->GetID());
process->Resume ();
}
else if (m_step_type == eStepTypeOut)
{
ThreadPlan *new_plan;
new_plan = thread->QueueThreadPlanForStepOut (abort_other_plans,
NULL,
false,
bool_stop_other_threads,
eVoteYes,
eVoteNoOpinion,
thread->GetSelectedFrameIndex());
// FIXME: This will keep the step plan on the thread stack when we hit a breakpoint while stepping over.
// Maybe there should be a parameter to control this.
new_plan->SetOkayToDiscard(false);
process->GetThreadList().SetSelectedThreadByID (thread->GetID());
process->Resume ();
}
else
{
result.AppendError ("step type is not supported");
result.SetStatus (eReturnStatusFailed);
}
if (synchronous_execution)
{
StateType state = process->WaitForProcessToStop (NULL);
//EventSP event_sp;
//StateType state = process->WaitForStateChangedEvents (NULL, event_sp);
//while (! StateIsStoppedState (state))
// {
// state = process->WaitForStateChangedEvents (NULL, event_sp);
// }
process->GetThreadList().SetSelectedThreadByID (thread->GetID());
result.SetDidChangeProcessState (true);
result.AppendMessageWithFormat ("Process %i %s\n", process->GetID(), StateAsCString (state));
result.SetStatus (eReturnStatusSuccessFinishNoResult);
}
}
return result.Succeeded();
}
protected:
StepType m_step_type;
StepScope m_step_scope;
CommandOptions m_options;
};
static OptionEnumValueElement
g_tri_running_mode[] =
{
{ eOnlyThisThread, "this-thread", "Run only this thread"},
{ eAllThreads, "all-threads", "Run all threads"},
{ eOnlyDuringStepping, "while-stepping", "Run only this thread while stepping"},
{ 0, NULL, NULL }
};
static OptionEnumValueElement
g_duo_running_mode[] =
{
{ eOnlyThisThread, "this-thread", "Run only this thread"},
{ eAllThreads, "all-threads", "Run all threads"},
{ 0, NULL, NULL }
};
OptionDefinition
CommandObjectThreadStepWithTypeAndScope::CommandOptions::g_option_table[] =
{
{ LLDB_OPT_SET_1, false, "avoid-no-debug", 'a', required_argument, NULL, 0, eArgTypeBoolean, "A boolean value that sets whether step-in will step over functions with no debug information."},
{ LLDB_OPT_SET_1, false, "run-mode", 'm', required_argument, g_tri_running_mode, 0, eArgTypeRunMode, "Determine how to run other threads while stepping the current thread."},
{ LLDB_OPT_SET_1, false, "step-over-regexp",'r', required_argument, NULL, 0, eArgTypeRegularExpression, "A regular expression that defines function names to step over."},
{ 0, false, NULL, 0, 0, NULL, 0, eArgTypeNone, NULL }
};
//-------------------------------------------------------------------------
// CommandObjectThreadContinue
//-------------------------------------------------------------------------
class CommandObjectThreadContinue : public CommandObject
{
public:
CommandObjectThreadContinue (CommandInterpreter &interpreter) :
CommandObject (interpreter,
"thread continue",
"Continue execution of one or more threads in an active process.",
NULL,
eFlagProcessMustBeLaunched | eFlagProcessMustBePaused)
{
CommandArgumentEntry arg;
CommandArgumentData thread_idx_arg;
// Define the first (and only) variant of this arg.
thread_idx_arg.arg_type = eArgTypeThreadIndex;
thread_idx_arg.arg_repetition = eArgRepeatPlus;
// There is only one variant this argument could be; put it into the argument entry.
arg.push_back (thread_idx_arg);
// Push the data for the first argument into the m_arguments vector.
m_arguments.push_back (arg);
}
virtual
~CommandObjectThreadContinue ()
{
}
virtual bool
Execute
(
Args& command,
CommandReturnObject &result
)
{
bool synchronous_execution = m_interpreter.GetSynchronous ();
if (!m_interpreter.GetDebugger().GetSelectedTarget().get())
{
result.AppendError ("invalid target, create a debug target using the 'target create' command");
result.SetStatus (eReturnStatusFailed);
return false;
}
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
Process *process = m_interpreter.GetExecutionContext().process;
if (process == NULL)
{
result.AppendError ("no process exists. Cannot continue");
result.SetStatus (eReturnStatusFailed);
return false;
}
StateType state = process->GetState();
if ((state == eStateCrashed) || (state == eStateStopped) || (state == eStateSuspended))
{
const uint32_t num_threads = process->GetThreadList().GetSize();
uint32_t idx;
const size_t argc = command.GetArgumentCount();
if (argc > 0)
{
std::vector<uint32_t> resume_thread_indexes;
for (uint32_t i=0; i<argc; ++i)
{
idx = Args::StringToUInt32 (command.GetArgumentAtIndex(0), LLDB_INVALID_INDEX32);
if (idx < num_threads)
resume_thread_indexes.push_back(idx);
else
result.AppendWarningWithFormat("Thread index %u out of range.\n", idx);
}
if (resume_thread_indexes.empty())
{
result.AppendError ("no valid thread indexes were specified");
result.SetStatus (eReturnStatusFailed);
return false;
}
else
{
result.AppendMessage ("Resuming thread ");
for (idx=0; idx<num_threads; ++idx)
{
Thread *thread = process->GetThreadList().GetThreadAtIndex(idx).get();
if (find(resume_thread_indexes.begin(), resume_thread_indexes.end(), idx) != resume_thread_indexes.end())
{
result.AppendMessageWithFormat ("%u ", idx);
thread->SetResumeState (eStateRunning);
}
else
{
thread->SetResumeState (eStateSuspended);
}
}
result.AppendMessageWithFormat ("in process %i\n", process->GetID());
}
}
else
{
Thread *current_thread = process->GetThreadList().GetSelectedThread().get();
if (current_thread == NULL)
{
result.AppendError ("the process doesn't have a current thread");
result.SetStatus (eReturnStatusFailed);
return false;
}
// Set the actions that the threads should each take when resuming
for (idx=0; idx<num_threads; ++idx)
{
Thread *thread = process->GetThreadList().GetThreadAtIndex(idx).get();
if (thread == current_thread)
{
result.AppendMessageWithFormat ("Resuming thread 0x%4.4x in process %i\n", thread->GetID(), process->GetID());
thread->SetResumeState (eStateRunning);
}
else
{
thread->SetResumeState (eStateSuspended);
}
}
}
Error error (process->Resume());
if (error.Success())
{
result.AppendMessageWithFormat ("Process %i resuming\n", process->GetID());
if (synchronous_execution)
{
state = process->WaitForProcessToStop (NULL);
result.SetDidChangeProcessState (true);
result.AppendMessageWithFormat ("Process %i %s\n", process->GetID(), StateAsCString (state));
result.SetStatus (eReturnStatusSuccessFinishNoResult);
}
else
{
result.SetStatus (eReturnStatusSuccessContinuingNoResult);
}
}
else
{
result.AppendErrorWithFormat("Failed to resume process: %s\n", error.AsCString());
result.SetStatus (eReturnStatusFailed);
}
}
else
{
result.AppendErrorWithFormat ("Process cannot be continued from its current state (%s).\n",
StateAsCString(state));
result.SetStatus (eReturnStatusFailed);
}
return result.Succeeded();
}
};
//-------------------------------------------------------------------------
// CommandObjectThreadUntil
//-------------------------------------------------------------------------
class CommandObjectThreadUntil : public CommandObject
{
public:
class CommandOptions : public Options
{
public:
uint32_t m_thread_idx;
uint32_t m_frame_idx;
CommandOptions (CommandInterpreter &interpreter) :
Options (interpreter),
m_thread_idx(LLDB_INVALID_THREAD_ID),
m_frame_idx(LLDB_INVALID_FRAME_ID)
{
Added two new classes for command options: lldb_private::OptionGroup lldb_private::OptionGroupOptions OptionGroup lets you define a class that encapsulates settings that you want to reuse in multiple commands. It contains only the option definitions and the ability to set the option values, but it doesn't directly interface with the lldb_private::Options class that is the front end to all of the CommandObject option parsing. For that the OptionGroupOptions class can be used. It aggregates one or more OptionGroup objects and directs the option setting to the appropriate OptionGroup class. For an example of this, take a look at the CommandObjectFile and how it uses its "m_option_group" object shown below to be able to set values in both the FileOptionGroup and PlatformOptionGroup classes. The members used in CommandObjectFile are: OptionGroupOptions m_option_group; FileOptionGroup m_file_options; PlatformOptionGroup m_platform_options; Then in the constructor for CommandObjectFile you can combine the option settings. The code below shows a simplified version of the constructor: CommandObjectFile::CommandObjectFile(CommandInterpreter &interpreter) : CommandObject (...), m_option_group (interpreter), m_file_options (), m_platform_options(true) { m_option_group.Append (&m_file_options); m_option_group.Append (&m_platform_options); m_option_group.Finalize(); } We append the m_file_options and then the m_platform_options and then tell the option group the finalize the results. This allows the m_option_group to become the organizer of our prefs and after option parsing we end up with valid preference settings in both the m_file_options and m_platform_options objects. This also allows any other commands to use the FileOptionGroup and PlatformOptionGroup classes to implement options for their commands. Renamed: virtual void Options::ResetOptionValues(); to: virtual void Options::OptionParsingStarting(); And implemented a new callback named: virtual Error Options::OptionParsingFinished(); This allows Options subclasses to verify that the options all go together after all of the options have been specified and gives the chance for the command object to return an error. It also gives a chance to take all of the option values and produce or initialize objects after all options have completed parsing. Modfied: virtual Error SetOptionValue (int option_idx, const char *option_arg) = 0; to be: virtual Error SetOptionValue (uint32_t option_idx, const char *option_arg) = 0; (option_idx is now unsigned). llvm-svn: 129415
2011-04-13 08:18:08 +08:00
// Keep default values of all options in one place: OptionParsingStarting ()
OptionParsingStarting ();
}
virtual
~CommandOptions ()
{
}
virtual Error
Added two new classes for command options: lldb_private::OptionGroup lldb_private::OptionGroupOptions OptionGroup lets you define a class that encapsulates settings that you want to reuse in multiple commands. It contains only the option definitions and the ability to set the option values, but it doesn't directly interface with the lldb_private::Options class that is the front end to all of the CommandObject option parsing. For that the OptionGroupOptions class can be used. It aggregates one or more OptionGroup objects and directs the option setting to the appropriate OptionGroup class. For an example of this, take a look at the CommandObjectFile and how it uses its "m_option_group" object shown below to be able to set values in both the FileOptionGroup and PlatformOptionGroup classes. The members used in CommandObjectFile are: OptionGroupOptions m_option_group; FileOptionGroup m_file_options; PlatformOptionGroup m_platform_options; Then in the constructor for CommandObjectFile you can combine the option settings. The code below shows a simplified version of the constructor: CommandObjectFile::CommandObjectFile(CommandInterpreter &interpreter) : CommandObject (...), m_option_group (interpreter), m_file_options (), m_platform_options(true) { m_option_group.Append (&m_file_options); m_option_group.Append (&m_platform_options); m_option_group.Finalize(); } We append the m_file_options and then the m_platform_options and then tell the option group the finalize the results. This allows the m_option_group to become the organizer of our prefs and after option parsing we end up with valid preference settings in both the m_file_options and m_platform_options objects. This also allows any other commands to use the FileOptionGroup and PlatformOptionGroup classes to implement options for their commands. Renamed: virtual void Options::ResetOptionValues(); to: virtual void Options::OptionParsingStarting(); And implemented a new callback named: virtual Error Options::OptionParsingFinished(); This allows Options subclasses to verify that the options all go together after all of the options have been specified and gives the chance for the command object to return an error. It also gives a chance to take all of the option values and produce or initialize objects after all options have completed parsing. Modfied: virtual Error SetOptionValue (int option_idx, const char *option_arg) = 0; to be: virtual Error SetOptionValue (uint32_t option_idx, const char *option_arg) = 0; (option_idx is now unsigned). llvm-svn: 129415
2011-04-13 08:18:08 +08:00
SetOptionValue (uint32_t option_idx, const char *option_arg)
{
Error error;
char short_option = (char) m_getopt_table[option_idx].val;
switch (short_option)
{
case 't':
{
m_thread_idx = Args::StringToUInt32 (option_arg, LLDB_INVALID_INDEX32);
if (m_thread_idx == LLDB_INVALID_INDEX32)
{
error.SetErrorStringWithFormat ("Invalid thread index '%s'.\n", option_arg);
}
}
break;
case 'f':
{
m_frame_idx = Args::StringToUInt32 (option_arg, LLDB_INVALID_FRAME_ID);
if (m_frame_idx == LLDB_INVALID_FRAME_ID)
{
error.SetErrorStringWithFormat ("Invalid frame index '%s'.\n", option_arg);
}
}
break;
case 'm':
{
bool found_one = false;
OptionEnumValueElement *enum_values = g_option_table[option_idx].enum_values;
lldb::RunMode run_mode = (lldb::RunMode) Args::StringToOptionEnum(option_arg, enum_values, eOnlyDuringStepping, &found_one);
if (!found_one)
error.SetErrorStringWithFormat("Invalid enumeration value for option '%c'.\n", short_option);
else if (run_mode == eAllThreads)
m_stop_others = false;
else
m_stop_others = true;
}
break;
default:
error.SetErrorStringWithFormat("Invalid short option character '%c'.\n", short_option);
break;
}
return error;
}
void
Added two new classes for command options: lldb_private::OptionGroup lldb_private::OptionGroupOptions OptionGroup lets you define a class that encapsulates settings that you want to reuse in multiple commands. It contains only the option definitions and the ability to set the option values, but it doesn't directly interface with the lldb_private::Options class that is the front end to all of the CommandObject option parsing. For that the OptionGroupOptions class can be used. It aggregates one or more OptionGroup objects and directs the option setting to the appropriate OptionGroup class. For an example of this, take a look at the CommandObjectFile and how it uses its "m_option_group" object shown below to be able to set values in both the FileOptionGroup and PlatformOptionGroup classes. The members used in CommandObjectFile are: OptionGroupOptions m_option_group; FileOptionGroup m_file_options; PlatformOptionGroup m_platform_options; Then in the constructor for CommandObjectFile you can combine the option settings. The code below shows a simplified version of the constructor: CommandObjectFile::CommandObjectFile(CommandInterpreter &interpreter) : CommandObject (...), m_option_group (interpreter), m_file_options (), m_platform_options(true) { m_option_group.Append (&m_file_options); m_option_group.Append (&m_platform_options); m_option_group.Finalize(); } We append the m_file_options and then the m_platform_options and then tell the option group the finalize the results. This allows the m_option_group to become the organizer of our prefs and after option parsing we end up with valid preference settings in both the m_file_options and m_platform_options objects. This also allows any other commands to use the FileOptionGroup and PlatformOptionGroup classes to implement options for their commands. Renamed: virtual void Options::ResetOptionValues(); to: virtual void Options::OptionParsingStarting(); And implemented a new callback named: virtual Error Options::OptionParsingFinished(); This allows Options subclasses to verify that the options all go together after all of the options have been specified and gives the chance for the command object to return an error. It also gives a chance to take all of the option values and produce or initialize objects after all options have completed parsing. Modfied: virtual Error SetOptionValue (int option_idx, const char *option_arg) = 0; to be: virtual Error SetOptionValue (uint32_t option_idx, const char *option_arg) = 0; (option_idx is now unsigned). llvm-svn: 129415
2011-04-13 08:18:08 +08:00
OptionParsingStarting ()
{
m_thread_idx = LLDB_INVALID_THREAD_ID;
m_frame_idx = 0;
m_stop_others = false;
}
const OptionDefinition*
GetDefinitions ()
{
return g_option_table;
}
uint32_t m_step_thread_idx;
bool m_stop_others;
// Options table: Required for subclasses of Options.
static OptionDefinition g_option_table[];
// Instance variables to hold the values for command options.
};
CommandObjectThreadUntil (CommandInterpreter &interpreter) :
CommandObject (interpreter,
"thread until",
"Run the current or specified thread until it reaches a given line number or leaves the current function.",
NULL,
eFlagProcessMustBeLaunched | eFlagProcessMustBePaused),
m_options (interpreter)
{
CommandArgumentEntry arg;
CommandArgumentData line_num_arg;
// Define the first (and only) variant of this arg.
line_num_arg.arg_type = eArgTypeLineNum;
line_num_arg.arg_repetition = eArgRepeatPlain;
// There is only one variant this argument could be; put it into the argument entry.
arg.push_back (line_num_arg);
// Push the data for the first argument into the m_arguments vector.
m_arguments.push_back (arg);
}
virtual
~CommandObjectThreadUntil ()
{
}
virtual
Options *
GetOptions ()
{
return &m_options;
}
virtual bool
Execute
(
Args& command,
CommandReturnObject &result
)
{
bool synchronous_execution = m_interpreter.GetSynchronous ();
Target *target = m_interpreter.GetDebugger().GetSelectedTarget().get();
if (target == NULL)
{
result.AppendError ("invalid target, create a debug target using the 'target create' command");
result.SetStatus (eReturnStatusFailed);
return false;
}
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
Process *process = m_interpreter.GetExecutionContext().process;
if (process == NULL)
{
result.AppendError ("need a valid process to step");
result.SetStatus (eReturnStatusFailed);
}
else
{
Thread *thread = NULL;
uint32_t line_number;
if (command.GetArgumentCount() != 1)
{
result.AppendErrorWithFormat ("No line number provided:\n%s", GetSyntax());
result.SetStatus (eReturnStatusFailed);
return false;
}
line_number = Args::StringToUInt32 (command.GetArgumentAtIndex(0), UINT32_MAX);
if (line_number == UINT32_MAX)
{
result.AppendErrorWithFormat ("Invalid line number: '%s'.\n", command.GetArgumentAtIndex(0));
result.SetStatus (eReturnStatusFailed);
return false;
}
if (m_options.m_thread_idx == LLDB_INVALID_THREAD_ID)
{
thread = process->GetThreadList().GetSelectedThread().get();
}
else
{
thread = process->GetThreadList().GetThreadAtIndex(m_options.m_thread_idx).get();
}
if (thread == NULL)
{
const uint32_t num_threads = process->GetThreadList().GetSize();
result.AppendErrorWithFormat ("Thread index %u is out of range (valid values are 0 - %u).\n",
m_options.m_thread_idx,
0,
num_threads);
result.SetStatus (eReturnStatusFailed);
return false;
}
const bool abort_other_plans = true;
StackFrame *frame = thread->GetStackFrameAtIndex(m_options.m_frame_idx).get();
if (frame == NULL)
{
result.AppendErrorWithFormat ("Frame index %u is out of range for thread %u.\n",
m_options.m_frame_idx,
m_options.m_thread_idx);
result.SetStatus (eReturnStatusFailed);
return false;
}
ThreadPlan *new_plan;
if (frame->HasDebugInformation ())
{
// Finally we got here... Translate the given line number to a bunch of addresses:
SymbolContext sc(frame->GetSymbolContext (eSymbolContextCompUnit));
LineTable *line_table = NULL;
if (sc.comp_unit)
line_table = sc.comp_unit->GetLineTable();
if (line_table == NULL)
{
result.AppendErrorWithFormat ("Failed to resolve the line table for frame %u of thread index %u.\n",
m_options.m_frame_idx, m_options.m_thread_idx);
result.SetStatus (eReturnStatusFailed);
return false;
}
LineEntry function_start;
uint32_t index_ptr = 0, end_ptr;
std::vector<addr_t> address_list;
// Find the beginning & end index of the
AddressRange fun_addr_range = sc.function->GetAddressRange();
Address fun_start_addr = fun_addr_range.GetBaseAddress();
line_table->FindLineEntryByAddress (fun_start_addr, function_start, &index_ptr);
Address fun_end_addr(fun_start_addr.GetSection(),
fun_start_addr.GetOffset() + fun_addr_range.GetByteSize());
line_table->FindLineEntryByAddress (fun_end_addr, function_start, &end_ptr);
bool all_in_function = true;
while (index_ptr <= end_ptr)
{
LineEntry line_entry;
index_ptr = sc.comp_unit->FindLineEntry(index_ptr, line_number, sc.comp_unit, &line_entry);
if (index_ptr == UINT32_MAX)
break;
addr_t address = line_entry.range.GetBaseAddress().GetLoadAddress(target);
if (address != LLDB_INVALID_ADDRESS)
{
if (fun_addr_range.ContainsLoadAddress (address, target))
address_list.push_back (address);
else
all_in_function = false;
}
index_ptr++;
}
if (address_list.size() == 0)
{
if (all_in_function)
result.AppendErrorWithFormat ("No line entries matching until target.\n");
else
result.AppendErrorWithFormat ("Until target outside of the current function.\n");
result.SetStatus (eReturnStatusFailed);
return false;
}
new_plan = thread->QueueThreadPlanForStepUntil (abort_other_plans,
&address_list.front(),
address_list.size(),
m_options.m_stop_others,
thread->GetSelectedFrameIndex ());
new_plan->SetOkayToDiscard(false);
}
else
{
result.AppendErrorWithFormat ("Frame index %u of thread %u has no debug information.\n",
m_options.m_frame_idx,
m_options.m_thread_idx);
result.SetStatus (eReturnStatusFailed);
return false;
}
process->GetThreadList().SetSelectedThreadByID (m_options.m_thread_idx);
Error error (process->Resume ());
if (error.Success())
{
result.AppendMessageWithFormat ("Process %i resuming\n", process->GetID());
if (synchronous_execution)
{
StateType state = process->WaitForProcessToStop (NULL);
result.SetDidChangeProcessState (true);
result.AppendMessageWithFormat ("Process %i %s\n", process->GetID(), StateAsCString (state));
result.SetStatus (eReturnStatusSuccessFinishNoResult);
}
else
{
result.SetStatus (eReturnStatusSuccessContinuingNoResult);
}
}
else
{
result.AppendErrorWithFormat("Failed to resume process: %s.\n", error.AsCString());
result.SetStatus (eReturnStatusFailed);
}
}
return result.Succeeded();
}
protected:
CommandOptions m_options;
};
OptionDefinition
CommandObjectThreadUntil::CommandOptions::g_option_table[] =
{
{ LLDB_OPT_SET_1, false, "frame", 'f', required_argument, NULL, 0, eArgTypeFrameIndex, "Frame index for until operation - defaults to 0"},
{ LLDB_OPT_SET_1, false, "thread", 't', required_argument, NULL, 0, eArgTypeThreadIndex, "Thread index for the thread for until operation"},
{ LLDB_OPT_SET_1, false, "run-mode",'m', required_argument, g_duo_running_mode, 0, eArgTypeRunMode,"Determine how to run other threads while stepping this one"},
{ 0, false, NULL, 0, 0, NULL, 0, eArgTypeNone, NULL }
};
//-------------------------------------------------------------------------
// CommandObjectThreadSelect
//-------------------------------------------------------------------------
class CommandObjectThreadSelect : public CommandObject
{
public:
CommandObjectThreadSelect (CommandInterpreter &interpreter) :
CommandObject (interpreter,
"thread select",
"Select a thread as the currently active thread.",
NULL,
eFlagProcessMustBeLaunched | eFlagProcessMustBePaused)
{
CommandArgumentEntry arg;
CommandArgumentData thread_idx_arg;
// Define the first (and only) variant of this arg.
thread_idx_arg.arg_type = eArgTypeThreadIndex;
thread_idx_arg.arg_repetition = eArgRepeatPlain;
// There is only one variant this argument could be; put it into the argument entry.
arg.push_back (thread_idx_arg);
// Push the data for the first argument into the m_arguments vector.
m_arguments.push_back (arg);
}
virtual
~CommandObjectThreadSelect ()
{
}
virtual bool
Execute
(
Args& command,
CommandReturnObject &result
)
{
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
Process *process = m_interpreter.GetExecutionContext().process;
if (process == NULL)
{
result.AppendError ("no process");
result.SetStatus (eReturnStatusFailed);
return false;
}
else if (command.GetArgumentCount() != 1)
{
result.AppendErrorWithFormat("'%s' takes exactly one thread index argument:\nUsage: \n", m_cmd_name.c_str(), m_cmd_syntax.c_str());
result.SetStatus (eReturnStatusFailed);
return false;
}
uint32_t index_id = Args::StringToUInt32(command.GetArgumentAtIndex(0), 0, 0);
Thread *new_thread = process->GetThreadList().FindThreadByIndexID(index_id).get();
if (new_thread == NULL)
{
result.AppendErrorWithFormat ("Invalid thread #%s.\n", command.GetArgumentAtIndex(0));
result.SetStatus (eReturnStatusFailed);
return false;
}
process->GetThreadList().SetSelectedThreadByID(new_thread->GetID());
result.SetStatus (eReturnStatusSuccessFinishNoResult);
Centralized a lot of the status information for processes, threads, and stack frame down in the lldb_private::Process, lldb_private::Thread, lldb_private::StackFrameList and the lldb_private::StackFrame classes. We had some command line commands that had duplicate versions of the process status output ("thread list" and "process status" for example). Removed the "file" command and placed it where it should have been: "target create". Made an alias for "file" to "target create" so we stay compatible with GDB commands. We can now have multple usable targets in lldb at the same time. This is nice for comparing two runs of a program or debugging more than one binary at the same time. The new command is "target select <target-idx>" and also to see a list of the current targets you can use the new "target list" command. The flow in a debug session can be: (lldb) target create /path/to/exe/a.out (lldb) breakpoint set --name main (lldb) run ... hit breakpoint (lldb) target create /bin/ls (lldb) run /tmp Process 36001 exited with status = 0 (0x00000000) (lldb) target list Current targets: target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) * target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) target select 0 Current targets: * target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) bt * thread #1: tid = 0x2d03, 0x0000000100000b9a a.out`main + 42 at main.c:16, stop reason = breakpoint 1.1 frame #0: 0x0000000100000b9a a.out`main + 42 at main.c:16 frame #1: 0x0000000100000b64 a.out`start + 52 Above we created a target for "a.out" and ran and hit a breakpoint at "main". Then we created a new target for /bin/ls and ran it. Then we listed the targest and selected our original "a.out" program, so we showed two concurent debug sessions going on at the same time. llvm-svn: 129695
2011-04-18 16:33:37 +08:00
const uint32_t start_frame = 0;
const uint32_t num_frames = 1;
const uint32_t num_frames_with_source = 1;
new_thread->GetStatus (result.GetOutputStream(),
start_frame,
num_frames,
num_frames_with_source);
return result.Succeeded();
}
};
//-------------------------------------------------------------------------
// CommandObjectThreadList
//-------------------------------------------------------------------------
class CommandObjectThreadList : public CommandObject
{
public:
CommandObjectThreadList (CommandInterpreter &interpreter):
CommandObject (interpreter,
"thread list",
"Show a summary of all current threads in a process.",
"thread list",
eFlagProcessMustBeLaunched | eFlagProcessMustBePaused)
{
}
~CommandObjectThreadList()
{
}
bool
Execute
(
Args& command,
CommandReturnObject &result
)
{
Stream &strm = result.GetOutputStream();
result.SetStatus (eReturnStatusSuccessFinishNoResult);
Moved the execution context that was in the Debugger into the CommandInterpreter where it was always being used. Make sure that Modules can track their object file offsets correctly to allow opening of sub object files (like the "__commpage" on darwin). Modified the Platforms to be able to launch processes. The first part of this move is the platform soon will become the entity that launches your program and when it does, it uses a new ProcessLaunchInfo class which encapsulates all process launching settings. This simplifies the internal APIs needed for launching. I want to slowly phase out process launching from the process classes, so for now we can still launch just as we used to, but eventually the platform is the object that should do the launching. Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able to launch processes with all of the new eLaunchFlag settings. Modified any code that was manually launching processes to use the Host::LaunchProcess functions. Fixed an issue where lldb_private::Args had implicitly defined copy constructors that could do the wrong thing. This has now been fixed by adding an appropriate copy constructor and assignment operator. Make sure we don't add empty ModuleSP entries to a module list. Fixed the commpage module creation on MacOSX, but we still need to train the MacOSX dynamic loader to not get rid of it when it doesn't have an entry in the all image infos. Abstracted many more calls from in ProcessGDBRemote down into the GDBRemoteCommunicationClient subclass to make the classes cleaner and more efficient. Fixed the default iOS ARM register context to be correct and also added support for targets that don't support the qThreadStopInfo packet by selecting the current thread (only if needed) and then sending a stop reply packet. Debugserver can now start up with a --unix-socket (-u for short) and can then bind to port zero and send the port it bound to to a listening process on the other end. This allows the GDB remote platform to spawn new GDB server instances (debugserver) to allow platform debugging. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
ExecutionContext exe_ctx(m_interpreter.GetExecutionContext());
if (exe_ctx.process)
{
Centralized a lot of the status information for processes, threads, and stack frame down in the lldb_private::Process, lldb_private::Thread, lldb_private::StackFrameList and the lldb_private::StackFrame classes. We had some command line commands that had duplicate versions of the process status output ("thread list" and "process status" for example). Removed the "file" command and placed it where it should have been: "target create". Made an alias for "file" to "target create" so we stay compatible with GDB commands. We can now have multple usable targets in lldb at the same time. This is nice for comparing two runs of a program or debugging more than one binary at the same time. The new command is "target select <target-idx>" and also to see a list of the current targets you can use the new "target list" command. The flow in a debug session can be: (lldb) target create /path/to/exe/a.out (lldb) breakpoint set --name main (lldb) run ... hit breakpoint (lldb) target create /bin/ls (lldb) run /tmp Process 36001 exited with status = 0 (0x00000000) (lldb) target list Current targets: target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) * target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) target select 0 Current targets: * target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) bt * thread #1: tid = 0x2d03, 0x0000000100000b9a a.out`main + 42 at main.c:16, stop reason = breakpoint 1.1 frame #0: 0x0000000100000b9a a.out`main + 42 at main.c:16 frame #1: 0x0000000100000b64 a.out`start + 52 Above we created a target for "a.out" and ran and hit a breakpoint at "main". Then we created a new target for /bin/ls and ran it. Then we listed the targest and selected our original "a.out" program, so we showed two concurent debug sessions going on at the same time. llvm-svn: 129695
2011-04-18 16:33:37 +08:00
const bool only_threads_with_stop_reason = false;
const uint32_t start_frame = 0;
const uint32_t num_frames = 0;
const uint32_t num_frames_with_source = 0;
exe_ctx.process->GetStatus(strm);
exe_ctx.process->GetThreadStatus (strm,
only_threads_with_stop_reason,
start_frame,
num_frames,
num_frames_with_source);
}
else
{
result.AppendError ("no current location or status available");
result.SetStatus (eReturnStatusFailed);
}
return result.Succeeded();
}
};
//-------------------------------------------------------------------------
// CommandObjectMultiwordThread
//-------------------------------------------------------------------------
CommandObjectMultiwordThread::CommandObjectMultiwordThread (CommandInterpreter &interpreter) :
CommandObjectMultiword (interpreter,
"thread",
"A set of commands for operating on one or more threads within a running process.",
"thread <subcommand> [<subcommand-options>]")
{
LoadSubCommand ("backtrace", CommandObjectSP (new CommandObjectThreadBacktrace (interpreter)));
LoadSubCommand ("continue", CommandObjectSP (new CommandObjectThreadContinue (interpreter)));
LoadSubCommand ("list", CommandObjectSP (new CommandObjectThreadList (interpreter)));
LoadSubCommand ("select", CommandObjectSP (new CommandObjectThreadSelect (interpreter)));
LoadSubCommand ("until", CommandObjectSP (new CommandObjectThreadUntil (interpreter)));
LoadSubCommand ("step-in", CommandObjectSP (new CommandObjectThreadStepWithTypeAndScope (
interpreter,
"thread step-in",
"Source level single step in specified thread (current thread, if none specified).",
NULL,
eFlagProcessMustBeLaunched | eFlagProcessMustBePaused,
eStepTypeInto,
eStepScopeSource)));
LoadSubCommand ("step-out", CommandObjectSP (new CommandObjectThreadStepWithTypeAndScope (
interpreter,
"thread step-out",
"Finish executing the current fucntion and return to its call site in specified thread (current thread, if none specified).",
NULL,
eFlagProcessMustBeLaunched | eFlagProcessMustBePaused,
eStepTypeOut,
eStepScopeSource)));
LoadSubCommand ("step-over", CommandObjectSP (new CommandObjectThreadStepWithTypeAndScope (
interpreter,
"thread step-over",
"Source level single step in specified thread (current thread, if none specified), stepping over calls.",
NULL,
eFlagProcessMustBeLaunched | eFlagProcessMustBePaused,
eStepTypeOver,
eStepScopeSource)));
LoadSubCommand ("step-inst", CommandObjectSP (new CommandObjectThreadStepWithTypeAndScope (
interpreter,
"thread step-inst",
"Single step one instruction in specified thread (current thread, if none specified).",
NULL,
eFlagProcessMustBeLaunched | eFlagProcessMustBePaused,
eStepTypeTrace,
eStepScopeInstruction)));
LoadSubCommand ("step-inst-over", CommandObjectSP (new CommandObjectThreadStepWithTypeAndScope (
interpreter,
"thread step-inst-over",
"Single step one instruction in specified thread (current thread, if none specified), stepping over calls.",
NULL,
eFlagProcessMustBeLaunched | eFlagProcessMustBePaused,
eStepTypeTraceOver,
eStepScopeInstruction)));
}
CommandObjectMultiwordThread::~CommandObjectMultiwordThread ()
{
}