| #
7260f620 |
| 18-Apr-2011 |
Greg Clayton <[email protected]> |
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::StackF
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
show more ...
|
| #
f6b8b581 |
| 13-Apr-2011 |
Greg Clayton <[email protected]> |
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 i
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
show more ...
|
| #
eb0103f2 |
| 07-Apr-2011 |
Greg Clayton <[email protected]> |
Modified the ArchSpec to take an optional "Platform *" when setting the triple. This allows you to have a platform selected, then specify a triple using "i386" and have the remaining triple items (ve
Modified the ArchSpec to take an optional "Platform *" when setting the triple. This allows you to have a platform selected, then specify a triple using "i386" and have the remaining triple items (vendor, os, and environment) set automatically.
Many interpreter commands take the "--arch" option to specify an architecture triple, so now the command options needed to be able to get to the current platform, so the Options class now take a reference to the interpreter on construction.
Modified the build LLVM building in the Xcode project to use the new Xcode project level user definitions:
LLVM_BUILD_DIR - a path to the llvm build directory LLVM_SOURCE_DIR - a path to the llvm sources for the llvm that will be used to build lldb LLVM_CONFIGURATION - the configuration that lldb is built for (Release, Release+Asserts, Debug, Debug+Asserts).
I also changed the LLVM build to not check if "lldb/llvm" is a symlink and then assume it is a real llvm build directory versus the unzipped llvm.zip package, so now you can actually have a "lldb/llvm" directory in your lldb sources.
llvm-svn: 129112
show more ...
|
|
Revision tags: llvmorg-2.9.0, llvmorg-2.9.0-rc3, llvmorg-2.9.0-rc2 |
|
| #
e0d378b3 |
| 24-Mar-2011 |
Greg Clayton <[email protected]> |
Fixed the LLDB build so that we can have private types, private enums and public types and public enums. This was done to keep the SWIG stuff from parsing all sorts of enums and types that weren't ne
Fixed the LLDB build so that we can have private types, private enums and public types and public enums. This was done to keep the SWIG stuff from parsing all sorts of enums and types that weren't needed, and allows us to abstract our API better.
llvm-svn: 128239
show more ...
|
| #
0292f4a5 |
| 22-Mar-2011 |
Jim Ingham <[email protected]> |
Clean up a few places where SetOptionValue was using the global optarg, rather than the option_arg value that was passed in.
llvm-svn: 128064
|
| #
9575d844 |
| 11-Mar-2011 |
Jim Ingham <[email protected]> |
Add a first pass at a "stop hook" mechanism. This allows you to add commands that get run every time the debugger stops, whether due to a breakpoint, the end of a step, interrupt, etc. You can also
Add a first pass at a "stop hook" mechanism. This allows you to add commands that get run every time the debugger stops, whether due to a breakpoint, the end of a step, interrupt, etc. You can also specify in which context you want the stop hook to run, for instance only on a particular thread, or only in a particular shared library, function, file, line range within a file.
Still need to add "in methods of a class" to the specifiers, and the ability to write the stop hooks in the Scripting language as well as in the Command Language.
llvm-svn: 127457
show more ...
|
|
Revision tags: llvmorg-2.9.0-rc1 |
|
| #
7791b332 |
| 03-Feb-2011 |
Johnny Chen <[email protected]> |
Add a test case test_image_search_paths() to test lldb's ability to do image search paths substitutions in order to achieve file mappings.
Modify CommandObjectTarget.cpp to properly set the status o
Add a test case test_image_search_paths() to test lldb's ability to do image search paths substitutions in order to achieve file mappings.
Modify CommandObjectTarget.cpp to properly set the status of the return object to make scripting like this:
self.runCmd("target image-search-paths add %s %s" % (os.getcwd(), new_dir))
works.
llvm-svn: 124762
show more ...
|
| #
c4a99bc4 |
| 01-Feb-2011 |
Greg Clayton <[email protected]> |
Patch from Kirk Beitz that removes an unneeded include of "sys/errno.h".
llvm-svn: 124638
|
|
Revision tags: llvmorg-2.8.0 |
|
| #
405fe67f |
| 04-Oct-2010 |
Caroline Tice <[email protected]> |
Modify existing commands with arguments to use the new argument mechanism (for standardized argument names, argument help, etc.)
llvm-svn: 115570
|
|
Revision tags: llvmorg-2.8.0-rc3, llvmorg-2.8.0-rc2 |
|
| #
a7015092 |
| 18-Sep-2010 |
Greg Clayton <[email protected]> |
Fixed the way set/show variables were being accessed to being natively accessed by the objects that own the settings. The previous approach wasn't very usable and made for a lot of unnecessary code
Fixed the way set/show variables were being accessed to being natively accessed by the objects that own the settings. The previous approach wasn't very usable and made for a lot of unnecessary code just to access variables that were already owned by the objects.
While I fixed those things, I saw that CommandObject objects should really have a reference to their command interpreter so they can access the terminal with if they want to output usaage. Fixed up all CommandObjects to take an interpreter and cleaned up the API to not need the interpreter to be passed in.
Fixed the disassemble command to output the usage if no options are passed down and arguments are passed (all disassebmle variants take options, there are no "args only").
llvm-svn: 114252
show more ...
|
| #
e3d26315 |
| 08-Sep-2010 |
Caroline Tice <[email protected]> |
Clean up, clarify and standardize help text, and fix a few help text formatting problems.
llvm-svn: 113408
|
|
Revision tags: llvmorg-2.8.0-rc1, llvmorg-2.8.0-rc0 |
|
| #
2976d00a |
| 26-Aug-2010 |
Jim Ingham <[email protected]> |
Change "Current" as in GetCurrentThread, GetCurrentStackFrame, etc, to "Selected" i.e. GetSelectedThread. Selected makes more sense, since these are set by some user action (a selection). I didn't
Change "Current" as in GetCurrentThread, GetCurrentStackFrame, etc, to "Selected" i.e. GetSelectedThread. Selected makes more sense, since these are set by some user action (a selection). I didn't change "CurrentProcess" since this is always controlled by the target, and a given target can only have one process, so it really can't be selected.
llvm-svn: 112221
show more ...
|
| #
6611103c |
| 23-Jun-2010 |
Greg Clayton <[email protected]> |
Very large changes that were needed in order to allow multiple connections to the debugger from GUI windows. Previously there was one global debugger instance that could be accessed that had its own
Very large changes that were needed in order to allow multiple connections to the debugger from GUI windows. Previously there was one global debugger instance that could be accessed that had its own command interpreter and current state (current target/process/thread/frame). When a GUI debugger was attached, if it opened more than one window that each had a console window, there were issues where the last one to setup the global debugger object won and got control of the debugger.
To avoid this we now create instances of the lldb_private::Debugger that each has its own state: - target list for targets the debugger instance owns - current process/thread/frame - its own command interpreter - its own input, output and error file handles to avoid conflicts - its own input reader stack
So now clients should call:
SBDebugger::Initialize(); // (static function)
SBDebugger debugger (SBDebugger::Create()); // Use which ever file handles you wish debugger.SetErrorFileHandle (stderr, false); debugger.SetOutputFileHandle (stdout, false); debugger.SetInputFileHandle (stdin, true);
// main loop SBDebugger::Terminate(); // (static function) SBDebugger::Initialize() and SBDebugger::Terminate() are ref counted to ensure nothing gets destroyed too early when multiple clients might be attached.
Cleaned up the command interpreter and the CommandObject and all subclasses to take more appropriate arguments.
llvm-svn: 106615
show more ...
|
| #
40af72e1 |
| 15-Jun-2010 |
Jim Ingham <[email protected]> |
Move Args.{cpp,h} and Options.{cpp,h} to Interpreter where they really belong.
llvm-svn: 106034
|
| #
30fdc8d8 |
| 08-Jun-2010 |
Chris Lattner <[email protected]> |
Initial checkin of lldb code from internal Apple repo.
llvm-svn: 105619
|