maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lldb/source/Core/Debugger.cpp

2495 lines
115 KiB
C++
Raw Normal View History

Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
//===-- Debugger.cpp --------------------------------------------*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
Committing type format code for Enrico Granata. This commit adds a new top level command named "type". Currently this command implements three commands: type format add <format> <typename1> [<typename2> ...] type format delete <typename1> [<typename2> ...] type format list [<typename1> [<typename2>] ...] This allows you to specify the default format that will be used to display types when you use "frame variable" or "expression", or the SBValue classes. Examples: // Format uint*_t as hex type format add x uint16_t uint32_t uint64_t // Format intptr_t as a pointer type format add p intptr_t The format characters are the same as "printf" for the most part with many additions. These format character specifiers are also used in many other commands ("frame variable" for one). The current list of format characters include: a - char buffer b - binary B - boolean c - char C - printable char d - signed decimal e - float f - float g - float i - signed decimal I - complex integer o - octal O - OSType p - pointer s - c-string u - unsigned decimal x - hex X - complex float y - bytes Y - bytes with ASCII llvm-svn: 133728
2011-06-24 01:59:56 +08:00
#include "lldb/Core/Debugger.h"
#include <map>
This commit adds a new top subcommand "summary" to command type named "type". Currently this command implements three commands: type summary add <format> <typename1> [<typename2> ...] type summary delete <typename1> [<typename2> ...] type summary list [<typename1> [<typename2>] ...] type summary clear This allows you to specify the default format that will be used to display summaries for variables, shown when you use "frame variable" or "expression", or the SBValue classes. Examples: type summary add "x = ${var.x}" Point type summary list type summary add --one-liner SimpleType llvm-svn: 134108
2011-06-30 06:27:15 +08:00
#include "clang/AST/DeclCXX.h"
#include "clang/AST/Type.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
#include "lldb/lldb-private.h"
#include "lldb/Core/ConnectionFileDescriptor.h"
<rdar://problem/11338654> Fixing a bug where having a summary for a bitfield without a format specified would in certain cases crash LLDB - This has also led to refactoring the by-type accessors for the data formatter subsystem. These now belong in our internal layer, and are just invoked by the public API stratum llvm-svn: 156429
2012-05-09 05:49:57 +08:00
#include "lldb/Core/DataVisualization.h"
Committing type format code for Enrico Granata. This commit adds a new top level command named "type". Currently this command implements three commands: type format add <format> <typename1> [<typename2> ...] type format delete <typename1> [<typename2> ...] type format list [<typename1> [<typename2>] ...] This allows you to specify the default format that will be used to display types when you use "frame variable" or "expression", or the SBValue classes. Examples: // Format uint*_t as hex type format add x uint16_t uint32_t uint64_t // Format intptr_t as a pointer type format add p intptr_t The format characters are the same as "printf" for the most part with many additions. These format character specifiers are also used in many other commands ("frame variable" for one). The current list of format characters include: a - char buffer b - binary B - boolean c - char C - printable char d - signed decimal e - float f - float g - float i - signed decimal I - complex integer o - octal O - OSType p - pointer s - c-string u - unsigned decimal x - hex X - complex float y - bytes Y - bytes with ASCII llvm-svn: 133728
2011-06-24 01:59:56 +08:00
#include "lldb/Core/FormatManager.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
#include "lldb/Core/InputReader.h"
While implementing unwind information using UnwindAssemblyInstEmulation I ran into some cleanup I have been wanting to do when reading/writing registers. Previously all RegisterContext subclasses would need to implement: virtual bool ReadRegisterBytes (uint32_t reg, DataExtractor &data); virtual bool WriteRegisterBytes (uint32_t reg, DataExtractor &data, uint32_t data_offset = 0); There is now a new class specifically designed to hold register values: lldb_private::RegisterValue The new register context calls that subclasses must implement are: virtual bool ReadRegister (const RegisterInfo *reg_info, RegisterValue &reg_value) = 0; virtual bool WriteRegister (const RegisterInfo *reg_info, const RegisterValue &reg_value) = 0; The RegisterValue class must be big enough to handle any register value. The class contains an enumeration for the value type, and then a union for the data value. Any integer/float values are stored directly in an appropriate host integer/float. Anything bigger is stored in a byte buffer that has a length and byte order. The RegisterValue class also knows how to copy register value bytes into in a buffer with a specified byte order which can be used to write the register value down into memory, and this does the right thing when not all bytes from the register values are needed (getting a uint8 from a uint32 register value..). All RegiterContext and other sources have been switched over to using the new regiter value class. llvm-svn: 131096
2011-05-10 04:18:18 +08:00
#include "lldb/Core/RegisterValue.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
#include "lldb/Core/State.h"
Added Debugger::GetAsync{Output/Error}Stream, and use it to print parse errors when we go to run a breakpoint condition. llvm-svn: 132517
2011-06-03 07:58:26 +08:00
#include "lldb/Core/StreamAsynchronousIO.h"
Add a logging mode that takes a callback and flush'es to that callback. Also add SB API's to set this callback, and to enable the log channels. llvm-svn: 151018
2012-02-21 10:23:08 +08:00
#include "lldb/Core/StreamCallback.h"
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
#include "lldb/Core/StreamString.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
#include "lldb/Core/Timer.h"
This commit adds a new top subcommand "summary" to command type named "type". Currently this command implements three commands: type summary add <format> <typename1> [<typename2> ...] type summary delete <typename1> [<typename2> ...] type summary list [<typename1> [<typename2>] ...] type summary clear This allows you to specify the default format that will be used to display summaries for variables, shown when you use "frame variable" or "expression", or the SBValue classes. Examples: type summary add "x = ${var.x}" Point type summary list type summary add --one-liner SimpleType llvm-svn: 134108
2011-06-30 06:27:15 +08:00
#include "lldb/Core/ValueObject.h"
Added a new thread and frame format that can be used to display a function name + arguments when the data is available. It seems to work really well, but some more testing is needed before we make this on by default. The new function format name is: ${function.name-with-args} To see how to use these formats see the website: http://lldb.llvm.org/formats.html Here is a sample backtrace of debugging LLDB with LLDB using this new format value: (lldb) thread backtrace all * thread #1: tid = 0x2203, 0x00007fff88a17bca libsystem_kernel.dylib __psynch_cvwait + 10, stop reason = signal SIGINT, name = <lldb.driver.main-thread>, queue = com.apple.main-thread frame #0: 0x00007fff88a17bca libsystem_kernel.dylib __psynch_cvwait + 10 frame #1: 0x00007fff884ae274 libsystem_c.dylib _pthread_cond_wait + 840 frame #2: 0x00000001010778ea LLDB lldb_private::Condition::Wait(this=0x0000000104846770, mutex=0x0000000104846730, abstime=0x0000000000000000, timed_out=0x00007fff5fbfdea7) + 138 at Condition.cpp:92 frame #3: 0x0000000101244c21 LLDB lldb_private::Predicate<bool>::WaitForValueEqualTo(this=0x0000000104846728, value=true, abstime=0x0000000000000000, timed_out=0x00007fff5fbfdea7) + 209 at Predicate.h:317 frame #4: 0x0000000100f6eeb2 LLDB lldb_private::Listener::WaitForEventsInternal(this=0x0000000104846660, timeout=0x0000000000000000, broadcaster=0x0000000000000000, broadcaster_names=0x0000000000000000, num_broadcaster_names=0x00000000, event_type_mask=0x00000000, event_sp=0x00007fff5fbfe030) + 386 at Listener.cpp:388 frame #5: 0x0000000100f6f231 LLDB lldb_private::Listener::WaitForEvent(this=0x0000000104846660, timeout=0x0000000000000000, event_sp=0x00007fff5fbfe030) + 81 at Listener.cpp:436 frame #6: 0x0000000100098dcd LLDB lldb::SBListener::WaitForEvent(this=0x00007fff5fbff0f0, timeout_secs=0xffffffff, event=0x00007fff5fbfe430) + 685 at SBListener.cpp:181 frame #7: 0x000000010000628c lldb Driver::MainLoop(this=0x00007fff5fbff620) + 5244 at Driver.cpp:1325 frame #8: 0x0000000100006ca3 lldb main(argc=1, argv=0x00007fff5fbff758, envp=0x00007fff5fbff768) + 419 at Driver.cpp:1460 frame #9: 0x0000000100000d54 lldb start + 52 thread #3: tid = 0x2703, 0x00007fff88a17df2 libsystem_kernel.dylib select$DARWIN_EXTSN + 10, name = <lldb.comm.debugger.input> frame #0: 0x00007fff88a17df2 libsystem_kernel.dylib select$DARWIN_EXTSN + 10 frame #1: 0x0000000100f3f072 LLDB lldb_private::ConnectionFileDescriptor::BytesAvailable(this=0x000000010524d040, timeout_usec=0x004c4b40, error_ptr=0x0000000105640a18) + 722 at ConnectionFileDescriptor.cpp:542 frame #2: 0x0000000100f3e6dd LLDB lldb_private::ConnectionFileDescriptor::Read(this=0x000000010524d040, dst=0x0000000105640a60, dst_len=1024, timeout_usec=0x004c4b40, status=0x0000000105640a14, error_ptr=0x0000000105640a18) + 301 at ConnectionFileDescriptor.cpp:273 frame #3: 0x0000000100f3b8f7 LLDB lldb_private::Communication::ReadFromConnection(this=0x0000000104846270, dst=0x0000000105640a60, dst_len=1024, timeout_usec=0x004c4b40, status=0x0000000105640a14, error_ptr=0x0000000105640a18) + 167 at Communication.cpp:317 frame #4: 0x0000000100f3b197 LLDB lldb_private::Communication::ReadThread(p=0x0000000104846270) + 327 at Communication.cpp:344 frame #5: 0x0000000101078923 LLDB ThreadCreateTrampoline(arg=0x00000001045f6650) + 227 at Host.cpp:549 frame #6: 0x00007fff884aa8bf libsystem_c.dylib _pthread_start + 335 frame #7: 0x00007fff884adb75 libsystem_c.dylib thread_start + 13 thread #4: tid = 0x2803, 0x00007fff88a17df2 libsystem_kernel.dylib select$DARWIN_EXTSN + 10, name = <lldb.comm.driver.editline> frame #0: 0x00007fff88a17df2 libsystem_kernel.dylib select$DARWIN_EXTSN + 10 frame #1: 0x0000000100f3f072 LLDB lldb_private::ConnectionFileDescriptor::BytesAvailable(this=0x0000000105700370, timeout_usec=0x004c4b40, error_ptr=0x00000001056c3a18) + 722 at ConnectionFileDescriptor.cpp:542 frame #2: 0x0000000100f3e6dd LLDB lldb_private::ConnectionFileDescriptor::Read(this=0x0000000105700370, dst=0x00000001056c3a60, dst_len=1024, timeout_usec=0x004c4b40, status=0x00000001056c3a14, error_ptr=0x00000001056c3a18) + 301 at ConnectionFileDescriptor.cpp:273 frame #3: 0x0000000100f3b8f7 LLDB lldb_private::Communication::ReadFromConnection(this=0x0000000105700000, dst=0x00000001056c3a60, dst_len=1024, timeout_usec=0x004c4b40, status=0x00000001056c3a14, error_ptr=0x00000001056c3a18) + 167 at Communication.cpp:317 frame #4: 0x0000000100f3b197 LLDB lldb_private::Communication::ReadThread(p=0x0000000105700000) + 327 at Communication.cpp:344 frame #5: 0x0000000101078923 LLDB ThreadCreateTrampoline(arg=0x0000000105700430) + 227 at Host.cpp:549 frame #6: 0x00007fff884aa8bf libsystem_c.dylib _pthread_start + 335 frame #7: 0x00007fff884adb75 libsystem_c.dylib thread_start + 13 thread #5: tid = 0x2903, 0x00007fff88a17df2 libsystem_kernel.dylib select$DARWIN_EXTSN + 10, name = <lldb.comm.driver.editline_output> frame #0: 0x00007fff88a17df2 libsystem_kernel.dylib select$DARWIN_EXTSN + 10 frame #1: 0x0000000100f3f072 LLDB lldb_private::ConnectionFileDescriptor::BytesAvailable(this=0x00000001057178f0, timeout_usec=0x004c4b40, error_ptr=0x0000000105980a18) + 722 at ConnectionFileDescriptor.cpp:542 frame #2: 0x0000000100f3e6dd LLDB lldb_private::ConnectionFileDescriptor::Read(this=0x00000001057178f0, dst=0x0000000105980a60, dst_len=1024, timeout_usec=0x004c4b40, status=0x0000000105980a14, error_ptr=0x0000000105980a18) + 301 at ConnectionFileDescriptor.cpp:273 frame #3: 0x0000000100f3b8f7 LLDB lldb_private::Communication::ReadFromConnection(this=0x0000000105717580, dst=0x0000000105980a60, dst_len=1024, timeout_usec=0x004c4b40, status=0x0000000105980a14, error_ptr=0x0000000105980a18) + 167 at Communication.cpp:317 frame #4: 0x0000000100f3b197 LLDB lldb_private::Communication::ReadThread(p=0x0000000105717580) + 327 at Communication.cpp:344 frame #5: 0x0000000101078923 LLDB ThreadCreateTrampoline(arg=0x00000001057179b0) + 227 at Host.cpp:549 frame #6: 0x00007fff884aa8bf libsystem_c.dylib _pthread_start + 335 frame #7: 0x00007fff884adb75 libsystem_c.dylib thread_start + 13 thread #6: tid = 0x2a03, 0x00007fff88a18af2 libsystem_kernel.dylib read + 10, name = <lldb.driver.commandline_io> frame #0: 0x00007fff88a18af2 libsystem_kernel.dylib read + 10 frame #1: 0x0000000100050c3b libedit.3.dylib read_init + 247 frame #2: 0x0000000100050e96 libedit.3.dylib el_wgetc + 155 frame #3: 0x000000010005115d libedit.3.dylib el_wgets + 578 frame #4: 0x000000010005debc libedit.3.dylib el_gets + 37 frame #5: 0x000000010000d409 lldb IOChannel::LibeditGetInput(this=0x0000000105700490, new_line=0x0000000105a03db0) + 89 at IOChannel.cpp:311 frame #6: 0x000000010000d8b6 lldb IOChannel::Run(this=0x0000000105700490) + 806 at IOChannel.cpp:391 frame #7: 0x000000010000d57d lldb IOChannel::IOReadThread(ptr=0x0000000105700490) + 29 at IOChannel.cpp:345 frame #8: 0x0000000101078923 LLDB ThreadCreateTrampoline(arg=0x00000001057179f0) + 227 at Host.cpp:549 frame #9: 0x00007fff884aa8bf libsystem_c.dylib _pthread_start + 335 frame #10: 0x00007fff884adb75 libsystem_c.dylib thread_start + 13 (lldb) llvm-svn: 148110
2012-01-13 16:39:16 +08:00
#include "lldb/Core/ValueObjectVariable.h"
Abtract terminal stuff into a new lldb_private::Terminal class where the implementation is hidden in the host layer. This avoids a slew of "#if LLDB_CONFIG_TERMIOS_SUPPORTED" statements in the code and keeps things cleaner. llvm-svn: 125057
2011-02-08 07:24:47 +08:00
#include "lldb/Host/Terminal.h"
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
2010-06-23 09:19:29 +08:00
#include "lldb/Interpreter/CommandInterpreter.h"
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
#include "lldb/Interpreter/OptionValueSInt64.h"
#include "lldb/Interpreter/OptionValueString.h"
Added a new thread and frame format that can be used to display a function name + arguments when the data is available. It seems to work really well, but some more testing is needed before we make this on by default. The new function format name is: ${function.name-with-args} To see how to use these formats see the website: http://lldb.llvm.org/formats.html Here is a sample backtrace of debugging LLDB with LLDB using this new format value: (lldb) thread backtrace all * thread #1: tid = 0x2203, 0x00007fff88a17bca libsystem_kernel.dylib __psynch_cvwait + 10, stop reason = signal SIGINT, name = <lldb.driver.main-thread>, queue = com.apple.main-thread frame #0: 0x00007fff88a17bca libsystem_kernel.dylib __psynch_cvwait + 10 frame #1: 0x00007fff884ae274 libsystem_c.dylib _pthread_cond_wait + 840 frame #2: 0x00000001010778ea LLDB lldb_private::Condition::Wait(this=0x0000000104846770, mutex=0x0000000104846730, abstime=0x0000000000000000, timed_out=0x00007fff5fbfdea7) + 138 at Condition.cpp:92 frame #3: 0x0000000101244c21 LLDB lldb_private::Predicate<bool>::WaitForValueEqualTo(this=0x0000000104846728, value=true, abstime=0x0000000000000000, timed_out=0x00007fff5fbfdea7) + 209 at Predicate.h:317 frame #4: 0x0000000100f6eeb2 LLDB lldb_private::Listener::WaitForEventsInternal(this=0x0000000104846660, timeout=0x0000000000000000, broadcaster=0x0000000000000000, broadcaster_names=0x0000000000000000, num_broadcaster_names=0x00000000, event_type_mask=0x00000000, event_sp=0x00007fff5fbfe030) + 386 at Listener.cpp:388 frame #5: 0x0000000100f6f231 LLDB lldb_private::Listener::WaitForEvent(this=0x0000000104846660, timeout=0x0000000000000000, event_sp=0x00007fff5fbfe030) + 81 at Listener.cpp:436 frame #6: 0x0000000100098dcd LLDB lldb::SBListener::WaitForEvent(this=0x00007fff5fbff0f0, timeout_secs=0xffffffff, event=0x00007fff5fbfe430) + 685 at SBListener.cpp:181 frame #7: 0x000000010000628c lldb Driver::MainLoop(this=0x00007fff5fbff620) + 5244 at Driver.cpp:1325 frame #8: 0x0000000100006ca3 lldb main(argc=1, argv=0x00007fff5fbff758, envp=0x00007fff5fbff768) + 419 at Driver.cpp:1460 frame #9: 0x0000000100000d54 lldb start + 52 thread #3: tid = 0x2703, 0x00007fff88a17df2 libsystem_kernel.dylib select$DARWIN_EXTSN + 10, name = <lldb.comm.debugger.input> frame #0: 0x00007fff88a17df2 libsystem_kernel.dylib select$DARWIN_EXTSN + 10 frame #1: 0x0000000100f3f072 LLDB lldb_private::ConnectionFileDescriptor::BytesAvailable(this=0x000000010524d040, timeout_usec=0x004c4b40, error_ptr=0x0000000105640a18) + 722 at ConnectionFileDescriptor.cpp:542 frame #2: 0x0000000100f3e6dd LLDB lldb_private::ConnectionFileDescriptor::Read(this=0x000000010524d040, dst=0x0000000105640a60, dst_len=1024, timeout_usec=0x004c4b40, status=0x0000000105640a14, error_ptr=0x0000000105640a18) + 301 at ConnectionFileDescriptor.cpp:273 frame #3: 0x0000000100f3b8f7 LLDB lldb_private::Communication::ReadFromConnection(this=0x0000000104846270, dst=0x0000000105640a60, dst_len=1024, timeout_usec=0x004c4b40, status=0x0000000105640a14, error_ptr=0x0000000105640a18) + 167 at Communication.cpp:317 frame #4: 0x0000000100f3b197 LLDB lldb_private::Communication::ReadThread(p=0x0000000104846270) + 327 at Communication.cpp:344 frame #5: 0x0000000101078923 LLDB ThreadCreateTrampoline(arg=0x00000001045f6650) + 227 at Host.cpp:549 frame #6: 0x00007fff884aa8bf libsystem_c.dylib _pthread_start + 335 frame #7: 0x00007fff884adb75 libsystem_c.dylib thread_start + 13 thread #4: tid = 0x2803, 0x00007fff88a17df2 libsystem_kernel.dylib select$DARWIN_EXTSN + 10, name = <lldb.comm.driver.editline> frame #0: 0x00007fff88a17df2 libsystem_kernel.dylib select$DARWIN_EXTSN + 10 frame #1: 0x0000000100f3f072 LLDB lldb_private::ConnectionFileDescriptor::BytesAvailable(this=0x0000000105700370, timeout_usec=0x004c4b40, error_ptr=0x00000001056c3a18) + 722 at ConnectionFileDescriptor.cpp:542 frame #2: 0x0000000100f3e6dd LLDB lldb_private::ConnectionFileDescriptor::Read(this=0x0000000105700370, dst=0x00000001056c3a60, dst_len=1024, timeout_usec=0x004c4b40, status=0x00000001056c3a14, error_ptr=0x00000001056c3a18) + 301 at ConnectionFileDescriptor.cpp:273 frame #3: 0x0000000100f3b8f7 LLDB lldb_private::Communication::ReadFromConnection(this=0x0000000105700000, dst=0x00000001056c3a60, dst_len=1024, timeout_usec=0x004c4b40, status=0x00000001056c3a14, error_ptr=0x00000001056c3a18) + 167 at Communication.cpp:317 frame #4: 0x0000000100f3b197 LLDB lldb_private::Communication::ReadThread(p=0x0000000105700000) + 327 at Communication.cpp:344 frame #5: 0x0000000101078923 LLDB ThreadCreateTrampoline(arg=0x0000000105700430) + 227 at Host.cpp:549 frame #6: 0x00007fff884aa8bf libsystem_c.dylib _pthread_start + 335 frame #7: 0x00007fff884adb75 libsystem_c.dylib thread_start + 13 thread #5: tid = 0x2903, 0x00007fff88a17df2 libsystem_kernel.dylib select$DARWIN_EXTSN + 10, name = <lldb.comm.driver.editline_output> frame #0: 0x00007fff88a17df2 libsystem_kernel.dylib select$DARWIN_EXTSN + 10 frame #1: 0x0000000100f3f072 LLDB lldb_private::ConnectionFileDescriptor::BytesAvailable(this=0x00000001057178f0, timeout_usec=0x004c4b40, error_ptr=0x0000000105980a18) + 722 at ConnectionFileDescriptor.cpp:542 frame #2: 0x0000000100f3e6dd LLDB lldb_private::ConnectionFileDescriptor::Read(this=0x00000001057178f0, dst=0x0000000105980a60, dst_len=1024, timeout_usec=0x004c4b40, status=0x0000000105980a14, error_ptr=0x0000000105980a18) + 301 at ConnectionFileDescriptor.cpp:273 frame #3: 0x0000000100f3b8f7 LLDB lldb_private::Communication::ReadFromConnection(this=0x0000000105717580, dst=0x0000000105980a60, dst_len=1024, timeout_usec=0x004c4b40, status=0x0000000105980a14, error_ptr=0x0000000105980a18) + 167 at Communication.cpp:317 frame #4: 0x0000000100f3b197 LLDB lldb_private::Communication::ReadThread(p=0x0000000105717580) + 327 at Communication.cpp:344 frame #5: 0x0000000101078923 LLDB ThreadCreateTrampoline(arg=0x00000001057179b0) + 227 at Host.cpp:549 frame #6: 0x00007fff884aa8bf libsystem_c.dylib _pthread_start + 335 frame #7: 0x00007fff884adb75 libsystem_c.dylib thread_start + 13 thread #6: tid = 0x2a03, 0x00007fff88a18af2 libsystem_kernel.dylib read + 10, name = <lldb.driver.commandline_io> frame #0: 0x00007fff88a18af2 libsystem_kernel.dylib read + 10 frame #1: 0x0000000100050c3b libedit.3.dylib read_init + 247 frame #2: 0x0000000100050e96 libedit.3.dylib el_wgetc + 155 frame #3: 0x000000010005115d libedit.3.dylib el_wgets + 578 frame #4: 0x000000010005debc libedit.3.dylib el_gets + 37 frame #5: 0x000000010000d409 lldb IOChannel::LibeditGetInput(this=0x0000000105700490, new_line=0x0000000105a03db0) + 89 at IOChannel.cpp:311 frame #6: 0x000000010000d8b6 lldb IOChannel::Run(this=0x0000000105700490) + 806 at IOChannel.cpp:391 frame #7: 0x000000010000d57d lldb IOChannel::IOReadThread(ptr=0x0000000105700490) + 29 at IOChannel.cpp:345 frame #8: 0x0000000101078923 LLDB ThreadCreateTrampoline(arg=0x00000001057179f0) + 227 at Host.cpp:549 frame #9: 0x00007fff884aa8bf libsystem_c.dylib _pthread_start + 335 frame #10: 0x00007fff884adb75 libsystem_c.dylib thread_start + 13 (lldb) llvm-svn: 148110
2012-01-13 16:39:16 +08:00
#include "lldb/Symbol/VariableList.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
#include "lldb/Target/TargetList.h"
#include "lldb/Target/Process.h"
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
#include "lldb/Target/RegisterContext.h"
#include "lldb/Target/StopInfo.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
#include "lldb/Target/Thread.h"
Added the ability to run expressions in any command. Expressions can be inserted in commands by using backticks: (lldb) memory read `$rsp-16` `$rsp+16` (lldb) memory read -c `(int)strlen(argv[0])` `argv[0]` The result of the expression will be inserted into the command as a sort of preprocess stage where this gets done first. We might need to tweak where this preprocess stage goes, but it is very functional already. Added ansi color support to the Debugger::FormatPrompt() so you can use things like "${ansi.fg.blue}" and "${ansi.bold}" many more. This helps in adding colors to your prompts without needing to know the ANSI color code strings. llvm-svn: 141948
2011-10-14 15:41:33 +08:00
#include "lldb/Utility/AnsiTerminal.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
using namespace lldb;
using namespace lldb_private;
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
static uint32_t g_shared_debugger_refcount = 0;
Add a unique ID to each debugger instance. Add functions to look up debugger by id Add global variable to lldb python module, to hold debugger id Modify embedded Python interpreter to update the global variable with the id of its current debugger. Modify the char ** typemap definition in lldb.swig to accept 'None' (for NULL) as a valid value. The point of all this is so that, when you drop into the embedded interpreter from the command interpreter (or when doing Python-based breakpoint commands), there is a way for the Python side to find/get the correct debugger instance ( by checking debugger_unique_id, then calling SBDebugger::FindDebuggerWithID on it). llvm-svn: 107287
2010-07-01 00:22:25 +08:00
static lldb::user_id_t g_unique_id = 1;
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
#pragma mark Static Functions
static Mutex &
GetDebuggerListMutex ()
{
static Mutex g_mutex(Mutex::eMutexTypeRecursive);
return g_mutex;
}
typedef std::vector<DebuggerSP> DebuggerList;
static DebuggerList &
GetDebuggerList()
{
// hide the static debugger list inside a singleton accessor to avoid
// global init contructors
static DebuggerList g_list;
return g_list;
}
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
OptionEnumValueElement
g_show_disassembly_enum_values[] =
{
{ Debugger::eStopDisassemblyTypeNever, "never", "Never show disassembly when displaying a stop context."},
{ Debugger::eStopDisassemblyTypeNoSource, "no-source", "Show disassembly when there is no source information, or the source file is missing when displaying a stop context."},
{ Debugger::eStopDisassemblyTypeAlways, "always", "Always show disassembly when displaying a stop context."},
{ 0, NULL, NULL }
};
OptionEnumValueElement
g_language_enumerators[] =
{
{ eScriptLanguageNone, "none", "Disable scripting languages."},
{ eScriptLanguagePython, "python", "Select python as the default scripting language."},
{ eScriptLanguageDefault, "default", "Select the lldb default as the default scripting language."},
};
#define MODULE_WITH_FUNC "{ ${module.file.basename}{`${function.name-with-args}${function.pc-offset}}}"
#define FILE_AND_LINE "{ at ${line.file.basename}:${line.number}}"
#define DEFAULT_THREAD_FORMAT "thread #${thread.index}: tid = ${thread.id}"\
"{, ${frame.pc}}"\
MODULE_WITH_FUNC\
FILE_AND_LINE\
"{, stop reason = ${thread.stop-reason}}"\
"{\\nReturn value: ${thread.return-value}}"\
"\\n"
#define DEFAULT_FRAME_FORMAT "frame #${frame.index}: ${frame.pc}"\
MODULE_WITH_FUNC\
FILE_AND_LINE\
"\\n"
<rdar://problem/12022079> Added a new "interpreter" properties to encapsulate any properties for the command interpreter. Right now this contains only "expand-regex-aliases", so you can now enable (disabled by default) the echoing of the command that a regular expression alias expands to: (lldb) b main Breakpoint created: 1: name = 'main', locations = 1 Note that the expanded regular expression command wasn't shown by default. You can enable it if you want to: (lldb) settings set interpreter.expand-regex-aliases true (lldb) b main breakpoint set --name 'main' Breakpoint created: 1: name = 'main', locations = 1 Also enabled auto completion for enumeration option values (OptionValueEnumeration) and for boolean option values (OptionValueBoolean). Fixed auto completion for settings names when nothing has been type (it should show all settings). llvm-svn: 162418
2012-08-23 08:22:02 +08:00
static PropertyDefinition
g_properties[] =
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
{
{ "auto-confirm", OptionValue::eTypeBoolean, true, false, NULL, NULL, "If true all confirmation prompts will receive their default reply." },
{ "frame-format", OptionValue::eTypeString , true, 0 , DEFAULT_FRAME_FORMAT, NULL, "The default frame format string to use when displaying stack frame information for threads." },
{ "notify-void", OptionValue::eTypeBoolean, true, false, NULL, NULL, "Notify the user explicitly if an expression returns void (default: false)." },
{ "prompt", OptionValue::eTypeString , true, 0 , "(lldb) ", NULL, "The debugger command line prompt displayed for the user." },
{ "script-lang", OptionValue::eTypeEnum , true, eScriptLanguagePython, NULL, g_language_enumerators, "The script language to be used for evaluating user-written scripts." },
{ "stop-disassembly-count", OptionValue::eTypeSInt64 , true, 4 , NULL, NULL, "The number of disassembly lines to show when displaying a stopped context." },
{ "stop-disassembly-display", OptionValue::eTypeEnum , true, Debugger::eStopDisassemblyTypeNoSource, NULL, g_show_disassembly_enum_values, "Control when to display disassembly when displaying a stopped context." },
{ "stop-line-count-after", OptionValue::eTypeSInt64 , true, 3 , NULL, NULL, "The number of sources lines to display that come after the current source line when displaying a stopped context." },
{ "stop-line-count-before", OptionValue::eTypeSInt64 , true, 3 , NULL, NULL, "The number of sources lines to display that come before the current source line when displaying a stopped context." },
{ "term-width", OptionValue::eTypeSInt64 , true, 80 , NULL, NULL, "The maximum number of columns to use for displaying text." },
{ "thread-format", OptionValue::eTypeString , true, 0 , DEFAULT_THREAD_FORMAT, NULL, "The default thread format string to use when displaying thread information." },
{ "use-external-editor", OptionValue::eTypeBoolean, true, false, NULL, NULL, "Whether to use an external editor or not." },
{ NULL, OptionValue::eTypeInvalid, true, 0 , NULL, NULL, NULL }
};
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
enum
{
ePropertyAutoConfirm = 0,
ePropertyFrameFormat,
ePropertyNotiftVoid,
ePropertyPrompt,
ePropertyScriptLanguage,
ePropertyStopDisassemblyCount,
ePropertyStopDisassemblyDisplay,
ePropertyStopLineCountAfter,
ePropertyStopLineCountBefore,
ePropertyTerminalWidth,
ePropertyThreadFormat,
ePropertyUseExternalEditor
};
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
//
//const char *
//Debugger::GetFrameFormat() const
//{
// return m_properties_sp->GetFrameFormat();
//}
//const char *
//Debugger::GetThreadFormat() const
//{
// return m_properties_sp->GetThreadFormat();
//}
//
bool
Debugger::GetAutoConfirm () const
Many GDB users always want to display disassembly when they stop by using something like "display/4i $pc" (or something like this). With LLDB we already were showing 3 lines of source before and 3 lines of source after the current source line when showing a stop context. We now improve this by allowing the user to control the number of lines with the new "stop-line-count-before" and "stop-line-count-after" settings. Also, there is a new setting for how many disassembly lines to show: "stop-disassembly-count". This will control how many source lines are shown when there is no source or when we have no source line info. settings set stop-line-count-before 3 settings set stop-line-count-after 3 settings set stop-disassembly-count 4 settings set stop-disassembly-display no-source The default values are set as shown above and allow 3 lines of source before and after (what we used to do) the current stop location, and will display 4 lines of disassembly if the source is not available or if we have no debug info. If both "stop-source-context-before" and "stop-source-context-after" are set to zero, this will disable showing any source when stopped. The "stop-disassembly-display" setting is an enumeration that allows you to control when to display disassembly. It has 3 possible values: "never" - never show disassembly no matter what "no-source" - only show disassembly when there is no source line info or the source files are missing "always" - always show disassembly. llvm-svn: 145050
2011-11-22 05:44:34 +08:00
{
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
const uint32_t idx = ePropertyAutoConfirm;
<rdar://problem/12022079> Added a new "interpreter" properties to encapsulate any properties for the command interpreter. Right now this contains only "expand-regex-aliases", so you can now enable (disabled by default) the echoing of the command that a regular expression alias expands to: (lldb) b main Breakpoint created: 1: name = 'main', locations = 1 Note that the expanded regular expression command wasn't shown by default. You can enable it if you want to: (lldb) settings set interpreter.expand-regex-aliases true (lldb) b main breakpoint set --name 'main' Breakpoint created: 1: name = 'main', locations = 1 Also enabled auto completion for enumeration option values (OptionValueEnumeration) and for boolean option values (OptionValueBoolean). Fixed auto completion for settings names when nothing has been type (it should show all settings). llvm-svn: 162418
2012-08-23 08:22:02 +08:00
return m_collection_sp->GetPropertyAtIndexAsBoolean (NULL, idx, g_properties[idx].default_uint_value != 0);
Many GDB users always want to display disassembly when they stop by using something like "display/4i $pc" (or something like this). With LLDB we already were showing 3 lines of source before and 3 lines of source after the current source line when showing a stop context. We now improve this by allowing the user to control the number of lines with the new "stop-line-count-before" and "stop-line-count-after" settings. Also, there is a new setting for how many disassembly lines to show: "stop-disassembly-count". This will control how many source lines are shown when there is no source or when we have no source line info. settings set stop-line-count-before 3 settings set stop-line-count-after 3 settings set stop-disassembly-count 4 settings set stop-disassembly-display no-source The default values are set as shown above and allow 3 lines of source before and after (what we used to do) the current stop location, and will display 4 lines of disassembly if the source is not available or if we have no debug info. If both "stop-source-context-before" and "stop-source-context-after" are set to zero, this will disable showing any source when stopped. The "stop-disassembly-display" setting is an enumeration that allows you to control when to display disassembly. It has 3 possible values: "never" - never show disassembly no matter what "no-source" - only show disassembly when there is no source line info or the source files are missing "always" - always show disassembly. llvm-svn: 145050
2011-11-22 05:44:34 +08:00
}
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
const char *
Debugger::GetFrameFormat() const
LLDB no longer prints <no result> by default if the expression returns nothing. There is now a setting, "notify-void." When the user enables that setting, lldb prints (void) if an expression's result is void. Otherwise, lldb is silent. <rdar://problem/11225150> llvm-svn: 161600
2012-08-10 02:18:47 +08:00
{
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
const uint32_t idx = ePropertyFrameFormat;
<rdar://problem/12022079> Added a new "interpreter" properties to encapsulate any properties for the command interpreter. Right now this contains only "expand-regex-aliases", so you can now enable (disabled by default) the echoing of the command that a regular expression alias expands to: (lldb) b main Breakpoint created: 1: name = 'main', locations = 1 Note that the expanded regular expression command wasn't shown by default. You can enable it if you want to: (lldb) settings set interpreter.expand-regex-aliases true (lldb) b main breakpoint set --name 'main' Breakpoint created: 1: name = 'main', locations = 1 Also enabled auto completion for enumeration option values (OptionValueEnumeration) and for boolean option values (OptionValueBoolean). Fixed auto completion for settings names when nothing has been type (it should show all settings). llvm-svn: 162418
2012-08-23 08:22:02 +08:00
return m_collection_sp->GetPropertyAtIndexAsString (NULL, idx, g_properties[idx].default_cstr_value);
LLDB no longer prints <no result> by default if the expression returns nothing. There is now a setting, "notify-void." When the user enables that setting, lldb prints (void) if an expression's result is void. Otherwise, lldb is silent. <rdar://problem/11225150> llvm-svn: 161600
2012-08-10 02:18:47 +08:00
}
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
bool
Debugger::GetNotifyVoid () const
Many GDB users always want to display disassembly when they stop by using something like "display/4i $pc" (or something like this). With LLDB we already were showing 3 lines of source before and 3 lines of source after the current source line when showing a stop context. We now improve this by allowing the user to control the number of lines with the new "stop-line-count-before" and "stop-line-count-after" settings. Also, there is a new setting for how many disassembly lines to show: "stop-disassembly-count". This will control how many source lines are shown when there is no source or when we have no source line info. settings set stop-line-count-before 3 settings set stop-line-count-after 3 settings set stop-disassembly-count 4 settings set stop-disassembly-display no-source The default values are set as shown above and allow 3 lines of source before and after (what we used to do) the current stop location, and will display 4 lines of disassembly if the source is not available or if we have no debug info. If both "stop-source-context-before" and "stop-source-context-after" are set to zero, this will disable showing any source when stopped. The "stop-disassembly-display" setting is an enumeration that allows you to control when to display disassembly. It has 3 possible values: "never" - never show disassembly no matter what "no-source" - only show disassembly when there is no source line info or the source files are missing "always" - always show disassembly. llvm-svn: 145050
2011-11-22 05:44:34 +08:00
{
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
const uint32_t idx = ePropertyNotiftVoid;
<rdar://problem/12022079> Added a new "interpreter" properties to encapsulate any properties for the command interpreter. Right now this contains only "expand-regex-aliases", so you can now enable (disabled by default) the echoing of the command that a regular expression alias expands to: (lldb) b main Breakpoint created: 1: name = 'main', locations = 1 Note that the expanded regular expression command wasn't shown by default. You can enable it if you want to: (lldb) settings set interpreter.expand-regex-aliases true (lldb) b main breakpoint set --name 'main' Breakpoint created: 1: name = 'main', locations = 1 Also enabled auto completion for enumeration option values (OptionValueEnumeration) and for boolean option values (OptionValueBoolean). Fixed auto completion for settings names when nothing has been type (it should show all settings). llvm-svn: 162418
2012-08-23 08:22:02 +08:00
return m_collection_sp->GetPropertyAtIndexAsBoolean (NULL, idx, g_properties[idx].default_uint_value != 0);
Many GDB users always want to display disassembly when they stop by using something like "display/4i $pc" (or something like this). With LLDB we already were showing 3 lines of source before and 3 lines of source after the current source line when showing a stop context. We now improve this by allowing the user to control the number of lines with the new "stop-line-count-before" and "stop-line-count-after" settings. Also, there is a new setting for how many disassembly lines to show: "stop-disassembly-count". This will control how many source lines are shown when there is no source or when we have no source line info. settings set stop-line-count-before 3 settings set stop-line-count-after 3 settings set stop-disassembly-count 4 settings set stop-disassembly-display no-source The default values are set as shown above and allow 3 lines of source before and after (what we used to do) the current stop location, and will display 4 lines of disassembly if the source is not available or if we have no debug info. If both "stop-source-context-before" and "stop-source-context-after" are set to zero, this will disable showing any source when stopped. The "stop-disassembly-display" setting is an enumeration that allows you to control when to display disassembly. It has 3 possible values: "never" - never show disassembly no matter what "no-source" - only show disassembly when there is no source line info or the source files are missing "always" - always show disassembly. llvm-svn: 145050
2011-11-22 05:44:34 +08:00
}
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
const char *
Debugger::GetPrompt() const
Many GDB users always want to display disassembly when they stop by using something like "display/4i $pc" (or something like this). With LLDB we already were showing 3 lines of source before and 3 lines of source after the current source line when showing a stop context. We now improve this by allowing the user to control the number of lines with the new "stop-line-count-before" and "stop-line-count-after" settings. Also, there is a new setting for how many disassembly lines to show: "stop-disassembly-count". This will control how many source lines are shown when there is no source or when we have no source line info. settings set stop-line-count-before 3 settings set stop-line-count-after 3 settings set stop-disassembly-count 4 settings set stop-disassembly-display no-source The default values are set as shown above and allow 3 lines of source before and after (what we used to do) the current stop location, and will display 4 lines of disassembly if the source is not available or if we have no debug info. If both "stop-source-context-before" and "stop-source-context-after" are set to zero, this will disable showing any source when stopped. The "stop-disassembly-display" setting is an enumeration that allows you to control when to display disassembly. It has 3 possible values: "never" - never show disassembly no matter what "no-source" - only show disassembly when there is no source line info or the source files are missing "always" - always show disassembly. llvm-svn: 145050
2011-11-22 05:44:34 +08:00
{
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
const uint32_t idx = ePropertyPrompt;
<rdar://problem/12022079> Added a new "interpreter" properties to encapsulate any properties for the command interpreter. Right now this contains only "expand-regex-aliases", so you can now enable (disabled by default) the echoing of the command that a regular expression alias expands to: (lldb) b main Breakpoint created: 1: name = 'main', locations = 1 Note that the expanded regular expression command wasn't shown by default. You can enable it if you want to: (lldb) settings set interpreter.expand-regex-aliases true (lldb) b main breakpoint set --name 'main' Breakpoint created: 1: name = 'main', locations = 1 Also enabled auto completion for enumeration option values (OptionValueEnumeration) and for boolean option values (OptionValueBoolean). Fixed auto completion for settings names when nothing has been type (it should show all settings). llvm-svn: 162418
2012-08-23 08:22:02 +08:00
return m_collection_sp->GetPropertyAtIndexAsString (NULL, idx, g_properties[idx].default_cstr_value);
Many GDB users always want to display disassembly when they stop by using something like "display/4i $pc" (or something like this). With LLDB we already were showing 3 lines of source before and 3 lines of source after the current source line when showing a stop context. We now improve this by allowing the user to control the number of lines with the new "stop-line-count-before" and "stop-line-count-after" settings. Also, there is a new setting for how many disassembly lines to show: "stop-disassembly-count". This will control how many source lines are shown when there is no source or when we have no source line info. settings set stop-line-count-before 3 settings set stop-line-count-after 3 settings set stop-disassembly-count 4 settings set stop-disassembly-display no-source The default values are set as shown above and allow 3 lines of source before and after (what we used to do) the current stop location, and will display 4 lines of disassembly if the source is not available or if we have no debug info. If both "stop-source-context-before" and "stop-source-context-after" are set to zero, this will disable showing any source when stopped. The "stop-disassembly-display" setting is an enumeration that allows you to control when to display disassembly. It has 3 possible values: "never" - never show disassembly no matter what "no-source" - only show disassembly when there is no source line info or the source files are missing "always" - always show disassembly. llvm-svn: 145050
2011-11-22 05:44:34 +08:00
}
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
void
Debugger::SetPrompt(const char *p)
Many GDB users always want to display disassembly when they stop by using something like "display/4i $pc" (or something like this). With LLDB we already were showing 3 lines of source before and 3 lines of source after the current source line when showing a stop context. We now improve this by allowing the user to control the number of lines with the new "stop-line-count-before" and "stop-line-count-after" settings. Also, there is a new setting for how many disassembly lines to show: "stop-disassembly-count". This will control how many source lines are shown when there is no source or when we have no source line info. settings set stop-line-count-before 3 settings set stop-line-count-after 3 settings set stop-disassembly-count 4 settings set stop-disassembly-display no-source The default values are set as shown above and allow 3 lines of source before and after (what we used to do) the current stop location, and will display 4 lines of disassembly if the source is not available or if we have no debug info. If both "stop-source-context-before" and "stop-source-context-after" are set to zero, this will disable showing any source when stopped. The "stop-disassembly-display" setting is an enumeration that allows you to control when to display disassembly. It has 3 possible values: "never" - never show disassembly no matter what "no-source" - only show disassembly when there is no source line info or the source files are missing "always" - always show disassembly. llvm-svn: 145050
2011-11-22 05:44:34 +08:00
{
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
const uint32_t idx = ePropertyPrompt;
m_collection_sp->SetPropertyAtIndexAsString (NULL, idx, p);
const char *new_prompt = GetPrompt();
EventSP prompt_change_event_sp (new Event(CommandInterpreter::eBroadcastBitResetPrompt, new EventDataBytes (new_prompt)));;
GetCommandInterpreter().BroadcastEvent (prompt_change_event_sp);
Many GDB users always want to display disassembly when they stop by using something like "display/4i $pc" (or something like this). With LLDB we already were showing 3 lines of source before and 3 lines of source after the current source line when showing a stop context. We now improve this by allowing the user to control the number of lines with the new "stop-line-count-before" and "stop-line-count-after" settings. Also, there is a new setting for how many disassembly lines to show: "stop-disassembly-count". This will control how many source lines are shown when there is no source or when we have no source line info. settings set stop-line-count-before 3 settings set stop-line-count-after 3 settings set stop-disassembly-count 4 settings set stop-disassembly-display no-source The default values are set as shown above and allow 3 lines of source before and after (what we used to do) the current stop location, and will display 4 lines of disassembly if the source is not available or if we have no debug info. If both "stop-source-context-before" and "stop-source-context-after" are set to zero, this will disable showing any source when stopped. The "stop-disassembly-display" setting is an enumeration that allows you to control when to display disassembly. It has 3 possible values: "never" - never show disassembly no matter what "no-source" - only show disassembly when there is no source line info or the source files are missing "always" - always show disassembly. llvm-svn: 145050
2011-11-22 05:44:34 +08:00
}
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
const char *
Debugger::GetThreadFormat() const
Many GDB users always want to display disassembly when they stop by using something like "display/4i $pc" (or something like this). With LLDB we already were showing 3 lines of source before and 3 lines of source after the current source line when showing a stop context. We now improve this by allowing the user to control the number of lines with the new "stop-line-count-before" and "stop-line-count-after" settings. Also, there is a new setting for how many disassembly lines to show: "stop-disassembly-count". This will control how many source lines are shown when there is no source or when we have no source line info. settings set stop-line-count-before 3 settings set stop-line-count-after 3 settings set stop-disassembly-count 4 settings set stop-disassembly-display no-source The default values are set as shown above and allow 3 lines of source before and after (what we used to do) the current stop location, and will display 4 lines of disassembly if the source is not available or if we have no debug info. If both "stop-source-context-before" and "stop-source-context-after" are set to zero, this will disable showing any source when stopped. The "stop-disassembly-display" setting is an enumeration that allows you to control when to display disassembly. It has 3 possible values: "never" - never show disassembly no matter what "no-source" - only show disassembly when there is no source line info or the source files are missing "always" - always show disassembly. llvm-svn: 145050
2011-11-22 05:44:34 +08:00
{
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
const uint32_t idx = ePropertyThreadFormat;
<rdar://problem/12022079> Added a new "interpreter" properties to encapsulate any properties for the command interpreter. Right now this contains only "expand-regex-aliases", so you can now enable (disabled by default) the echoing of the command that a regular expression alias expands to: (lldb) b main Breakpoint created: 1: name = 'main', locations = 1 Note that the expanded regular expression command wasn't shown by default. You can enable it if you want to: (lldb) settings set interpreter.expand-regex-aliases true (lldb) b main breakpoint set --name 'main' Breakpoint created: 1: name = 'main', locations = 1 Also enabled auto completion for enumeration option values (OptionValueEnumeration) and for boolean option values (OptionValueBoolean). Fixed auto completion for settings names when nothing has been type (it should show all settings). llvm-svn: 162418
2012-08-23 08:22:02 +08:00
return m_collection_sp->GetPropertyAtIndexAsString (NULL, idx, g_properties[idx].default_cstr_value);
Many GDB users always want to display disassembly when they stop by using something like "display/4i $pc" (or something like this). With LLDB we already were showing 3 lines of source before and 3 lines of source after the current source line when showing a stop context. We now improve this by allowing the user to control the number of lines with the new "stop-line-count-before" and "stop-line-count-after" settings. Also, there is a new setting for how many disassembly lines to show: "stop-disassembly-count". This will control how many source lines are shown when there is no source or when we have no source line info. settings set stop-line-count-before 3 settings set stop-line-count-after 3 settings set stop-disassembly-count 4 settings set stop-disassembly-display no-source The default values are set as shown above and allow 3 lines of source before and after (what we used to do) the current stop location, and will display 4 lines of disassembly if the source is not available or if we have no debug info. If both "stop-source-context-before" and "stop-source-context-after" are set to zero, this will disable showing any source when stopped. The "stop-disassembly-display" setting is an enumeration that allows you to control when to display disassembly. It has 3 possible values: "never" - never show disassembly no matter what "no-source" - only show disassembly when there is no source line info or the source files are missing "always" - always show disassembly. llvm-svn: 145050
2011-11-22 05:44:34 +08:00
}
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
lldb::ScriptLanguage
Debugger::GetScriptLanguage() const
Many GDB users always want to display disassembly when they stop by using something like "display/4i $pc" (or something like this). With LLDB we already were showing 3 lines of source before and 3 lines of source after the current source line when showing a stop context. We now improve this by allowing the user to control the number of lines with the new "stop-line-count-before" and "stop-line-count-after" settings. Also, there is a new setting for how many disassembly lines to show: "stop-disassembly-count". This will control how many source lines are shown when there is no source or when we have no source line info. settings set stop-line-count-before 3 settings set stop-line-count-after 3 settings set stop-disassembly-count 4 settings set stop-disassembly-display no-source The default values are set as shown above and allow 3 lines of source before and after (what we used to do) the current stop location, and will display 4 lines of disassembly if the source is not available or if we have no debug info. If both "stop-source-context-before" and "stop-source-context-after" are set to zero, this will disable showing any source when stopped. The "stop-disassembly-display" setting is an enumeration that allows you to control when to display disassembly. It has 3 possible values: "never" - never show disassembly no matter what "no-source" - only show disassembly when there is no source line info or the source files are missing "always" - always show disassembly. llvm-svn: 145050
2011-11-22 05:44:34 +08:00
{
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
const uint32_t idx = ePropertyScriptLanguage;
<rdar://problem/12022079> Added a new "interpreter" properties to encapsulate any properties for the command interpreter. Right now this contains only "expand-regex-aliases", so you can now enable (disabled by default) the echoing of the command that a regular expression alias expands to: (lldb) b main Breakpoint created: 1: name = 'main', locations = 1 Note that the expanded regular expression command wasn't shown by default. You can enable it if you want to: (lldb) settings set interpreter.expand-regex-aliases true (lldb) b main breakpoint set --name 'main' Breakpoint created: 1: name = 'main', locations = 1 Also enabled auto completion for enumeration option values (OptionValueEnumeration) and for boolean option values (OptionValueBoolean). Fixed auto completion for settings names when nothing has been type (it should show all settings). llvm-svn: 162418
2012-08-23 08:22:02 +08:00
return (lldb::ScriptLanguage)m_collection_sp->GetPropertyAtIndexAsEnumeration (NULL, idx, g_properties[idx].default_uint_value);
Many GDB users always want to display disassembly when they stop by using something like "display/4i $pc" (or something like this). With LLDB we already were showing 3 lines of source before and 3 lines of source after the current source line when showing a stop context. We now improve this by allowing the user to control the number of lines with the new "stop-line-count-before" and "stop-line-count-after" settings. Also, there is a new setting for how many disassembly lines to show: "stop-disassembly-count". This will control how many source lines are shown when there is no source or when we have no source line info. settings set stop-line-count-before 3 settings set stop-line-count-after 3 settings set stop-disassembly-count 4 settings set stop-disassembly-display no-source The default values are set as shown above and allow 3 lines of source before and after (what we used to do) the current stop location, and will display 4 lines of disassembly if the source is not available or if we have no debug info. If both "stop-source-context-before" and "stop-source-context-after" are set to zero, this will disable showing any source when stopped. The "stop-disassembly-display" setting is an enumeration that allows you to control when to display disassembly. It has 3 possible values: "never" - never show disassembly no matter what "no-source" - only show disassembly when there is no source line info or the source files are missing "always" - always show disassembly. llvm-svn: 145050
2011-11-22 05:44:34 +08:00
}
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
bool
Debugger::SetScriptLanguage (lldb::ScriptLanguage script_lang)
Many GDB users always want to display disassembly when they stop by using something like "display/4i $pc" (or something like this). With LLDB we already were showing 3 lines of source before and 3 lines of source after the current source line when showing a stop context. We now improve this by allowing the user to control the number of lines with the new "stop-line-count-before" and "stop-line-count-after" settings. Also, there is a new setting for how many disassembly lines to show: "stop-disassembly-count". This will control how many source lines are shown when there is no source or when we have no source line info. settings set stop-line-count-before 3 settings set stop-line-count-after 3 settings set stop-disassembly-count 4 settings set stop-disassembly-display no-source The default values are set as shown above and allow 3 lines of source before and after (what we used to do) the current stop location, and will display 4 lines of disassembly if the source is not available or if we have no debug info. If both "stop-source-context-before" and "stop-source-context-after" are set to zero, this will disable showing any source when stopped. The "stop-disassembly-display" setting is an enumeration that allows you to control when to display disassembly. It has 3 possible values: "never" - never show disassembly no matter what "no-source" - only show disassembly when there is no source line info or the source files are missing "always" - always show disassembly. llvm-svn: 145050
2011-11-22 05:44:34 +08:00
{
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
const uint32_t idx = ePropertyScriptLanguage;
return m_collection_sp->SetPropertyAtIndexAsEnumeration (NULL, idx, script_lang);
Many GDB users always want to display disassembly when they stop by using something like "display/4i $pc" (or something like this). With LLDB we already were showing 3 lines of source before and 3 lines of source after the current source line when showing a stop context. We now improve this by allowing the user to control the number of lines with the new "stop-line-count-before" and "stop-line-count-after" settings. Also, there is a new setting for how many disassembly lines to show: "stop-disassembly-count". This will control how many source lines are shown when there is no source or when we have no source line info. settings set stop-line-count-before 3 settings set stop-line-count-after 3 settings set stop-disassembly-count 4 settings set stop-disassembly-display no-source The default values are set as shown above and allow 3 lines of source before and after (what we used to do) the current stop location, and will display 4 lines of disassembly if the source is not available or if we have no debug info. If both "stop-source-context-before" and "stop-source-context-after" are set to zero, this will disable showing any source when stopped. The "stop-disassembly-display" setting is an enumeration that allows you to control when to display disassembly. It has 3 possible values: "never" - never show disassembly no matter what "no-source" - only show disassembly when there is no source line info or the source files are missing "always" - always show disassembly. llvm-svn: 145050
2011-11-22 05:44:34 +08:00
}
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
uint32_t
Debugger::GetTerminalWidth () const
Many GDB users always want to display disassembly when they stop by using something like "display/4i $pc" (or something like this). With LLDB we already were showing 3 lines of source before and 3 lines of source after the current source line when showing a stop context. We now improve this by allowing the user to control the number of lines with the new "stop-line-count-before" and "stop-line-count-after" settings. Also, there is a new setting for how many disassembly lines to show: "stop-disassembly-count". This will control how many source lines are shown when there is no source or when we have no source line info. settings set stop-line-count-before 3 settings set stop-line-count-after 3 settings set stop-disassembly-count 4 settings set stop-disassembly-display no-source The default values are set as shown above and allow 3 lines of source before and after (what we used to do) the current stop location, and will display 4 lines of disassembly if the source is not available or if we have no debug info. If both "stop-source-context-before" and "stop-source-context-after" are set to zero, this will disable showing any source when stopped. The "stop-disassembly-display" setting is an enumeration that allows you to control when to display disassembly. It has 3 possible values: "never" - never show disassembly no matter what "no-source" - only show disassembly when there is no source line info or the source files are missing "always" - always show disassembly. llvm-svn: 145050
2011-11-22 05:44:34 +08:00
{
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
const uint32_t idx = ePropertyTerminalWidth;
<rdar://problem/12022079> Added a new "interpreter" properties to encapsulate any properties for the command interpreter. Right now this contains only "expand-regex-aliases", so you can now enable (disabled by default) the echoing of the command that a regular expression alias expands to: (lldb) b main Breakpoint created: 1: name = 'main', locations = 1 Note that the expanded regular expression command wasn't shown by default. You can enable it if you want to: (lldb) settings set interpreter.expand-regex-aliases true (lldb) b main breakpoint set --name 'main' Breakpoint created: 1: name = 'main', locations = 1 Also enabled auto completion for enumeration option values (OptionValueEnumeration) and for boolean option values (OptionValueBoolean). Fixed auto completion for settings names when nothing has been type (it should show all settings). llvm-svn: 162418
2012-08-23 08:22:02 +08:00
return m_collection_sp->GetPropertyAtIndexAsSInt64 (NULL, idx, g_properties[idx].default_uint_value);
Many GDB users always want to display disassembly when they stop by using something like "display/4i $pc" (or something like this). With LLDB we already were showing 3 lines of source before and 3 lines of source after the current source line when showing a stop context. We now improve this by allowing the user to control the number of lines with the new "stop-line-count-before" and "stop-line-count-after" settings. Also, there is a new setting for how many disassembly lines to show: "stop-disassembly-count". This will control how many source lines are shown when there is no source or when we have no source line info. settings set stop-line-count-before 3 settings set stop-line-count-after 3 settings set stop-disassembly-count 4 settings set stop-disassembly-display no-source The default values are set as shown above and allow 3 lines of source before and after (what we used to do) the current stop location, and will display 4 lines of disassembly if the source is not available or if we have no debug info. If both "stop-source-context-before" and "stop-source-context-after" are set to zero, this will disable showing any source when stopped. The "stop-disassembly-display" setting is an enumeration that allows you to control when to display disassembly. It has 3 possible values: "never" - never show disassembly no matter what "no-source" - only show disassembly when there is no source line info or the source files are missing "always" - always show disassembly. llvm-svn: 145050
2011-11-22 05:44:34 +08:00
}
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
bool
Debugger::SetTerminalWidth (uint32_t term_width)
Many GDB users always want to display disassembly when they stop by using something like "display/4i $pc" (or something like this). With LLDB we already were showing 3 lines of source before and 3 lines of source after the current source line when showing a stop context. We now improve this by allowing the user to control the number of lines with the new "stop-line-count-before" and "stop-line-count-after" settings. Also, there is a new setting for how many disassembly lines to show: "stop-disassembly-count". This will control how many source lines are shown when there is no source or when we have no source line info. settings set stop-line-count-before 3 settings set stop-line-count-after 3 settings set stop-disassembly-count 4 settings set stop-disassembly-display no-source The default values are set as shown above and allow 3 lines of source before and after (what we used to do) the current stop location, and will display 4 lines of disassembly if the source is not available or if we have no debug info. If both "stop-source-context-before" and "stop-source-context-after" are set to zero, this will disable showing any source when stopped. The "stop-disassembly-display" setting is an enumeration that allows you to control when to display disassembly. It has 3 possible values: "never" - never show disassembly no matter what "no-source" - only show disassembly when there is no source line info or the source files are missing "always" - always show disassembly. llvm-svn: 145050
2011-11-22 05:44:34 +08:00
{
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
const uint32_t idx = ePropertyTerminalWidth;
return m_collection_sp->SetPropertyAtIndexAsSInt64 (NULL, idx, term_width);
Many GDB users always want to display disassembly when they stop by using something like "display/4i $pc" (or something like this). With LLDB we already were showing 3 lines of source before and 3 lines of source after the current source line when showing a stop context. We now improve this by allowing the user to control the number of lines with the new "stop-line-count-before" and "stop-line-count-after" settings. Also, there is a new setting for how many disassembly lines to show: "stop-disassembly-count". This will control how many source lines are shown when there is no source or when we have no source line info. settings set stop-line-count-before 3 settings set stop-line-count-after 3 settings set stop-disassembly-count 4 settings set stop-disassembly-display no-source The default values are set as shown above and allow 3 lines of source before and after (what we used to do) the current stop location, and will display 4 lines of disassembly if the source is not available or if we have no debug info. If both "stop-source-context-before" and "stop-source-context-after" are set to zero, this will disable showing any source when stopped. The "stop-disassembly-display" setting is an enumeration that allows you to control when to display disassembly. It has 3 possible values: "never" - never show disassembly no matter what "no-source" - only show disassembly when there is no source line info or the source files are missing "always" - always show disassembly. llvm-svn: 145050
2011-11-22 05:44:34 +08:00
}
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
bool
Debugger::GetUseExternalEditor () const
Many GDB users always want to display disassembly when they stop by using something like "display/4i $pc" (or something like this). With LLDB we already were showing 3 lines of source before and 3 lines of source after the current source line when showing a stop context. We now improve this by allowing the user to control the number of lines with the new "stop-line-count-before" and "stop-line-count-after" settings. Also, there is a new setting for how many disassembly lines to show: "stop-disassembly-count". This will control how many source lines are shown when there is no source or when we have no source line info. settings set stop-line-count-before 3 settings set stop-line-count-after 3 settings set stop-disassembly-count 4 settings set stop-disassembly-display no-source The default values are set as shown above and allow 3 lines of source before and after (what we used to do) the current stop location, and will display 4 lines of disassembly if the source is not available or if we have no debug info. If both "stop-source-context-before" and "stop-source-context-after" are set to zero, this will disable showing any source when stopped. The "stop-disassembly-display" setting is an enumeration that allows you to control when to display disassembly. It has 3 possible values: "never" - never show disassembly no matter what "no-source" - only show disassembly when there is no source line info or the source files are missing "always" - always show disassembly. llvm-svn: 145050
2011-11-22 05:44:34 +08:00
{
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
const uint32_t idx = ePropertyUseExternalEditor;
<rdar://problem/12022079> Added a new "interpreter" properties to encapsulate any properties for the command interpreter. Right now this contains only "expand-regex-aliases", so you can now enable (disabled by default) the echoing of the command that a regular expression alias expands to: (lldb) b main Breakpoint created: 1: name = 'main', locations = 1 Note that the expanded regular expression command wasn't shown by default. You can enable it if you want to: (lldb) settings set interpreter.expand-regex-aliases true (lldb) b main breakpoint set --name 'main' Breakpoint created: 1: name = 'main', locations = 1 Also enabled auto completion for enumeration option values (OptionValueEnumeration) and for boolean option values (OptionValueBoolean). Fixed auto completion for settings names when nothing has been type (it should show all settings). llvm-svn: 162418
2012-08-23 08:22:02 +08:00
return m_collection_sp->GetPropertyAtIndexAsBoolean (NULL, idx, g_properties[idx].default_uint_value != 0);
Many GDB users always want to display disassembly when they stop by using something like "display/4i $pc" (or something like this). With LLDB we already were showing 3 lines of source before and 3 lines of source after the current source line when showing a stop context. We now improve this by allowing the user to control the number of lines with the new "stop-line-count-before" and "stop-line-count-after" settings. Also, there is a new setting for how many disassembly lines to show: "stop-disassembly-count". This will control how many source lines are shown when there is no source or when we have no source line info. settings set stop-line-count-before 3 settings set stop-line-count-after 3 settings set stop-disassembly-count 4 settings set stop-disassembly-display no-source The default values are set as shown above and allow 3 lines of source before and after (what we used to do) the current stop location, and will display 4 lines of disassembly if the source is not available or if we have no debug info. If both "stop-source-context-before" and "stop-source-context-after" are set to zero, this will disable showing any source when stopped. The "stop-disassembly-display" setting is an enumeration that allows you to control when to display disassembly. It has 3 possible values: "never" - never show disassembly no matter what "no-source" - only show disassembly when there is no source line info or the source files are missing "always" - always show disassembly. llvm-svn: 145050
2011-11-22 05:44:34 +08:00
}
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
bool
Debugger::SetUseExternalEditor (bool b)
Many GDB users always want to display disassembly when they stop by using something like "display/4i $pc" (or something like this). With LLDB we already were showing 3 lines of source before and 3 lines of source after the current source line when showing a stop context. We now improve this by allowing the user to control the number of lines with the new "stop-line-count-before" and "stop-line-count-after" settings. Also, there is a new setting for how many disassembly lines to show: "stop-disassembly-count". This will control how many source lines are shown when there is no source or when we have no source line info. settings set stop-line-count-before 3 settings set stop-line-count-after 3 settings set stop-disassembly-count 4 settings set stop-disassembly-display no-source The default values are set as shown above and allow 3 lines of source before and after (what we used to do) the current stop location, and will display 4 lines of disassembly if the source is not available or if we have no debug info. If both "stop-source-context-before" and "stop-source-context-after" are set to zero, this will disable showing any source when stopped. The "stop-disassembly-display" setting is an enumeration that allows you to control when to display disassembly. It has 3 possible values: "never" - never show disassembly no matter what "no-source" - only show disassembly when there is no source line info or the source files are missing "always" - always show disassembly. llvm-svn: 145050
2011-11-22 05:44:34 +08:00
{
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
const uint32_t idx = ePropertyUseExternalEditor;
return m_collection_sp->SetPropertyAtIndexAsBoolean (NULL, idx, b);
Many GDB users always want to display disassembly when they stop by using something like "display/4i $pc" (or something like this). With LLDB we already were showing 3 lines of source before and 3 lines of source after the current source line when showing a stop context. We now improve this by allowing the user to control the number of lines with the new "stop-line-count-before" and "stop-line-count-after" settings. Also, there is a new setting for how many disassembly lines to show: "stop-disassembly-count". This will control how many source lines are shown when there is no source or when we have no source line info. settings set stop-line-count-before 3 settings set stop-line-count-after 3 settings set stop-disassembly-count 4 settings set stop-disassembly-display no-source The default values are set as shown above and allow 3 lines of source before and after (what we used to do) the current stop location, and will display 4 lines of disassembly if the source is not available or if we have no debug info. If both "stop-source-context-before" and "stop-source-context-after" are set to zero, this will disable showing any source when stopped. The "stop-disassembly-display" setting is an enumeration that allows you to control when to display disassembly. It has 3 possible values: "never" - never show disassembly no matter what "no-source" - only show disassembly when there is no source line info or the source files are missing "always" - always show disassembly. llvm-svn: 145050
2011-11-22 05:44:34 +08:00
}
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
uint32_t
Debugger::GetStopSourceLineCount (bool before) const
Many GDB users always want to display disassembly when they stop by using something like "display/4i $pc" (or something like this). With LLDB we already were showing 3 lines of source before and 3 lines of source after the current source line when showing a stop context. We now improve this by allowing the user to control the number of lines with the new "stop-line-count-before" and "stop-line-count-after" settings. Also, there is a new setting for how many disassembly lines to show: "stop-disassembly-count". This will control how many source lines are shown when there is no source or when we have no source line info. settings set stop-line-count-before 3 settings set stop-line-count-after 3 settings set stop-disassembly-count 4 settings set stop-disassembly-display no-source The default values are set as shown above and allow 3 lines of source before and after (what we used to do) the current stop location, and will display 4 lines of disassembly if the source is not available or if we have no debug info. If both "stop-source-context-before" and "stop-source-context-after" are set to zero, this will disable showing any source when stopped. The "stop-disassembly-display" setting is an enumeration that allows you to control when to display disassembly. It has 3 possible values: "never" - never show disassembly no matter what "no-source" - only show disassembly when there is no source line info or the source files are missing "always" - always show disassembly. llvm-svn: 145050
2011-11-22 05:44:34 +08:00
{
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
const uint32_t idx = before ? ePropertyStopLineCountBefore : ePropertyStopLineCountAfter;
<rdar://problem/12022079> Added a new "interpreter" properties to encapsulate any properties for the command interpreter. Right now this contains only "expand-regex-aliases", so you can now enable (disabled by default) the echoing of the command that a regular expression alias expands to: (lldb) b main Breakpoint created: 1: name = 'main', locations = 1 Note that the expanded regular expression command wasn't shown by default. You can enable it if you want to: (lldb) settings set interpreter.expand-regex-aliases true (lldb) b main breakpoint set --name 'main' Breakpoint created: 1: name = 'main', locations = 1 Also enabled auto completion for enumeration option values (OptionValueEnumeration) and for boolean option values (OptionValueBoolean). Fixed auto completion for settings names when nothing has been type (it should show all settings). llvm-svn: 162418
2012-08-23 08:22:02 +08:00
return m_collection_sp->GetPropertyAtIndexAsSInt64 (NULL, idx, g_properties[idx].default_uint_value);
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
}
Many GDB users always want to display disassembly when they stop by using something like "display/4i $pc" (or something like this). With LLDB we already were showing 3 lines of source before and 3 lines of source after the current source line when showing a stop context. We now improve this by allowing the user to control the number of lines with the new "stop-line-count-before" and "stop-line-count-after" settings. Also, there is a new setting for how many disassembly lines to show: "stop-disassembly-count". This will control how many source lines are shown when there is no source or when we have no source line info. settings set stop-line-count-before 3 settings set stop-line-count-after 3 settings set stop-disassembly-count 4 settings set stop-disassembly-display no-source The default values are set as shown above and allow 3 lines of source before and after (what we used to do) the current stop location, and will display 4 lines of disassembly if the source is not available or if we have no debug info. If both "stop-source-context-before" and "stop-source-context-after" are set to zero, this will disable showing any source when stopped. The "stop-disassembly-display" setting is an enumeration that allows you to control when to display disassembly. It has 3 possible values: "never" - never show disassembly no matter what "no-source" - only show disassembly when there is no source line info or the source files are missing "always" - always show disassembly. llvm-svn: 145050
2011-11-22 05:44:34 +08:00
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
Debugger::StopDisassemblyType
Debugger::GetStopDisassemblyDisplay () const
{
const uint32_t idx = ePropertyStopDisassemblyDisplay;
<rdar://problem/12022079> Added a new "interpreter" properties to encapsulate any properties for the command interpreter. Right now this contains only "expand-regex-aliases", so you can now enable (disabled by default) the echoing of the command that a regular expression alias expands to: (lldb) b main Breakpoint created: 1: name = 'main', locations = 1 Note that the expanded regular expression command wasn't shown by default. You can enable it if you want to: (lldb) settings set interpreter.expand-regex-aliases true (lldb) b main breakpoint set --name 'main' Breakpoint created: 1: name = 'main', locations = 1 Also enabled auto completion for enumeration option values (OptionValueEnumeration) and for boolean option values (OptionValueBoolean). Fixed auto completion for settings names when nothing has been type (it should show all settings). llvm-svn: 162418
2012-08-23 08:22:02 +08:00
return (Debugger::StopDisassemblyType)m_collection_sp->GetPropertyAtIndexAsEnumeration (NULL, idx, g_properties[idx].default_uint_value);
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
}
Many GDB users always want to display disassembly when they stop by using something like "display/4i $pc" (or something like this). With LLDB we already were showing 3 lines of source before and 3 lines of source after the current source line when showing a stop context. We now improve this by allowing the user to control the number of lines with the new "stop-line-count-before" and "stop-line-count-after" settings. Also, there is a new setting for how many disassembly lines to show: "stop-disassembly-count". This will control how many source lines are shown when there is no source or when we have no source line info. settings set stop-line-count-before 3 settings set stop-line-count-after 3 settings set stop-disassembly-count 4 settings set stop-disassembly-display no-source The default values are set as shown above and allow 3 lines of source before and after (what we used to do) the current stop location, and will display 4 lines of disassembly if the source is not available or if we have no debug info. If both "stop-source-context-before" and "stop-source-context-after" are set to zero, this will disable showing any source when stopped. The "stop-disassembly-display" setting is an enumeration that allows you to control when to display disassembly. It has 3 possible values: "never" - never show disassembly no matter what "no-source" - only show disassembly when there is no source line info or the source files are missing "always" - always show disassembly. llvm-svn: 145050
2011-11-22 05:44:34 +08:00
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
uint32_t
Debugger::GetDisassemblyLineCount () const
{
const uint32_t idx = ePropertyStopDisassemblyCount;
<rdar://problem/12022079> Added a new "interpreter" properties to encapsulate any properties for the command interpreter. Right now this contains only "expand-regex-aliases", so you can now enable (disabled by default) the echoing of the command that a regular expression alias expands to: (lldb) b main Breakpoint created: 1: name = 'main', locations = 1 Note that the expanded regular expression command wasn't shown by default. You can enable it if you want to: (lldb) settings set interpreter.expand-regex-aliases true (lldb) b main breakpoint set --name 'main' Breakpoint created: 1: name = 'main', locations = 1 Also enabled auto completion for enumeration option values (OptionValueEnumeration) and for boolean option values (OptionValueBoolean). Fixed auto completion for settings names when nothing has been type (it should show all settings). llvm-svn: 162418
2012-08-23 08:22:02 +08:00
return m_collection_sp->GetPropertyAtIndexAsSInt64 (NULL, idx, g_properties[idx].default_uint_value);
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
}
Many GDB users always want to display disassembly when they stop by using something like "display/4i $pc" (or something like this). With LLDB we already were showing 3 lines of source before and 3 lines of source after the current source line when showing a stop context. We now improve this by allowing the user to control the number of lines with the new "stop-line-count-before" and "stop-line-count-after" settings. Also, there is a new setting for how many disassembly lines to show: "stop-disassembly-count". This will control how many source lines are shown when there is no source or when we have no source line info. settings set stop-line-count-before 3 settings set stop-line-count-after 3 settings set stop-disassembly-count 4 settings set stop-disassembly-display no-source The default values are set as shown above and allow 3 lines of source before and after (what we used to do) the current stop location, and will display 4 lines of disassembly if the source is not available or if we have no debug info. If both "stop-source-context-before" and "stop-source-context-after" are set to zero, this will disable showing any source when stopped. The "stop-disassembly-display" setting is an enumeration that allows you to control when to display disassembly. It has 3 possible values: "never" - never show disassembly no matter what "no-source" - only show disassembly when there is no source line info or the source files are missing "always" - always show disassembly. llvm-svn: 145050
2011-11-22 05:44:34 +08:00
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
#pragma mark Debugger
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
//const DebuggerPropertiesSP &
//Debugger::GetSettings() const
//{
// return m_properties_sp;
//}
//
Cleaned up code that wasn't using the Initialize and Terminate paradigm by changing it to use it. There was an extra parameter added to the static accessor global user settings controllers that wasn't needed. A bool was being used as a parameter to the accessor just so it could be used to clean up the global user settings controller which is now fixed by splitting up the initialization into the "static void Class::Initialize()", access into the "static UserSettingsControllerSP & Class::GetSettingsController()", and cleanup into "static void Class::Terminate()". Also added initialize and terminate calls to the logging code to avoid issues when LLDB is shutting down. There were cases after the logging was switched over to use shared pointers where we could crash if the global destructor chain was being run and it causes the log to be destroyed and any any logging occurred. llvm-svn: 119757
2010-11-19 07:32:35 +08:00
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 08:29:16 +08:00
int
Debugger::TestDebuggerRefCount ()
{
return g_shared_debugger_refcount;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
void
Debugger::Initialize ()
{
<rdar://problem/11148044> Fixed a potential crasher that could happen after Debugger::Terminate() was called. llvm-svn: 153774
2012-03-31 04:53:46 +08:00
if (g_shared_debugger_refcount++ == 0)
Fixed an issue where the UserSettingsControllers were being created out of order and this was causing the target, process and thread trees to not be available. llvm-svn: 119784
2010-11-19 11:46:01 +08:00
lldb_private::Initialize();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
void
Debugger::Terminate ()
{
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
2010-06-23 09:19:29 +08:00
if (g_shared_debugger_refcount > 0)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
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
2010-06-23 09:19:29 +08:00
g_shared_debugger_refcount--;
if (g_shared_debugger_refcount == 0)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Fixed an issue where the UserSettingsControllers were being created out of order and this was causing the target, process and thread trees to not be available. llvm-svn: 119784
2010-11-19 11:46:01 +08:00
lldb_private::WillTerminate();
lldb_private::Terminate();
Replace Mutex guarding python interpreter access with Predicate, allowing timeouts & informing the user when the lock is unavailable. Fixed problem where Debugger::Terminate was clearing the debugger list even when the global ref count was greater than zero. llvm-svn: 123674
2011-01-18 05:55:19 +08:00
// Clear our master list of debugger objects
Mutex::Locker locker (GetDebuggerListMutex ());
GetDebuggerList().clear();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
}
}
The UserSettings controllers must be initialized & terminated in the correct order. Previously this was tacitly implemented but not enforced, so it was possible to accidentally do things in the wrong order and cause problems. This fixes that problem. llvm-svn: 127430
2011-03-11 06:14:10 +08:00
void
Debugger::SettingsInitialize ()
{
Remove further outdated "settings" code and also implement a few missing things. llvm-svn: 162376
2012-08-23 02:39:03 +08:00
Target::SettingsInitialize ();
The UserSettings controllers must be initialized & terminated in the correct order. Previously this was tacitly implemented but not enforced, so it was possible to accidentally do things in the wrong order and cause problems. This fixes that problem. llvm-svn: 127430
2011-03-11 06:14:10 +08:00
}
void
Debugger::SettingsTerminate ()
{
Remove further outdated "settings" code and also implement a few missing things. llvm-svn: 162376
2012-08-23 02:39:03 +08:00
Target::SettingsTerminate ();
The UserSettings controllers must be initialized & terminated in the correct order. Previously this was tacitly implemented but not enforced, so it was possible to accidentally do things in the wrong order and cause problems. This fixes that problem. llvm-svn: 127430
2011-03-11 06:14:10 +08:00
}
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
2010-06-23 09:19:29 +08:00
DebuggerSP
Add a logging mode that takes a callback and flush'es to that callback. Also add SB API's to set this callback, and to enable the log channels. llvm-svn: 151018
2012-02-21 10:23:08 +08:00
Debugger::CreateInstance (lldb::LogOutputCallback log_callback, void *baton)
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
2010-06-23 09:19:29 +08:00
{
Add a logging mode that takes a callback and flush'es to that callback. Also add SB API's to set this callback, and to enable the log channels. llvm-svn: 151018
2012-02-21 10:23:08 +08:00
DebuggerSP debugger_sp (new Debugger(log_callback, baton));
<rdar://problem/11148044> Fixed a potential crasher that could happen after Debugger::Terminate() was called. llvm-svn: 153774
2012-03-31 04:53:46 +08:00
if (g_shared_debugger_refcount > 0)
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
2010-06-23 09:19:29 +08:00
{
Mutex::Locker locker (GetDebuggerListMutex ());
GetDebuggerList().push_back(debugger_sp);
}
return debugger_sp;
}
Add API and implementation for SBDebugger::Destroy and Debugger::Destroy. llvm-svn: 124011
2011-01-22 09:02:07 +08:00
void
Adopt the intrusive pointers in: lldb_private::Breakpoint lldb_private::BreakpointLocations lldb_private::BreakpointSite lldb_private::Debugger lldb_private::StackFrame lldb_private::Thread lldb_private::Target llvm-svn: 139985
2011-09-17 16:33:22 +08:00
Debugger::Destroy (DebuggerSP &debugger_sp)
Add API and implementation for SBDebugger::Destroy and Debugger::Destroy. llvm-svn: 124011
2011-01-22 09:02:07 +08:00
{
if (debugger_sp.get() == NULL)
return;
Track whether a process was Launched or Attached to. If Attached, the detach when the debugger is destroyed, rather than killing the process. Also added a Debugger::Clear, which gets called in Debugger::Destroy to deal with all the targets in the Debugger. Also made the Driver's main loop call Destroy on the debugger, rather than just Destroying the currently selected Target's process. llvm-svn: 139853
2011-09-16 05:36:42 +08:00
debugger_sp->Clear();
<rdar://problem/11148044> Fixed a potential crasher that could happen after Debugger::Terminate() was called. llvm-svn: 153774
2012-03-31 04:53:46 +08:00
if (g_shared_debugger_refcount > 0)
Add API and implementation for SBDebugger::Destroy and Debugger::Destroy. llvm-svn: 124011
2011-01-22 09:02:07 +08:00
{
<rdar://problem/11148044> Fixed a potential crasher that could happen after Debugger::Terminate() was called. llvm-svn: 153774
2012-03-31 04:53:46 +08:00
Mutex::Locker locker (GetDebuggerListMutex ());
DebuggerList &debugger_list = GetDebuggerList ();
DebuggerList::iterator pos, end = debugger_list.end();
for (pos = debugger_list.begin (); pos != end; ++pos)
Add API and implementation for SBDebugger::Destroy and Debugger::Destroy. llvm-svn: 124011
2011-01-22 09:02:07 +08:00
{
<rdar://problem/11148044> Fixed a potential crasher that could happen after Debugger::Terminate() was called. llvm-svn: 153774
2012-03-31 04:53:46 +08:00
if ((*pos).get() == debugger_sp.get())
{
debugger_list.erase (pos);
return;
}
Add API and implementation for SBDebugger::Destroy and Debugger::Destroy. llvm-svn: 124011
2011-01-22 09:02:07 +08:00
}
}
}
Adopt the intrusive pointers in: lldb_private::Breakpoint lldb_private::BreakpointLocations lldb_private::BreakpointSite lldb_private::Debugger lldb_private::StackFrame lldb_private::Thread lldb_private::Target llvm-svn: 139985
2011-09-17 16:33:22 +08:00
DebuggerSP
This is a very large commit that completely re-does the way lldb handles user settable internal variables (the equivalent of set/show variables in gdb). In addition to the basic infrastructure (most of which is defined in UserSettingsController.{h,cpp}, there are examples of two classes that have been set up to contain user settable variables (the Debugger and Process classes). The 'settings' command has been modified to be a command-subcommand structure, and the 'set', 'show' and 'append' commands have been moved into this sub-commabnd structure. The old StateVariable class has been completely replaced by this, and the state variable dictionary has been removed from the Command Interpreter. Places that formerly accessed the state variable mechanism have been modified to access the variables in this new structure instead (checking the term-width; getting/checking the prompt; etc.) Variables are attached to classes; there are two basic "flavors" of variables that can be set: "global" variables (static/class-wide), and "instance" variables (one per instance of the class). The whole thing has been set up so that any global or instance variable can be set at any time (e.g. on start up, in your .lldbinit file), whether or not any instances actually exist (there's a whole pending and default values mechanism to help deal with that). llvm-svn: 113041
2010-09-04 08:03:46 +08:00
Debugger::FindDebuggerWithInstanceName (const ConstString &instance_name)
{
Adopt the intrusive pointers in: lldb_private::Breakpoint lldb_private::BreakpointLocations lldb_private::BreakpointSite lldb_private::Debugger lldb_private::StackFrame lldb_private::Thread lldb_private::Target llvm-svn: 139985
2011-09-17 16:33:22 +08:00
DebuggerSP debugger_sp;
Remove further outdated "settings" code and also implement a few missing things. llvm-svn: 162376
2012-08-23 02:39:03 +08:00
if (g_shared_debugger_refcount > 0)
{
Mutex::Locker locker (GetDebuggerListMutex ());
DebuggerList &debugger_list = GetDebuggerList();
DebuggerList::iterator pos, end = debugger_list.end();
for (pos = debugger_list.begin(); pos != end; ++pos)
{
if ((*pos).get()->m_instance_name == instance_name)
{
debugger_sp = *pos;
break;
}
}
}
This is a very large commit that completely re-does the way lldb handles user settable internal variables (the equivalent of set/show variables in gdb). In addition to the basic infrastructure (most of which is defined in UserSettingsController.{h,cpp}, there are examples of two classes that have been set up to contain user settable variables (the Debugger and Process classes). The 'settings' command has been modified to be a command-subcommand structure, and the 'set', 'show' and 'append' commands have been moved into this sub-commabnd structure. The old StateVariable class has been completely replaced by this, and the state variable dictionary has been removed from the Command Interpreter. Places that formerly accessed the state variable mechanism have been modified to access the variables in this new structure instead (checking the term-width; getting/checking the prompt; etc.) Variables are attached to classes; there are two basic "flavors" of variables that can be set: "global" variables (static/class-wide), and "instance" variables (one per instance of the class). The whole thing has been set up so that any global or instance variable can be set at any time (e.g. on start up, in your .lldbinit file), whether or not any instances actually exist (there's a whole pending and default values mechanism to help deal with that). llvm-svn: 113041
2010-09-04 08:03:46 +08:00
return debugger_sp;
}
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
2010-06-23 09:19:29 +08:00
TargetSP
Debugger::FindTargetWithProcessID (lldb::pid_t pid)
{
Adopt the intrusive pointers in: lldb_private::Breakpoint lldb_private::BreakpointLocations lldb_private::BreakpointSite lldb_private::Debugger lldb_private::StackFrame lldb_private::Thread lldb_private::Target llvm-svn: 139985
2011-09-17 16:33:22 +08:00
TargetSP target_sp;
<rdar://problem/11148044> Fixed a potential crasher that could happen after Debugger::Terminate() was called. llvm-svn: 153774
2012-03-31 04:53:46 +08:00
if (g_shared_debugger_refcount > 0)
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
2010-06-23 09:19:29 +08:00
{
<rdar://problem/11148044> Fixed a potential crasher that could happen after Debugger::Terminate() was called. llvm-svn: 153774
2012-03-31 04:53:46 +08:00
Mutex::Locker locker (GetDebuggerListMutex ());
DebuggerList &debugger_list = GetDebuggerList();
DebuggerList::iterator pos, end = debugger_list.end();
for (pos = debugger_list.begin(); pos != end; ++pos)
{
target_sp = (*pos)->GetTargetList().FindTargetWithProcessID (pid);
if (target_sp)
break;
}
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
2010-06-23 09:19:29 +08:00
}
return target_sp;
}
Made the darwin host layer properly reap any child processes that it spawns. After recent changes we weren't reaping child processes resulting in many zombie processes. This was fixed by adding more settings to the ProcessLaunchOptions class that allow clients to specify a callback function and baton to be notified when their process dies. If one is not supplied a default callback will be used that "does the right thing". Cleaned up a race condition in the ProcessGDBRemote class that would attempt to monitor when debugserver died. Added an extra boolean to the process monitor callbacks that indicate if a process exited or not. If your process exited with a zero exit status and no signal, both items could be zero. Modified the process monitor functions to not require a callback function in order to reap the child process. llvm-svn: 144780
2011-11-16 13:37:56 +08:00
TargetSP
Debugger::FindTargetWithProcess (Process *process)
{
TargetSP target_sp;
<rdar://problem/11148044> Fixed a potential crasher that could happen after Debugger::Terminate() was called. llvm-svn: 153774
2012-03-31 04:53:46 +08:00
if (g_shared_debugger_refcount > 0)
Made the darwin host layer properly reap any child processes that it spawns. After recent changes we weren't reaping child processes resulting in many zombie processes. This was fixed by adding more settings to the ProcessLaunchOptions class that allow clients to specify a callback function and baton to be notified when their process dies. If one is not supplied a default callback will be used that "does the right thing". Cleaned up a race condition in the ProcessGDBRemote class that would attempt to monitor when debugserver died. Added an extra boolean to the process monitor callbacks that indicate if a process exited or not. If your process exited with a zero exit status and no signal, both items could be zero. Modified the process monitor functions to not require a callback function in order to reap the child process. llvm-svn: 144780
2011-11-16 13:37:56 +08:00
{
<rdar://problem/11148044> Fixed a potential crasher that could happen after Debugger::Terminate() was called. llvm-svn: 153774
2012-03-31 04:53:46 +08:00
Mutex::Locker locker (GetDebuggerListMutex ());
DebuggerList &debugger_list = GetDebuggerList();
DebuggerList::iterator pos, end = debugger_list.end();
for (pos = debugger_list.begin(); pos != end; ++pos)
{
target_sp = (*pos)->GetTargetList().FindTargetWithProcess (process);
if (target_sp)
break;
}
Made the darwin host layer properly reap any child processes that it spawns. After recent changes we weren't reaping child processes resulting in many zombie processes. This was fixed by adding more settings to the ProcessLaunchOptions class that allow clients to specify a callback function and baton to be notified when their process dies. If one is not supplied a default callback will be used that "does the right thing". Cleaned up a race condition in the ProcessGDBRemote class that would attempt to monitor when debugserver died. Added an extra boolean to the process monitor callbacks that indicate if a process exited or not. If your process exited with a zero exit status and no signal, both items could be zero. Modified the process monitor functions to not require a callback function in order to reap the child process. llvm-svn: 144780
2011-11-16 13:37:56 +08:00
}
return target_sp;
}
Add a logging mode that takes a callback and flush'es to that callback. Also add SB API's to set this callback, and to enable the log channels. llvm-svn: 151018
2012-02-21 10:23:08 +08:00
Debugger::Debugger (lldb::LogOutputCallback log_callback, void *baton) :
Add a unique ID to each debugger instance. Add functions to look up debugger by id Add global variable to lldb python module, to hold debugger id Modify embedded Python interpreter to update the global variable with the id of its current debugger. Modify the char ** typemap definition in lldb.swig to accept 'None' (for NULL) as a valid value. The point of all this is so that, when you drop into the embedded interpreter from the command interpreter (or when doing Python-based breakpoint commands), there is a way for the Python side to find/get the correct debugger instance ( by checking debugger_unique_id, then calling SBDebugger::FindDebuggerWithID on it). llvm-svn: 107287
2010-07-01 00:22:25 +08:00
UserID (g_unique_id++),
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
Properties(OptionValuePropertiesSP(new OptionValueProperties())),
More reverting of the EOF stuff as the API was changed which we don't want to do. Closing on EOF is an option that can be set on the lldb_private::Communication or the lldb::SBCommunication objects after they are created. Of course the EOF support isn't hooked up, so they don't do anything at the moment, but they are left in so when the code is fixed, it will be easy to get working again. llvm-svn: 120885
2010-12-04 10:39:47 +08:00
m_input_comm("debugger.input"),
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
m_input_file (),
m_output_file (),
m_error_file (),
Add a general mechanism to wait on the debugger for Broadcasters of a given class/event bit set. Use this to allow the lldb Driver to emit notifications for breakpoint modifications. <rdar://problem/10619974> llvm-svn: 150665
2012-02-16 14:50:00 +08:00
m_target_list (*this),
Added more platform support. There are now some new commands: platform status -- gets status information for the selected platform platform create <platform-name> -- creates a new instance of a remote platform platform list -- list all available platforms platform select -- select a platform instance as the current platform (not working yet) When using "platform create" it will create a remote platform and make it the selected platform. For instances for iPhone OS debugging on Mac OS X one can do: (lldb) platform create remote-ios --sdk-version=4.0 Remote platform: iOS platform SDK version: 4.0 SDK path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0" Not connected to a remote device. (lldb) file ~/Documents/a.out Current executable set to '~/Documents/a.out' (armv6). (lldb) image list [ 0] /Volumes/work/gclayton/Documents/devb/attach/a.out [ 1] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/dyld [ 2] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/libSystem.B.dylib Note that this is all happening prior to running _or_ connecting to a remote platform. Once connected to a remote platform the OS version might change which means we will need to update our dependecies. Also once we run, we will need to match up the actualy binaries with the actualy UUID's to files in the SDK, or download and cache them locally. This is just the start of the remote platforms, but this modification is the first iteration in getting the platforms really doing something. llvm-svn: 127934
2011-03-19 09:12:21 +08:00
m_platform_list (),
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
m_listener ("lldb.Debugger"),
SBSourceManager now gets the real source manager either from the Debugger or Target. Also, move the SourceManager file cache into the debugger so it can be shared amongst the targets. llvm-svn: 139564
2011-09-13 08:29:56 +08:00
m_source_manager(*this),
m_source_file_cache(),
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
2010-06-23 09:19:29 +08:00
m_command_interpreter_ap (new CommandInterpreter (*this, eScriptLanguageDefault, false)),
Create new class, InputReaderStack, to better handle mutexes around input readers and prevent deadlocking; modify Debugger to use the new class. llvm-svn: 132475
2011-06-03 03:18:55 +08:00
m_input_reader_stack (),
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
m_input_reader_data (),
m_instance_name()
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
char instance_cstr[256];
snprintf(instance_cstr, sizeof(instance_cstr), "debugger_%d", (int)GetID());
m_instance_name.SetCString(instance_cstr);
Add a logging mode that takes a callback and flush'es to that callback. Also add SB API's to set this callback, and to enable the log channels. llvm-svn: 151018
2012-02-21 10:23:08 +08:00
if (log_callback)
m_log_callback_stream_sp.reset (new StreamCallback (log_callback, baton));
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
2010-06-23 09:19:29 +08:00
m_command_interpreter_ap->Initialize ();
Added more platform support. There are now some new commands: platform status -- gets status information for the selected platform platform create <platform-name> -- creates a new instance of a remote platform platform list -- list all available platforms platform select -- select a platform instance as the current platform (not working yet) When using "platform create" it will create a remote platform and make it the selected platform. For instances for iPhone OS debugging on Mac OS X one can do: (lldb) platform create remote-ios --sdk-version=4.0 Remote platform: iOS platform SDK version: 4.0 SDK path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0" Not connected to a remote device. (lldb) file ~/Documents/a.out Current executable set to '~/Documents/a.out' (armv6). (lldb) image list [ 0] /Volumes/work/gclayton/Documents/devb/attach/a.out [ 1] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/dyld [ 2] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/libSystem.B.dylib Note that this is all happening prior to running _or_ connecting to a remote platform. Once connected to a remote platform the OS version might change which means we will need to update our dependecies. Also once we run, we will need to match up the actualy binaries with the actualy UUID's to files in the SDK, or download and cache them locally. This is just the start of the remote platforms, but this modification is the first iteration in getting the platforms really doing something. llvm-svn: 127934
2011-03-19 09:12:21 +08:00
// Always add our default platform to the platform list
PlatformSP default_platform_sp (Platform::GetDefaultPlatform());
assert (default_platform_sp.get());
m_platform_list.Append (default_platform_sp, true);
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
<rdar://problem/12022079> Added a new "interpreter" properties to encapsulate any properties for the command interpreter. Right now this contains only "expand-regex-aliases", so you can now enable (disabled by default) the echoing of the command that a regular expression alias expands to: (lldb) b main Breakpoint created: 1: name = 'main', locations = 1 Note that the expanded regular expression command wasn't shown by default. You can enable it if you want to: (lldb) settings set interpreter.expand-regex-aliases true (lldb) b main breakpoint set --name 'main' Breakpoint created: 1: name = 'main', locations = 1 Also enabled auto completion for enumeration option values (OptionValueEnumeration) and for boolean option values (OptionValueBoolean). Fixed auto completion for settings names when nothing has been type (it should show all settings). llvm-svn: 162418
2012-08-23 08:22:02 +08:00
m_collection_sp->Initialize (g_properties);
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
m_collection_sp->AppendProperty (ConstString("target"),
ConstString("Settings specify to debugging targets."),
true,
Target::GetGlobalProperties()->GetValueProperties());
<rdar://problem/12022079> Added a new "interpreter" properties to encapsulate any properties for the command interpreter. Right now this contains only "expand-regex-aliases", so you can now enable (disabled by default) the echoing of the command that a regular expression alias expands to: (lldb) b main Breakpoint created: 1: name = 'main', locations = 1 Note that the expanded regular expression command wasn't shown by default. You can enable it if you want to: (lldb) settings set interpreter.expand-regex-aliases true (lldb) b main breakpoint set --name 'main' Breakpoint created: 1: name = 'main', locations = 1 Also enabled auto completion for enumeration option values (OptionValueEnumeration) and for boolean option values (OptionValueBoolean). Fixed auto completion for settings names when nothing has been type (it should show all settings). llvm-svn: 162418
2012-08-23 08:22:02 +08:00
if (m_command_interpreter_ap.get())
{
m_collection_sp->AppendProperty (ConstString("interpreter"),
ConstString("Settings specify to the debugger's command interpreter."),
true,
m_command_interpreter_ap->GetValueProperties());
}
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
OptionValueSInt64 *term_width = m_collection_sp->GetPropertyAtIndexAsOptionValueSInt64 (NULL, ePropertyTerminalWidth);
term_width->SetMinimumValue(10);
term_width->SetMaximumValue(1024);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Debugger::~Debugger ()
Track whether a process was Launched or Attached to. If Attached, the detach when the debugger is destroyed, rather than killing the process. Also added a Debugger::Clear, which gets called in Debugger::Destroy to deal with all the targets in the Debugger. Also made the Driver's main loop call Destroy on the debugger, rather than just Destroying the currently selected Target's process. llvm-svn: 139853
2011-09-16 05:36:42 +08:00
{
Clear();
}
void
Debugger::Clear()
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Add code to make sure InputReaders finish and are cleaned up when a Debugger object is destroyed or re-set. (Thus making sure that, for example, the Python interpreter finishes and exits cleanly rather than being left in an undefined state.) llvm-svn: 122255
2010-12-21 02:35:50 +08:00
CleanUpInputReaders();
Cleaned up the the code that figures out the inlined stack frames given a symbol context that represents an inlined function. This function has been renamed internally to: bool SymbolContext::GetParentOfInlinedScope (const Address &curr_frame_pc, SymbolContext &next_frame_sc, Address &next_frame_pc) const; And externally to: SBSymbolContext SBSymbolContext::GetParentOfInlinedScope (const SBAddress &curr_frame_pc, SBAddress &parent_frame_addr) const; The correct blocks are now correctly calculated. Switched the stack backtracing engine (in StackFrameList) and the address context printing over to using the internal SymbolContext::GetParentOfInlinedScope(...) so all inlined callstacks will match exactly. llvm-svn: 140910
2011-10-01 08:45:15 +08:00
m_listener.Clear();
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
2010-06-23 09:19:29 +08:00
int num_targets = m_target_list.GetNumTargets();
for (int i = 0; i < num_targets; i++)
{
<rdar://problem/10684141> When the lldb_private::Debugger goes away, it should cleanup all of its targets. llvm-svn: 148189
2012-01-15 01:04:19 +08:00
TargetSP target_sp (m_target_list.GetTargetAtIndex (i));
if (target_sp)
Track whether a process was Launched or Attached to. If Attached, the detach when the debugger is destroyed, rather than killing the process. Also added a Debugger::Clear, which gets called in Debugger::Destroy to deal with all the targets in the Debugger. Also made the Driver's main loop call Destroy on the debugger, rather than just Destroying the currently selected Target's process. llvm-svn: 139853
2011-09-16 05:36:42 +08:00
{
<rdar://problem/10684141> When the lldb_private::Debugger goes away, it should cleanup all of its targets. llvm-svn: 148189
2012-01-15 01:04:19 +08:00
ProcessSP process_sp (target_sp->GetProcessSP());
if (process_sp)
{
if (process_sp->GetShouldDetach())
process_sp->Detach();
}
target_sp->Destroy();
Track whether a process was Launched or Attached to. If Attached, the detach when the debugger is destroyed, rather than killing the process. Also added a Debugger::Clear, which gets called in Debugger::Destroy to deal with all the targets in the Debugger. Also made the Driver's main loop call Destroy on the debugger, rather than just Destroying the currently selected Target's process. llvm-svn: 139853
2011-09-16 05:36:42 +08:00
}
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
2010-06-23 09:19:29 +08:00
}
Add a general mechanism to wait on the debugger for Broadcasters of a given class/event bit set. Use this to allow the lldb Driver to emit notifications for breakpoint modifications. <rdar://problem/10619974> llvm-svn: 150665
2012-02-16 14:50:00 +08:00
BroadcasterManager::Clear ();
<rdar://problem/11246147> Make sure our debugger STDIN read thread shuts down quickly when we are done with it. We had a case where the owner of the file handle was not closing it and caused spins. llvm-svn: 156879
2012-05-16 08:11:54 +08:00
// Close the input file _before_ we close the input read communications class
// as it does NOT own the input file, our m_input_file does.
GetInputFile().Close ();
// Now that we have closed m_input_file, we can now tell our input communication
// class to close down. Its read thread should quickly exit after we close
// the input file handle above.
m_input_comm.Clear ();
Track whether a process was Launched or Attached to. If Attached, the detach when the debugger is destroyed, rather than killing the process. Also added a Debugger::Clear, which gets called in Debugger::Destroy to deal with all the targets in the Debugger. Also made the Driver's main loop call Destroy on the debugger, rather than just Destroying the currently selected Target's process. llvm-svn: 139853
2011-09-16 05:36:42 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Don't have the debugger default to ignoring EOF. This is only what the driver (or anything running in a terminal) wants. Not what a UI (Xcode) would want where it creates a debugger per debug window. The current code had an infinite loop after a debug session ended. llvm-svn: 132280
2011-05-29 12:06:55 +08:00
bool
Debugger::GetCloseInputOnEOF () const
{
return m_input_comm.GetCloseOnEOF();
}
void
Debugger::SetCloseInputOnEOF (bool b)
{
m_input_comm.SetCloseOnEOF(b);
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
bool
Debugger::GetAsyncExecution ()
{
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
2010-06-23 09:19:29 +08:00
return !m_command_interpreter_ap->GetSynchronous();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
void
Debugger::SetAsyncExecution (bool async_execution)
{
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
2010-06-23 09:19:29 +08:00
m_command_interpreter_ap->SetSynchronous (!async_execution);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
void
Debugger::SetInputFileHandle (FILE *fh, bool tranfer_ownership)
{
Use Host::File in lldb_private::StreamFile and other places to cleanup host layer a bit more. llvm-svn: 125149
2011-02-09 09:08:52 +08:00
File &in_file = GetInputFile();
in_file.SetStream (fh, tranfer_ownership);
if (in_file.IsValid() == false)
in_file.SetStream (stdin, true);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
// Disconnect from any old connection if we had one
m_input_comm.Disconnect ();
<rdar://problem/9731573> Fixed two double "int close(int fd)" issues found by our file descriptor interposing library on darwin: The first is in SBDebugger::SetInputFileHandle (FILE *file, bool transfer_ownership) where we would give our FILE * to a lldb_private::File object member variable and tell it that it owned the file descriptor if "transfer_ownership" was true, and then we would also give it to the communication plug-in that waits for stdin to come in and tell it that it owned the FILE *. They would both try and close the file. The seconds was when we use a file descriptor through ConnectionFileDescriptor where someone else is creating a connection with ConnectionFileDescriptor and a URL like: "fd://123". We were always taking ownwership of the fd 123, when we shouldn't be. There is a TODO in the comments that says we should allow URL options to be passed to be able to specify this later (something like: "fd://123?transer_ownership=1"), but we can get to this later. llvm-svn: 148201
2012-01-15 04:47:38 +08:00
// Pass false as the second argument to ConnectionFileDescriptor below because
// our "in_file" above will already take ownership if requested and we don't
// want to objects trying to own and close a file descriptor.
m_input_comm.SetConnection (new ConnectionFileDescriptor (in_file.GetDescriptor(), false));
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
m_input_comm.SetReadThreadBytesReceivedCallback (Debugger::DispatchInputCallback, this);
Error error;
if (m_input_comm.StartReadThread (&error) == false)
{
Use Host::File in lldb_private::StreamFile and other places to cleanup host layer a bit more. llvm-svn: 125149
2011-02-09 09:08:52 +08:00
File &err_file = GetErrorFile();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Use Host::File in lldb_private::StreamFile and other places to cleanup host layer a bit more. llvm-svn: 125149
2011-02-09 09:08:52 +08:00
err_file.Printf ("error: failed to main input read thread: %s", error.AsCString() ? error.AsCString() : "unkown error");
exit(1);
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
void
Debugger::SetOutputFileHandle (FILE *fh, bool tranfer_ownership)
{
Use Host::File in lldb_private::StreamFile and other places to cleanup host layer a bit more. llvm-svn: 125149
2011-02-09 09:08:52 +08:00
File &out_file = GetOutputFile();
out_file.SetStream (fh, tranfer_ownership);
if (out_file.IsValid() == false)
out_file.SetStream (stdout, false);
Split up the Python script interpreter code to allow multiple script interpreter objects to exist within the same process (one script interpreter object per debugger object). The python script interpreter objects are all using the same global Python script interpreter; they use separate dictionaries to keep their data separate, and mutex's to prevent any object attempting to use the global Python interpreter when another object is already using it. llvm-svn: 123415
2011-01-14 08:29:16 +08:00
GetCommandInterpreter().GetScriptInterpreter()->ResetOutputFileHandle (fh);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
void
Debugger::SetErrorFileHandle (FILE *fh, bool tranfer_ownership)
{
Use Host::File in lldb_private::StreamFile and other places to cleanup host layer a bit more. llvm-svn: 125149
2011-02-09 09:08:52 +08:00
File &err_file = GetErrorFile();
err_file.SetStream (fh, tranfer_ownership);
if (err_file.IsValid() == false)
err_file.SetStream (stderr, false);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
ExecutionContext
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
2010-08-27 05:32:51 +08:00
Debugger::GetSelectedExecutionContext ()
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
ExecutionContext exe_ctx;
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
TargetSP target_sp(GetSelectedTarget());
exe_ctx.SetTargetSP (target_sp);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (target_sp)
{
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
ProcessSP process_sp (target_sp->GetProcessSP());
exe_ctx.SetProcessSP (process_sp);
if (process_sp && process_sp->IsRunning() == false)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
ThreadSP thread_sp (process_sp->GetThreadList().GetSelectedThread());
if (thread_sp)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
exe_ctx.SetThreadSP (thread_sp);
exe_ctx.SetFrameSP (thread_sp->GetSelectedFrame());
if (exe_ctx.GetFramePtr() == NULL)
exe_ctx.SetFrameSP (thread_sp->GetStackFrameAtIndex (0));
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
}
}
return exe_ctx;
}
Add a new function to Debugger for finding the top/current input reader. Always make sure the input reader stack is not empty before trying to get the top element from the stack. llvm-svn: 125255
2011-02-10 09:15:13 +08:00
InputReaderSP
Debugger::GetCurrentInputReader ()
{
InputReaderSP reader_sp;
Create new class, InputReaderStack, to better handle mutexes around input readers and prevent deadlocking; modify Debugger to use the new class. llvm-svn: 132475
2011-06-03 03:18:55 +08:00
if (!m_input_reader_stack.IsEmpty())
Add a new function to Debugger for finding the top/current input reader. Always make sure the input reader stack is not empty before trying to get the top element from the stack. llvm-svn: 125255
2011-02-10 09:15:13 +08:00
{
// Clear any finished readers from the stack
while (CheckIfTopInputReaderIsDone()) ;
Create new class, InputReaderStack, to better handle mutexes around input readers and prevent deadlocking; modify Debugger to use the new class. llvm-svn: 132475
2011-06-03 03:18:55 +08:00
if (!m_input_reader_stack.IsEmpty())
reader_sp = m_input_reader_stack.Top();
Add a new function to Debugger for finding the top/current input reader. Always make sure the input reader stack is not empty before trying to get the top element from the stack. llvm-svn: 125255
2011-02-10 09:15:13 +08:00
}
return reader_sp;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
void
Debugger::DispatchInputCallback (void *baton, const void *bytes, size_t bytes_len)
{
Add the ability to catch and do the right thing with Interrupts (often control-c) and end-of-file (often control-d). llvm-svn: 119837
2010-11-20 04:47:54 +08:00
if (bytes_len > 0)
((Debugger *)baton)->DispatchInput ((char *)bytes, bytes_len);
else
((Debugger *)baton)->DispatchInputEndOfFile ();
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
void
Debugger::DispatchInput (const char *bytes, size_t bytes_len)
{
Add the ability to catch and do the right thing with Interrupts (often control-c) and end-of-file (often control-d). llvm-svn: 119837
2010-11-20 04:47:54 +08:00
if (bytes == NULL || bytes_len == 0)
return;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
WriteToDefaultReader (bytes, bytes_len);
}
Add the ability to catch and do the right thing with Interrupts (often control-c) and end-of-file (often control-d). llvm-svn: 119837
2010-11-20 04:47:54 +08:00
void
Debugger::DispatchInputInterrupt ()
{
m_input_reader_data.clear();
Add a new function to Debugger for finding the top/current input reader. Always make sure the input reader stack is not empty before trying to get the top element from the stack. llvm-svn: 125255
2011-02-10 09:15:13 +08:00
InputReaderSP reader_sp (GetCurrentInputReader ());
if (reader_sp)
Add the ability to catch and do the right thing with Interrupts (often control-c) and end-of-file (often control-d). llvm-svn: 119837
2010-11-20 04:47:54 +08:00
{
Add a new function to Debugger for finding the top/current input reader. Always make sure the input reader stack is not empty before trying to get the top element from the stack. llvm-svn: 125255
2011-02-10 09:15:13 +08:00
reader_sp->Notify (eInputReaderInterrupt);
Add the ability to catch and do the right thing with Interrupts (often control-c) and end-of-file (often control-d). llvm-svn: 119837
2010-11-20 04:47:54 +08:00
Add a new function to Debugger for finding the top/current input reader. Always make sure the input reader stack is not empty before trying to get the top element from the stack. llvm-svn: 125255
2011-02-10 09:15:13 +08:00
// If notifying the reader of the interrupt finished the reader, we should pop it off the stack.
Add the ability to catch and do the right thing with Interrupts (often control-c) and end-of-file (often control-d). llvm-svn: 119837
2010-11-20 04:47:54 +08:00
while (CheckIfTopInputReaderIsDone ()) ;
}
}
void
Debugger::DispatchInputEndOfFile ()
{
m_input_reader_data.clear();
Add a new function to Debugger for finding the top/current input reader. Always make sure the input reader stack is not empty before trying to get the top element from the stack. llvm-svn: 125255
2011-02-10 09:15:13 +08:00
InputReaderSP reader_sp (GetCurrentInputReader ());
if (reader_sp)
Add the ability to catch and do the right thing with Interrupts (often control-c) and end-of-file (often control-d). llvm-svn: 119837
2010-11-20 04:47:54 +08:00
{
Add a new function to Debugger for finding the top/current input reader. Always make sure the input reader stack is not empty before trying to get the top element from the stack. llvm-svn: 125255
2011-02-10 09:15:13 +08:00
reader_sp->Notify (eInputReaderEndOfFile);
Add the ability to catch and do the right thing with Interrupts (often control-c) and end-of-file (often control-d). llvm-svn: 119837
2010-11-20 04:47:54 +08:00
Add a new function to Debugger for finding the top/current input reader. Always make sure the input reader stack is not empty before trying to get the top element from the stack. llvm-svn: 125255
2011-02-10 09:15:13 +08:00
// If notifying the reader of the end-of-file finished the reader, we should pop it off the stack.
Add the ability to catch and do the right thing with Interrupts (often control-c) and end-of-file (often control-d). llvm-svn: 119837
2010-11-20 04:47:54 +08:00
while (CheckIfTopInputReaderIsDone ()) ;
}
}
Add code to make sure InputReaders finish and are cleaned up when a Debugger object is destroyed or re-set. (Thus making sure that, for example, the Python interpreter finishes and exits cleanly rather than being left in an undefined state.) llvm-svn: 122255
2010-12-21 02:35:50 +08:00
void
Debugger::CleanUpInputReaders ()
{
m_input_reader_data.clear();
Add a new function to Debugger for finding the top/current input reader. Always make sure the input reader stack is not empty before trying to get the top element from the stack. llvm-svn: 125255
2011-02-10 09:15:13 +08:00
// The bottom input reader should be the main debugger input reader. We do not want to close that one here.
Create new class, InputReaderStack, to better handle mutexes around input readers and prevent deadlocking; modify Debugger to use the new class. llvm-svn: 132475
2011-06-03 03:18:55 +08:00
while (m_input_reader_stack.GetSize() > 1)
Add code to make sure InputReaders finish and are cleaned up when a Debugger object is destroyed or re-set. (Thus making sure that, for example, the Python interpreter finishes and exits cleanly rather than being left in an undefined state.) llvm-svn: 122255
2010-12-21 02:35:50 +08:00
{
Add a new function to Debugger for finding the top/current input reader. Always make sure the input reader stack is not empty before trying to get the top element from the stack. llvm-svn: 125255
2011-02-10 09:15:13 +08:00
InputReaderSP reader_sp (GetCurrentInputReader ());
Add code to make sure InputReaders finish and are cleaned up when a Debugger object is destroyed or re-set. (Thus making sure that, for example, the Python interpreter finishes and exits cleanly rather than being left in an undefined state.) llvm-svn: 122255
2010-12-21 02:35:50 +08:00
if (reader_sp)
{
reader_sp->Notify (eInputReaderEndOfFile);
reader_sp->SetIsDone (true);
}
}
}
This patch captures and serializes all output being written by the command line driver, including the lldb prompt being output by editline, the asynchronous process output & error messages, and asynchronous messages written by target stop-hooks. As part of this it introduces a new Stream class, StreamAsynchronousIO. A StreamAsynchronousIO object is created with a broadcaster, who will eventually broadcast the stream's data for a listener to handle, and an event type indicating what type of event the broadcaster will broadcast. When the Write method is called on a StreamAsynchronousIO object, the data is appended to an internal string. When the Flush method is called on a StreamAsynchronousIO object, it broadcasts it's data string and clears the string. Anything in lldb-core that needs to generate asynchronous output for the end-user should use the StreamAsynchronousIO objects. I have also added a new notification type for InputReaders, to let them know that a asynchronous output has been written. This is to allow the input readers to, for example, refresh their prompts and lines, if desired. I added the case statements to all the input readers to catch this notification, but I haven't added any code for handling them yet (except to the IOChannel input reader). llvm-svn: 130721
2011-05-03 04:41:46 +08:00
void
Debugger::NotifyTopInputReader (InputReaderAction notification)
{
InputReaderSP reader_sp (GetCurrentInputReader());
if (reader_sp)
{
reader_sp->Notify (notification);
// Flush out any input readers that are done.
while (CheckIfTopInputReaderIsDone ())
/* Do nothing. */;
}
}
Make sure writing asynchronous output only backs up & overwrites prompt if the IOChannel input reader is the top input reader. llvm-svn: 131110
2011-05-10 07:06:58 +08:00
bool
Adopt the intrusive pointers in: lldb_private::Breakpoint lldb_private::BreakpointLocations lldb_private::BreakpointSite lldb_private::Debugger lldb_private::StackFrame lldb_private::Thread lldb_private::Target llvm-svn: 139985
2011-09-17 16:33:22 +08:00
Debugger::InputReaderIsTopReader (const InputReaderSP& reader_sp)
Make sure writing asynchronous output only backs up & overwrites prompt if the IOChannel input reader is the top input reader. llvm-svn: 131110
2011-05-10 07:06:58 +08:00
{
Add 'batch_mode' to CommandInterpreter. Modify InputReaders to not write output (prompts, instructions,etc.) if the CommandInterpreter is in batch_mode. Also, finish updating InputReaders to write to the asynchronous stream, rather than using the Debugger's output file directly. llvm-svn: 133162
2011-06-17 00:27:19 +08:00
InputReaderSP top_reader_sp (GetCurrentInputReader());
Make sure writing asynchronous output only backs up & overwrites prompt if the IOChannel input reader is the top input reader. llvm-svn: 131110
2011-05-10 07:06:58 +08:00
Add 'batch_mode' to CommandInterpreter. Modify InputReaders to not write output (prompts, instructions,etc.) if the CommandInterpreter is in batch_mode. Also, finish updating InputReaders to write to the asynchronous stream, rather than using the Debugger's output file directly. llvm-svn: 133162
2011-06-17 00:27:19 +08:00
return (reader_sp.get() == top_reader_sp.get());
Make sure writing asynchronous output only backs up & overwrites prompt if the IOChannel input reader is the top input reader. llvm-svn: 131110
2011-05-10 07:06:58 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
void
Debugger::WriteToDefaultReader (const char *bytes, size_t bytes_len)
{
if (bytes && bytes_len)
m_input_reader_data.append (bytes, bytes_len);
if (m_input_reader_data.empty())
return;
Create new class, InputReaderStack, to better handle mutexes around input readers and prevent deadlocking; modify Debugger to use the new class. llvm-svn: 132475
2011-06-03 03:18:55 +08:00
while (!m_input_reader_stack.IsEmpty() && !m_input_reader_data.empty())
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
// Get the input reader from the top of the stack
Add a new function to Debugger for finding the top/current input reader. Always make sure the input reader stack is not empty before trying to get the top element from the stack. llvm-svn: 125255
2011-02-10 09:15:13 +08:00
InputReaderSP reader_sp (GetCurrentInputReader ());
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (!reader_sp)
break;
Remove use of STL collection class use of the "data()" method since it isn't part of C++'98. Most of these were "std::vector<T>::data()" and "std::string::data()". llvm-svn: 108957
2010-07-21 06:52:08 +08:00
size_t bytes_handled = reader_sp->HandleRawBytes (m_input_reader_data.c_str(),
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
m_input_reader_data.size());
if (bytes_handled)
{
m_input_reader_data.erase (0, bytes_handled);
}
else
{
// No bytes were handled, we might not have reached our
// granularity, just return and wait for more data
break;
}
}
Add a new function to Debugger for finding the top/current input reader. Always make sure the input reader stack is not empty before trying to get the top element from the stack. llvm-svn: 125255
2011-02-10 09:15:13 +08:00
// Flush out any input readers that are done.
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
while (CheckIfTopInputReaderIsDone ())
/* Do nothing. */;
}
void
Debugger::PushInputReader (const InputReaderSP& reader_sp)
{
if (!reader_sp)
return;
Add a new function to Debugger for finding the top/current input reader. Always make sure the input reader stack is not empty before trying to get the top element from the stack. llvm-svn: 125255
2011-02-10 09:15:13 +08:00
// Deactivate the old top reader
InputReaderSP top_reader_sp (GetCurrentInputReader ());
if (top_reader_sp)
top_reader_sp->Notify (eInputReaderDeactivate);
Create new class, InputReaderStack, to better handle mutexes around input readers and prevent deadlocking; modify Debugger to use the new class. llvm-svn: 132475
2011-06-03 03:18:55 +08:00
m_input_reader_stack.Push (reader_sp);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
reader_sp->Notify (eInputReaderActivate);
ActivateInputReader (reader_sp);
}
bool
Adopt the intrusive pointers in: lldb_private::Breakpoint lldb_private::BreakpointLocations lldb_private::BreakpointSite lldb_private::Debugger lldb_private::StackFrame lldb_private::Thread lldb_private::Target llvm-svn: 139985
2011-09-17 16:33:22 +08:00
Debugger::PopInputReader (const InputReaderSP& pop_reader_sp)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
bool result = false;
// The reader on the stop of the stack is done, so let the next
// read on the stack referesh its prompt and if there is one...
Create new class, InputReaderStack, to better handle mutexes around input readers and prevent deadlocking; modify Debugger to use the new class. llvm-svn: 132475
2011-06-03 03:18:55 +08:00
if (!m_input_reader_stack.IsEmpty())
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Add a new function to Debugger for finding the top/current input reader. Always make sure the input reader stack is not empty before trying to get the top element from the stack. llvm-svn: 125255
2011-02-10 09:15:13 +08:00
// Cannot call GetCurrentInputReader here, as that would cause an infinite loop.
Create new class, InputReaderStack, to better handle mutexes around input readers and prevent deadlocking; modify Debugger to use the new class. llvm-svn: 132475
2011-06-03 03:18:55 +08:00
InputReaderSP reader_sp(m_input_reader_stack.Top());
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (!pop_reader_sp || pop_reader_sp.get() == reader_sp.get())
{
Create new class, InputReaderStack, to better handle mutexes around input readers and prevent deadlocking; modify Debugger to use the new class. llvm-svn: 132475
2011-06-03 03:18:55 +08:00
m_input_reader_stack.Pop ();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
reader_sp->Notify (eInputReaderDeactivate);
reader_sp->Notify (eInputReaderDone);
result = true;
Create new class, InputReaderStack, to better handle mutexes around input readers and prevent deadlocking; modify Debugger to use the new class. llvm-svn: 132475
2011-06-03 03:18:55 +08:00
if (!m_input_reader_stack.IsEmpty())
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Create new class, InputReaderStack, to better handle mutexes around input readers and prevent deadlocking; modify Debugger to use the new class. llvm-svn: 132475
2011-06-03 03:18:55 +08:00
reader_sp = m_input_reader_stack.Top();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (reader_sp)
{
ActivateInputReader (reader_sp);
reader_sp->Notify (eInputReaderReactivate);
}
}
}
}
return result;
}
bool
Debugger::CheckIfTopInputReaderIsDone ()
{
bool result = false;
Create new class, InputReaderStack, to better handle mutexes around input readers and prevent deadlocking; modify Debugger to use the new class. llvm-svn: 132475
2011-06-03 03:18:55 +08:00
if (!m_input_reader_stack.IsEmpty())
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Add a new function to Debugger for finding the top/current input reader. Always make sure the input reader stack is not empty before trying to get the top element from the stack. llvm-svn: 125255
2011-02-10 09:15:13 +08:00
// Cannot call GetCurrentInputReader here, as that would cause an infinite loop.
Create new class, InputReaderStack, to better handle mutexes around input readers and prevent deadlocking; modify Debugger to use the new class. llvm-svn: 132475
2011-06-03 03:18:55 +08:00
InputReaderSP reader_sp(m_input_reader_stack.Top());
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (reader_sp && reader_sp->IsDone())
{
result = true;
PopInputReader (reader_sp);
}
}
return result;
}
void
Debugger::ActivateInputReader (const InputReaderSP &reader_sp)
{
Use Host::File in lldb_private::StreamFile and other places to cleanup host layer a bit more. llvm-svn: 125149
2011-02-09 09:08:52 +08:00
int input_fd = m_input_file.GetFile().GetDescriptor();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Use Host::File in lldb_private::StreamFile and other places to cleanup host layer a bit more. llvm-svn: 125149
2011-02-09 09:08:52 +08:00
if (input_fd >= 0)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Use Host::File in lldb_private::StreamFile and other places to cleanup host layer a bit more. llvm-svn: 125149
2011-02-09 09:08:52 +08:00
Terminal tty(input_fd);
Abtract terminal stuff into a new lldb_private::Terminal class where the implementation is hidden in the host layer. This avoids a slew of "#if LLDB_CONFIG_TERMIOS_SUPPORTED" statements in the code and keeps things cleaner. llvm-svn: 125057
2011-02-08 07:24:47 +08:00
tty.SetEcho(reader_sp->GetEcho());
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Abtract terminal stuff into a new lldb_private::Terminal class where the implementation is hidden in the host layer. This avoids a slew of "#if LLDB_CONFIG_TERMIOS_SUPPORTED" statements in the code and keeps things cleaner. llvm-svn: 125057
2011-02-08 07:24:47 +08:00
switch (reader_sp->GetGranularity())
{
case eInputReaderGranularityByte:
case eInputReaderGranularityWord:
tty.SetCanonical (false);
break;
case eInputReaderGranularityLine:
case eInputReaderGranularityAll:
tty.SetCanonical (true);
break;
default:
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
}
}
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
2010-06-23 09:19:29 +08:00
Added Debugger::GetAsync{Output/Error}Stream, and use it to print parse errors when we go to run a breakpoint condition. llvm-svn: 132517
2011-06-03 07:58:26 +08:00
StreamSP
Debugger::GetAsyncOutputStream ()
{
return StreamSP (new StreamAsynchronousIO (GetCommandInterpreter(),
CommandInterpreter::eBroadcastBitAsynchronousOutputData));
}
StreamSP
Debugger::GetAsyncErrorStream ()
{
return StreamSP (new StreamAsynchronousIO (GetCommandInterpreter(),
CommandInterpreter::eBroadcastBitAsynchronousErrorData));
}
<rdar://problem/10062621> New public API for handling formatters: creating, deleting, modifying categories, and formatters, and managing type/formatter association. This provides SB classes for each of the main object types involved in providing formatter support: SBTypeCategory SBTypeFilter SBTypeFormat SBTypeSummary SBTypeSynthetic plus, an SBTypeNameSpecifier class that is used on the public API layer to abstract the notion that formatters can be applied to plain type-names as well as to regular expressions For naming consistency, this patch also renames a lot of formatters-related classes. Plus, the changes in how flags are handled that started with summaries is now extended to other classes as well. A new enum (lldb::eTypeOption) is meant to support this on the public side. The patch also adds several new calls to the formatter infrastructure that are used to implement by-index accessing and several other design changes required to accommodate the new API layer. An architectural change is introduced in that backing objects for formatters now become writable. On the public API layer, CoW is implemented to prevent unwanted propagation of changes. Lastly, there are some modifications in how the "default" category is constructed and managed in relation to other categories. llvm-svn: 150558
2012-02-15 10:34:21 +08:00
uint32_t
Debugger::GetNumDebuggers()
{
<rdar://problem/11148044> Fixed a potential crasher that could happen after Debugger::Terminate() was called. llvm-svn: 153774
2012-03-31 04:53:46 +08:00
if (g_shared_debugger_refcount > 0)
{
Mutex::Locker locker (GetDebuggerListMutex ());
return GetDebuggerList().size();
}
return 0;
<rdar://problem/10062621> New public API for handling formatters: creating, deleting, modifying categories, and formatters, and managing type/formatter association. This provides SB classes for each of the main object types involved in providing formatter support: SBTypeCategory SBTypeFilter SBTypeFormat SBTypeSummary SBTypeSynthetic plus, an SBTypeNameSpecifier class that is used on the public API layer to abstract the notion that formatters can be applied to plain type-names as well as to regular expressions For naming consistency, this patch also renames a lot of formatters-related classes. Plus, the changes in how flags are handled that started with summaries is now extended to other classes as well. A new enum (lldb::eTypeOption) is meant to support this on the public side. The patch also adds several new calls to the formatter infrastructure that are used to implement by-index accessing and several other design changes required to accommodate the new API layer. An architectural change is introduced in that backing objects for formatters now become writable. On the public API layer, CoW is implemented to prevent unwanted propagation of changes. Lastly, there are some modifications in how the "default" category is constructed and managed in relation to other categories. llvm-svn: 150558
2012-02-15 10:34:21 +08:00
}
lldb::DebuggerSP
Debugger::GetDebuggerAtIndex (uint32_t index)
{
DebuggerSP debugger_sp;
<rdar://problem/11148044> Fixed a potential crasher that could happen after Debugger::Terminate() was called. llvm-svn: 153774
2012-03-31 04:53:46 +08:00
if (g_shared_debugger_refcount > 0)
{
Mutex::Locker locker (GetDebuggerListMutex ());
DebuggerList &debugger_list = GetDebuggerList();
<rdar://problem/10062621> New public API for handling formatters: creating, deleting, modifying categories, and formatters, and managing type/formatter association. This provides SB classes for each of the main object types involved in providing formatter support: SBTypeCategory SBTypeFilter SBTypeFormat SBTypeSummary SBTypeSynthetic plus, an SBTypeNameSpecifier class that is used on the public API layer to abstract the notion that formatters can be applied to plain type-names as well as to regular expressions For naming consistency, this patch also renames a lot of formatters-related classes. Plus, the changes in how flags are handled that started with summaries is now extended to other classes as well. A new enum (lldb::eTypeOption) is meant to support this on the public side. The patch also adds several new calls to the formatter infrastructure that are used to implement by-index accessing and several other design changes required to accommodate the new API layer. An architectural change is introduced in that backing objects for formatters now become writable. On the public API layer, CoW is implemented to prevent unwanted propagation of changes. Lastly, there are some modifications in how the "default" category is constructed and managed in relation to other categories. llvm-svn: 150558
2012-02-15 10:34:21 +08:00
<rdar://problem/11148044> Fixed a potential crasher that could happen after Debugger::Terminate() was called. llvm-svn: 153774
2012-03-31 04:53:46 +08:00
if (index < debugger_list.size())
debugger_sp = debugger_list[index];
}
<rdar://problem/10062621> New public API for handling formatters: creating, deleting, modifying categories, and formatters, and managing type/formatter association. This provides SB classes for each of the main object types involved in providing formatter support: SBTypeCategory SBTypeFilter SBTypeFormat SBTypeSummary SBTypeSynthetic plus, an SBTypeNameSpecifier class that is used on the public API layer to abstract the notion that formatters can be applied to plain type-names as well as to regular expressions For naming consistency, this patch also renames a lot of formatters-related classes. Plus, the changes in how flags are handled that started with summaries is now extended to other classes as well. A new enum (lldb::eTypeOption) is meant to support this on the public side. The patch also adds several new calls to the formatter infrastructure that are used to implement by-index accessing and several other design changes required to accommodate the new API layer. An architectural change is introduced in that backing objects for formatters now become writable. On the public API layer, CoW is implemented to prevent unwanted propagation of changes. Lastly, there are some modifications in how the "default" category is constructed and managed in relation to other categories. llvm-svn: 150558
2012-02-15 10:34:21 +08:00
return debugger_sp;
}
Add a unique ID to each debugger instance. Add functions to look up debugger by id Add global variable to lldb python module, to hold debugger id Modify embedded Python interpreter to update the global variable with the id of its current debugger. Modify the char ** typemap definition in lldb.swig to accept 'None' (for NULL) as a valid value. The point of all this is so that, when you drop into the embedded interpreter from the command interpreter (or when doing Python-based breakpoint commands), there is a way for the Python side to find/get the correct debugger instance ( by checking debugger_unique_id, then calling SBDebugger::FindDebuggerWithID on it). llvm-svn: 107287
2010-07-01 00:22:25 +08:00
DebuggerSP
Debugger::FindDebuggerWithID (lldb::user_id_t id)
{
Adopt the intrusive pointers in: lldb_private::Breakpoint lldb_private::BreakpointLocations lldb_private::BreakpointSite lldb_private::Debugger lldb_private::StackFrame lldb_private::Thread lldb_private::Target llvm-svn: 139985
2011-09-17 16:33:22 +08:00
DebuggerSP debugger_sp;
Add a unique ID to each debugger instance. Add functions to look up debugger by id Add global variable to lldb python module, to hold debugger id Modify embedded Python interpreter to update the global variable with the id of its current debugger. Modify the char ** typemap definition in lldb.swig to accept 'None' (for NULL) as a valid value. The point of all this is so that, when you drop into the embedded interpreter from the command interpreter (or when doing Python-based breakpoint commands), there is a way for the Python side to find/get the correct debugger instance ( by checking debugger_unique_id, then calling SBDebugger::FindDebuggerWithID on it). llvm-svn: 107287
2010-07-01 00:22:25 +08:00
<rdar://problem/11148044> Fixed a potential crasher that could happen after Debugger::Terminate() was called. llvm-svn: 153774
2012-03-31 04:53:46 +08:00
if (g_shared_debugger_refcount > 0)
Add a unique ID to each debugger instance. Add functions to look up debugger by id Add global variable to lldb python module, to hold debugger id Modify embedded Python interpreter to update the global variable with the id of its current debugger. Modify the char ** typemap definition in lldb.swig to accept 'None' (for NULL) as a valid value. The point of all this is so that, when you drop into the embedded interpreter from the command interpreter (or when doing Python-based breakpoint commands), there is a way for the Python side to find/get the correct debugger instance ( by checking debugger_unique_id, then calling SBDebugger::FindDebuggerWithID on it). llvm-svn: 107287
2010-07-01 00:22:25 +08:00
{
<rdar://problem/11148044> Fixed a potential crasher that could happen after Debugger::Terminate() was called. llvm-svn: 153774
2012-03-31 04:53:46 +08:00
Mutex::Locker locker (GetDebuggerListMutex ());
DebuggerList &debugger_list = GetDebuggerList();
DebuggerList::iterator pos, end = debugger_list.end();
for (pos = debugger_list.begin(); pos != end; ++pos)
Add a unique ID to each debugger instance. Add functions to look up debugger by id Add global variable to lldb python module, to hold debugger id Modify embedded Python interpreter to update the global variable with the id of its current debugger. Modify the char ** typemap definition in lldb.swig to accept 'None' (for NULL) as a valid value. The point of all this is so that, when you drop into the embedded interpreter from the command interpreter (or when doing Python-based breakpoint commands), there is a way for the Python side to find/get the correct debugger instance ( by checking debugger_unique_id, then calling SBDebugger::FindDebuggerWithID on it). llvm-svn: 107287
2010-07-01 00:22:25 +08:00
{
<rdar://problem/11148044> Fixed a potential crasher that could happen after Debugger::Terminate() was called. llvm-svn: 153774
2012-03-31 04:53:46 +08:00
if ((*pos).get()->GetID() == id)
{
debugger_sp = *pos;
break;
}
Add a unique ID to each debugger instance. Add functions to look up debugger by id Add global variable to lldb python module, to hold debugger id Modify embedded Python interpreter to update the global variable with the id of its current debugger. Modify the char ** typemap definition in lldb.swig to accept 'None' (for NULL) as a valid value. The point of all this is so that, when you drop into the embedded interpreter from the command interpreter (or when doing Python-based breakpoint commands), there is a way for the Python side to find/get the correct debugger instance ( by checking debugger_unique_id, then calling SBDebugger::FindDebuggerWithID on it). llvm-svn: 107287
2010-07-01 00:22:25 +08:00
}
}
return debugger_sp;
}
This is a very large commit that completely re-does the way lldb handles user settable internal variables (the equivalent of set/show variables in gdb). In addition to the basic infrastructure (most of which is defined in UserSettingsController.{h,cpp}, there are examples of two classes that have been set up to contain user settable variables (the Debugger and Process classes). The 'settings' command has been modified to be a command-subcommand structure, and the 'set', 'show' and 'append' commands have been moved into this sub-commabnd structure. The old StateVariable class has been completely replaced by this, and the state variable dictionary has been removed from the Command Interpreter. Places that formerly accessed the state variable mechanism have been modified to access the variables in this new structure instead (checking the term-width; getting/checking the prompt; etc.) Variables are attached to classes; there are two basic "flavors" of variables that can be set: "global" variables (static/class-wide), and "instance" variables (one per instance of the class). The whole thing has been set up so that any global or instance variable can be set at any time (e.g. on start up, in your .lldbinit file), whether or not any instances actually exist (there's a whole pending and default values mechanism to help deal with that). llvm-svn: 113041
2010-09-04 08:03:46 +08:00
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
static void
TestPromptFormats (StackFrame *frame)
{
if (frame == NULL)
return;
StreamString s;
const char *prompt_format =
"{addr = '${addr}'\n}"
"{process.id = '${process.id}'\n}"
"{process.name = '${process.name}'\n}"
"{process.file.basename = '${process.file.basename}'\n}"
"{process.file.fullpath = '${process.file.fullpath}'\n}"
"{thread.id = '${thread.id}'\n}"
"{thread.index = '${thread.index}'\n}"
"{thread.name = '${thread.name}'\n}"
"{thread.queue = '${thread.queue}'\n}"
"{thread.stop-reason = '${thread.stop-reason}'\n}"
"{target.arch = '${target.arch}'\n}"
"{module.file.basename = '${module.file.basename}'\n}"
"{module.file.fullpath = '${module.file.fullpath}'\n}"
"{file.basename = '${file.basename}'\n}"
"{file.fullpath = '${file.fullpath}'\n}"
"{frame.index = '${frame.index}'\n}"
"{frame.pc = '${frame.pc}'\n}"
"{frame.sp = '${frame.sp}'\n}"
"{frame.fp = '${frame.fp}'\n}"
"{frame.flags = '${frame.flags}'\n}"
"{frame.reg.rdi = '${frame.reg.rdi}'\n}"
"{frame.reg.rip = '${frame.reg.rip}'\n}"
"{frame.reg.rsp = '${frame.reg.rsp}'\n}"
"{frame.reg.rbp = '${frame.reg.rbp}'\n}"
"{frame.reg.rflags = '${frame.reg.rflags}'\n}"
"{frame.reg.xmm0 = '${frame.reg.xmm0}'\n}"
"{frame.reg.carp = '${frame.reg.carp}'\n}"
"{function.id = '${function.id}'\n}"
"{function.name = '${function.name}'\n}"
<rdar://problem/10684141> When the lldb_private::Debugger goes away, it should cleanup all of its targets. llvm-svn: 148189
2012-01-15 01:04:19 +08:00
"{function.name-with-args = '${function.name-with-args}'\n}"
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
"{function.addr-offset = '${function.addr-offset}'\n}"
"{function.line-offset = '${function.line-offset}'\n}"
"{function.pc-offset = '${function.pc-offset}'\n}"
"{line.file.basename = '${line.file.basename}'\n}"
"{line.file.fullpath = '${line.file.fullpath}'\n}"
"{line.number = '${line.number}'\n}"
"{line.start-addr = '${line.start-addr}'\n}"
"{line.end-addr = '${line.end-addr}'\n}"
;
SymbolContext sc (frame->GetSymbolContext(eSymbolContextEverything));
ExecutionContext exe_ctx;
There are now to new "settings set" variables that live in each debugger instance: settings set frame-format <string> settings set thread-format <string> This allows users to control the information that is seen when dumping threads and frames. The default values are set such that they do what they used to do prior to changing over the the user defined formats. This allows users with terminals that can display color to make different items different colors using the escape control codes. A few alias examples that will colorize your thread and frame prompts are: settings set frame-format 'frame #${frame.index}: \033[0;33m${frame.pc}\033[0m{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{ \033[0;35mat \033[1;35m${line.file.basename}:${line.number}}\033[0m\n' settings set thread-format 'thread #${thread.index}: \033[1;33mtid\033[0;33m = ${thread.id}\033[0m{, \033[0;33m${frame.pc}\033[0m}{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{, \033[1;35mstop reason\033[0;35m = ${thread.stop-reason}\033[0m}{, \033[1;36mname = \033[0;36m${thread.name}\033[0m}{, \033[1;32mqueue = \033[0;32m${thread.queue}}\033[0m\n' A quick web search for "colorize terminal output" should allow you to see what you can do to make your output look like you want it. The "settings set" commands above can of course be added to your ~/.lldbinit file for permanent use. Changed the pure virtual void ExecutionContextScope::Calculate (ExecutionContext&); To: void ExecutionContextScope::CalculateExecutionContext (ExecutionContext&); I did this because this is a class that anything in the execution context heirarchy inherits from and "target->Calculate (exe_ctx)" didn't always tell you what it was really trying to do unless you look at the parameter. llvm-svn: 115485
2010-10-04 09:05:56 +08:00
frame->CalculateExecutionContext(exe_ctx);
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
const char *end = NULL;
if (Debugger::FormatPrompt (prompt_format, &sc, &exe_ctx, &sc.line_entry.range.GetBaseAddress(), s, &end))
{
printf("%s\n", s.GetData());
}
else
{
printf ("error: at '%s'\n", end);
printf ("what we got: %s\n", s.GetData());
}
}
new syntax for summary strings: - ${*expr} now simply means to dereference expr before actually using it - bitfields, array ranges and pointer ranges now work in a (hopefully) more natural and language-compliant way a new class TypeHierarchyNavigator replicates the behavior of the FormatManager in going through type hierarchies when one-lining summary strings, children's summaries can be used as well as values llvm-svn: 134458
2011-07-06 10:13:41 +08:00
static bool
Additional code cleanups ; Short option name for --python-script in type summary add moved from -s to -o (this is a preliminary step in moving the short option for --summary-string from -f to -s) ; Accordingly updated the test suite llvm-svn: 138315
2011-08-23 08:32:52 +08:00
ScanFormatDescriptor (const char* var_name_begin,
const char* var_name_end,
const char** var_name_final,
const char** percent_position,
Adopt the intrusive pointers in: lldb_private::Breakpoint lldb_private::BreakpointLocations lldb_private::BreakpointSite lldb_private::Debugger lldb_private::StackFrame lldb_private::Thread lldb_private::Target llvm-svn: 139985
2011-09-17 16:33:22 +08:00
Format* custom_format,
Additional code cleanups ; Short option name for --python-script in type summary add moved from -s to -o (this is a preliminary step in moving the short option for --summary-string from -f to -s) ; Accordingly updated the test suite llvm-svn: 138315
2011-08-23 08:32:52 +08:00
ValueObject::ValueObjectRepresentationStyle* val_obj_display)
new syntax for summary strings: - ${*expr} now simply means to dereference expr before actually using it - bitfields, array ranges and pointer ranges now work in a (hopefully) more natural and language-compliant way a new class TypeHierarchyNavigator replicates the behavior of the FormatManager in going through type hierarchies when one-lining summary strings, children's summaries can be used as well as values llvm-svn: 134458
2011-07-06 10:13:41 +08:00
{
some editing of data visualization error messages to make them more meaningful debugging printfs() for data visualization turned into a meaningful log: - introduced a new log category `types' in channel `lldb' llvm-svn: 135773
2011-07-23 01:03:19 +08:00
LogSP log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_TYPES));
new syntax for summary strings: - ${*expr} now simply means to dereference expr before actually using it - bitfields, array ranges and pointer ranges now work in a (hopefully) more natural and language-compliant way a new class TypeHierarchyNavigator replicates the behavior of the FormatManager in going through type hierarchies when one-lining summary strings, children's summaries can be used as well as values llvm-svn: 134458
2011-07-06 10:13:41 +08:00
*percent_position = ::strchr(var_name_begin,'%');
Fixed some issues with ARM backtraces by not processing any push/pop instructions if they are conditional. Also fixed issues where the PC wasn't getting bit zero stripped for ARM targets when a stack frame was thumb. We now properly call through the GetOpcodeLoadAddress() functions to make sure the addresses are properly stripped for any targets that may decorate up their addresses. We now don't pass the SIGSTOP signals along. We can revisit this soon, but currently this was interfering with debugging some older ARM targets that don't have vCont support in the GDB server. llvm-svn: 134461
2011-07-06 12:07:21 +08:00
if (!*percent_position || *percent_position > var_name_end)
some editing of data visualization error messages to make them more meaningful debugging printfs() for data visualization turned into a meaningful log: - introduced a new log category `types' in channel `lldb' llvm-svn: 135773
2011-07-23 01:03:19 +08:00
{
if (log)
log->Printf("no format descriptor in string, skipping");
new syntax for summary strings: - ${*expr} now simply means to dereference expr before actually using it - bitfields, array ranges and pointer ranges now work in a (hopefully) more natural and language-compliant way a new class TypeHierarchyNavigator replicates the behavior of the FormatManager in going through type hierarchies when one-lining summary strings, children's summaries can be used as well as values llvm-svn: 134458
2011-07-06 10:13:41 +08:00
*var_name_final = var_name_end;
some editing of data visualization error messages to make them more meaningful debugging printfs() for data visualization turned into a meaningful log: - introduced a new log category `types' in channel `lldb' llvm-svn: 135773
2011-07-23 01:03:19 +08:00
}
new syntax for summary strings: - ${*expr} now simply means to dereference expr before actually using it - bitfields, array ranges and pointer ranges now work in a (hopefully) more natural and language-compliant way a new class TypeHierarchyNavigator replicates the behavior of the FormatManager in going through type hierarchies when one-lining summary strings, children's summaries can be used as well as values llvm-svn: 134458
2011-07-06 10:13:41 +08:00
else
{
*var_name_final = *percent_position;
char* format_name = new char[var_name_end-*var_name_final]; format_name[var_name_end-*var_name_final-1] = '\0';
memcpy(format_name, *var_name_final+1, var_name_end-*var_name_final-1);
some editing of data visualization error messages to make them more meaningful debugging printfs() for data visualization turned into a meaningful log: - introduced a new log category `types' in channel `lldb' llvm-svn: 135773
2011-07-23 01:03:19 +08:00
if (log)
log->Printf("parsing %s as a format descriptor", format_name);
new syntax for summary strings: - ${*expr} now simply means to dereference expr before actually using it - bitfields, array ranges and pointer ranges now work in a (hopefully) more natural and language-compliant way a new class TypeHierarchyNavigator replicates the behavior of the FormatManager in going through type hierarchies when one-lining summary strings, children's summaries can be used as well as values llvm-svn: 134458
2011-07-06 10:13:41 +08:00
if ( !FormatManager::GetFormatFromCString(format_name,
true,
*custom_format) )
{
some editing of data visualization error messages to make them more meaningful debugging printfs() for data visualization turned into a meaningful log: - introduced a new log category `types' in channel `lldb' llvm-svn: 135773
2011-07-23 01:03:19 +08:00
if (log)
log->Printf("%s is an unknown format", format_name);
new syntax for summary strings: - ${*expr} now simply means to dereference expr before actually using it - bitfields, array ranges and pointer ranges now work in a (hopefully) more natural and language-compliant way a new class TypeHierarchyNavigator replicates the behavior of the FormatManager in going through type hierarchies when one-lining summary strings, children's summaries can be used as well as values llvm-svn: 134458
2011-07-06 10:13:41 +08:00
// if this is an @ sign, print ObjC description
Fixed some issues with ARM backtraces by not processing any push/pop instructions if they are conditional. Also fixed issues where the PC wasn't getting bit zero stripped for ARM targets when a stack frame was thumb. We now properly call through the GetOpcodeLoadAddress() functions to make sure the addresses are properly stripped for any targets that may decorate up their addresses. We now don't pass the SIGSTOP signals along. We can revisit this soon, but currently this was interfering with debugging some older ARM targets that don't have vCont support in the GDB server. llvm-svn: 134461
2011-07-06 12:07:21 +08:00
if (*format_name == '@')
Massive enumeration name changes: a number of enums in ValueObject were not following the naming pattern Changes to synthetic children: - the update(self): function can now (optionally) return a value - if it returns boolean value True, ValueObjectSyntheticFilter will not clear its caches across stop-points this should allow better performance for Python-based synthetic children when one can be sure that the child ValueObjects have not changed - making a difference between a synthetic VO and a VO with a synthetic value: now a ValueObjectSyntheticFilter will not return itself as its own synthetic value, but will (correctly) claim to itself be synthetic - cleared up the internal synthetic children architecture to make a more consistent use of pointers and references instead of shared pointers when possible - major cleanup of unnecessary #include, data and functions in ValueObjectSyntheticFilter itself - removed the SyntheticValueType enum and replaced it with a plain boolean (to which it was equivalent in the first place) Some clean ups to the summary generation code Centralized the code that clears out user-visible strings and data in ValueObject More efficient summaries for libc++ containers llvm-svn: 153061
2012-03-20 06:58:49 +08:00
*val_obj_display = ValueObject::eValueObjectRepresentationStyleLanguageSpecific;
new syntax for summary strings: - ${*expr} now simply means to dereference expr before actually using it - bitfields, array ranges and pointer ranges now work in a (hopefully) more natural and language-compliant way a new class TypeHierarchyNavigator replicates the behavior of the FormatManager in going through type hierarchies when one-lining summary strings, children's summaries can be used as well as values llvm-svn: 134458
2011-07-06 10:13:41 +08:00
// if this is a V, print the value using the default format
some editing of data visualization error messages to make them more meaningful debugging printfs() for data visualization turned into a meaningful log: - introduced a new log category `types' in channel `lldb' llvm-svn: 135773
2011-07-23 01:03:19 +08:00
else if (*format_name == 'V')
Massive enumeration name changes: a number of enums in ValueObject were not following the naming pattern Changes to synthetic children: - the update(self): function can now (optionally) return a value - if it returns boolean value True, ValueObjectSyntheticFilter will not clear its caches across stop-points this should allow better performance for Python-based synthetic children when one can be sure that the child ValueObjects have not changed - making a difference between a synthetic VO and a VO with a synthetic value: now a ValueObjectSyntheticFilter will not return itself as its own synthetic value, but will (correctly) claim to itself be synthetic - cleared up the internal synthetic children architecture to make a more consistent use of pointers and references instead of shared pointers when possible - major cleanup of unnecessary #include, data and functions in ValueObjectSyntheticFilter itself - removed the SyntheticValueType enum and replaced it with a plain boolean (to which it was equivalent in the first place) Some clean ups to the summary generation code Centralized the code that clears out user-visible strings and data in ValueObject More efficient summaries for libc++ containers llvm-svn: 153061
2012-03-20 06:58:49 +08:00
*val_obj_display = ValueObject::eValueObjectRepresentationStyleValue;
when typing a summary string you can use the %S symbol to explicitly indicate that you want the summary to be used to print the target object (e.g. ${var%S}). this might already be the default if your variable is of an aggregate type new feature: synthetic filters. you can restrict the number of children for your variables to only a meaningful subset - the restricted list of children obeys the typical rules (e.g. summaries prevail over children) - one-line summaries show only the filtered (synthetic) children, if you type an expanded summary string, or you use Python scripts, all the real children are accessible - to provide a synthetic children list use the "type synth add" command, as in: type synth add foo_type --child varA --child varB[0] --child varC->packet->flags[1-4] (you can use ., ->, single-item array operator [N] and bitfield operator [N-M]; array slice access is not supported, giving simplified names to expression paths is not supported) - a new -S option to frame variable and target variable lets you override synthetic children and instead show real ones llvm-svn: 135731
2011-07-22 08:16:08 +08:00
// if this is an L, print the location of the value
some editing of data visualization error messages to make them more meaningful debugging printfs() for data visualization turned into a meaningful log: - introduced a new log category `types' in channel `lldb' llvm-svn: 135773
2011-07-23 01:03:19 +08:00
else if (*format_name == 'L')
Massive enumeration name changes: a number of enums in ValueObject were not following the naming pattern Changes to synthetic children: - the update(self): function can now (optionally) return a value - if it returns boolean value True, ValueObjectSyntheticFilter will not clear its caches across stop-points this should allow better performance for Python-based synthetic children when one can be sure that the child ValueObjects have not changed - making a difference between a synthetic VO and a VO with a synthetic value: now a ValueObjectSyntheticFilter will not return itself as its own synthetic value, but will (correctly) claim to itself be synthetic - cleared up the internal synthetic children architecture to make a more consistent use of pointers and references instead of shared pointers when possible - major cleanup of unnecessary #include, data and functions in ValueObjectSyntheticFilter itself - removed the SyntheticValueType enum and replaced it with a plain boolean (to which it was equivalent in the first place) Some clean ups to the summary generation code Centralized the code that clears out user-visible strings and data in ValueObject More efficient summaries for libc++ containers llvm-svn: 153061
2012-03-20 06:58:49 +08:00
*val_obj_display = ValueObject::eValueObjectRepresentationStyleLocation;
when typing a summary string you can use the %S symbol to explicitly indicate that you want the summary to be used to print the target object (e.g. ${var%S}). this might already be the default if your variable is of an aggregate type new feature: synthetic filters. you can restrict the number of children for your variables to only a meaningful subset - the restricted list of children obeys the typical rules (e.g. summaries prevail over children) - one-line summaries show only the filtered (synthetic) children, if you type an expanded summary string, or you use Python scripts, all the real children are accessible - to provide a synthetic children list use the "type synth add" command, as in: type synth add foo_type --child varA --child varB[0] --child varC->packet->flags[1-4] (you can use ., ->, single-item array operator [N] and bitfield operator [N-M]; array slice access is not supported, giving simplified names to expression paths is not supported) - a new -S option to frame variable and target variable lets you override synthetic children and instead show real ones llvm-svn: 135731
2011-07-22 08:16:08 +08:00
// if this is an S, print the summary after all
some editing of data visualization error messages to make them more meaningful debugging printfs() for data visualization turned into a meaningful log: - introduced a new log category `types' in channel `lldb' llvm-svn: 135773
2011-07-23 01:03:19 +08:00
else if (*format_name == 'S')
Massive enumeration name changes: a number of enums in ValueObject were not following the naming pattern Changes to synthetic children: - the update(self): function can now (optionally) return a value - if it returns boolean value True, ValueObjectSyntheticFilter will not clear its caches across stop-points this should allow better performance for Python-based synthetic children when one can be sure that the child ValueObjects have not changed - making a difference between a synthetic VO and a VO with a synthetic value: now a ValueObjectSyntheticFilter will not return itself as its own synthetic value, but will (correctly) claim to itself be synthetic - cleared up the internal synthetic children architecture to make a more consistent use of pointers and references instead of shared pointers when possible - major cleanup of unnecessary #include, data and functions in ValueObjectSyntheticFilter itself - removed the SyntheticValueType enum and replaced it with a plain boolean (to which it was equivalent in the first place) Some clean ups to the summary generation code Centralized the code that clears out user-visible strings and data in ValueObject More efficient summaries for libc++ containers llvm-svn: 153061
2012-03-20 06:58:49 +08:00
*val_obj_display = ValueObject::eValueObjectRepresentationStyleSummary;
New formatting symbol %# can be used in summary strings to get the "count of children" of a variable - accordingly, the test cases for the synthetic providers for the std:: containers have been edited to use ${svar%#} instead of ${svar.len} to print out the count of elements ; the .len synthetic child has been removed from the synthetic providers The synthetic children providers for the std:: containers now return None when asked for children indexes >= num_children() Basic code to support filter names based on regular expressions (WIP) llvm-svn: 136862
2011-08-04 10:34:29 +08:00
else if (*format_name == '#')
Massive enumeration name changes: a number of enums in ValueObject were not following the naming pattern Changes to synthetic children: - the update(self): function can now (optionally) return a value - if it returns boolean value True, ValueObjectSyntheticFilter will not clear its caches across stop-points this should allow better performance for Python-based synthetic children when one can be sure that the child ValueObjects have not changed - making a difference between a synthetic VO and a VO with a synthetic value: now a ValueObjectSyntheticFilter will not return itself as its own synthetic value, but will (correctly) claim to itself be synthetic - cleared up the internal synthetic children architecture to make a more consistent use of pointers and references instead of shared pointers when possible - major cleanup of unnecessary #include, data and functions in ValueObjectSyntheticFilter itself - removed the SyntheticValueType enum and replaced it with a plain boolean (to which it was equivalent in the first place) Some clean ups to the summary generation code Centralized the code that clears out user-visible strings and data in ValueObject More efficient summaries for libc++ containers llvm-svn: 153061
2012-03-20 06:58:49 +08:00
*val_obj_display = ValueObject::eValueObjectRepresentationStyleChildrenCount;
- Now using ${var} as the summary for an aggregate type will produce "name-of-type @ object-location" instead of giving an error e.g. you may get "foo_class @ 0x123456" when typing "type summary add -f ${var} foo_class" - Added a new special formatting token %T for summaries. This shows the type of the object. Using it, the new "type @ location" summary could be manually generated by writing ${var%T} @ ${var%L} - Bits and pieces required to support "frame variable array[n-m]" The feature is not enabled yet because some additional design and support code is required, but the basics are getting there - Fixed a potential issue where a ValueObjectSyntheticFilter was not holding on to its SyntheticChildrenSP Because of the way VOSF are being built now, this has never been an actual issue, but it is still sensible for a VOSF to hold on to the SyntheticChildrenSP as well as to its FrontEnd llvm-svn: 138080
2011-08-20 05:13:46 +08:00
else if (*format_name == 'T')
Massive enumeration name changes: a number of enums in ValueObject were not following the naming pattern Changes to synthetic children: - the update(self): function can now (optionally) return a value - if it returns boolean value True, ValueObjectSyntheticFilter will not clear its caches across stop-points this should allow better performance for Python-based synthetic children when one can be sure that the child ValueObjects have not changed - making a difference between a synthetic VO and a VO with a synthetic value: now a ValueObjectSyntheticFilter will not return itself as its own synthetic value, but will (correctly) claim to itself be synthetic - cleared up the internal synthetic children architecture to make a more consistent use of pointers and references instead of shared pointers when possible - major cleanup of unnecessary #include, data and functions in ValueObjectSyntheticFilter itself - removed the SyntheticValueType enum and replaced it with a plain boolean (to which it was equivalent in the first place) Some clean ups to the summary generation code Centralized the code that clears out user-visible strings and data in ValueObject More efficient summaries for libc++ containers llvm-svn: 153061
2012-03-20 06:58:49 +08:00
*val_obj_display = ValueObject::eValueObjectRepresentationStyleType;
some editing of data visualization error messages to make them more meaningful debugging printfs() for data visualization turned into a meaningful log: - introduced a new log category `types' in channel `lldb' llvm-svn: 135773
2011-07-23 01:03:19 +08:00
else if (log)
log->Printf("%s is an error, leaving the previous value alone", format_name);
new syntax for summary strings: - ${*expr} now simply means to dereference expr before actually using it - bitfields, array ranges and pointer ranges now work in a (hopefully) more natural and language-compliant way a new class TypeHierarchyNavigator replicates the behavior of the FormatManager in going through type hierarchies when one-lining summary strings, children's summaries can be used as well as values llvm-svn: 134458
2011-07-06 10:13:41 +08:00
}
// a good custom format tells us to print the value using it
else
some editing of data visualization error messages to make them more meaningful debugging printfs() for data visualization turned into a meaningful log: - introduced a new log category `types' in channel `lldb' llvm-svn: 135773
2011-07-23 01:03:19 +08:00
{
if (log)
log->Printf("will display value for this VO");
Massive enumeration name changes: a number of enums in ValueObject were not following the naming pattern Changes to synthetic children: - the update(self): function can now (optionally) return a value - if it returns boolean value True, ValueObjectSyntheticFilter will not clear its caches across stop-points this should allow better performance for Python-based synthetic children when one can be sure that the child ValueObjects have not changed - making a difference between a synthetic VO and a VO with a synthetic value: now a ValueObjectSyntheticFilter will not return itself as its own synthetic value, but will (correctly) claim to itself be synthetic - cleared up the internal synthetic children architecture to make a more consistent use of pointers and references instead of shared pointers when possible - major cleanup of unnecessary #include, data and functions in ValueObjectSyntheticFilter itself - removed the SyntheticValueType enum and replaced it with a plain boolean (to which it was equivalent in the first place) Some clean ups to the summary generation code Centralized the code that clears out user-visible strings and data in ValueObject More efficient summaries for libc++ containers llvm-svn: 153061
2012-03-20 06:58:49 +08:00
*val_obj_display = ValueObject::eValueObjectRepresentationStyleValue;
some editing of data visualization error messages to make them more meaningful debugging printfs() for data visualization turned into a meaningful log: - introduced a new log category `types' in channel `lldb' llvm-svn: 135773
2011-07-23 01:03:19 +08:00
}
new syntax for summary strings: - ${*expr} now simply means to dereference expr before actually using it - bitfields, array ranges and pointer ranges now work in a (hopefully) more natural and language-compliant way a new class TypeHierarchyNavigator replicates the behavior of the FormatManager in going through type hierarchies when one-lining summary strings, children's summaries can be used as well as values llvm-svn: 134458
2011-07-06 10:13:41 +08:00
delete format_name;
}
some editing of data visualization error messages to make them more meaningful debugging printfs() for data visualization turned into a meaningful log: - introduced a new log category `types' in channel `lldb' llvm-svn: 135773
2011-07-23 01:03:19 +08:00
if (log)
log->Printf("final format description outcome: custom_format = %d, val_obj_display = %d",
*custom_format,
*val_obj_display);
new syntax for summary strings: - ${*expr} now simply means to dereference expr before actually using it - bitfields, array ranges and pointer ranges now work in a (hopefully) more natural and language-compliant way a new class TypeHierarchyNavigator replicates the behavior of the FormatManager in going through type hierarchies when one-lining summary strings, children's summaries can be used as well as values llvm-svn: 134458
2011-07-06 10:13:41 +08:00
return true;
}
static bool
Additional code cleanups ; Short option name for --python-script in type summary add moved from -s to -o (this is a preliminary step in moving the short option for --summary-string from -f to -s) ; Accordingly updated the test suite llvm-svn: 138315
2011-08-23 08:32:52 +08:00
ScanBracketedRange (const char* var_name_begin,
const char* var_name_end,
const char* var_name_final,
const char** open_bracket_position,
const char** separator_position,
const char** close_bracket_position,
const char** var_name_final_if_array_range,
int64_t* index_lower,
int64_t* index_higher)
new syntax for summary strings: - ${*expr} now simply means to dereference expr before actually using it - bitfields, array ranges and pointer ranges now work in a (hopefully) more natural and language-compliant way a new class TypeHierarchyNavigator replicates the behavior of the FormatManager in going through type hierarchies when one-lining summary strings, children's summaries can be used as well as values llvm-svn: 134458
2011-07-06 10:13:41 +08:00
{
some editing of data visualization error messages to make them more meaningful debugging printfs() for data visualization turned into a meaningful log: - introduced a new log category `types' in channel `lldb' llvm-svn: 135773
2011-07-23 01:03:19 +08:00
LogSP log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_TYPES));
new syntax for summary strings: - ${*expr} now simply means to dereference expr before actually using it - bitfields, array ranges and pointer ranges now work in a (hopefully) more natural and language-compliant way a new class TypeHierarchyNavigator replicates the behavior of the FormatManager in going through type hierarchies when one-lining summary strings, children's summaries can be used as well as values llvm-svn: 134458
2011-07-06 10:13:41 +08:00
*open_bracket_position = ::strchr(var_name_begin,'[');
Fixed some issues with ARM backtraces by not processing any push/pop instructions if they are conditional. Also fixed issues where the PC wasn't getting bit zero stripped for ARM targets when a stack frame was thumb. We now properly call through the GetOpcodeLoadAddress() functions to make sure the addresses are properly stripped for any targets that may decorate up their addresses. We now don't pass the SIGSTOP signals along. We can revisit this soon, but currently this was interfering with debugging some older ARM targets that don't have vCont support in the GDB server. llvm-svn: 134461
2011-07-06 12:07:21 +08:00
if (*open_bracket_position && *open_bracket_position < var_name_final)
new syntax for summary strings: - ${*expr} now simply means to dereference expr before actually using it - bitfields, array ranges and pointer ranges now work in a (hopefully) more natural and language-compliant way a new class TypeHierarchyNavigator replicates the behavior of the FormatManager in going through type hierarchies when one-lining summary strings, children's summaries can be used as well as values llvm-svn: 134458
2011-07-06 10:13:41 +08:00
{
*separator_position = ::strchr(*open_bracket_position,'-'); // might be NULL if this is a simple var[N] bitfield
*close_bracket_position = ::strchr(*open_bracket_position,']');
// as usual, we assume that [] will come before %
//printf("trying to expand a []\n");
*var_name_final_if_array_range = *open_bracket_position;
Fixed some issues with ARM backtraces by not processing any push/pop instructions if they are conditional. Also fixed issues where the PC wasn't getting bit zero stripped for ARM targets when a stack frame was thumb. We now properly call through the GetOpcodeLoadAddress() functions to make sure the addresses are properly stripped for any targets that may decorate up their addresses. We now don't pass the SIGSTOP signals along. We can revisit this soon, but currently this was interfering with debugging some older ARM targets that don't have vCont support in the GDB server. llvm-svn: 134461
2011-07-06 12:07:21 +08:00
if (*close_bracket_position - *open_bracket_position == 1)
new syntax for summary strings: - ${*expr} now simply means to dereference expr before actually using it - bitfields, array ranges and pointer ranges now work in a (hopefully) more natural and language-compliant way a new class TypeHierarchyNavigator replicates the behavior of the FormatManager in going through type hierarchies when one-lining summary strings, children's summaries can be used as well as values llvm-svn: 134458
2011-07-06 10:13:41 +08:00
{
some editing of data visualization error messages to make them more meaningful debugging printfs() for data visualization turned into a meaningful log: - introduced a new log category `types' in channel `lldb' llvm-svn: 135773
2011-07-23 01:03:19 +08:00
if (log)
log->Printf("[] detected.. going from 0 to end of data");
new syntax for summary strings: - ${*expr} now simply means to dereference expr before actually using it - bitfields, array ranges and pointer ranges now work in a (hopefully) more natural and language-compliant way a new class TypeHierarchyNavigator replicates the behavior of the FormatManager in going through type hierarchies when one-lining summary strings, children's summaries can be used as well as values llvm-svn: 134458
2011-07-06 10:13:41 +08:00
*index_lower = 0;
}
else if (*separator_position == NULL || *separator_position > var_name_end)
{
char *end = NULL;
*index_lower = ::strtoul (*open_bracket_position+1, &end, 0);
*index_higher = *index_lower;
some editing of data visualization error messages to make them more meaningful debugging printfs() for data visualization turned into a meaningful log: - introduced a new log category `types' in channel `lldb' llvm-svn: 135773
2011-07-23 01:03:19 +08:00
if (log)
Update declarations for all functions/methods that accept printf-style stdarg formats to use __attribute__ format so the compiler can flag incorrect uses. Fix all incorrect uses. Most of these are innocuous, a few were resulting in crashes. llvm-svn: 140185
2011-09-21 05:44:10 +08:00
log->Printf("[%lld] detected, high index is same", *index_lower);
new syntax for summary strings: - ${*expr} now simply means to dereference expr before actually using it - bitfields, array ranges and pointer ranges now work in a (hopefully) more natural and language-compliant way a new class TypeHierarchyNavigator replicates the behavior of the FormatManager in going through type hierarchies when one-lining summary strings, children's summaries can be used as well as values llvm-svn: 134458
2011-07-06 10:13:41 +08:00
}
Fixed some issues with ARM backtraces by not processing any push/pop instructions if they are conditional. Also fixed issues where the PC wasn't getting bit zero stripped for ARM targets when a stack frame was thumb. We now properly call through the GetOpcodeLoadAddress() functions to make sure the addresses are properly stripped for any targets that may decorate up their addresses. We now don't pass the SIGSTOP signals along. We can revisit this soon, but currently this was interfering with debugging some older ARM targets that don't have vCont support in the GDB server. llvm-svn: 134461
2011-07-06 12:07:21 +08:00
else if (*close_bracket_position && *close_bracket_position < var_name_end)
new syntax for summary strings: - ${*expr} now simply means to dereference expr before actually using it - bitfields, array ranges and pointer ranges now work in a (hopefully) more natural and language-compliant way a new class TypeHierarchyNavigator replicates the behavior of the FormatManager in going through type hierarchies when one-lining summary strings, children's summaries can be used as well as values llvm-svn: 134458
2011-07-06 10:13:41 +08:00
{
char *end = NULL;
*index_lower = ::strtoul (*open_bracket_position+1, &end, 0);
*index_higher = ::strtoul (*separator_position+1, &end, 0);
some editing of data visualization error messages to make them more meaningful debugging printfs() for data visualization turned into a meaningful log: - introduced a new log category `types' in channel `lldb' llvm-svn: 135773
2011-07-23 01:03:19 +08:00
if (log)
Update declarations for all functions/methods that accept printf-style stdarg formats to use __attribute__ format so the compiler can flag incorrect uses. Fix all incorrect uses. Most of these are innocuous, a few were resulting in crashes. llvm-svn: 140185
2011-09-21 05:44:10 +08:00
log->Printf("[%lld-%lld] detected", *index_lower, *index_higher);
new syntax for summary strings: - ${*expr} now simply means to dereference expr before actually using it - bitfields, array ranges and pointer ranges now work in a (hopefully) more natural and language-compliant way a new class TypeHierarchyNavigator replicates the behavior of the FormatManager in going through type hierarchies when one-lining summary strings, children's summaries can be used as well as values llvm-svn: 134458
2011-07-06 10:13:41 +08:00
}
else
some editing of data visualization error messages to make them more meaningful debugging printfs() for data visualization turned into a meaningful log: - introduced a new log category `types' in channel `lldb' llvm-svn: 135773
2011-07-23 01:03:19 +08:00
{
if (log)
log->Printf("expression is erroneous, cannot extract indices out of it");
new syntax for summary strings: - ${*expr} now simply means to dereference expr before actually using it - bitfields, array ranges and pointer ranges now work in a (hopefully) more natural and language-compliant way a new class TypeHierarchyNavigator replicates the behavior of the FormatManager in going through type hierarchies when one-lining summary strings, children's summaries can be used as well as values llvm-svn: 134458
2011-07-06 10:13:41 +08:00
return false;
some editing of data visualization error messages to make them more meaningful debugging printfs() for data visualization turned into a meaningful log: - introduced a new log category `types' in channel `lldb' llvm-svn: 135773
2011-07-23 01:03:19 +08:00
}
new syntax for summary strings: - ${*expr} now simply means to dereference expr before actually using it - bitfields, array ranges and pointer ranges now work in a (hopefully) more natural and language-compliant way a new class TypeHierarchyNavigator replicates the behavior of the FormatManager in going through type hierarchies when one-lining summary strings, children's summaries can be used as well as values llvm-svn: 134458
2011-07-06 10:13:41 +08:00
if (*index_lower > *index_higher && *index_higher > 0)
{
some editing of data visualization error messages to make them more meaningful debugging printfs() for data visualization turned into a meaningful log: - introduced a new log category `types' in channel `lldb' llvm-svn: 135773
2011-07-23 01:03:19 +08:00
if (log)
log->Printf("swapping indices");
new syntax for summary strings: - ${*expr} now simply means to dereference expr before actually using it - bitfields, array ranges and pointer ranges now work in a (hopefully) more natural and language-compliant way a new class TypeHierarchyNavigator replicates the behavior of the FormatManager in going through type hierarchies when one-lining summary strings, children's summaries can be used as well as values llvm-svn: 134458
2011-07-06 10:13:41 +08:00
int temp = *index_lower;
*index_lower = *index_higher;
*index_higher = temp;
}
}
some editing of data visualization error messages to make them more meaningful debugging printfs() for data visualization turned into a meaningful log: - introduced a new log category `types' in channel `lldb' llvm-svn: 135773
2011-07-23 01:03:19 +08:00
else if (log)
log->Printf("no bracketed range, skipping entirely");
new syntax for summary strings: - ${*expr} now simply means to dereference expr before actually using it - bitfields, array ranges and pointer ranges now work in a (hopefully) more natural and language-compliant way a new class TypeHierarchyNavigator replicates the behavior of the FormatManager in going through type hierarchies when one-lining summary strings, children's summaries can be used as well as values llvm-svn: 134458
2011-07-06 10:13:41 +08:00
return true;
}
static ValueObjectSP
Additional code cleanups ; Short option name for --python-script in type summary add moved from -s to -o (this is a preliminary step in moving the short option for --summary-string from -f to -s) ; Accordingly updated the test suite llvm-svn: 138315
2011-08-23 08:32:52 +08:00
ExpandIndexedExpression (ValueObject* valobj,
uint32_t index,
StackFrame* frame,
bool deref_pointer)
new syntax for summary strings: - ${*expr} now simply means to dereference expr before actually using it - bitfields, array ranges and pointer ranges now work in a (hopefully) more natural and language-compliant way a new class TypeHierarchyNavigator replicates the behavior of the FormatManager in going through type hierarchies when one-lining summary strings, children's summaries can be used as well as values llvm-svn: 134458
2011-07-06 10:13:41 +08:00
{
some editing of data visualization error messages to make them more meaningful debugging printfs() for data visualization turned into a meaningful log: - introduced a new log category `types' in channel `lldb' llvm-svn: 135773
2011-07-23 01:03:19 +08:00
LogSP log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_TYPES));
final fix for the global constructors issue new GetValueForExpressionPath() method in ValueObject to navigate expression paths in a more bitfield vs slices aware way changes to the varformats.html document (WIP) llvm-svn: 134679
2011-07-08 10:51:01 +08:00
const char* ptr_deref_format = "[%d]";
std::auto_ptr<char> ptr_deref_buffer(new char[10]);
::sprintf(ptr_deref_buffer.get(), ptr_deref_format, index);
some editing of data visualization error messages to make them more meaningful debugging printfs() for data visualization turned into a meaningful log: - introduced a new log category `types' in channel `lldb' llvm-svn: 135773
2011-07-23 01:03:19 +08:00
if (log)
log->Printf("name to deref: %s",ptr_deref_buffer.get());
final fix for the global constructors issue new GetValueForExpressionPath() method in ValueObject to navigate expression paths in a more bitfield vs slices aware way changes to the varformats.html document (WIP) llvm-svn: 134679
2011-07-08 10:51:01 +08:00
const char* first_unparsed;
ValueObject::GetValueForExpressionPathOptions options;
ValueObject::ExpressionPathEndResultType final_value_type;
ValueObject::ExpressionPathScanEndReason reason_to_stop;
Massive enumeration name changes: a number of enums in ValueObject were not following the naming pattern Changes to synthetic children: - the update(self): function can now (optionally) return a value - if it returns boolean value True, ValueObjectSyntheticFilter will not clear its caches across stop-points this should allow better performance for Python-based synthetic children when one can be sure that the child ValueObjects have not changed - making a difference between a synthetic VO and a VO with a synthetic value: now a ValueObjectSyntheticFilter will not return itself as its own synthetic value, but will (correctly) claim to itself be synthetic - cleared up the internal synthetic children architecture to make a more consistent use of pointers and references instead of shared pointers when possible - major cleanup of unnecessary #include, data and functions in ValueObjectSyntheticFilter itself - removed the SyntheticValueType enum and replaced it with a plain boolean (to which it was equivalent in the first place) Some clean ups to the summary generation code Centralized the code that clears out user-visible strings and data in ValueObject More efficient summaries for libc++ containers llvm-svn: 153061
2012-03-20 06:58:49 +08:00
ValueObject::ExpressionPathAftermath what_next = (deref_pointer ? ValueObject::eExpressionPathAftermathDereference : ValueObject::eExpressionPathAftermathNothing);
First round of code cleanups: - all instances of "vobj" have been renamed to "valobj" - class Debugger::Formatting has been renamed to DataVisualization (defined in FormatManager.h/cpp) The interface to this class has not changed - FormatCategory now uses ConstString's as keys to the navigators instead of repeatedly casting from ConstString to const char* and back all the time Next step is making the same happen for categories themselves - category gnu-libstdc++ is defined in the constructor for a FormatManager The source code for it is defined in gnu_libstdcpp.py, drawn from examples/synthetic at compile time All references to previous 'osxcpp' name have been removed from both code and file names Functional changes: - the name of the option to use a summary string for 'type summary add' has changed from the previous --format-string to the new --summary-string. It is expected that the short option will change from -f to -s, and -s for --python-script will become -o llvm-svn: 137886
2011-08-18 06:13:59 +08:00
ValueObjectSP item = valobj->GetValueForExpressionPath (ptr_deref_buffer.get(),
final fix for the global constructors issue new GetValueForExpressionPath() method in ValueObject to navigate expression paths in a more bitfield vs slices aware way changes to the varformats.html document (WIP) llvm-svn: 134679
2011-07-08 10:51:01 +08:00
&first_unparsed,
&reason_to_stop,
&final_value_type,
options,
&what_next);
if (!item)
{
some editing of data visualization error messages to make them more meaningful debugging printfs() for data visualization turned into a meaningful log: - introduced a new log category `types' in channel `lldb' llvm-svn: 135773
2011-07-23 01:03:19 +08:00
if (log)
log->Printf("ERROR: unparsed portion = %s, why stopping = %d,"
" final_value_type %d",
final fix for the global constructors issue new GetValueForExpressionPath() method in ValueObject to navigate expression paths in a more bitfield vs slices aware way changes to the varformats.html document (WIP) llvm-svn: 134679
2011-07-08 10:51:01 +08:00
first_unparsed, reason_to_stop, final_value_type);
new syntax for summary strings: - ${*expr} now simply means to dereference expr before actually using it - bitfields, array ranges and pointer ranges now work in a (hopefully) more natural and language-compliant way a new class TypeHierarchyNavigator replicates the behavior of the FormatManager in going through type hierarchies when one-lining summary strings, children's summaries can be used as well as values llvm-svn: 134458
2011-07-06 10:13:41 +08:00
}
final fix for the global constructors issue new GetValueForExpressionPath() method in ValueObject to navigate expression paths in a more bitfield vs slices aware way changes to the varformats.html document (WIP) llvm-svn: 134679
2011-07-08 10:51:01 +08:00
else
{
some editing of data visualization error messages to make them more meaningful debugging printfs() for data visualization turned into a meaningful log: - introduced a new log category `types' in channel `lldb' llvm-svn: 135773
2011-07-23 01:03:19 +08:00
if (log)
log->Printf("ALL RIGHT: unparsed portion = %s, why stopping = %d,"
" final_value_type %d",
final fix for the global constructors issue new GetValueForExpressionPath() method in ValueObject to navigate expression paths in a more bitfield vs slices aware way changes to the varformats.html document (WIP) llvm-svn: 134679
2011-07-08 10:51:01 +08:00
first_unparsed, reason_to_stop, final_value_type);
}
new syntax for summary strings: - ${*expr} now simply means to dereference expr before actually using it - bitfields, array ranges and pointer ranges now work in a (hopefully) more natural and language-compliant way a new class TypeHierarchyNavigator replicates the behavior of the FormatManager in going through type hierarchies when one-lining summary strings, children's summaries can be used as well as values llvm-svn: 134458
2011-07-06 10:13:41 +08:00
return item;
}
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
bool
Debugger::FormatPrompt
(
const char *format,
const SymbolContext *sc,
const ExecutionContext *exe_ctx,
const Address *addr,
Stream &s,
This commit adds a new top subcommand "summary" to command type named "type". Currently this command implements three commands: type summary add <format> <typename1> [<typename2> ...] type summary delete <typename1> [<typename2> ...] type summary list [<typename1> [<typename2>] ...] type summary clear This allows you to specify the default format that will be used to display summaries for variables, shown when you use "frame variable" or "expression", or the SBValue classes. Examples: type summary add "x = ${var.x}" Point type summary list type summary add --one-liner SimpleType llvm-svn: 134108
2011-06-30 06:27:15 +08:00
const char **end,
First round of code cleanups: - all instances of "vobj" have been renamed to "valobj" - class Debugger::Formatting has been renamed to DataVisualization (defined in FormatManager.h/cpp) The interface to this class has not changed - FormatCategory now uses ConstString's as keys to the navigators instead of repeatedly casting from ConstString to const char* and back all the time Next step is making the same happen for categories themselves - category gnu-libstdc++ is defined in the constructor for a FormatManager The source code for it is defined in gnu_libstdcpp.py, drawn from examples/synthetic at compile time All references to previous 'osxcpp' name have been removed from both code and file names Functional changes: - the name of the option to use a summary string for 'type summary add' has changed from the previous --format-string to the new --summary-string. It is expected that the short option will change from -f to -s, and -s for --python-script will become -o llvm-svn: 137886
2011-08-18 06:13:59 +08:00
ValueObject* valobj
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
)
{
First round of code cleanups: - all instances of "vobj" have been renamed to "valobj" - class Debugger::Formatting has been renamed to DataVisualization (defined in FormatManager.h/cpp) The interface to this class has not changed - FormatCategory now uses ConstString's as keys to the navigators instead of repeatedly casting from ConstString to const char* and back all the time Next step is making the same happen for categories themselves - category gnu-libstdc++ is defined in the constructor for a FormatManager The source code for it is defined in gnu_libstdcpp.py, drawn from examples/synthetic at compile time All references to previous 'osxcpp' name have been removed from both code and file names Functional changes: - the name of the option to use a summary string for 'type summary add' has changed from the previous --format-string to the new --summary-string. It is expected that the short option will change from -f to -s, and -s for --python-script will become -o llvm-svn: 137886
2011-08-18 06:13:59 +08:00
ValueObject* realvalobj = NULL; // makes it super-easy to parse pointers
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
bool success = true;
const char *p;
some editing of data visualization error messages to make them more meaningful debugging printfs() for data visualization turned into a meaningful log: - introduced a new log category `types' in channel `lldb' llvm-svn: 135773
2011-07-23 01:03:19 +08:00
LogSP log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_TYPES));
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
for (p = format; *p != '\0'; ++p)
{
First round of code cleanups: - all instances of "vobj" have been renamed to "valobj" - class Debugger::Formatting has been renamed to DataVisualization (defined in FormatManager.h/cpp) The interface to this class has not changed - FormatCategory now uses ConstString's as keys to the navigators instead of repeatedly casting from ConstString to const char* and back all the time Next step is making the same happen for categories themselves - category gnu-libstdc++ is defined in the constructor for a FormatManager The source code for it is defined in gnu_libstdcpp.py, drawn from examples/synthetic at compile time All references to previous 'osxcpp' name have been removed from both code and file names Functional changes: - the name of the option to use a summary string for 'type summary add' has changed from the previous --format-string to the new --summary-string. It is expected that the short option will change from -f to -s, and -s for --python-script will become -o llvm-svn: 137886
2011-08-18 06:13:59 +08:00
if (realvalobj)
This commit adds a new top subcommand "summary" to command type named "type". Currently this command implements three commands: type summary add <format> <typename1> [<typename2> ...] type summary delete <typename1> [<typename2> ...] type summary list [<typename1> [<typename2>] ...] type summary clear This allows you to specify the default format that will be used to display summaries for variables, shown when you use "frame variable" or "expression", or the SBValue classes. Examples: type summary add "x = ${var.x}" Point type summary list type summary add --one-liner SimpleType llvm-svn: 134108
2011-06-30 06:27:15 +08:00
{
First round of code cleanups: - all instances of "vobj" have been renamed to "valobj" - class Debugger::Formatting has been renamed to DataVisualization (defined in FormatManager.h/cpp) The interface to this class has not changed - FormatCategory now uses ConstString's as keys to the navigators instead of repeatedly casting from ConstString to const char* and back all the time Next step is making the same happen for categories themselves - category gnu-libstdc++ is defined in the constructor for a FormatManager The source code for it is defined in gnu_libstdcpp.py, drawn from examples/synthetic at compile time All references to previous 'osxcpp' name have been removed from both code and file names Functional changes: - the name of the option to use a summary string for 'type summary add' has changed from the previous --format-string to the new --summary-string. It is expected that the short option will change from -f to -s, and -s for --python-script will become -o llvm-svn: 137886
2011-08-18 06:13:59 +08:00
valobj = realvalobj;
realvalobj = NULL;
This commit adds a new top subcommand "summary" to command type named "type". Currently this command implements three commands: type summary add <format> <typename1> [<typename2> ...] type summary delete <typename1> [<typename2> ...] type summary list [<typename1> [<typename2>] ...] type summary clear This allows you to specify the default format that will be used to display summaries for variables, shown when you use "frame variable" or "expression", or the SBValue classes. Examples: type summary add "x = ${var.x}" Point type summary list type summary add --one-liner SimpleType llvm-svn: 134108
2011-06-30 06:27:15 +08:00
}
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
size_t non_special_chars = ::strcspn (p, "${}\\");
if (non_special_chars > 0)
{
if (success)
s.Write (p, non_special_chars);
p += non_special_chars;
}
if (*p == '\0')
{
break;
}
else if (*p == '{')
{
// Start a new scope that must have everything it needs if it is to
// to make it into the final output stream "s". If you want to make
// a format that only prints out the function or symbol name if there
// is one in the symbol context you can use:
// "{function =${function.name}}"
// The first '{' starts a new scope that end with the matching '}' at
// the end of the string. The contents "function =${function.name}"
// will then be evaluated and only be output if there is a function
// or symbol with a valid name.
StreamString sub_strm;
++p; // Skip the '{'
First round of code cleanups: - all instances of "vobj" have been renamed to "valobj" - class Debugger::Formatting has been renamed to DataVisualization (defined in FormatManager.h/cpp) The interface to this class has not changed - FormatCategory now uses ConstString's as keys to the navigators instead of repeatedly casting from ConstString to const char* and back all the time Next step is making the same happen for categories themselves - category gnu-libstdc++ is defined in the constructor for a FormatManager The source code for it is defined in gnu_libstdcpp.py, drawn from examples/synthetic at compile time All references to previous 'osxcpp' name have been removed from both code and file names Functional changes: - the name of the option to use a summary string for 'type summary add' has changed from the previous --format-string to the new --summary-string. It is expected that the short option will change from -f to -s, and -s for --python-script will become -o llvm-svn: 137886
2011-08-18 06:13:59 +08:00
if (FormatPrompt (p, sc, exe_ctx, addr, sub_strm, &p, valobj))
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
{
// The stream had all it needed
s.Write(sub_strm.GetData(), sub_strm.GetSize());
}
if (*p != '}')
{
success = false;
break;
}
}
else if (*p == '}')
{
// End of a enclosing scope
break;
}
else if (*p == '$')
{
// We have a prompt variable to print
++p;
if (*p == '{')
{
++p;
const char *var_name_begin = p;
const char *var_name_end = ::strchr (p, '}');
if (var_name_end && var_name_begin < var_name_end)
{
// if we have already failed to parse, skip this variable
if (success)
{
const char *cstr = NULL;
Address format_addr;
bool calculate_format_addr_function_offset = false;
// Set reg_kind and reg_num to invalid values
RegisterKind reg_kind = kNumRegisterKinds;
uint32_t reg_num = LLDB_INVALID_REGNUM;
FileSpec format_file_spec;
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
2011-03-25 05:19:54 +08:00
const RegisterInfo *reg_info = NULL;
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
RegisterContext *reg_ctx = NULL;
new syntax for summary strings: - ${*expr} now simply means to dereference expr before actually using it - bitfields, array ranges and pointer ranges now work in a (hopefully) more natural and language-compliant way a new class TypeHierarchyNavigator replicates the behavior of the FormatManager in going through type hierarchies when one-lining summary strings, children's summaries can be used as well as values llvm-svn: 134458
2011-07-06 10:13:41 +08:00
bool do_deref_pointer = false;
Massive enumeration name changes: a number of enums in ValueObject were not following the naming pattern Changes to synthetic children: - the update(self): function can now (optionally) return a value - if it returns boolean value True, ValueObjectSyntheticFilter will not clear its caches across stop-points this should allow better performance for Python-based synthetic children when one can be sure that the child ValueObjects have not changed - making a difference between a synthetic VO and a VO with a synthetic value: now a ValueObjectSyntheticFilter will not return itself as its own synthetic value, but will (correctly) claim to itself be synthetic - cleared up the internal synthetic children architecture to make a more consistent use of pointers and references instead of shared pointers when possible - major cleanup of unnecessary #include, data and functions in ValueObjectSyntheticFilter itself - removed the SyntheticValueType enum and replaced it with a plain boolean (to which it was equivalent in the first place) Some clean ups to the summary generation code Centralized the code that clears out user-visible strings and data in ValueObject More efficient summaries for libc++ containers llvm-svn: 153061
2012-03-20 06:58:49 +08:00
ValueObject::ExpressionPathScanEndReason reason_to_stop = ValueObject::eExpressionPathScanEndReasonEndOfString;
ValueObject::ExpressionPathEndResultType final_value_type = ValueObject::eExpressionPathEndResultTypePlain;
final fix for the global constructors issue new GetValueForExpressionPath() method in ValueObject to navigate expression paths in a more bitfield vs slices aware way changes to the varformats.html document (WIP) llvm-svn: 134679
2011-07-08 10:51:01 +08:00
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
// Each variable must set success to true below...
bool var_success = false;
switch (var_name_begin[0])
{
This commit adds a new top subcommand "summary" to command type named "type". Currently this command implements three commands: type summary add <format> <typename1> [<typename2> ...] type summary delete <typename1> [<typename2> ...] type summary list [<typename1> [<typename2>] ...] type summary clear This allows you to specify the default format that will be used to display summaries for variables, shown when you use "frame variable" or "expression", or the SBValue classes. Examples: type summary add "x = ${var.x}" Point type summary list type summary add --one-liner SimpleType llvm-svn: 134108
2011-06-30 06:27:15 +08:00
case '*':
case 'v':
Public API changes: - Completely new implementation of SBType - Various enhancements in several other classes Python synthetic children providers for std::vector<T>, std::list<T> and std::map<K,V>: - these return the actual elements into the container as the children of the container - basic template name parsing that works (hopefully) on both Clang and GCC - find them in examples/synthetic and in the test suite in functionalities/data-formatter/data-formatter-python-synth New summary string token ${svar : - the syntax is just the same as in ${var but this new token lets you read the values coming from the synthetic children provider instead of the actual children - Python providers above provide a synthetic child len that returns the number of elements into the container Full bug fix for the issue in which getting byte size for a non-complete type would crash LLDB Several other fixes, including: - inverted the order of arguments in the ClangASTType constructor - EvaluationPoint now only returns SharedPointer's to Target and Process - the help text for several type subcommands now correctly indicates argument-less options as such llvm-svn: 136504
2011-07-30 03:53:35 +08:00
case 's':
This commit adds a new top subcommand "summary" to command type named "type". Currently this command implements three commands: type summary add <format> <typename1> [<typename2> ...] type summary delete <typename1> [<typename2> ...] type summary list [<typename1> [<typename2>] ...] type summary clear This allows you to specify the default format that will be used to display summaries for variables, shown when you use "frame variable" or "expression", or the SBValue classes. Examples: type summary add "x = ${var.x}" Point type summary list type summary add --one-liner SimpleType llvm-svn: 134108
2011-06-30 06:27:15 +08:00
{
First round of code cleanups: - all instances of "vobj" have been renamed to "valobj" - class Debugger::Formatting has been renamed to DataVisualization (defined in FormatManager.h/cpp) The interface to this class has not changed - FormatCategory now uses ConstString's as keys to the navigators instead of repeatedly casting from ConstString to const char* and back all the time Next step is making the same happen for categories themselves - category gnu-libstdc++ is defined in the constructor for a FormatManager The source code for it is defined in gnu_libstdcpp.py, drawn from examples/synthetic at compile time All references to previous 'osxcpp' name have been removed from both code and file names Functional changes: - the name of the option to use a summary string for 'type summary add' has changed from the previous --format-string to the new --summary-string. It is expected that the short option will change from -f to -s, and -s for --python-script will become -o llvm-svn: 137886
2011-08-18 06:13:59 +08:00
if (!valobj)
Public API changes: - Completely new implementation of SBType - Various enhancements in several other classes Python synthetic children providers for std::vector<T>, std::list<T> and std::map<K,V>: - these return the actual elements into the container as the children of the container - basic template name parsing that works (hopefully) on both Clang and GCC - find them in examples/synthetic and in the test suite in functionalities/data-formatter/data-formatter-python-synth New summary string token ${svar : - the syntax is just the same as in ${var but this new token lets you read the values coming from the synthetic children provider instead of the actual children - Python providers above provide a synthetic child len that returns the number of elements into the container Full bug fix for the issue in which getting byte size for a non-complete type would crash LLDB Several other fixes, including: - inverted the order of arguments in the ClangASTType constructor - EvaluationPoint now only returns SharedPointer's to Target and Process - the help text for several type subcommands now correctly indicates argument-less options as such llvm-svn: 136504
2011-07-30 03:53:35 +08:00
break;
Fixed a bug where a variable could not be formatted in a summary if its datatype already had a custom format Fixed a bug where Objective-C variables coming out of the expression parser could crash the Python synthetic providers: - expression parser output has a "frozen data" component, which is a byte-exact copy of the value (in host memory), if trying to read into memory based on the host address, LLDB would crash. we are now passing the correct (target) pointer to the Python code Objective-C "id" variables are now formatted according to their dynamic type, if the -d option to frame variable is used: - Code based on the Objective-C 2.0 runtime is used to obtain this information without running code on the target llvm-svn: 136695
2011-08-03 01:27:39 +08:00
if (log)
log->Printf("initial string: %s",var_name_begin);
Public API changes: - Completely new implementation of SBType - Various enhancements in several other classes Python synthetic children providers for std::vector<T>, std::list<T> and std::map<K,V>: - these return the actual elements into the container as the children of the container - basic template name parsing that works (hopefully) on both Clang and GCC - find them in examples/synthetic and in the test suite in functionalities/data-formatter/data-formatter-python-synth New summary string token ${svar : - the syntax is just the same as in ${var but this new token lets you read the values coming from the synthetic children provider instead of the actual children - Python providers above provide a synthetic child len that returns the number of elements into the container Full bug fix for the issue in which getting byte size for a non-complete type would crash LLDB Several other fixes, including: - inverted the order of arguments in the ClangASTType constructor - EvaluationPoint now only returns SharedPointer's to Target and Process - the help text for several type subcommands now correctly indicates argument-less options as such llvm-svn: 136504
2011-07-30 03:53:35 +08:00
// check for *var and *svar
if (*var_name_begin == '*')
{
do_deref_pointer = true;
var_name_begin++;
}
Fixed a bug where a variable could not be formatted in a summary if its datatype already had a custom format Fixed a bug where Objective-C variables coming out of the expression parser could crash the Python synthetic providers: - expression parser output has a "frozen data" component, which is a byte-exact copy of the value (in host memory), if trying to read into memory based on the host address, LLDB would crash. we are now passing the correct (target) pointer to the Python code Objective-C "id" variables are now formatted according to their dynamic type, if the -d option to frame variable is used: - Code based on the Objective-C 2.0 runtime is used to obtain this information without running code on the target llvm-svn: 136695
2011-08-03 01:27:39 +08:00
if (log)
log->Printf("initial string: %s",var_name_begin);
Public API changes: - Completely new implementation of SBType - Various enhancements in several other classes Python synthetic children providers for std::vector<T>, std::list<T> and std::map<K,V>: - these return the actual elements into the container as the children of the container - basic template name parsing that works (hopefully) on both Clang and GCC - find them in examples/synthetic and in the test suite in functionalities/data-formatter/data-formatter-python-synth New summary string token ${svar : - the syntax is just the same as in ${var but this new token lets you read the values coming from the synthetic children provider instead of the actual children - Python providers above provide a synthetic child len that returns the number of elements into the container Full bug fix for the issue in which getting byte size for a non-complete type would crash LLDB Several other fixes, including: - inverted the order of arguments in the ClangASTType constructor - EvaluationPoint now only returns SharedPointer's to Target and Process - the help text for several type subcommands now correctly indicates argument-less options as such llvm-svn: 136504
2011-07-30 03:53:35 +08:00
if (*var_name_begin == 's')
{
Synthetic values are now automatically enabled and active by default. SBValue is set up to always wrap a synthetic value when one is available. A new setting enable-synthetic-value is provided on the target to disable this behavior. There also is a new GetNonSyntheticValue() API call on SBValue to go back from synthetic to non-synthetic. There is no call to go from non-synthetic to synthetic. The test suite has been changed accordingly. Fallout from changes to type searching: an hack has to be played to make it possible to use maps that contain std::string due to the special name replacement operated by clang Fixing a test case that was using libstdcpp instead of libc++ - caught as a consequence of said changes to type searching llvm-svn: 153495
2012-03-27 10:35:13 +08:00
if (!valobj->IsSynthetic())
valobj = valobj->GetSyntheticValue().get();
Massive enumeration name changes: a number of enums in ValueObject were not following the naming pattern Changes to synthetic children: - the update(self): function can now (optionally) return a value - if it returns boolean value True, ValueObjectSyntheticFilter will not clear its caches across stop-points this should allow better performance for Python-based synthetic children when one can be sure that the child ValueObjects have not changed - making a difference between a synthetic VO and a VO with a synthetic value: now a ValueObjectSyntheticFilter will not return itself as its own synthetic value, but will (correctly) claim to itself be synthetic - cleared up the internal synthetic children architecture to make a more consistent use of pointers and references instead of shared pointers when possible - major cleanup of unnecessary #include, data and functions in ValueObjectSyntheticFilter itself - removed the SyntheticValueType enum and replaced it with a plain boolean (to which it was equivalent in the first place) Some clean ups to the summary generation code Centralized the code that clears out user-visible strings and data in ValueObject More efficient summaries for libc++ containers llvm-svn: 153061
2012-03-20 06:58:49 +08:00
if (!valobj)
break;
Public API changes: - Completely new implementation of SBType - Various enhancements in several other classes Python synthetic children providers for std::vector<T>, std::list<T> and std::map<K,V>: - these return the actual elements into the container as the children of the container - basic template name parsing that works (hopefully) on both Clang and GCC - find them in examples/synthetic and in the test suite in functionalities/data-formatter/data-formatter-python-synth New summary string token ${svar : - the syntax is just the same as in ${var but this new token lets you read the values coming from the synthetic children provider instead of the actual children - Python providers above provide a synthetic child len that returns the number of elements into the container Full bug fix for the issue in which getting byte size for a non-complete type would crash LLDB Several other fixes, including: - inverted the order of arguments in the ClangASTType constructor - EvaluationPoint now only returns SharedPointer's to Target and Process - the help text for several type subcommands now correctly indicates argument-less options as such llvm-svn: 136504
2011-07-30 03:53:35 +08:00
var_name_begin++;
}
Fixed a bug where a variable could not be formatted in a summary if its datatype already had a custom format Fixed a bug where Objective-C variables coming out of the expression parser could crash the Python synthetic providers: - expression parser output has a "frozen data" component, which is a byte-exact copy of the value (in host memory), if trying to read into memory based on the host address, LLDB would crash. we are now passing the correct (target) pointer to the Python code Objective-C "id" variables are now formatted according to their dynamic type, if the -d option to frame variable is used: - Code based on the Objective-C 2.0 runtime is used to obtain this information without running code on the target llvm-svn: 136695
2011-08-03 01:27:39 +08:00
if (log)
log->Printf("initial string: %s",var_name_begin);
Public API changes: - Completely new implementation of SBType - Various enhancements in several other classes Python synthetic children providers for std::vector<T>, std::list<T> and std::map<K,V>: - these return the actual elements into the container as the children of the container - basic template name parsing that works (hopefully) on both Clang and GCC - find them in examples/synthetic and in the test suite in functionalities/data-formatter/data-formatter-python-synth New summary string token ${svar : - the syntax is just the same as in ${var but this new token lets you read the values coming from the synthetic children provider instead of the actual children - Python providers above provide a synthetic child len that returns the number of elements into the container Full bug fix for the issue in which getting byte size for a non-complete type would crash LLDB Several other fixes, including: - inverted the order of arguments in the ClangASTType constructor - EvaluationPoint now only returns SharedPointer's to Target and Process - the help text for several type subcommands now correctly indicates argument-less options as such llvm-svn: 136504
2011-07-30 03:53:35 +08:00
// should be a 'v' by now
if (*var_name_begin != 'v')
break;
Fixed a bug where a variable could not be formatted in a summary if its datatype already had a custom format Fixed a bug where Objective-C variables coming out of the expression parser could crash the Python synthetic providers: - expression parser output has a "frozen data" component, which is a byte-exact copy of the value (in host memory), if trying to read into memory based on the host address, LLDB would crash. we are now passing the correct (target) pointer to the Python code Objective-C "id" variables are now formatted according to their dynamic type, if the -d option to frame variable is used: - Code based on the Objective-C 2.0 runtime is used to obtain this information without running code on the target llvm-svn: 136695
2011-08-03 01:27:39 +08:00
if (log)
log->Printf("initial string: %s",var_name_begin);
final fix for the global constructors issue new GetValueForExpressionPath() method in ValueObject to navigate expression paths in a more bitfield vs slices aware way changes to the varformats.html document (WIP) llvm-svn: 134679
2011-07-08 10:51:01 +08:00
ValueObject::ExpressionPathAftermath what_next = (do_deref_pointer ?
Massive enumeration name changes: a number of enums in ValueObject were not following the naming pattern Changes to synthetic children: - the update(self): function can now (optionally) return a value - if it returns boolean value True, ValueObjectSyntheticFilter will not clear its caches across stop-points this should allow better performance for Python-based synthetic children when one can be sure that the child ValueObjects have not changed - making a difference between a synthetic VO and a VO with a synthetic value: now a ValueObjectSyntheticFilter will not return itself as its own synthetic value, but will (correctly) claim to itself be synthetic - cleared up the internal synthetic children architecture to make a more consistent use of pointers and references instead of shared pointers when possible - major cleanup of unnecessary #include, data and functions in ValueObjectSyntheticFilter itself - removed the SyntheticValueType enum and replaced it with a plain boolean (to which it was equivalent in the first place) Some clean ups to the summary generation code Centralized the code that clears out user-visible strings and data in ValueObject More efficient summaries for libc++ containers llvm-svn: 153061
2012-03-20 06:58:49 +08:00
ValueObject::eExpressionPathAftermathDereference : ValueObject::eExpressionPathAftermathNothing);
final fix for the global constructors issue new GetValueForExpressionPath() method in ValueObject to navigate expression paths in a more bitfield vs slices aware way changes to the varformats.html document (WIP) llvm-svn: 134679
2011-07-08 10:51:01 +08:00
ValueObject::GetValueForExpressionPathOptions options;
Fixed an issue where a pointer's address was being logged instead of its value Access to synthetic children by name: if your object has a synthetic child named foo you can now type frame variable object.foo (or ->foo if you have a pointer) and that will print the value of the synthetic child (if your object has an actual child named foo, the actual child prevails!) this behavior should also work in summaries, and you should be able to use ${var.foo} and ${svar.foo} interchangeably (but using svar.foo will mask an actual child named foo) llvm-svn: 137314
2011-08-12 01:08:01 +08:00
options.DontCheckDotVsArrowSyntax().DoAllowBitfieldSyntax().DoAllowFragileIVar().DoAllowSyntheticChildren();
Massive enumeration name changes: a number of enums in ValueObject were not following the naming pattern Changes to synthetic children: - the update(self): function can now (optionally) return a value - if it returns boolean value True, ValueObjectSyntheticFilter will not clear its caches across stop-points this should allow better performance for Python-based synthetic children when one can be sure that the child ValueObjects have not changed - making a difference between a synthetic VO and a VO with a synthetic value: now a ValueObjectSyntheticFilter will not return itself as its own synthetic value, but will (correctly) claim to itself be synthetic - cleared up the internal synthetic children architecture to make a more consistent use of pointers and references instead of shared pointers when possible - major cleanup of unnecessary #include, data and functions in ValueObjectSyntheticFilter itself - removed the SyntheticValueType enum and replaced it with a plain boolean (to which it was equivalent in the first place) Some clean ups to the summary generation code Centralized the code that clears out user-visible strings and data in ValueObject More efficient summaries for libc++ containers llvm-svn: 153061
2012-03-20 06:58:49 +08:00
ValueObject::ValueObjectRepresentationStyle val_obj_display = ValueObject::eValueObjectRepresentationStyleSummary;
Fixed some issues with ARM backtraces by not processing any push/pop instructions if they are conditional. Also fixed issues where the PC wasn't getting bit zero stripped for ARM targets when a stack frame was thumb. We now properly call through the GetOpcodeLoadAddress() functions to make sure the addresses are properly stripped for any targets that may decorate up their addresses. We now don't pass the SIGSTOP signals along. We can revisit this soon, but currently this was interfering with debugging some older ARM targets that don't have vCont support in the GDB server. llvm-svn: 134461
2011-07-06 12:07:21 +08:00
ValueObject* target = NULL;
Adopt the intrusive pointers in: lldb_private::Breakpoint lldb_private::BreakpointLocations lldb_private::BreakpointSite lldb_private::Debugger lldb_private::StackFrame lldb_private::Thread lldb_private::Target llvm-svn: 139985
2011-09-17 16:33:22 +08:00
Format custom_format = eFormatInvalid;
Fixed some issues with ARM backtraces by not processing any push/pop instructions if they are conditional. Also fixed issues where the PC wasn't getting bit zero stripped for ARM targets when a stack frame was thumb. We now properly call through the GetOpcodeLoadAddress() functions to make sure the addresses are properly stripped for any targets that may decorate up their addresses. We now don't pass the SIGSTOP signals along. We can revisit this soon, but currently this was interfering with debugging some older ARM targets that don't have vCont support in the GDB server. llvm-svn: 134461
2011-07-06 12:07:21 +08:00
const char* var_name_final = NULL;
const char* var_name_final_if_array_range = NULL;
const char* close_bracket_position = NULL;
int64_t index_lower = -1;
int64_t index_higher = -1;
bool is_array_range = false;
final fix for the global constructors issue new GetValueForExpressionPath() method in ValueObject to navigate expression paths in a more bitfield vs slices aware way changes to the varformats.html document (WIP) llvm-svn: 134679
2011-07-08 10:51:01 +08:00
const char* first_unparsed;
Second round of code cleanups: - reorganizing classes layout to have public part first Typedefs that we want to keep private, but must be defined for some public code to work correctly are an exception - avoiding methods in the form T foo() { code; } all on one-line - moving method implementations from .h to .cpp whenever feasible Templatized code is an exception and so are very small methods - generally, adhering to coding conventions followed project-wide Functional changes: - fixed an issue where using ${var} in a summary for an aggregate, and then displaying a pointer-to-aggregate would lead to no summary being displayed The issue was not a major one because all ${var} was meant to do in that context was display an error for invalid use of pointer Accordingly fixed test cases and added a new test case llvm-svn: 137944
2011-08-19 00:38:26 +08:00
bool was_plain_var = false;
bool was_var_format = false;
<rdar://problem/11338654> Fixing a bug where having a summary for a bitfield without a format specified would in certain cases crash LLDB - This has also led to refactoring the by-type accessors for the data formatter subsystem. These now belong in our internal layer, and are just invoked by the public API stratum llvm-svn: 156429
2012-05-09 05:49:57 +08:00
bool was_var_indexed = false;
final fix for the global constructors issue new GetValueForExpressionPath() method in ValueObject to navigate expression paths in a more bitfield vs slices aware way changes to the varformats.html document (WIP) llvm-svn: 134679
2011-07-08 10:51:01 +08:00
First round of code cleanups: - all instances of "vobj" have been renamed to "valobj" - class Debugger::Formatting has been renamed to DataVisualization (defined in FormatManager.h/cpp) The interface to this class has not changed - FormatCategory now uses ConstString's as keys to the navigators instead of repeatedly casting from ConstString to const char* and back all the time Next step is making the same happen for categories themselves - category gnu-libstdc++ is defined in the constructor for a FormatManager The source code for it is defined in gnu_libstdcpp.py, drawn from examples/synthetic at compile time All references to previous 'osxcpp' name have been removed from both code and file names Functional changes: - the name of the option to use a summary string for 'type summary add' has changed from the previous --format-string to the new --summary-string. It is expected that the short option will change from -f to -s, and -s for --python-script will become -o llvm-svn: 137886
2011-08-18 06:13:59 +08:00
if (!valobj) break;
// simplest case ${var}, just print valobj's value
Fixed some issues with ARM backtraces by not processing any push/pop instructions if they are conditional. Also fixed issues where the PC wasn't getting bit zero stripped for ARM targets when a stack frame was thumb. We now properly call through the GetOpcodeLoadAddress() functions to make sure the addresses are properly stripped for any targets that may decorate up their addresses. We now don't pass the SIGSTOP signals along. We can revisit this soon, but currently this was interfering with debugging some older ARM targets that don't have vCont support in the GDB server. llvm-svn: 134461
2011-07-06 12:07:21 +08:00
if (::strncmp (var_name_begin, "var}", strlen("var}")) == 0)
{
Second round of code cleanups: - reorganizing classes layout to have public part first Typedefs that we want to keep private, but must be defined for some public code to work correctly are an exception - avoiding methods in the form T foo() { code; } all on one-line - moving method implementations from .h to .cpp whenever feasible Templatized code is an exception and so are very small methods - generally, adhering to coding conventions followed project-wide Functional changes: - fixed an issue where using ${var} in a summary for an aggregate, and then displaying a pointer-to-aggregate would lead to no summary being displayed The issue was not a major one because all ${var} was meant to do in that context was display an error for invalid use of pointer Accordingly fixed test cases and added a new test case llvm-svn: 137944
2011-08-19 00:38:26 +08:00
was_plain_var = true;
First round of code cleanups: - all instances of "vobj" have been renamed to "valobj" - class Debugger::Formatting has been renamed to DataVisualization (defined in FormatManager.h/cpp) The interface to this class has not changed - FormatCategory now uses ConstString's as keys to the navigators instead of repeatedly casting from ConstString to const char* and back all the time Next step is making the same happen for categories themselves - category gnu-libstdc++ is defined in the constructor for a FormatManager The source code for it is defined in gnu_libstdcpp.py, drawn from examples/synthetic at compile time All references to previous 'osxcpp' name have been removed from both code and file names Functional changes: - the name of the option to use a summary string for 'type summary add' has changed from the previous --format-string to the new --summary-string. It is expected that the short option will change from -f to -s, and -s for --python-script will become -o llvm-svn: 137886
2011-08-18 06:13:59 +08:00
target = valobj;
Massive enumeration name changes: a number of enums in ValueObject were not following the naming pattern Changes to synthetic children: - the update(self): function can now (optionally) return a value - if it returns boolean value True, ValueObjectSyntheticFilter will not clear its caches across stop-points this should allow better performance for Python-based synthetic children when one can be sure that the child ValueObjects have not changed - making a difference between a synthetic VO and a VO with a synthetic value: now a ValueObjectSyntheticFilter will not return itself as its own synthetic value, but will (correctly) claim to itself be synthetic - cleared up the internal synthetic children architecture to make a more consistent use of pointers and references instead of shared pointers when possible - major cleanup of unnecessary #include, data and functions in ValueObjectSyntheticFilter itself - removed the SyntheticValueType enum and replaced it with a plain boolean (to which it was equivalent in the first place) Some clean ups to the summary generation code Centralized the code that clears out user-visible strings and data in ValueObject More efficient summaries for libc++ containers llvm-svn: 153061
2012-03-20 06:58:49 +08:00
val_obj_display = ValueObject::eValueObjectRepresentationStyleValue;
Fixed some issues with ARM backtraces by not processing any push/pop instructions if they are conditional. Also fixed issues where the PC wasn't getting bit zero stripped for ARM targets when a stack frame was thumb. We now properly call through the GetOpcodeLoadAddress() functions to make sure the addresses are properly stripped for any targets that may decorate up their addresses. We now don't pass the SIGSTOP signals along. We can revisit this soon, but currently this was interfering with debugging some older ARM targets that don't have vCont support in the GDB server. llvm-svn: 134461
2011-07-06 12:07:21 +08:00
}
else if (::strncmp(var_name_begin,"var%",strlen("var%")) == 0)
{
Second round of code cleanups: - reorganizing classes layout to have public part first Typedefs that we want to keep private, but must be defined for some public code to work correctly are an exception - avoiding methods in the form T foo() { code; } all on one-line - moving method implementations from .h to .cpp whenever feasible Templatized code is an exception and so are very small methods - generally, adhering to coding conventions followed project-wide Functional changes: - fixed an issue where using ${var} in a summary for an aggregate, and then displaying a pointer-to-aggregate would lead to no summary being displayed The issue was not a major one because all ${var} was meant to do in that context was display an error for invalid use of pointer Accordingly fixed test cases and added a new test case llvm-svn: 137944
2011-08-19 00:38:26 +08:00
was_var_format = true;
Fixed some issues with ARM backtraces by not processing any push/pop instructions if they are conditional. Also fixed issues where the PC wasn't getting bit zero stripped for ARM targets when a stack frame was thumb. We now properly call through the GetOpcodeLoadAddress() functions to make sure the addresses are properly stripped for any targets that may decorate up their addresses. We now don't pass the SIGSTOP signals along. We can revisit this soon, but currently this was interfering with debugging some older ARM targets that don't have vCont support in the GDB server. llvm-svn: 134461
2011-07-06 12:07:21 +08:00
// this is a variable with some custom format applied to it
const char* percent_position;
First round of code cleanups: - all instances of "vobj" have been renamed to "valobj" - class Debugger::Formatting has been renamed to DataVisualization (defined in FormatManager.h/cpp) The interface to this class has not changed - FormatCategory now uses ConstString's as keys to the navigators instead of repeatedly casting from ConstString to const char* and back all the time Next step is making the same happen for categories themselves - category gnu-libstdc++ is defined in the constructor for a FormatManager The source code for it is defined in gnu_libstdcpp.py, drawn from examples/synthetic at compile time All references to previous 'osxcpp' name have been removed from both code and file names Functional changes: - the name of the option to use a summary string for 'type summary add' has changed from the previous --format-string to the new --summary-string. It is expected that the short option will change from -f to -s, and -s for --python-script will become -o llvm-svn: 137886
2011-08-18 06:13:59 +08:00
target = valobj;
Massive enumeration name changes: a number of enums in ValueObject were not following the naming pattern Changes to synthetic children: - the update(self): function can now (optionally) return a value - if it returns boolean value True, ValueObjectSyntheticFilter will not clear its caches across stop-points this should allow better performance for Python-based synthetic children when one can be sure that the child ValueObjects have not changed - making a difference between a synthetic VO and a VO with a synthetic value: now a ValueObjectSyntheticFilter will not return itself as its own synthetic value, but will (correctly) claim to itself be synthetic - cleared up the internal synthetic children architecture to make a more consistent use of pointers and references instead of shared pointers when possible - major cleanup of unnecessary #include, data and functions in ValueObjectSyntheticFilter itself - removed the SyntheticValueType enum and replaced it with a plain boolean (to which it was equivalent in the first place) Some clean ups to the summary generation code Centralized the code that clears out user-visible strings and data in ValueObject More efficient summaries for libc++ containers llvm-svn: 153061
2012-03-20 06:58:49 +08:00
val_obj_display = ValueObject::eValueObjectRepresentationStyleValue;
Fixed some issues with ARM backtraces by not processing any push/pop instructions if they are conditional. Also fixed issues where the PC wasn't getting bit zero stripped for ARM targets when a stack frame was thumb. We now properly call through the GetOpcodeLoadAddress() functions to make sure the addresses are properly stripped for any targets that may decorate up their addresses. We now don't pass the SIGSTOP signals along. We can revisit this soon, but currently this was interfering with debugging some older ARM targets that don't have vCont support in the GDB server. llvm-svn: 134461
2011-07-06 12:07:21 +08:00
ScanFormatDescriptor (var_name_begin,
var_name_end,
&var_name_final,
&percent_position,
&custom_format,
&val_obj_display);
}
// this is ${var.something} or multiple .something nested
else if (::strncmp (var_name_begin, "var", strlen("var")) == 0)
This commit adds a new top subcommand "summary" to command type named "type". Currently this command implements three commands: type summary add <format> <typename1> [<typename2> ...] type summary delete <typename1> [<typename2> ...] type summary list [<typename1> [<typename2>] ...] type summary clear This allows you to specify the default format that will be used to display summaries for variables, shown when you use "frame variable" or "expression", or the SBValue classes. Examples: type summary add "x = ${var.x}" Point type summary list type summary add --one-liner SimpleType llvm-svn: 134108
2011-06-30 06:27:15 +08:00
{
<rdar://problem/11338654> Fixing a bug where having a summary for a bitfield without a format specified would in certain cases crash LLDB - This has also led to refactoring the by-type accessors for the data formatter subsystem. These now belong in our internal layer, and are just invoked by the public API stratum llvm-svn: 156429
2012-05-09 05:49:57 +08:00
if (::strncmp(var_name_begin, "var[", strlen("var[")) == 0)
was_var_indexed = true;
Fixed some issues with ARM backtraces by not processing any push/pop instructions if they are conditional. Also fixed issues where the PC wasn't getting bit zero stripped for ARM targets when a stack frame was thumb. We now properly call through the GetOpcodeLoadAddress() functions to make sure the addresses are properly stripped for any targets that may decorate up their addresses. We now don't pass the SIGSTOP signals along. We can revisit this soon, but currently this was interfering with debugging some older ARM targets that don't have vCont support in the GDB server. llvm-svn: 134461
2011-07-06 12:07:21 +08:00
const char* percent_position;
ScanFormatDescriptor (var_name_begin,
var_name_end,
&var_name_final,
&percent_position,
&custom_format,
&val_obj_display);
const char* open_bracket_position;
const char* separator_position;
ScanBracketedRange (var_name_begin,
var_name_end,
var_name_final,
&open_bracket_position,
&separator_position,
&close_bracket_position,
&var_name_final_if_array_range,
&index_lower,
&index_higher);
Error error;
final fix for the global constructors issue new GetValueForExpressionPath() method in ValueObject to navigate expression paths in a more bitfield vs slices aware way changes to the varformats.html document (WIP) llvm-svn: 134679
2011-07-08 10:51:01 +08:00
std::auto_ptr<char> expr_path(new char[var_name_final-var_name_begin-1]);
::memset(expr_path.get(), 0, var_name_final-var_name_begin-1);
memcpy(expr_path.get(), var_name_begin+3,var_name_final-var_name_begin-3);
some editing of data visualization error messages to make them more meaningful debugging printfs() for data visualization turned into a meaningful log: - introduced a new log category `types' in channel `lldb' llvm-svn: 135773
2011-07-23 01:03:19 +08:00
if (log)
log->Printf("symbol to expand: %s",expr_path.get());
final fix for the global constructors issue new GetValueForExpressionPath() method in ValueObject to navigate expression paths in a more bitfield vs slices aware way changes to the varformats.html document (WIP) llvm-svn: 134679
2011-07-08 10:51:01 +08:00
First round of code cleanups: - all instances of "vobj" have been renamed to "valobj" - class Debugger::Formatting has been renamed to DataVisualization (defined in FormatManager.h/cpp) The interface to this class has not changed - FormatCategory now uses ConstString's as keys to the navigators instead of repeatedly casting from ConstString to const char* and back all the time Next step is making the same happen for categories themselves - category gnu-libstdc++ is defined in the constructor for a FormatManager The source code for it is defined in gnu_libstdcpp.py, drawn from examples/synthetic at compile time All references to previous 'osxcpp' name have been removed from both code and file names Functional changes: - the name of the option to use a summary string for 'type summary add' has changed from the previous --format-string to the new --summary-string. It is expected that the short option will change from -f to -s, and -s for --python-script will become -o llvm-svn: 137886
2011-08-18 06:13:59 +08:00
target = valobj->GetValueForExpressionPath(expr_path.get(),
final fix for the global constructors issue new GetValueForExpressionPath() method in ValueObject to navigate expression paths in a more bitfield vs slices aware way changes to the varformats.html document (WIP) llvm-svn: 134679
2011-07-08 10:51:01 +08:00
&first_unparsed,
&reason_to_stop,
&final_value_type,
options,
&what_next).get();
if (!target)
Fixed some issues with ARM backtraces by not processing any push/pop instructions if they are conditional. Also fixed issues where the PC wasn't getting bit zero stripped for ARM targets when a stack frame was thumb. We now properly call through the GetOpcodeLoadAddress() functions to make sure the addresses are properly stripped for any targets that may decorate up their addresses. We now don't pass the SIGSTOP signals along. We can revisit this soon, but currently this was interfering with debugging some older ARM targets that don't have vCont support in the GDB server. llvm-svn: 134461
2011-07-06 12:07:21 +08:00
{
some editing of data visualization error messages to make them more meaningful debugging printfs() for data visualization turned into a meaningful log: - introduced a new log category `types' in channel `lldb' llvm-svn: 135773
2011-07-23 01:03:19 +08:00
if (log)
log->Printf("ERROR: unparsed portion = %s, why stopping = %d,"
" final_value_type %d",
final fix for the global constructors issue new GetValueForExpressionPath() method in ValueObject to navigate expression paths in a more bitfield vs slices aware way changes to the varformats.html document (WIP) llvm-svn: 134679
2011-07-08 10:51:01 +08:00
first_unparsed, reason_to_stop, final_value_type);
break;
new syntax for summary strings: - ${*expr} now simply means to dereference expr before actually using it - bitfields, array ranges and pointer ranges now work in a (hopefully) more natural and language-compliant way a new class TypeHierarchyNavigator replicates the behavior of the FormatManager in going through type hierarchies when one-lining summary strings, children's summaries can be used as well as values llvm-svn: 134458
2011-07-06 10:13:41 +08:00
}
final fix for the global constructors issue new GetValueForExpressionPath() method in ValueObject to navigate expression paths in a more bitfield vs slices aware way changes to the varformats.html document (WIP) llvm-svn: 134679
2011-07-08 10:51:01 +08:00
else
{
some editing of data visualization error messages to make them more meaningful debugging printfs() for data visualization turned into a meaningful log: - introduced a new log category `types' in channel `lldb' llvm-svn: 135773
2011-07-23 01:03:19 +08:00
if (log)
log->Printf("ALL RIGHT: unparsed portion = %s, why stopping = %d,"
" final_value_type %d",
final fix for the global constructors issue new GetValueForExpressionPath() method in ValueObject to navigate expression paths in a more bitfield vs slices aware way changes to the varformats.html document (WIP) llvm-svn: 134679
2011-07-08 10:51:01 +08:00
first_unparsed, reason_to_stop, final_value_type);
}
Fixed some issues with ARM backtraces by not processing any push/pop instructions if they are conditional. Also fixed issues where the PC wasn't getting bit zero stripped for ARM targets when a stack frame was thumb. We now properly call through the GetOpcodeLoadAddress() functions to make sure the addresses are properly stripped for any targets that may decorate up their addresses. We now don't pass the SIGSTOP signals along. We can revisit this soon, but currently this was interfering with debugging some older ARM targets that don't have vCont support in the GDB server. llvm-svn: 134461
2011-07-06 12:07:21 +08:00
}
else
new syntax for summary strings: - ${*expr} now simply means to dereference expr before actually using it - bitfields, array ranges and pointer ranges now work in a (hopefully) more natural and language-compliant way a new class TypeHierarchyNavigator replicates the behavior of the FormatManager in going through type hierarchies when one-lining summary strings, children's summaries can be used as well as values llvm-svn: 134458
2011-07-06 10:13:41 +08:00
break;
final fix for the global constructors issue new GetValueForExpressionPath() method in ValueObject to navigate expression paths in a more bitfield vs slices aware way changes to the varformats.html document (WIP) llvm-svn: 134679
2011-07-08 10:51:01 +08:00
Massive enumeration name changes: a number of enums in ValueObject were not following the naming pattern Changes to synthetic children: - the update(self): function can now (optionally) return a value - if it returns boolean value True, ValueObjectSyntheticFilter will not clear its caches across stop-points this should allow better performance for Python-based synthetic children when one can be sure that the child ValueObjects have not changed - making a difference between a synthetic VO and a VO with a synthetic value: now a ValueObjectSyntheticFilter will not return itself as its own synthetic value, but will (correctly) claim to itself be synthetic - cleared up the internal synthetic children architecture to make a more consistent use of pointers and references instead of shared pointers when possible - major cleanup of unnecessary #include, data and functions in ValueObjectSyntheticFilter itself - removed the SyntheticValueType enum and replaced it with a plain boolean (to which it was equivalent in the first place) Some clean ups to the summary generation code Centralized the code that clears out user-visible strings and data in ValueObject More efficient summaries for libc++ containers llvm-svn: 153061
2012-03-20 06:58:49 +08:00
is_array_range = (final_value_type == ValueObject::eExpressionPathEndResultTypeBoundedRange ||
final_value_type == ValueObject::eExpressionPathEndResultTypeUnboundedRange);
final fix for the global constructors issue new GetValueForExpressionPath() method in ValueObject to navigate expression paths in a more bitfield vs slices aware way changes to the varformats.html document (WIP) llvm-svn: 134679
2011-07-08 10:51:01 +08:00
Massive enumeration name changes: a number of enums in ValueObject were not following the naming pattern Changes to synthetic children: - the update(self): function can now (optionally) return a value - if it returns boolean value True, ValueObjectSyntheticFilter will not clear its caches across stop-points this should allow better performance for Python-based synthetic children when one can be sure that the child ValueObjects have not changed - making a difference between a synthetic VO and a VO with a synthetic value: now a ValueObjectSyntheticFilter will not return itself as its own synthetic value, but will (correctly) claim to itself be synthetic - cleared up the internal synthetic children architecture to make a more consistent use of pointers and references instead of shared pointers when possible - major cleanup of unnecessary #include, data and functions in ValueObjectSyntheticFilter itself - removed the SyntheticValueType enum and replaced it with a plain boolean (to which it was equivalent in the first place) Some clean ups to the summary generation code Centralized the code that clears out user-visible strings and data in ValueObject More efficient summaries for libc++ containers llvm-svn: 153061
2012-03-20 06:58:49 +08:00
do_deref_pointer = (what_next == ValueObject::eExpressionPathAftermathDereference);
Fixed some issues with ARM backtraces by not processing any push/pop instructions if they are conditional. Also fixed issues where the PC wasn't getting bit zero stripped for ARM targets when a stack frame was thumb. We now properly call through the GetOpcodeLoadAddress() functions to make sure the addresses are properly stripped for any targets that may decorate up their addresses. We now don't pass the SIGSTOP signals along. We can revisit this soon, but currently this was interfering with debugging some older ARM targets that don't have vCont support in the GDB server. llvm-svn: 134461
2011-07-06 12:07:21 +08:00
bug fix in summary strings: - ${*var[].something} was not working as expected options -p and -r now also work for type format add llvm-svn: 134523
2011-07-07 03:27:11 +08:00
if (do_deref_pointer && !is_array_range)
new syntax for summary strings: - ${*expr} now simply means to dereference expr before actually using it - bitfields, array ranges and pointer ranges now work in a (hopefully) more natural and language-compliant way a new class TypeHierarchyNavigator replicates the behavior of the FormatManager in going through type hierarchies when one-lining summary strings, children's summaries can be used as well as values llvm-svn: 134458
2011-07-06 10:13:41 +08:00
{
Fixed some issues with ARM backtraces by not processing any push/pop instructions if they are conditional. Also fixed issues where the PC wasn't getting bit zero stripped for ARM targets when a stack frame was thumb. We now properly call through the GetOpcodeLoadAddress() functions to make sure the addresses are properly stripped for any targets that may decorate up their addresses. We now don't pass the SIGSTOP signals along. We can revisit this soon, but currently this was interfering with debugging some older ARM targets that don't have vCont support in the GDB server. llvm-svn: 134461
2011-07-06 12:07:21 +08:00
// I have not deref-ed yet, let's do it
// this happens when we are not going through GetValueForVariableExpressionPath
// to get to the target ValueObject
Error error;
target = target->Dereference(error).get();
Additional code cleanups ; Short option name for --python-script in type summary add moved from -s to -o (this is a preliminary step in moving the short option for --summary-string from -f to -s) ; Accordingly updated the test suite llvm-svn: 138315
2011-08-23 08:32:52 +08:00
if (error.Fail())
{
if (log)
log->Printf("ERROR: %s\n", error.AsCString("unknown")); \
break;
}
Fixed some issues with ARM backtraces by not processing any push/pop instructions if they are conditional. Also fixed issues where the PC wasn't getting bit zero stripped for ARM targets when a stack frame was thumb. We now properly call through the GetOpcodeLoadAddress() functions to make sure the addresses are properly stripped for any targets that may decorate up their addresses. We now don't pass the SIGSTOP signals along. We can revisit this soon, but currently this was interfering with debugging some older ARM targets that don't have vCont support in the GDB server. llvm-svn: 134461
2011-07-06 12:07:21 +08:00
do_deref_pointer = false;
new syntax for summary strings: - ${*expr} now simply means to dereference expr before actually using it - bitfields, array ranges and pointer ranges now work in a (hopefully) more natural and language-compliant way a new class TypeHierarchyNavigator replicates the behavior of the FormatManager in going through type hierarchies when one-lining summary strings, children's summaries can be used as well as values llvm-svn: 134458
2011-07-06 10:13:41 +08:00
}
smarter summary strings: - formats %s %char[] %c and %a now work to print 0-terminated c-strings if they are applied to a char* or char[] even without the [] operator (e.g. ${var%s}) - array formats (char[], intN[], ..) now work when applied to an array of a scalar type even without the [] operator (e.g. ${var%int32_t[]}) LLDB will not crash because of endless loop when trying to obtain a summary for an object that has no value and references itself in its summary string In many cases, a wrong summary string will now display an "<error>" message instead of giving out an empty string llvm-svn: 135007
2011-07-13 06:56:10 +08:00
<rdar://problem/11338654> Fixing a bug where having a summary for a bitfield without a format specified would in certain cases crash LLDB - This has also led to refactoring the by-type accessors for the data formatter subsystem. These now belong in our internal layer, and are just invoked by the public API stratum llvm-svn: 156429
2012-05-09 05:49:57 +08:00
// <rdar://problem/11338654>
// we do not want to use the summary for a bitfield of type T:n
// if we were originally dealing with just a T - that would get
// us into an endless recursion
if (target->IsBitfield() && was_var_indexed)
{
// TODO: check for a (T:n)-specific summary - we should still obey that
StreamString bitfield_name;
bitfield_name.Printf("%s:%d", target->GetTypeName().AsCString(), target->GetBitfieldBitSize());
lldb::TypeNameSpecifierImplSP type_sp(new TypeNameSpecifierImpl(bitfield_name.GetData(),false));
if (!DataVisualization::GetSummaryForType(type_sp))
val_obj_display = ValueObject::eValueObjectRepresentationStyleValue;
}
Second round of code cleanups: - reorganizing classes layout to have public part first Typedefs that we want to keep private, but must be defined for some public code to work correctly are an exception - avoiding methods in the form T foo() { code; } all on one-line - moving method implementations from .h to .cpp whenever feasible Templatized code is an exception and so are very small methods - generally, adhering to coding conventions followed project-wide Functional changes: - fixed an issue where using ${var} in a summary for an aggregate, and then displaying a pointer-to-aggregate would lead to no summary being displayed The issue was not a major one because all ${var} was meant to do in that context was display an error for invalid use of pointer Accordingly fixed test cases and added a new test case llvm-svn: 137944
2011-08-19 00:38:26 +08:00
// TODO use flags for these
smarter summary strings: - formats %s %char[] %c and %a now work to print 0-terminated c-strings if they are applied to a char* or char[] even without the [] operator (e.g. ${var%s}) - array formats (char[], intN[], ..) now work when applied to an array of a scalar type even without the [] operator (e.g. ${var%int32_t[]}) LLDB will not crash because of endless loop when trying to obtain a summary for an object that has no value and references itself in its summary string In many cases, a wrong summary string will now display an "<error>" message instead of giving out an empty string llvm-svn: 135007
2011-07-13 06:56:10 +08:00
bool is_array = ClangASTContext::IsArrayType(target->GetClangType());
bool is_pointer = ClangASTContext::IsPointerType(target->GetClangType());
Second round of code cleanups: - reorganizing classes layout to have public part first Typedefs that we want to keep private, but must be defined for some public code to work correctly are an exception - avoiding methods in the form T foo() { code; } all on one-line - moving method implementations from .h to .cpp whenever feasible Templatized code is an exception and so are very small methods - generally, adhering to coding conventions followed project-wide Functional changes: - fixed an issue where using ${var} in a summary for an aggregate, and then displaying a pointer-to-aggregate would lead to no summary being displayed The issue was not a major one because all ${var} was meant to do in that context was display an error for invalid use of pointer Accordingly fixed test cases and added a new test case llvm-svn: 137944
2011-08-19 00:38:26 +08:00
bool is_aggregate = ClangASTContext::IsAggregateType(target->GetClangType());
smarter summary strings: - formats %s %char[] %c and %a now work to print 0-terminated c-strings if they are applied to a char* or char[] even without the [] operator (e.g. ${var%s}) - array formats (char[], intN[], ..) now work when applied to an array of a scalar type even without the [] operator (e.g. ${var%int32_t[]}) LLDB will not crash because of endless loop when trying to obtain a summary for an object that has no value and references itself in its summary string In many cases, a wrong summary string will now display an "<error>" message instead of giving out an empty string llvm-svn: 135007
2011-07-13 06:56:10 +08:00
Massive enumeration name changes: a number of enums in ValueObject were not following the naming pattern Changes to synthetic children: - the update(self): function can now (optionally) return a value - if it returns boolean value True, ValueObjectSyntheticFilter will not clear its caches across stop-points this should allow better performance for Python-based synthetic children when one can be sure that the child ValueObjects have not changed - making a difference between a synthetic VO and a VO with a synthetic value: now a ValueObjectSyntheticFilter will not return itself as its own synthetic value, but will (correctly) claim to itself be synthetic - cleared up the internal synthetic children architecture to make a more consistent use of pointers and references instead of shared pointers when possible - major cleanup of unnecessary #include, data and functions in ValueObjectSyntheticFilter itself - removed the SyntheticValueType enum and replaced it with a plain boolean (to which it was equivalent in the first place) Some clean ups to the summary generation code Centralized the code that clears out user-visible strings and data in ValueObject More efficient summaries for libc++ containers llvm-svn: 153061
2012-03-20 06:58:49 +08:00
if ((is_array || is_pointer) && (!is_array_range) && val_obj_display == ValueObject::eValueObjectRepresentationStyleValue) // this should be wrong, but there are some exceptions
smarter summary strings: - formats %s %char[] %c and %a now work to print 0-terminated c-strings if they are applied to a char* or char[] even without the [] operator (e.g. ${var%s}) - array formats (char[], intN[], ..) now work when applied to an array of a scalar type even without the [] operator (e.g. ${var%int32_t[]}) LLDB will not crash because of endless loop when trying to obtain a summary for an object that has no value and references itself in its summary string In many cases, a wrong summary string will now display an "<error>" message instead of giving out an empty string llvm-svn: 135007
2011-07-13 06:56:10 +08:00
{
Second round of code cleanups: - reorganizing classes layout to have public part first Typedefs that we want to keep private, but must be defined for some public code to work correctly are an exception - avoiding methods in the form T foo() { code; } all on one-line - moving method implementations from .h to .cpp whenever feasible Templatized code is an exception and so are very small methods - generally, adhering to coding conventions followed project-wide Functional changes: - fixed an issue where using ${var} in a summary for an aggregate, and then displaying a pointer-to-aggregate would lead to no summary being displayed The issue was not a major one because all ${var} was meant to do in that context was display an error for invalid use of pointer Accordingly fixed test cases and added a new test case llvm-svn: 137944
2011-08-19 00:38:26 +08:00
StreamString str_temp;
some editing of data visualization error messages to make them more meaningful debugging printfs() for data visualization turned into a meaningful log: - introduced a new log category `types' in channel `lldb' llvm-svn: 135773
2011-07-23 01:03:19 +08:00
if (log)
log->Printf("I am into array || pointer && !range");
- Now using ${var} as the summary for an aggregate type will produce "name-of-type @ object-location" instead of giving an error e.g. you may get "foo_class @ 0x123456" when typing "type summary add -f ${var} foo_class" - Added a new special formatting token %T for summaries. This shows the type of the object. Using it, the new "type @ location" summary could be manually generated by writing ${var%T} @ ${var%L} - Bits and pieces required to support "frame variable array[n-m]" The feature is not enabled yet because some additional design and support code is required, but the basics are getting there - Fixed a potential issue where a ValueObjectSyntheticFilter was not holding on to its SyntheticChildrenSP Because of the way VOSF are being built now, this has never been an actual issue, but it is still sensible for a VOSF to hold on to the SyntheticChildrenSP as well as to its FrontEnd llvm-svn: 138080
2011-08-20 05:13:46 +08:00
Massive enumeration name changes: a number of enums in ValueObject were not following the naming pattern Changes to synthetic children: - the update(self): function can now (optionally) return a value - if it returns boolean value True, ValueObjectSyntheticFilter will not clear its caches across stop-points this should allow better performance for Python-based synthetic children when one can be sure that the child ValueObjects have not changed - making a difference between a synthetic VO and a VO with a synthetic value: now a ValueObjectSyntheticFilter will not return itself as its own synthetic value, but will (correctly) claim to itself be synthetic - cleared up the internal synthetic children architecture to make a more consistent use of pointers and references instead of shared pointers when possible - major cleanup of unnecessary #include, data and functions in ValueObjectSyntheticFilter itself - removed the SyntheticValueType enum and replaced it with a plain boolean (to which it was equivalent in the first place) Some clean ups to the summary generation code Centralized the code that clears out user-visible strings and data in ValueObject More efficient summaries for libc++ containers llvm-svn: 153061
2012-03-20 06:58:49 +08:00
if (target->HasSpecialPrintableRepresentation(val_obj_display,
custom_format))
Second round of code cleanups: - reorganizing classes layout to have public part first Typedefs that we want to keep private, but must be defined for some public code to work correctly are an exception - avoiding methods in the form T foo() { code; } all on one-line - moving method implementations from .h to .cpp whenever feasible Templatized code is an exception and so are very small methods - generally, adhering to coding conventions followed project-wide Functional changes: - fixed an issue where using ${var} in a summary for an aggregate, and then displaying a pointer-to-aggregate would lead to no summary being displayed The issue was not a major one because all ${var} was meant to do in that context was display an error for invalid use of pointer Accordingly fixed test cases and added a new test case llvm-svn: 137944
2011-08-19 00:38:26 +08:00
{
- Now using ${var} as the summary for an aggregate type will produce "name-of-type @ object-location" instead of giving an error e.g. you may get "foo_class @ 0x123456" when typing "type summary add -f ${var} foo_class" - Added a new special formatting token %T for summaries. This shows the type of the object. Using it, the new "type @ location" summary could be manually generated by writing ${var%T} @ ${var%L} - Bits and pieces required to support "frame variable array[n-m]" The feature is not enabled yet because some additional design and support code is required, but the basics are getting there - Fixed a potential issue where a ValueObjectSyntheticFilter was not holding on to its SyntheticChildrenSP Because of the way VOSF are being built now, this has never been an actual issue, but it is still sensible for a VOSF to hold on to the SyntheticChildrenSP as well as to its FrontEnd llvm-svn: 138080
2011-08-20 05:13:46 +08:00
// try to use the special cases
var_success = target->DumpPrintableRepresentation(str_temp,
val_obj_display,
custom_format);
if (log)
log->Printf("special cases did%s match", var_success ? "" : "n't");
// should not happen
if (!var_success)
s << "<invalid usage of pointer value as object>";
else
s << str_temp.GetData();
Second round of code cleanups: - reorganizing classes layout to have public part first Typedefs that we want to keep private, but must be defined for some public code to work correctly are an exception - avoiding methods in the form T foo() { code; } all on one-line - moving method implementations from .h to .cpp whenever feasible Templatized code is an exception and so are very small methods - generally, adhering to coding conventions followed project-wide Functional changes: - fixed an issue where using ${var} in a summary for an aggregate, and then displaying a pointer-to-aggregate would lead to no summary being displayed The issue was not a major one because all ${var} was meant to do in that context was display an error for invalid use of pointer Accordingly fixed test cases and added a new test case llvm-svn: 137944
2011-08-19 00:38:26 +08:00
var_success = true;
- Now using ${var} as the summary for an aggregate type will produce "name-of-type @ object-location" instead of giving an error e.g. you may get "foo_class @ 0x123456" when typing "type summary add -f ${var} foo_class" - Added a new special formatting token %T for summaries. This shows the type of the object. Using it, the new "type @ location" summary could be manually generated by writing ${var%T} @ ${var%L} - Bits and pieces required to support "frame variable array[n-m]" The feature is not enabled yet because some additional design and support code is required, but the basics are getting there - Fixed a potential issue where a ValueObjectSyntheticFilter was not holding on to its SyntheticChildrenSP Because of the way VOSF are being built now, this has never been an actual issue, but it is still sensible for a VOSF to hold on to the SyntheticChildrenSP as well as to its FrontEnd llvm-svn: 138080
2011-08-20 05:13:46 +08:00
break;
Second round of code cleanups: - reorganizing classes layout to have public part first Typedefs that we want to keep private, but must be defined for some public code to work correctly are an exception - avoiding methods in the form T foo() { code; } all on one-line - moving method implementations from .h to .cpp whenever feasible Templatized code is an exception and so are very small methods - generally, adhering to coding conventions followed project-wide Functional changes: - fixed an issue where using ${var} in a summary for an aggregate, and then displaying a pointer-to-aggregate would lead to no summary being displayed The issue was not a major one because all ${var} was meant to do in that context was display an error for invalid use of pointer Accordingly fixed test cases and added a new test case llvm-svn: 137944
2011-08-19 00:38:26 +08:00
}
else
- Now using ${var} as the summary for an aggregate type will produce "name-of-type @ object-location" instead of giving an error e.g. you may get "foo_class @ 0x123456" when typing "type summary add -f ${var} foo_class" - Added a new special formatting token %T for summaries. This shows the type of the object. Using it, the new "type @ location" summary could be manually generated by writing ${var%T} @ ${var%L} - Bits and pieces required to support "frame variable array[n-m]" The feature is not enabled yet because some additional design and support code is required, but the basics are getting there - Fixed a potential issue where a ValueObjectSyntheticFilter was not holding on to its SyntheticChildrenSP Because of the way VOSF are being built now, this has never been an actual issue, but it is still sensible for a VOSF to hold on to the SyntheticChildrenSP as well as to its FrontEnd llvm-svn: 138080
2011-08-20 05:13:46 +08:00
{
Improved the user-friendliness of errors shown by the summary feature in certain areas Renamed format "signed decimal" to be "decimal". "unsigned decimal" remains unchanged: - the name "signed decimal" was interfering with symbol %S (use summary) in summary strings. because of the way summary strings are implemented, this did not really lead to a bug, but simply to performing more steps than necessary to display a summary. this is fixed. Documentation improvements (more on synthetic children, some information on filters). This is still a WIP. llvm-svn: 138384
2011-08-24 05:26:09 +08:00
if (was_plain_var) // if ${var}
- Now using ${var} as the summary for an aggregate type will produce "name-of-type @ object-location" instead of giving an error e.g. you may get "foo_class @ 0x123456" when typing "type summary add -f ${var} foo_class" - Added a new special formatting token %T for summaries. This shows the type of the object. Using it, the new "type @ location" summary could be manually generated by writing ${var%T} @ ${var%L} - Bits and pieces required to support "frame variable array[n-m]" The feature is not enabled yet because some additional design and support code is required, but the basics are getting there - Fixed a potential issue where a ValueObjectSyntheticFilter was not holding on to its SyntheticChildrenSP Because of the way VOSF are being built now, this has never been an actual issue, but it is still sensible for a VOSF to hold on to the SyntheticChildrenSP as well as to its FrontEnd llvm-svn: 138080
2011-08-20 05:13:46 +08:00
{
s << target->GetTypeName() << " @ " << target->GetLocationAsCString();
}
Improved the user-friendliness of errors shown by the summary feature in certain areas Renamed format "signed decimal" to be "decimal". "unsigned decimal" remains unchanged: - the name "signed decimal" was interfering with symbol %S (use summary) in summary strings. because of the way summary strings are implemented, this did not really lead to a bug, but simply to performing more steps than necessary to display a summary. this is fixed. Documentation improvements (more on synthetic children, some information on filters). This is still a WIP. llvm-svn: 138384
2011-08-24 05:26:09 +08:00
else if (is_pointer) // if pointer, value is the address stored
{
Ran the static analyzer on the codebase and found a few things. llvm-svn: 160338
2012-07-17 11:23:13 +08:00
target->DumpPrintableRepresentation (s,
val_obj_display,
custom_format,
ValueObject::ePrintableRepresentationSpecialCasesDisable);
Improved the user-friendliness of errors shown by the summary feature in certain areas Renamed format "signed decimal" to be "decimal". "unsigned decimal" remains unchanged: - the name "signed decimal" was interfering with symbol %S (use summary) in summary strings. because of the way summary strings are implemented, this did not really lead to a bug, but simply to performing more steps than necessary to display a summary. this is fixed. Documentation improvements (more on synthetic children, some information on filters). This is still a WIP. llvm-svn: 138384
2011-08-24 05:26:09 +08:00
}
- Now using ${var} as the summary for an aggregate type will produce "name-of-type @ object-location" instead of giving an error e.g. you may get "foo_class @ 0x123456" when typing "type summary add -f ${var} foo_class" - Added a new special formatting token %T for summaries. This shows the type of the object. Using it, the new "type @ location" summary could be manually generated by writing ${var%T} @ ${var%L} - Bits and pieces required to support "frame variable array[n-m]" The feature is not enabled yet because some additional design and support code is required, but the basics are getting there - Fixed a potential issue where a ValueObjectSyntheticFilter was not holding on to its SyntheticChildrenSP Because of the way VOSF are being built now, this has never been an actual issue, but it is still sensible for a VOSF to hold on to the SyntheticChildrenSP as well as to its FrontEnd llvm-svn: 138080
2011-08-20 05:13:46 +08:00
else
{
s << "<invalid usage of pointer value as object>";
}
var_success = true;
break;
}
}
// if directly trying to print ${var}, and this is an aggregate, display a nice
// type @ location message
if (is_aggregate && was_plain_var)
{
s << target->GetTypeName() << " @ " << target->GetLocationAsCString();
var_success = true;
Second round of code cleanups: - reorganizing classes layout to have public part first Typedefs that we want to keep private, but must be defined for some public code to work correctly are an exception - avoiding methods in the form T foo() { code; } all on one-line - moving method implementations from .h to .cpp whenever feasible Templatized code is an exception and so are very small methods - generally, adhering to coding conventions followed project-wide Functional changes: - fixed an issue where using ${var} in a summary for an aggregate, and then displaying a pointer-to-aggregate would lead to no summary being displayed The issue was not a major one because all ${var} was meant to do in that context was display an error for invalid use of pointer Accordingly fixed test cases and added a new test case llvm-svn: 137944
2011-08-19 00:38:26 +08:00
break;
}
- Now using ${var} as the summary for an aggregate type will produce "name-of-type @ object-location" instead of giving an error e.g. you may get "foo_class @ 0x123456" when typing "type summary add -f ${var} foo_class" - Added a new special formatting token %T for summaries. This shows the type of the object. Using it, the new "type @ location" summary could be manually generated by writing ${var%T} @ ${var%L} - Bits and pieces required to support "frame variable array[n-m]" The feature is not enabled yet because some additional design and support code is required, but the basics are getting there - Fixed a potential issue where a ValueObjectSyntheticFilter was not holding on to its SyntheticChildrenSP Because of the way VOSF are being built now, this has never been an actual issue, but it is still sensible for a VOSF to hold on to the SyntheticChildrenSP as well as to its FrontEnd llvm-svn: 138080
2011-08-20 05:13:46 +08:00
// if directly trying to print ${var%V}, and this is an aggregate, do not let the user do it
Massive enumeration name changes: a number of enums in ValueObject were not following the naming pattern Changes to synthetic children: - the update(self): function can now (optionally) return a value - if it returns boolean value True, ValueObjectSyntheticFilter will not clear its caches across stop-points this should allow better performance for Python-based synthetic children when one can be sure that the child ValueObjects have not changed - making a difference between a synthetic VO and a VO with a synthetic value: now a ValueObjectSyntheticFilter will not return itself as its own synthetic value, but will (correctly) claim to itself be synthetic - cleared up the internal synthetic children architecture to make a more consistent use of pointers and references instead of shared pointers when possible - major cleanup of unnecessary #include, data and functions in ValueObjectSyntheticFilter itself - removed the SyntheticValueType enum and replaced it with a plain boolean (to which it was equivalent in the first place) Some clean ups to the summary generation code Centralized the code that clears out user-visible strings and data in ValueObject More efficient summaries for libc++ containers llvm-svn: 153061
2012-03-20 06:58:49 +08:00
if (is_aggregate && ((was_var_format && val_obj_display == ValueObject::eValueObjectRepresentationStyleValue)))
Second round of code cleanups: - reorganizing classes layout to have public part first Typedefs that we want to keep private, but must be defined for some public code to work correctly are an exception - avoiding methods in the form T foo() { code; } all on one-line - moving method implementations from .h to .cpp whenever feasible Templatized code is an exception and so are very small methods - generally, adhering to coding conventions followed project-wide Functional changes: - fixed an issue where using ${var} in a summary for an aggregate, and then displaying a pointer-to-aggregate would lead to no summary being displayed The issue was not a major one because all ${var} was meant to do in that context was display an error for invalid use of pointer Accordingly fixed test cases and added a new test case llvm-svn: 137944
2011-08-19 00:38:26 +08:00
{
s << "<invalid use of aggregate type>";
var_success = true;
smarter summary strings: - formats %s %char[] %c and %a now work to print 0-terminated c-strings if they are applied to a char* or char[] even without the [] operator (e.g. ${var%s}) - array formats (char[], intN[], ..) now work when applied to an array of a scalar type even without the [] operator (e.g. ${var%int32_t[]}) LLDB will not crash because of endless loop when trying to obtain a summary for an object that has no value and references itself in its summary string In many cases, a wrong summary string will now display an "<error>" message instead of giving out an empty string llvm-svn: 135007
2011-07-13 06:56:10 +08:00
break;
}
Fixed some issues with ARM backtraces by not processing any push/pop instructions if they are conditional. Also fixed issues where the PC wasn't getting bit zero stripped for ARM targets when a stack frame was thumb. We now properly call through the GetOpcodeLoadAddress() functions to make sure the addresses are properly stripped for any targets that may decorate up their addresses. We now don't pass the SIGSTOP signals along. We can revisit this soon, but currently this was interfering with debugging some older ARM targets that don't have vCont support in the GDB server. llvm-svn: 134461
2011-07-06 12:07:21 +08:00
if (!is_array_range)
some editing of data visualization error messages to make them more meaningful debugging printfs() for data visualization turned into a meaningful log: - introduced a new log category `types' in channel `lldb' llvm-svn: 135773
2011-07-23 01:03:19 +08:00
{
if (log)
log->Printf("dumping ordinary printable output");
Fixed some issues with ARM backtraces by not processing any push/pop instructions if they are conditional. Also fixed issues where the PC wasn't getting bit zero stripped for ARM targets when a stack frame was thumb. We now properly call through the GetOpcodeLoadAddress() functions to make sure the addresses are properly stripped for any targets that may decorate up their addresses. We now don't pass the SIGSTOP signals along. We can revisit this soon, but currently this was interfering with debugging some older ARM targets that don't have vCont support in the GDB server. llvm-svn: 134461
2011-07-06 12:07:21 +08:00
var_success = target->DumpPrintableRepresentation(s,val_obj_display, custom_format);
some editing of data visualization error messages to make them more meaningful debugging printfs() for data visualization turned into a meaningful log: - introduced a new log category `types' in channel `lldb' llvm-svn: 135773
2011-07-23 01:03:19 +08:00
}
Fixed some issues with ARM backtraces by not processing any push/pop instructions if they are conditional. Also fixed issues where the PC wasn't getting bit zero stripped for ARM targets when a stack frame was thumb. We now properly call through the GetOpcodeLoadAddress() functions to make sure the addresses are properly stripped for any targets that may decorate up their addresses. We now don't pass the SIGSTOP signals along. We can revisit this soon, but currently this was interfering with debugging some older ARM targets that don't have vCont support in the GDB server. llvm-svn: 134461
2011-07-06 12:07:21 +08:00
else
some editing of data visualization error messages to make them more meaningful debugging printfs() for data visualization turned into a meaningful log: - introduced a new log category `types' in channel `lldb' llvm-svn: 135773
2011-07-23 01:03:19 +08:00
{
if (log)
log->Printf("checking if I can handle as array");
Fixed some issues with ARM backtraces by not processing any push/pop instructions if they are conditional. Also fixed issues where the PC wasn't getting bit zero stripped for ARM targets when a stack frame was thumb. We now properly call through the GetOpcodeLoadAddress() functions to make sure the addresses are properly stripped for any targets that may decorate up their addresses. We now don't pass the SIGSTOP signals along. We can revisit this soon, but currently this was interfering with debugging some older ARM targets that don't have vCont support in the GDB server. llvm-svn: 134461
2011-07-06 12:07:21 +08:00
if (!is_array && !is_pointer)
break;
some editing of data visualization error messages to make them more meaningful debugging printfs() for data visualization turned into a meaningful log: - introduced a new log category `types' in channel `lldb' llvm-svn: 135773
2011-07-23 01:03:19 +08:00
if (log)
log->Printf("handle as array");
final fix for the global constructors issue new GetValueForExpressionPath() method in ValueObject to navigate expression paths in a more bitfield vs slices aware way changes to the varformats.html document (WIP) llvm-svn: 134679
2011-07-08 10:51:01 +08:00
const char* special_directions = NULL;
StreamString special_directions_writer;
Fixed some issues with ARM backtraces by not processing any push/pop instructions if they are conditional. Also fixed issues where the PC wasn't getting bit zero stripped for ARM targets when a stack frame was thumb. We now properly call through the GetOpcodeLoadAddress() functions to make sure the addresses are properly stripped for any targets that may decorate up their addresses. We now don't pass the SIGSTOP signals along. We can revisit this soon, but currently this was interfering with debugging some older ARM targets that don't have vCont support in the GDB server. llvm-svn: 134461
2011-07-06 12:07:21 +08:00
if (close_bracket_position && (var_name_end-close_bracket_position > 1))
{
final fix for the global constructors issue new GetValueForExpressionPath() method in ValueObject to navigate expression paths in a more bitfield vs slices aware way changes to the varformats.html document (WIP) llvm-svn: 134679
2011-07-08 10:51:01 +08:00
ConstString additional_data;
additional_data.SetCStringWithLength(close_bracket_position+1, var_name_end-close_bracket_position-1);
special_directions_writer.Printf("${%svar%s}",
do_deref_pointer ? "*" : "",
additional_data.GetCString());
special_directions = special_directions_writer.GetData();
Fixed some issues with ARM backtraces by not processing any push/pop instructions if they are conditional. Also fixed issues where the PC wasn't getting bit zero stripped for ARM targets when a stack frame was thumb. We now properly call through the GetOpcodeLoadAddress() functions to make sure the addresses are properly stripped for any targets that may decorate up their addresses. We now don't pass the SIGSTOP signals along. We can revisit this soon, but currently this was interfering with debugging some older ARM targets that don't have vCont support in the GDB server. llvm-svn: 134461
2011-07-06 12:07:21 +08:00
}
new syntax for summary strings: - ${*expr} now simply means to dereference expr before actually using it - bitfields, array ranges and pointer ranges now work in a (hopefully) more natural and language-compliant way a new class TypeHierarchyNavigator replicates the behavior of the FormatManager in going through type hierarchies when one-lining summary strings, children's summaries can be used as well as values llvm-svn: 134458
2011-07-06 10:13:41 +08:00
Fixed some issues with ARM backtraces by not processing any push/pop instructions if they are conditional. Also fixed issues where the PC wasn't getting bit zero stripped for ARM targets when a stack frame was thumb. We now properly call through the GetOpcodeLoadAddress() functions to make sure the addresses are properly stripped for any targets that may decorate up their addresses. We now don't pass the SIGSTOP signals along. We can revisit this soon, but currently this was interfering with debugging some older ARM targets that don't have vCont support in the GDB server. llvm-svn: 134461
2011-07-06 12:07:21 +08:00
// let us display items index_lower thru index_higher of this array
s.PutChar('[');
var_success = true;
if (index_higher < 0)
First round of code cleanups: - all instances of "vobj" have been renamed to "valobj" - class Debugger::Formatting has been renamed to DataVisualization (defined in FormatManager.h/cpp) The interface to this class has not changed - FormatCategory now uses ConstString's as keys to the navigators instead of repeatedly casting from ConstString to const char* and back all the time Next step is making the same happen for categories themselves - category gnu-libstdc++ is defined in the constructor for a FormatManager The source code for it is defined in gnu_libstdcpp.py, drawn from examples/synthetic at compile time All references to previous 'osxcpp' name have been removed from both code and file names Functional changes: - the name of the option to use a summary string for 'type summary add' has changed from the previous --format-string to the new --summary-string. It is expected that the short option will change from -f to -s, and -s for --python-script will become -o llvm-svn: 137886
2011-08-18 06:13:59 +08:00
index_higher = valobj->GetNumChildren() - 1;
Fixed some issues with ARM backtraces by not processing any push/pop instructions if they are conditional. Also fixed issues where the PC wasn't getting bit zero stripped for ARM targets when a stack frame was thumb. We now properly call through the GetOpcodeLoadAddress() functions to make sure the addresses are properly stripped for any targets that may decorate up their addresses. We now don't pass the SIGSTOP signals along. We can revisit this soon, but currently this was interfering with debugging some older ARM targets that don't have vCont support in the GDB server. llvm-svn: 134461
2011-07-06 12:07:21 +08:00
This checking is part one of trying to add some threading safety to our internals. The first part of this is to use a new class: lldb_private::ExecutionContextRef This class holds onto weak pointers to the target, process, thread and frame and it also contains the thread ID and frame Stack ID in case the thread and frame objects go away and come back as new objects that represent the same logical thread/frame. ExecutionContextRef objcets have accessors to access shared pointers for the target, process, thread and frame which might return NULL if the backing object is no longer available. This allows for references to persistent program state without needing to hold a shared pointer to each object and potentially keeping that object around for longer than it needs to be. You can also "Lock" and ExecutionContextRef (which contains weak pointers) object into an ExecutionContext (which contains strong, or shared pointers) with code like ExecutionContext exe_ctx (my_obj->GetExectionContextRef().Lock()); llvm-svn: 150801
2012-02-17 15:49:44 +08:00
uint32_t max_num_children = target->GetTargetSP()->GetMaximumNumberOfChildrenToDisplay();
*Some more optimizations in usage of ConstString *New setting target.max-children-count gives an upper-bound to the number of child objects that will be displayed at each depth-level This might be a breaking change in some scenarios. To override the new limit you can use the --show-all-children (-A) option to frame variable or increase the limit in your lldbinit file *Command "type synthetic" has been split in two: - "type synthetic" now only handles Python synthetic children providers - the new command "type filter" handles filters Because filters and synthetic providers are both ways to replace the children of a ValueObject, only one can be effective at any given time. llvm-svn: 137416
2011-08-12 10:00:06 +08:00
Fixed some issues with ARM backtraces by not processing any push/pop instructions if they are conditional. Also fixed issues where the PC wasn't getting bit zero stripped for ARM targets when a stack frame was thumb. We now properly call through the GetOpcodeLoadAddress() functions to make sure the addresses are properly stripped for any targets that may decorate up their addresses. We now don't pass the SIGSTOP signals along. We can revisit this soon, but currently this was interfering with debugging some older ARM targets that don't have vCont support in the GDB server. llvm-svn: 134461
2011-07-06 12:07:21 +08:00
for (;index_lower<=index_higher;index_lower++)
{
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
ValueObject* item = ExpandIndexedExpression (target,
index_lower,
exe_ctx->GetFramePtr(),
false).get();
Fixed some issues with ARM backtraces by not processing any push/pop instructions if they are conditional. Also fixed issues where the PC wasn't getting bit zero stripped for ARM targets when a stack frame was thumb. We now properly call through the GetOpcodeLoadAddress() functions to make sure the addresses are properly stripped for any targets that may decorate up their addresses. We now don't pass the SIGSTOP signals along. We can revisit this soon, but currently this was interfering with debugging some older ARM targets that don't have vCont support in the GDB server. llvm-svn: 134461
2011-07-06 12:07:21 +08:00
final fix for the global constructors issue new GetValueForExpressionPath() method in ValueObject to navigate expression paths in a more bitfield vs slices aware way changes to the varformats.html document (WIP) llvm-svn: 134679
2011-07-08 10:51:01 +08:00
if (!item)
{
some editing of data visualization error messages to make them more meaningful debugging printfs() for data visualization turned into a meaningful log: - introduced a new log category `types' in channel `lldb' llvm-svn: 135773
2011-07-23 01:03:19 +08:00
if (log)
Update declarations for all functions/methods that accept printf-style stdarg formats to use __attribute__ format so the compiler can flag incorrect uses. Fix all incorrect uses. Most of these are innocuous, a few were resulting in crashes. llvm-svn: 140185
2011-09-21 05:44:10 +08:00
log->Printf("ERROR in getting child item at index %lld", index_lower);
final fix for the global constructors issue new GetValueForExpressionPath() method in ValueObject to navigate expression paths in a more bitfield vs slices aware way changes to the varformats.html document (WIP) llvm-svn: 134679
2011-07-08 10:51:01 +08:00
}
else
{
some editing of data visualization error messages to make them more meaningful debugging printfs() for data visualization turned into a meaningful log: - introduced a new log category `types' in channel `lldb' llvm-svn: 135773
2011-07-23 01:03:19 +08:00
if (log)
log->Printf("special_directions for child item: %s",special_directions);
final fix for the global constructors issue new GetValueForExpressionPath() method in ValueObject to navigate expression paths in a more bitfield vs slices aware way changes to the varformats.html document (WIP) llvm-svn: 134679
2011-07-08 10:51:01 +08:00
}
Fixed some issues with ARM backtraces by not processing any push/pop instructions if they are conditional. Also fixed issues where the PC wasn't getting bit zero stripped for ARM targets when a stack frame was thumb. We now properly call through the GetOpcodeLoadAddress() functions to make sure the addresses are properly stripped for any targets that may decorate up their addresses. We now don't pass the SIGSTOP signals along. We can revisit this soon, but currently this was interfering with debugging some older ARM targets that don't have vCont support in the GDB server. llvm-svn: 134461
2011-07-06 12:07:21 +08:00
if (!special_directions)
var_success &= item->DumpPrintableRepresentation(s,val_obj_display, custom_format);
else
var_success &= FormatPrompt(special_directions, sc, exe_ctx, addr, s, NULL, item);
*Some more optimizations in usage of ConstString *New setting target.max-children-count gives an upper-bound to the number of child objects that will be displayed at each depth-level This might be a breaking change in some scenarios. To override the new limit you can use the --show-all-children (-A) option to frame variable or increase the limit in your lldbinit file *Command "type synthetic" has been split in two: - "type synthetic" now only handles Python synthetic children providers - the new command "type filter" handles filters Because filters and synthetic providers are both ways to replace the children of a ValueObject, only one can be effective at any given time. llvm-svn: 137416
2011-08-12 10:00:06 +08:00
if (--max_num_children == 0)
{
s.PutCString(", ...");
break;
}
Fixed some issues with ARM backtraces by not processing any push/pop instructions if they are conditional. Also fixed issues where the PC wasn't getting bit zero stripped for ARM targets when a stack frame was thumb. We now properly call through the GetOpcodeLoadAddress() functions to make sure the addresses are properly stripped for any targets that may decorate up their addresses. We now don't pass the SIGSTOP signals along. We can revisit this soon, but currently this was interfering with debugging some older ARM targets that don't have vCont support in the GDB server. llvm-svn: 134461
2011-07-06 12:07:21 +08:00
if (index_lower < index_higher)
s.PutChar(',');
}
s.PutChar(']');
new syntax for summary strings: - ${*expr} now simply means to dereference expr before actually using it - bitfields, array ranges and pointer ranges now work in a (hopefully) more natural and language-compliant way a new class TypeHierarchyNavigator replicates the behavior of the FormatManager in going through type hierarchies when one-lining summary strings, children's summaries can be used as well as values llvm-svn: 134458
2011-07-06 10:13:41 +08:00
}
This commit adds a new top subcommand "summary" to command type named "type". Currently this command implements three commands: type summary add <format> <typename1> [<typename2> ...] type summary delete <typename1> [<typename2> ...] type summary list [<typename1> [<typename2>] ...] type summary clear This allows you to specify the default format that will be used to display summaries for variables, shown when you use "frame variable" or "expression", or the SBValue classes. Examples: type summary add "x = ${var.x}" Point type summary list type summary add --one-liner SimpleType llvm-svn: 134108
2011-06-30 06:27:15 +08:00
}
new syntax for summary strings: - ${*expr} now simply means to dereference expr before actually using it - bitfields, array ranges and pointer ranges now work in a (hopefully) more natural and language-compliant way a new class TypeHierarchyNavigator replicates the behavior of the FormatManager in going through type hierarchies when one-lining summary strings, children's summaries can be used as well as values llvm-svn: 134458
2011-07-06 10:13:41 +08:00
break;
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
case 'a':
if (::strncmp (var_name_begin, "addr}", strlen("addr}")) == 0)
{
if (addr && addr->IsValid())
{
var_success = true;
format_addr = *addr;
}
}
Added the ability to run expressions in any command. Expressions can be inserted in commands by using backticks: (lldb) memory read `$rsp-16` `$rsp+16` (lldb) memory read -c `(int)strlen(argv[0])` `argv[0]` The result of the expression will be inserted into the command as a sort of preprocess stage where this gets done first. We might need to tweak where this preprocess stage goes, but it is very functional already. Added ansi color support to the Debugger::FormatPrompt() so you can use things like "${ansi.fg.blue}" and "${ansi.bold}" many more. This helps in adding colors to your prompts without needing to know the ANSI color code strings. llvm-svn: 141948
2011-10-14 15:41:33 +08:00
else if (::strncmp (var_name_begin, "ansi.", strlen("ansi.")) == 0)
{
var_success = true;
var_name_begin += strlen("ansi."); // Skip the "ansi."
if (::strncmp (var_name_begin, "fg.", strlen("fg.")) == 0)
{
var_name_begin += strlen("fg."); // Skip the "fg."
if (::strncmp (var_name_begin, "black}", strlen("black}")) == 0)
{
s.Printf ("%s%s%s",
lldb_utility::ansi::k_escape_start,
lldb_utility::ansi::k_fg_black,
lldb_utility::ansi::k_escape_end);
}
else if (::strncmp (var_name_begin, "red}", strlen("red}")) == 0)
{
s.Printf ("%s%s%s",
lldb_utility::ansi::k_escape_start,
lldb_utility::ansi::k_fg_red,
lldb_utility::ansi::k_escape_end);
}
else if (::strncmp (var_name_begin, "green}", strlen("green}")) == 0)
{
s.Printf ("%s%s%s",
lldb_utility::ansi::k_escape_start,
lldb_utility::ansi::k_fg_green,
lldb_utility::ansi::k_escape_end);
}
else if (::strncmp (var_name_begin, "yellow}", strlen("yellow}")) == 0)
{
s.Printf ("%s%s%s",
lldb_utility::ansi::k_escape_start,
lldb_utility::ansi::k_fg_yellow,
lldb_utility::ansi::k_escape_end);
}
else if (::strncmp (var_name_begin, "blue}", strlen("blue}")) == 0)
{
s.Printf ("%s%s%s",
lldb_utility::ansi::k_escape_start,
lldb_utility::ansi::k_fg_blue,
lldb_utility::ansi::k_escape_end);
}
else if (::strncmp (var_name_begin, "purple}", strlen("purple}")) == 0)
{
s.Printf ("%s%s%s",
lldb_utility::ansi::k_escape_start,
lldb_utility::ansi::k_fg_purple,
lldb_utility::ansi::k_escape_end);
}
else if (::strncmp (var_name_begin, "cyan}", strlen("cyan}")) == 0)
{
s.Printf ("%s%s%s",
lldb_utility::ansi::k_escape_start,
lldb_utility::ansi::k_fg_cyan,
lldb_utility::ansi::k_escape_end);
}
else if (::strncmp (var_name_begin, "white}", strlen("white}")) == 0)
{
s.Printf ("%s%s%s",
lldb_utility::ansi::k_escape_start,
lldb_utility::ansi::k_fg_white,
lldb_utility::ansi::k_escape_end);
}
else
{
var_success = false;
}
}
else if (::strncmp (var_name_begin, "bg.", strlen("bg.")) == 0)
{
var_name_begin += strlen("bg."); // Skip the "bg."
if (::strncmp (var_name_begin, "black}", strlen("black}")) == 0)
{
s.Printf ("%s%s%s",
lldb_utility::ansi::k_escape_start,
lldb_utility::ansi::k_bg_black,
lldb_utility::ansi::k_escape_end);
}
else if (::strncmp (var_name_begin, "red}", strlen("red}")) == 0)
{
s.Printf ("%s%s%s",
lldb_utility::ansi::k_escape_start,
lldb_utility::ansi::k_bg_red,
lldb_utility::ansi::k_escape_end);
}
else if (::strncmp (var_name_begin, "green}", strlen("green}")) == 0)
{
s.Printf ("%s%s%s",
lldb_utility::ansi::k_escape_start,
lldb_utility::ansi::k_bg_green,
lldb_utility::ansi::k_escape_end);
}
else if (::strncmp (var_name_begin, "yellow}", strlen("yellow}")) == 0)
{
s.Printf ("%s%s%s",
lldb_utility::ansi::k_escape_start,
lldb_utility::ansi::k_bg_yellow,
lldb_utility::ansi::k_escape_end);
}
else if (::strncmp (var_name_begin, "blue}", strlen("blue}")) == 0)
{
s.Printf ("%s%s%s",
lldb_utility::ansi::k_escape_start,
lldb_utility::ansi::k_bg_blue,
lldb_utility::ansi::k_escape_end);
}
else if (::strncmp (var_name_begin, "purple}", strlen("purple}")) == 0)
{
s.Printf ("%s%s%s",
lldb_utility::ansi::k_escape_start,
lldb_utility::ansi::k_bg_purple,
lldb_utility::ansi::k_escape_end);
}
else if (::strncmp (var_name_begin, "cyan}", strlen("cyan}")) == 0)
{
s.Printf ("%s%s%s",
lldb_utility::ansi::k_escape_start,
lldb_utility::ansi::k_bg_cyan,
lldb_utility::ansi::k_escape_end);
}
else if (::strncmp (var_name_begin, "white}", strlen("white}")) == 0)
{
s.Printf ("%s%s%s",
lldb_utility::ansi::k_escape_start,
lldb_utility::ansi::k_bg_white,
lldb_utility::ansi::k_escape_end);
}
else
{
var_success = false;
}
}
else if (::strncmp (var_name_begin, "normal}", strlen ("normal}")) == 0)
{
s.Printf ("%s%s%s",
lldb_utility::ansi::k_escape_start,
lldb_utility::ansi::k_ctrl_normal,
lldb_utility::ansi::k_escape_end);
}
else if (::strncmp (var_name_begin, "bold}", strlen("bold}")) == 0)
{
s.Printf ("%s%s%s",
lldb_utility::ansi::k_escape_start,
lldb_utility::ansi::k_ctrl_bold,
lldb_utility::ansi::k_escape_end);
}
else if (::strncmp (var_name_begin, "faint}", strlen("faint}")) == 0)
{
s.Printf ("%s%s%s",
lldb_utility::ansi::k_escape_start,
lldb_utility::ansi::k_ctrl_faint,
lldb_utility::ansi::k_escape_end);
}
else if (::strncmp (var_name_begin, "italic}", strlen("italic}")) == 0)
{
s.Printf ("%s%s%s",
lldb_utility::ansi::k_escape_start,
lldb_utility::ansi::k_ctrl_italic,
lldb_utility::ansi::k_escape_end);
}
else if (::strncmp (var_name_begin, "underline}", strlen("underline}")) == 0)
{
s.Printf ("%s%s%s",
lldb_utility::ansi::k_escape_start,
lldb_utility::ansi::k_ctrl_underline,
lldb_utility::ansi::k_escape_end);
}
else if (::strncmp (var_name_begin, "slow-blink}", strlen("slow-blink}")) == 0)
{
s.Printf ("%s%s%s",
lldb_utility::ansi::k_escape_start,
lldb_utility::ansi::k_ctrl_slow_blink,
lldb_utility::ansi::k_escape_end);
}
else if (::strncmp (var_name_begin, "fast-blink}", strlen("fast-blink}")) == 0)
{
s.Printf ("%s%s%s",
lldb_utility::ansi::k_escape_start,
lldb_utility::ansi::k_ctrl_fast_blink,
lldb_utility::ansi::k_escape_end);
}
else if (::strncmp (var_name_begin, "negative}", strlen("negative}")) == 0)
{
s.Printf ("%s%s%s",
lldb_utility::ansi::k_escape_start,
lldb_utility::ansi::k_ctrl_negative,
lldb_utility::ansi::k_escape_end);
}
else if (::strncmp (var_name_begin, "conceal}", strlen("conceal}")) == 0)
{
s.Printf ("%s%s%s",
lldb_utility::ansi::k_escape_start,
lldb_utility::ansi::k_ctrl_conceal,
lldb_utility::ansi::k_escape_end);
}
else if (::strncmp (var_name_begin, "crossed-out}", strlen("crossed-out}")) == 0)
{
s.Printf ("%s%s%s",
lldb_utility::ansi::k_escape_start,
lldb_utility::ansi::k_ctrl_crossed_out,
lldb_utility::ansi::k_escape_end);
}
else
{
var_success = false;
}
}
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
break;
case 'p':
if (::strncmp (var_name_begin, "process.", strlen("process.")) == 0)
{
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
if (exe_ctx)
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
{
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
Process *process = exe_ctx->GetProcessPtr();
if (process)
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
{
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
var_name_begin += ::strlen ("process.");
if (::strncmp (var_name_begin, "id}", strlen("id}")) == 0)
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
{
Moved lldb::user_id_t values to be 64 bit. This was going to be needed for process IDs, and thread IDs, but was mainly needed for for the UserID's for Types so that DWARF with debug map can work flawlessly. With DWARF in .o files the type ID was the DIE offset in the DWARF for the .o file which is not unique across all .o files, so now the SymbolFileDWARFDebugMap class will make the .o file index part (the high 32 bits) of the unique type identifier so it can uniquely identify the types. llvm-svn: 142534
2011-10-20 02:09:39 +08:00
s.Printf("%llu", process->GetID());
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
var_success = true;
}
else if ((::strncmp (var_name_begin, "name}", strlen("name}")) == 0) ||
(::strncmp (var_name_begin, "file.basename}", strlen("file.basename}")) == 0) ||
(::strncmp (var_name_begin, "file.fullpath}", strlen("file.fullpath}")) == 0))
{
Module *exe_module = process->GetTarget().GetExecutableModulePointer();
if (exe_module)
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
{
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
if (var_name_begin[0] == 'n' || var_name_begin[5] == 'f')
{
format_file_spec.GetFilename() = exe_module->GetFileSpec().GetFilename();
var_success = format_file_spec;
}
else
{
format_file_spec = exe_module->GetFileSpec();
var_success = format_file_spec;
}
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
}
}
}
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
}
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
}
break;
case 't':
if (::strncmp (var_name_begin, "thread.", strlen("thread.")) == 0)
{
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
if (exe_ctx)
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
{
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
Thread *thread = exe_ctx->GetThreadPtr();
if (thread)
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
{
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
var_name_begin += ::strlen ("thread.");
if (::strncmp (var_name_begin, "id}", strlen("id}")) == 0)
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
{
Moved lldb::user_id_t values to be 64 bit. This was going to be needed for process IDs, and thread IDs, but was mainly needed for for the UserID's for Types so that DWARF with debug map can work flawlessly. With DWARF in .o files the type ID was the DIE offset in the DWARF for the .o file which is not unique across all .o files, so now the SymbolFileDWARFDebugMap class will make the .o file index part (the high 32 bits) of the unique type identifier so it can uniquely identify the types. llvm-svn: 142534
2011-10-20 02:09:39 +08:00
s.Printf("0x%4.4llx", thread->GetID());
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
var_success = true;
}
else if (::strncmp (var_name_begin, "index}", strlen("index}")) == 0)
{
s.Printf("%u", thread->GetIndexID());
var_success = true;
}
else if (::strncmp (var_name_begin, "name}", strlen("name}")) == 0)
{
cstr = thread->GetName();
var_success = cstr && cstr[0];
if (var_success)
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
s.PutCString(cstr);
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
}
else if (::strncmp (var_name_begin, "queue}", strlen("queue}")) == 0)
{
cstr = thread->GetQueueName();
var_success = cstr && cstr[0];
if (var_success)
s.PutCString(cstr);
}
else if (::strncmp (var_name_begin, "stop-reason}", strlen("stop-reason}")) == 0)
{
StopInfoSP stop_info_sp = thread->GetStopInfo ();
if (stop_info_sp)
{
cstr = stop_info_sp->GetDescription();
if (cstr && cstr[0])
{
s.PutCString(cstr);
var_success = true;
}
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
}
}
Add the ability to capture the return value in a thread's stop info, and print it as part of the thread format output. Currently this is only done for the ThreadPlanStepOut. Add a convenience API ABI::GetReturnValueObject. Change the ValueObject::EvaluationPoint to BE an ExecutionContextScope, rather than trying to hand out one of its subsidiary object's pointers. That way this will always be good. llvm-svn: 146806
2011-12-17 09:35:57 +08:00
else if (::strncmp (var_name_begin, "return-value}", strlen("return-value}")) == 0)
{
StopInfoSP stop_info_sp = thread->GetStopInfo ();
if (stop_info_sp)
{
ValueObjectSP return_valobj_sp = StopInfo::GetReturnValueObject (stop_info_sp);
if (return_valobj_sp)
{
Improve the x86_64 return value decoder to handle most structure returns. Switch from GetReturnValue, which was hardly ever used, to GetReturnValueObject which is much more convenient. Return the "return value object" as a persistent variable if requested. llvm-svn: 147157
2011-12-23 03:12:40 +08:00
ValueObject::DumpValueObjectOptions dump_options;
ValueObject::DumpValueObject (s, return_valobj_sp.get(), dump_options);
var_success = true;
Add the ability to capture the return value in a thread's stop info, and print it as part of the thread format output. Currently this is only done for the ThreadPlanStepOut. Add a convenience API ABI::GetReturnValueObject. Change the ValueObject::EvaluationPoint to BE an ExecutionContextScope, rather than trying to hand out one of its subsidiary object's pointers. That way this will always be good. llvm-svn: 146806
2011-12-17 09:35:57 +08:00
}
}
}
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
}
}
}
else if (::strncmp (var_name_begin, "target.", strlen("target.")) == 0)
{
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
// TODO: hookup properties
// if (!target_properties_sp)
// {
// Target *target = Target::GetTargetFromContexts (exe_ctx, sc);
// if (target)
// target_properties_sp = target->GetProperties();
// }
//
// if (target_properties_sp)
// {
// var_name_begin += ::strlen ("target.");
// const char *end_property = strchr(var_name_begin, '}');
// if (end_property)
// {
// ConstString property_name(var_name_begin, end_property - var_name_begin);
// std::string property_value (target_properties_sp->GetPropertyValue(property_name));
// if (!property_value.empty())
// {
// s.PutCString (property_value.c_str());
// var_success = true;
// }
// }
// }
There are now to new "settings set" variables that live in each debugger instance: settings set frame-format <string> settings set thread-format <string> This allows users to control the information that is seen when dumping threads and frames. The default values are set such that they do what they used to do prior to changing over the the user defined formats. This allows users with terminals that can display color to make different items different colors using the escape control codes. A few alias examples that will colorize your thread and frame prompts are: settings set frame-format 'frame #${frame.index}: \033[0;33m${frame.pc}\033[0m{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{ \033[0;35mat \033[1;35m${line.file.basename}:${line.number}}\033[0m\n' settings set thread-format 'thread #${thread.index}: \033[1;33mtid\033[0;33m = ${thread.id}\033[0m{, \033[0;33m${frame.pc}\033[0m}{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{, \033[1;35mstop reason\033[0;35m = ${thread.stop-reason}\033[0m}{, \033[1;36mname = \033[0;36m${thread.name}\033[0m}{, \033[1;32mqueue = \033[0;32m${thread.queue}}\033[0m\n' A quick web search for "colorize terminal output" should allow you to see what you can do to make your output look like you want it. The "settings set" commands above can of course be added to your ~/.lldbinit file for permanent use. Changed the pure virtual void ExecutionContextScope::Calculate (ExecutionContext&); To: void ExecutionContextScope::CalculateExecutionContext (ExecutionContext&); I did this because this is a class that anything in the execution context heirarchy inherits from and "target->Calculate (exe_ctx)" didn't always tell you what it was really trying to do unless you look at the parameter. llvm-svn: 115485
2010-10-04 09:05:56 +08:00
Target *target = Target::GetTargetFromContexts (exe_ctx, sc);
if (target)
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
{
var_name_begin += ::strlen ("target.");
if (::strncmp (var_name_begin, "arch}", strlen("arch}")) == 0)
{
ArchSpec arch (target->GetArchitecture ());
if (arch.IsValid())
{
Abtracted all mach-o and ELF out of ArchSpec. This patch is a modified form of Stephen Wilson's idea (thanks for the input Stephen!). What I ended up doing was: - Got rid of ArchSpec::CPU (which was a generic CPU enumeration that mimics the contents of llvm::Triple::ArchType). We now rely upon the llvm::Triple to give us the machine type from llvm::Triple::ArchType. - There is a new ArchSpec::Core definition which further qualifies the CPU core we are dealing with into a single enumeration. If you need support for a new Core and want to debug it in LLDB, it must be added to this list. In the future we can allow for dynamic core registration, but for now it is hard coded. - The ArchSpec can now be initialized with a llvm::Triple or with a C string that represents the triple (it can just be an arch still like "i386"). - The ArchSpec can still initialize itself with a architecture type -- mach-o with cpu type and subtype, or ELF with e_machine + e_flags -- and this will then get translated into the internal llvm::Triple::ArchSpec + ArchSpec::Core. The mach-o cpu type and subtype can be accessed using the getter functions: uint32_t ArchSpec::GetMachOCPUType () const; uint32_t ArchSpec::GetMachOCPUSubType () const; But these functions are just converting out internal llvm::Triple::ArchSpec + ArchSpec::Core back into mach-o. Same goes for ELF. All code has been updated to deal with the changes. This should abstract us until later when the llvm::TargetSpec stuff gets finalized and we can then adopt it. llvm-svn: 126278
2011-02-23 08:35:02 +08:00
s.PutCString (arch.GetArchitectureName());
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
var_success = true;
}
}
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
}
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
}
break;
case 'm':
if (::strncmp (var_name_begin, "module.", strlen("module.")) == 0)
{
There are now to new "settings set" variables that live in each debugger instance: settings set frame-format <string> settings set thread-format <string> This allows users to control the information that is seen when dumping threads and frames. The default values are set such that they do what they used to do prior to changing over the the user defined formats. This allows users with terminals that can display color to make different items different colors using the escape control codes. A few alias examples that will colorize your thread and frame prompts are: settings set frame-format 'frame #${frame.index}: \033[0;33m${frame.pc}\033[0m{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{ \033[0;35mat \033[1;35m${line.file.basename}:${line.number}}\033[0m\n' settings set thread-format 'thread #${thread.index}: \033[1;33mtid\033[0;33m = ${thread.id}\033[0m{, \033[0;33m${frame.pc}\033[0m}{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{, \033[1;35mstop reason\033[0;35m = ${thread.stop-reason}\033[0m}{, \033[1;36mname = \033[0;36m${thread.name}\033[0m}{, \033[1;32mqueue = \033[0;32m${thread.queue}}\033[0m\n' A quick web search for "colorize terminal output" should allow you to see what you can do to make your output look like you want it. The "settings set" commands above can of course be added to your ~/.lldbinit file for permanent use. Changed the pure virtual void ExecutionContextScope::Calculate (ExecutionContext&); To: void ExecutionContextScope::CalculateExecutionContext (ExecutionContext&); I did this because this is a class that anything in the execution context heirarchy inherits from and "target->Calculate (exe_ctx)" didn't always tell you what it was really trying to do unless you look at the parameter. llvm-svn: 115485
2010-10-04 09:05:56 +08:00
if (sc && sc->module_sp.get())
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
{
There are now to new "settings set" variables that live in each debugger instance: settings set frame-format <string> settings set thread-format <string> This allows users to control the information that is seen when dumping threads and frames. The default values are set such that they do what they used to do prior to changing over the the user defined formats. This allows users with terminals that can display color to make different items different colors using the escape control codes. A few alias examples that will colorize your thread and frame prompts are: settings set frame-format 'frame #${frame.index}: \033[0;33m${frame.pc}\033[0m{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{ \033[0;35mat \033[1;35m${line.file.basename}:${line.number}}\033[0m\n' settings set thread-format 'thread #${thread.index}: \033[1;33mtid\033[0;33m = ${thread.id}\033[0m{, \033[0;33m${frame.pc}\033[0m}{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{, \033[1;35mstop reason\033[0;35m = ${thread.stop-reason}\033[0m}{, \033[1;36mname = \033[0;36m${thread.name}\033[0m}{, \033[1;32mqueue = \033[0;32m${thread.queue}}\033[0m\n' A quick web search for "colorize terminal output" should allow you to see what you can do to make your output look like you want it. The "settings set" commands above can of course be added to your ~/.lldbinit file for permanent use. Changed the pure virtual void ExecutionContextScope::Calculate (ExecutionContext&); To: void ExecutionContextScope::CalculateExecutionContext (ExecutionContext&); I did this because this is a class that anything in the execution context heirarchy inherits from and "target->Calculate (exe_ctx)" didn't always tell you what it was really trying to do unless you look at the parameter. llvm-svn: 115485
2010-10-04 09:05:56 +08:00
Module *module = sc->module_sp.get();
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
var_name_begin += ::strlen ("module.");
if (::strncmp (var_name_begin, "file.", strlen("file.")) == 0)
{
if (module->GetFileSpec())
{
var_name_begin += ::strlen ("file.");
if (::strncmp (var_name_begin, "basename}", strlen("basename}")) == 0)
{
format_file_spec.GetFilename() = module->GetFileSpec().GetFilename();
var_success = format_file_spec;
}
else if (::strncmp (var_name_begin, "fullpath}", strlen("fullpath}")) == 0)
{
format_file_spec = module->GetFileSpec();
var_success = format_file_spec;
}
}
}
}
}
break;
case 'f':
if (::strncmp (var_name_begin, "file.", strlen("file.")) == 0)
{
if (sc && sc->comp_unit != NULL)
{
var_name_begin += ::strlen ("file.");
if (::strncmp (var_name_begin, "basename}", strlen("basename}")) == 0)
{
format_file_spec.GetFilename() = sc->comp_unit->GetFilename();
var_success = format_file_spec;
}
else if (::strncmp (var_name_begin, "fullpath}", strlen("fullpath}")) == 0)
{
format_file_spec = *sc->comp_unit;
var_success = format_file_spec;
}
}
}
else if (::strncmp (var_name_begin, "frame.", strlen("frame.")) == 0)
{
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
if (exe_ctx)
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
{
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
StackFrame *frame = exe_ctx->GetFramePtr();
if (frame)
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
{
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
var_name_begin += ::strlen ("frame.");
if (::strncmp (var_name_begin, "index}", strlen("index}")) == 0)
{
s.Printf("%u", frame->GetFrameIndex());
var_success = true;
}
else if (::strncmp (var_name_begin, "pc}", strlen("pc}")) == 0)
{
reg_kind = eRegisterKindGeneric;
reg_num = LLDB_REGNUM_GENERIC_PC;
var_success = true;
}
else if (::strncmp (var_name_begin, "sp}", strlen("sp}")) == 0)
{
reg_kind = eRegisterKindGeneric;
reg_num = LLDB_REGNUM_GENERIC_SP;
var_success = true;
}
else if (::strncmp (var_name_begin, "fp}", strlen("fp}")) == 0)
{
reg_kind = eRegisterKindGeneric;
reg_num = LLDB_REGNUM_GENERIC_FP;
var_success = true;
}
else if (::strncmp (var_name_begin, "flags}", strlen("flags}")) == 0)
{
reg_kind = eRegisterKindGeneric;
reg_num = LLDB_REGNUM_GENERIC_FLAGS;
var_success = true;
}
else if (::strncmp (var_name_begin, "reg.", strlen ("reg.")) == 0)
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
{
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
reg_ctx = frame->GetRegisterContext().get();
if (reg_ctx)
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
{
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
var_name_begin += ::strlen ("reg.");
if (var_name_begin < var_name_end)
{
std::string reg_name (var_name_begin, var_name_end);
reg_info = reg_ctx->GetRegisterInfoByName (reg_name.c_str());
if (reg_info)
var_success = true;
}
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
}
}
}
}
}
else if (::strncmp (var_name_begin, "function.", strlen("function.")) == 0)
{
if (sc && (sc->function != NULL || sc->symbol != NULL))
{
var_name_begin += ::strlen ("function.");
if (::strncmp (var_name_begin, "id}", strlen("id}")) == 0)
{
if (sc->function)
Moved lldb::user_id_t values to be 64 bit. This was going to be needed for process IDs, and thread IDs, but was mainly needed for for the UserID's for Types so that DWARF with debug map can work flawlessly. With DWARF in .o files the type ID was the DIE offset in the DWARF for the .o file which is not unique across all .o files, so now the SymbolFileDWARFDebugMap class will make the .o file index part (the high 32 bits) of the unique type identifier so it can uniquely identify the types. llvm-svn: 142534
2011-10-20 02:09:39 +08:00
s.Printf("function{0x%8.8llx}", sc->function->GetID());
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
else
s.Printf("symbol[%u]", sc->symbol->GetID());
var_success = true;
}
else if (::strncmp (var_name_begin, "name}", strlen("name}")) == 0)
{
if (sc->function)
cstr = sc->function->GetName().AsCString (NULL);
else if (sc->symbol)
cstr = sc->symbol->GetName().AsCString (NULL);
if (cstr)
{
s.PutCString(cstr);
Fixed and issue where we weren't seeing inlined functions anymore. We also now show the correct pc-offset within the inlined function. llvm-svn: 115522
2010-10-05 01:26:49 +08:00
if (sc->block)
{
Block *inline_block = sc->block->GetContainingInlinedBlock ();
if (inline_block)
{
const InlineFunctionInfo *inline_info = sc->block->GetInlinedFunctionInfo();
if (inline_info)
{
s.PutCString(" [inlined] ");
inline_info->GetName().Dump(&s);
}
}
}
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
var_success = true;
}
}
Added a new thread and frame format that can be used to display a function name + arguments when the data is available. It seems to work really well, but some more testing is needed before we make this on by default. The new function format name is: ${function.name-with-args} To see how to use these formats see the website: http://lldb.llvm.org/formats.html Here is a sample backtrace of debugging LLDB with LLDB using this new format value: (lldb) thread backtrace all * thread #1: tid = 0x2203, 0x00007fff88a17bca libsystem_kernel.dylib __psynch_cvwait + 10, stop reason = signal SIGINT, name = <lldb.driver.main-thread>, queue = com.apple.main-thread frame #0: 0x00007fff88a17bca libsystem_kernel.dylib __psynch_cvwait + 10 frame #1: 0x00007fff884ae274 libsystem_c.dylib _pthread_cond_wait + 840 frame #2: 0x00000001010778ea LLDB lldb_private::Condition::Wait(this=0x0000000104846770, mutex=0x0000000104846730, abstime=0x0000000000000000, timed_out=0x00007fff5fbfdea7) + 138 at Condition.cpp:92 frame #3: 0x0000000101244c21 LLDB lldb_private::Predicate<bool>::WaitForValueEqualTo(this=0x0000000104846728, value=true, abstime=0x0000000000000000, timed_out=0x00007fff5fbfdea7) + 209 at Predicate.h:317 frame #4: 0x0000000100f6eeb2 LLDB lldb_private::Listener::WaitForEventsInternal(this=0x0000000104846660, timeout=0x0000000000000000, broadcaster=0x0000000000000000, broadcaster_names=0x0000000000000000, num_broadcaster_names=0x00000000, event_type_mask=0x00000000, event_sp=0x00007fff5fbfe030) + 386 at Listener.cpp:388 frame #5: 0x0000000100f6f231 LLDB lldb_private::Listener::WaitForEvent(this=0x0000000104846660, timeout=0x0000000000000000, event_sp=0x00007fff5fbfe030) + 81 at Listener.cpp:436 frame #6: 0x0000000100098dcd LLDB lldb::SBListener::WaitForEvent(this=0x00007fff5fbff0f0, timeout_secs=0xffffffff, event=0x00007fff5fbfe430) + 685 at SBListener.cpp:181 frame #7: 0x000000010000628c lldb Driver::MainLoop(this=0x00007fff5fbff620) + 5244 at Driver.cpp:1325 frame #8: 0x0000000100006ca3 lldb main(argc=1, argv=0x00007fff5fbff758, envp=0x00007fff5fbff768) + 419 at Driver.cpp:1460 frame #9: 0x0000000100000d54 lldb start + 52 thread #3: tid = 0x2703, 0x00007fff88a17df2 libsystem_kernel.dylib select$DARWIN_EXTSN + 10, name = <lldb.comm.debugger.input> frame #0: 0x00007fff88a17df2 libsystem_kernel.dylib select$DARWIN_EXTSN + 10 frame #1: 0x0000000100f3f072 LLDB lldb_private::ConnectionFileDescriptor::BytesAvailable(this=0x000000010524d040, timeout_usec=0x004c4b40, error_ptr=0x0000000105640a18) + 722 at ConnectionFileDescriptor.cpp:542 frame #2: 0x0000000100f3e6dd LLDB lldb_private::ConnectionFileDescriptor::Read(this=0x000000010524d040, dst=0x0000000105640a60, dst_len=1024, timeout_usec=0x004c4b40, status=0x0000000105640a14, error_ptr=0x0000000105640a18) + 301 at ConnectionFileDescriptor.cpp:273 frame #3: 0x0000000100f3b8f7 LLDB lldb_private::Communication::ReadFromConnection(this=0x0000000104846270, dst=0x0000000105640a60, dst_len=1024, timeout_usec=0x004c4b40, status=0x0000000105640a14, error_ptr=0x0000000105640a18) + 167 at Communication.cpp:317 frame #4: 0x0000000100f3b197 LLDB lldb_private::Communication::ReadThread(p=0x0000000104846270) + 327 at Communication.cpp:344 frame #5: 0x0000000101078923 LLDB ThreadCreateTrampoline(arg=0x00000001045f6650) + 227 at Host.cpp:549 frame #6: 0x00007fff884aa8bf libsystem_c.dylib _pthread_start + 335 frame #7: 0x00007fff884adb75 libsystem_c.dylib thread_start + 13 thread #4: tid = 0x2803, 0x00007fff88a17df2 libsystem_kernel.dylib select$DARWIN_EXTSN + 10, name = <lldb.comm.driver.editline> frame #0: 0x00007fff88a17df2 libsystem_kernel.dylib select$DARWIN_EXTSN + 10 frame #1: 0x0000000100f3f072 LLDB lldb_private::ConnectionFileDescriptor::BytesAvailable(this=0x0000000105700370, timeout_usec=0x004c4b40, error_ptr=0x00000001056c3a18) + 722 at ConnectionFileDescriptor.cpp:542 frame #2: 0x0000000100f3e6dd LLDB lldb_private::ConnectionFileDescriptor::Read(this=0x0000000105700370, dst=0x00000001056c3a60, dst_len=1024, timeout_usec=0x004c4b40, status=0x00000001056c3a14, error_ptr=0x00000001056c3a18) + 301 at ConnectionFileDescriptor.cpp:273 frame #3: 0x0000000100f3b8f7 LLDB lldb_private::Communication::ReadFromConnection(this=0x0000000105700000, dst=0x00000001056c3a60, dst_len=1024, timeout_usec=0x004c4b40, status=0x00000001056c3a14, error_ptr=0x00000001056c3a18) + 167 at Communication.cpp:317 frame #4: 0x0000000100f3b197 LLDB lldb_private::Communication::ReadThread(p=0x0000000105700000) + 327 at Communication.cpp:344 frame #5: 0x0000000101078923 LLDB ThreadCreateTrampoline(arg=0x0000000105700430) + 227 at Host.cpp:549 frame #6: 0x00007fff884aa8bf libsystem_c.dylib _pthread_start + 335 frame #7: 0x00007fff884adb75 libsystem_c.dylib thread_start + 13 thread #5: tid = 0x2903, 0x00007fff88a17df2 libsystem_kernel.dylib select$DARWIN_EXTSN + 10, name = <lldb.comm.driver.editline_output> frame #0: 0x00007fff88a17df2 libsystem_kernel.dylib select$DARWIN_EXTSN + 10 frame #1: 0x0000000100f3f072 LLDB lldb_private::ConnectionFileDescriptor::BytesAvailable(this=0x00000001057178f0, timeout_usec=0x004c4b40, error_ptr=0x0000000105980a18) + 722 at ConnectionFileDescriptor.cpp:542 frame #2: 0x0000000100f3e6dd LLDB lldb_private::ConnectionFileDescriptor::Read(this=0x00000001057178f0, dst=0x0000000105980a60, dst_len=1024, timeout_usec=0x004c4b40, status=0x0000000105980a14, error_ptr=0x0000000105980a18) + 301 at ConnectionFileDescriptor.cpp:273 frame #3: 0x0000000100f3b8f7 LLDB lldb_private::Communication::ReadFromConnection(this=0x0000000105717580, dst=0x0000000105980a60, dst_len=1024, timeout_usec=0x004c4b40, status=0x0000000105980a14, error_ptr=0x0000000105980a18) + 167 at Communication.cpp:317 frame #4: 0x0000000100f3b197 LLDB lldb_private::Communication::ReadThread(p=0x0000000105717580) + 327 at Communication.cpp:344 frame #5: 0x0000000101078923 LLDB ThreadCreateTrampoline(arg=0x00000001057179b0) + 227 at Host.cpp:549 frame #6: 0x00007fff884aa8bf libsystem_c.dylib _pthread_start + 335 frame #7: 0x00007fff884adb75 libsystem_c.dylib thread_start + 13 thread #6: tid = 0x2a03, 0x00007fff88a18af2 libsystem_kernel.dylib read + 10, name = <lldb.driver.commandline_io> frame #0: 0x00007fff88a18af2 libsystem_kernel.dylib read + 10 frame #1: 0x0000000100050c3b libedit.3.dylib read_init + 247 frame #2: 0x0000000100050e96 libedit.3.dylib el_wgetc + 155 frame #3: 0x000000010005115d libedit.3.dylib el_wgets + 578 frame #4: 0x000000010005debc libedit.3.dylib el_gets + 37 frame #5: 0x000000010000d409 lldb IOChannel::LibeditGetInput(this=0x0000000105700490, new_line=0x0000000105a03db0) + 89 at IOChannel.cpp:311 frame #6: 0x000000010000d8b6 lldb IOChannel::Run(this=0x0000000105700490) + 806 at IOChannel.cpp:391 frame #7: 0x000000010000d57d lldb IOChannel::IOReadThread(ptr=0x0000000105700490) + 29 at IOChannel.cpp:345 frame #8: 0x0000000101078923 LLDB ThreadCreateTrampoline(arg=0x00000001057179f0) + 227 at Host.cpp:549 frame #9: 0x00007fff884aa8bf libsystem_c.dylib _pthread_start + 335 frame #10: 0x00007fff884adb75 libsystem_c.dylib thread_start + 13 (lldb) llvm-svn: 148110
2012-01-13 16:39:16 +08:00
else if (::strncmp (var_name_begin, "name-with-args}", strlen("name-with-args}")) == 0)
{
// Print the function name with arguments in it
if (sc->function)
{
var_success = true;
ExecutionContextScope *exe_scope = exe_ctx ? exe_ctx->GetBestExecutionContextScope() : NULL;
cstr = sc->function->GetName().AsCString (NULL);
if (cstr)
{
const InlineFunctionInfo *inline_info = NULL;
VariableListSP variable_list_sp;
bool get_function_vars = true;
if (sc->block)
{
Block *inline_block = sc->block->GetContainingInlinedBlock ();
if (inline_block)
{
get_function_vars = false;
inline_info = sc->block->GetInlinedFunctionInfo();
if (inline_info)
variable_list_sp = inline_block->GetBlockVariableList (true);
}
}
if (get_function_vars)
{
variable_list_sp = sc->function->GetBlock(true).GetBlockVariableList (true);
}
if (inline_info)
{
s.PutCString (cstr);
s.PutCString (" [inlined] ");
cstr = inline_info->GetName().GetCString();
}
VariableList args;
if (variable_list_sp)
{
const size_t num_variables = variable_list_sp->GetSize();
for (size_t var_idx = 0; var_idx < num_variables; ++var_idx)
{
VariableSP var_sp (variable_list_sp->GetVariableAtIndex(var_idx));
if (var_sp->GetScope() == eValueTypeVariableArgument)
args.AddVariable (var_sp);
}
}
if (args.GetSize() > 0)
{
const char *open_paren = strchr (cstr, '(');
const char *close_paren = NULL;
if (open_paren)
close_paren = strchr (open_paren, ')');
if (open_paren)
s.Write(cstr, open_paren - cstr + 1);
else
{
s.PutCString (cstr);
s.PutChar ('(');
}
Fixed an issue in the debugger format strings that include "${function.name-with-args}" where we grabbed the variable list size from the wrong list (we needed it from "args" and we were getting it from "variable_list_sp"). llvm-svn: 148425
2012-01-19 05:56:18 +08:00
const size_t num_args = args.GetSize();
Added a new thread and frame format that can be used to display a function name + arguments when the data is available. It seems to work really well, but some more testing is needed before we make this on by default. The new function format name is: ${function.name-with-args} To see how to use these formats see the website: http://lldb.llvm.org/formats.html Here is a sample backtrace of debugging LLDB with LLDB using this new format value: (lldb) thread backtrace all * thread #1: tid = 0x2203, 0x00007fff88a17bca libsystem_kernel.dylib __psynch_cvwait + 10, stop reason = signal SIGINT, name = <lldb.driver.main-thread>, queue = com.apple.main-thread frame #0: 0x00007fff88a17bca libsystem_kernel.dylib __psynch_cvwait + 10 frame #1: 0x00007fff884ae274 libsystem_c.dylib _pthread_cond_wait + 840 frame #2: 0x00000001010778ea LLDB lldb_private::Condition::Wait(this=0x0000000104846770, mutex=0x0000000104846730, abstime=0x0000000000000000, timed_out=0x00007fff5fbfdea7) + 138 at Condition.cpp:92 frame #3: 0x0000000101244c21 LLDB lldb_private::Predicate<bool>::WaitForValueEqualTo(this=0x0000000104846728, value=true, abstime=0x0000000000000000, timed_out=0x00007fff5fbfdea7) + 209 at Predicate.h:317 frame #4: 0x0000000100f6eeb2 LLDB lldb_private::Listener::WaitForEventsInternal(this=0x0000000104846660, timeout=0x0000000000000000, broadcaster=0x0000000000000000, broadcaster_names=0x0000000000000000, num_broadcaster_names=0x00000000, event_type_mask=0x00000000, event_sp=0x00007fff5fbfe030) + 386 at Listener.cpp:388 frame #5: 0x0000000100f6f231 LLDB lldb_private::Listener::WaitForEvent(this=0x0000000104846660, timeout=0x0000000000000000, event_sp=0x00007fff5fbfe030) + 81 at Listener.cpp:436 frame #6: 0x0000000100098dcd LLDB lldb::SBListener::WaitForEvent(this=0x00007fff5fbff0f0, timeout_secs=0xffffffff, event=0x00007fff5fbfe430) + 685 at SBListener.cpp:181 frame #7: 0x000000010000628c lldb Driver::MainLoop(this=0x00007fff5fbff620) + 5244 at Driver.cpp:1325 frame #8: 0x0000000100006ca3 lldb main(argc=1, argv=0x00007fff5fbff758, envp=0x00007fff5fbff768) + 419 at Driver.cpp:1460 frame #9: 0x0000000100000d54 lldb start + 52 thread #3: tid = 0x2703, 0x00007fff88a17df2 libsystem_kernel.dylib select$DARWIN_EXTSN + 10, name = <lldb.comm.debugger.input> frame #0: 0x00007fff88a17df2 libsystem_kernel.dylib select$DARWIN_EXTSN + 10 frame #1: 0x0000000100f3f072 LLDB lldb_private::ConnectionFileDescriptor::BytesAvailable(this=0x000000010524d040, timeout_usec=0x004c4b40, error_ptr=0x0000000105640a18) + 722 at ConnectionFileDescriptor.cpp:542 frame #2: 0x0000000100f3e6dd LLDB lldb_private::ConnectionFileDescriptor::Read(this=0x000000010524d040, dst=0x0000000105640a60, dst_len=1024, timeout_usec=0x004c4b40, status=0x0000000105640a14, error_ptr=0x0000000105640a18) + 301 at ConnectionFileDescriptor.cpp:273 frame #3: 0x0000000100f3b8f7 LLDB lldb_private::Communication::ReadFromConnection(this=0x0000000104846270, dst=0x0000000105640a60, dst_len=1024, timeout_usec=0x004c4b40, status=0x0000000105640a14, error_ptr=0x0000000105640a18) + 167 at Communication.cpp:317 frame #4: 0x0000000100f3b197 LLDB lldb_private::Communication::ReadThread(p=0x0000000104846270) + 327 at Communication.cpp:344 frame #5: 0x0000000101078923 LLDB ThreadCreateTrampoline(arg=0x00000001045f6650) + 227 at Host.cpp:549 frame #6: 0x00007fff884aa8bf libsystem_c.dylib _pthread_start + 335 frame #7: 0x00007fff884adb75 libsystem_c.dylib thread_start + 13 thread #4: tid = 0x2803, 0x00007fff88a17df2 libsystem_kernel.dylib select$DARWIN_EXTSN + 10, name = <lldb.comm.driver.editline> frame #0: 0x00007fff88a17df2 libsystem_kernel.dylib select$DARWIN_EXTSN + 10 frame #1: 0x0000000100f3f072 LLDB lldb_private::ConnectionFileDescriptor::BytesAvailable(this=0x0000000105700370, timeout_usec=0x004c4b40, error_ptr=0x00000001056c3a18) + 722 at ConnectionFileDescriptor.cpp:542 frame #2: 0x0000000100f3e6dd LLDB lldb_private::ConnectionFileDescriptor::Read(this=0x0000000105700370, dst=0x00000001056c3a60, dst_len=1024, timeout_usec=0x004c4b40, status=0x00000001056c3a14, error_ptr=0x00000001056c3a18) + 301 at ConnectionFileDescriptor.cpp:273 frame #3: 0x0000000100f3b8f7 LLDB lldb_private::Communication::ReadFromConnection(this=0x0000000105700000, dst=0x00000001056c3a60, dst_len=1024, timeout_usec=0x004c4b40, status=0x00000001056c3a14, error_ptr=0x00000001056c3a18) + 167 at Communication.cpp:317 frame #4: 0x0000000100f3b197 LLDB lldb_private::Communication::ReadThread(p=0x0000000105700000) + 327 at Communication.cpp:344 frame #5: 0x0000000101078923 LLDB ThreadCreateTrampoline(arg=0x0000000105700430) + 227 at Host.cpp:549 frame #6: 0x00007fff884aa8bf libsystem_c.dylib _pthread_start + 335 frame #7: 0x00007fff884adb75 libsystem_c.dylib thread_start + 13 thread #5: tid = 0x2903, 0x00007fff88a17df2 libsystem_kernel.dylib select$DARWIN_EXTSN + 10, name = <lldb.comm.driver.editline_output> frame #0: 0x00007fff88a17df2 libsystem_kernel.dylib select$DARWIN_EXTSN + 10 frame #1: 0x0000000100f3f072 LLDB lldb_private::ConnectionFileDescriptor::BytesAvailable(this=0x00000001057178f0, timeout_usec=0x004c4b40, error_ptr=0x0000000105980a18) + 722 at ConnectionFileDescriptor.cpp:542 frame #2: 0x0000000100f3e6dd LLDB lldb_private::ConnectionFileDescriptor::Read(this=0x00000001057178f0, dst=0x0000000105980a60, dst_len=1024, timeout_usec=0x004c4b40, status=0x0000000105980a14, error_ptr=0x0000000105980a18) + 301 at ConnectionFileDescriptor.cpp:273 frame #3: 0x0000000100f3b8f7 LLDB lldb_private::Communication::ReadFromConnection(this=0x0000000105717580, dst=0x0000000105980a60, dst_len=1024, timeout_usec=0x004c4b40, status=0x0000000105980a14, error_ptr=0x0000000105980a18) + 167 at Communication.cpp:317 frame #4: 0x0000000100f3b197 LLDB lldb_private::Communication::ReadThread(p=0x0000000105717580) + 327 at Communication.cpp:344 frame #5: 0x0000000101078923 LLDB ThreadCreateTrampoline(arg=0x00000001057179b0) + 227 at Host.cpp:549 frame #6: 0x00007fff884aa8bf libsystem_c.dylib _pthread_start + 335 frame #7: 0x00007fff884adb75 libsystem_c.dylib thread_start + 13 thread #6: tid = 0x2a03, 0x00007fff88a18af2 libsystem_kernel.dylib read + 10, name = <lldb.driver.commandline_io> frame #0: 0x00007fff88a18af2 libsystem_kernel.dylib read + 10 frame #1: 0x0000000100050c3b libedit.3.dylib read_init + 247 frame #2: 0x0000000100050e96 libedit.3.dylib el_wgetc + 155 frame #3: 0x000000010005115d libedit.3.dylib el_wgets + 578 frame #4: 0x000000010005debc libedit.3.dylib el_gets + 37 frame #5: 0x000000010000d409 lldb IOChannel::LibeditGetInput(this=0x0000000105700490, new_line=0x0000000105a03db0) + 89 at IOChannel.cpp:311 frame #6: 0x000000010000d8b6 lldb IOChannel::Run(this=0x0000000105700490) + 806 at IOChannel.cpp:391 frame #7: 0x000000010000d57d lldb IOChannel::IOReadThread(ptr=0x0000000105700490) + 29 at IOChannel.cpp:345 frame #8: 0x0000000101078923 LLDB ThreadCreateTrampoline(arg=0x00000001057179f0) + 227 at Host.cpp:549 frame #9: 0x00007fff884aa8bf libsystem_c.dylib _pthread_start + 335 frame #10: 0x00007fff884adb75 libsystem_c.dylib thread_start + 13 (lldb) llvm-svn: 148110
2012-01-13 16:39:16 +08:00
for (size_t arg_idx = 0; arg_idx < num_args; ++arg_idx)
{
VariableSP var_sp (args.GetVariableAtIndex (arg_idx));
ValueObjectSP var_value_sp (ValueObjectVariable::Create (exe_scope, var_sp));
const char *var_name = var_value_sp->GetName().GetCString();
const char *var_value = var_value_sp->GetValueAsCString();
if (var_value_sp->GetError().Success())
{
if (arg_idx > 0)
s.PutCString (", ");
s.Printf ("%s=%s", var_name, var_value);
}
}
if (close_paren)
s.PutCString (close_paren);
else
s.PutChar(')');
}
else
{
s.PutCString(cstr);
}
}
}
else if (sc->symbol)
{
cstr = sc->symbol->GetName().AsCString (NULL);
if (cstr)
{
s.PutCString(cstr);
var_success = true;
}
}
}
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
else if (::strncmp (var_name_begin, "addr-offset}", strlen("addr-offset}")) == 0)
{
var_success = addr != NULL;
if (var_success)
{
format_addr = *addr;
calculate_format_addr_function_offset = true;
}
}
else if (::strncmp (var_name_begin, "line-offset}", strlen("line-offset}")) == 0)
{
var_success = sc->line_entry.range.GetBaseAddress().IsValid();
if (var_success)
{
format_addr = sc->line_entry.range.GetBaseAddress();
calculate_format_addr_function_offset = true;
}
}
else if (::strncmp (var_name_begin, "pc-offset}", strlen("pc-offset}")) == 0)
{
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
StackFrame *frame = exe_ctx->GetFramePtr();
var_success = frame != NULL;
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
if (var_success)
{
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
format_addr = frame->GetFrameCodeAddress();
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
calculate_format_addr_function_offset = true;
}
}
}
}
break;
case 'l':
if (::strncmp (var_name_begin, "line.", strlen("line.")) == 0)
{
if (sc && sc->line_entry.IsValid())
{
var_name_begin += ::strlen ("line.");
if (::strncmp (var_name_begin, "file.", strlen("file.")) == 0)
{
var_name_begin += ::strlen ("file.");
if (::strncmp (var_name_begin, "basename}", strlen("basename}")) == 0)
{
format_file_spec.GetFilename() = sc->line_entry.file.GetFilename();
var_success = format_file_spec;
}
else if (::strncmp (var_name_begin, "fullpath}", strlen("fullpath}")) == 0)
{
format_file_spec = sc->line_entry.file;
var_success = format_file_spec;
}
}
else if (::strncmp (var_name_begin, "number}", strlen("number}")) == 0)
{
var_success = true;
s.Printf("%u", sc->line_entry.line);
}
else if ((::strncmp (var_name_begin, "start-addr}", strlen("start-addr}")) == 0) ||
(::strncmp (var_name_begin, "end-addr}", strlen("end-addr}")) == 0))
{
var_success = sc && sc->line_entry.range.GetBaseAddress().IsValid();
if (var_success)
{
format_addr = sc->line_entry.range.GetBaseAddress();
if (var_name_begin[0] == 'e')
format_addr.Slide (sc->line_entry.range.GetByteSize());
}
}
}
}
break;
}
if (var_success)
{
// If format addr is valid, then we need to print an address
if (reg_num != LLDB_INVALID_REGNUM)
{
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
StackFrame *frame = exe_ctx->GetFramePtr();
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
// We have a register value to display...
if (reg_num == LLDB_REGNUM_GENERIC_PC && reg_kind == eRegisterKindGeneric)
{
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
format_addr = frame->GetFrameCodeAddress();
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
}
else
{
if (reg_ctx == NULL)
Converted the lldb_private::Process over to use the intrusive shared pointers. Changed the ExecutionContext over to use shared pointers for the target, process, thread and frame since these objects can easily go away at any time and any object that was holding onto an ExecutionContext was running the risk of using a bad object. Now that the shared pointers for target, process, thread and frame are just a single pointer (they all use the instrusive shared pointers) the execution context is much safer and still the same size. Made the shared pointers in the the ExecutionContext class protected and made accessors for all of the various ways to get at the pointers, references, and shared pointers. llvm-svn: 140298
2011-09-22 12:58:26 +08:00
reg_ctx = frame->GetRegisterContext().get();
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
if (reg_ctx)
{
if (reg_kind != kNumRegisterKinds)
reg_num = reg_ctx->ConvertRegisterKindToRegisterNumber(reg_kind, reg_num);
reg_info = reg_ctx->GetRegisterInfoAtIndex (reg_num);
var_success = reg_info != NULL;
}
}
}
if (reg_info != NULL)
{
While implementing unwind information using UnwindAssemblyInstEmulation I ran into some cleanup I have been wanting to do when reading/writing registers. Previously all RegisterContext subclasses would need to implement: virtual bool ReadRegisterBytes (uint32_t reg, DataExtractor &data); virtual bool WriteRegisterBytes (uint32_t reg, DataExtractor &data, uint32_t data_offset = 0); There is now a new class specifically designed to hold register values: lldb_private::RegisterValue The new register context calls that subclasses must implement are: virtual bool ReadRegister (const RegisterInfo *reg_info, RegisterValue &reg_value) = 0; virtual bool WriteRegister (const RegisterInfo *reg_info, const RegisterValue &reg_value) = 0; The RegisterValue class must be big enough to handle any register value. The class contains an enumeration for the value type, and then a union for the data value. Any integer/float values are stored directly in an appropriate host integer/float. Anything bigger is stored in a byte buffer that has a length and byte order. The RegisterValue class also knows how to copy register value bytes into in a buffer with a specified byte order which can be used to write the register value down into memory, and this does the right thing when not all bytes from the register values are needed (getting a uint8 from a uint32 register value..). All RegiterContext and other sources have been switched over to using the new regiter value class. llvm-svn: 131096
2011-05-10 04:18:18 +08:00
RegisterValue reg_value;
var_success = reg_ctx->ReadRegister (reg_info, reg_value);
if (var_success)
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
{
Added generic register numbers for simple ABI argument registers and defined the appropriate registers for arm and x86_64. The register names for the arguments that are the size of a pointer or less are all named "arg1", "arg2", etc. This allows you to read these registers by name: (lldb) register read arg1 arg2 arg3 ... You can also now specify you want to see alternate register names when executing the read register command: (lldb) register read --alternate (lldb) register read -A llvm-svn: 131376
2011-05-15 12:12:07 +08:00
reg_value.Dump(&s, reg_info, false, false, eFormatDefault);
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
}
}
if (format_file_spec)
{
s << format_file_spec;
}
// If format addr is valid, then we need to print an address
if (format_addr.IsValid())
{
There are now to new "settings set" variables that live in each debugger instance: settings set frame-format <string> settings set thread-format <string> This allows users to control the information that is seen when dumping threads and frames. The default values are set such that they do what they used to do prior to changing over the the user defined formats. This allows users with terminals that can display color to make different items different colors using the escape control codes. A few alias examples that will colorize your thread and frame prompts are: settings set frame-format 'frame #${frame.index}: \033[0;33m${frame.pc}\033[0m{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{ \033[0;35mat \033[1;35m${line.file.basename}:${line.number}}\033[0m\n' settings set thread-format 'thread #${thread.index}: \033[1;33mtid\033[0;33m = ${thread.id}\033[0m{, \033[0;33m${frame.pc}\033[0m}{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{, \033[1;35mstop reason\033[0;35m = ${thread.stop-reason}\033[0m}{, \033[1;36mname = \033[0;36m${thread.name}\033[0m}{, \033[1;32mqueue = \033[0;32m${thread.queue}}\033[0m\n' A quick web search for "colorize terminal output" should allow you to see what you can do to make your output look like you want it. The "settings set" commands above can of course be added to your ~/.lldbinit file for permanent use. Changed the pure virtual void ExecutionContextScope::Calculate (ExecutionContext&); To: void ExecutionContextScope::CalculateExecutionContext (ExecutionContext&); I did this because this is a class that anything in the execution context heirarchy inherits from and "target->Calculate (exe_ctx)" didn't always tell you what it was really trying to do unless you look at the parameter. llvm-svn: 115485
2010-10-04 09:05:56 +08:00
var_success = false;
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
if (calculate_format_addr_function_offset)
{
Address func_addr;
There are now to new "settings set" variables that live in each debugger instance: settings set frame-format <string> settings set thread-format <string> This allows users to control the information that is seen when dumping threads and frames. The default values are set such that they do what they used to do prior to changing over the the user defined formats. This allows users with terminals that can display color to make different items different colors using the escape control codes. A few alias examples that will colorize your thread and frame prompts are: settings set frame-format 'frame #${frame.index}: \033[0;33m${frame.pc}\033[0m{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{ \033[0;35mat \033[1;35m${line.file.basename}:${line.number}}\033[0m\n' settings set thread-format 'thread #${thread.index}: \033[1;33mtid\033[0;33m = ${thread.id}\033[0m{, \033[0;33m${frame.pc}\033[0m}{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{, \033[1;35mstop reason\033[0;35m = ${thread.stop-reason}\033[0m}{, \033[1;36mname = \033[0;36m${thread.name}\033[0m}{, \033[1;32mqueue = \033[0;32m${thread.queue}}\033[0m\n' A quick web search for "colorize terminal output" should allow you to see what you can do to make your output look like you want it. The "settings set" commands above can of course be added to your ~/.lldbinit file for permanent use. Changed the pure virtual void ExecutionContextScope::Calculate (ExecutionContext&); To: void ExecutionContextScope::CalculateExecutionContext (ExecutionContext&); I did this because this is a class that anything in the execution context heirarchy inherits from and "target->Calculate (exe_ctx)" didn't always tell you what it was really trying to do unless you look at the parameter. llvm-svn: 115485
2010-10-04 09:05:56 +08:00
if (sc)
{
if (sc->function)
Fixed and issue where we weren't seeing inlined functions anymore. We also now show the correct pc-offset within the inlined function. llvm-svn: 115522
2010-10-05 01:26:49 +08:00
{
There are now to new "settings set" variables that live in each debugger instance: settings set frame-format <string> settings set thread-format <string> This allows users to control the information that is seen when dumping threads and frames. The default values are set such that they do what they used to do prior to changing over the the user defined formats. This allows users with terminals that can display color to make different items different colors using the escape control codes. A few alias examples that will colorize your thread and frame prompts are: settings set frame-format 'frame #${frame.index}: \033[0;33m${frame.pc}\033[0m{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{ \033[0;35mat \033[1;35m${line.file.basename}:${line.number}}\033[0m\n' settings set thread-format 'thread #${thread.index}: \033[1;33mtid\033[0;33m = ${thread.id}\033[0m{, \033[0;33m${frame.pc}\033[0m}{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{, \033[1;35mstop reason\033[0;35m = ${thread.stop-reason}\033[0m}{, \033[1;36mname = \033[0;36m${thread.name}\033[0m}{, \033[1;32mqueue = \033[0;32m${thread.queue}}\033[0m\n' A quick web search for "colorize terminal output" should allow you to see what you can do to make your output look like you want it. The "settings set" commands above can of course be added to your ~/.lldbinit file for permanent use. Changed the pure virtual void ExecutionContextScope::Calculate (ExecutionContext&); To: void ExecutionContextScope::CalculateExecutionContext (ExecutionContext&); I did this because this is a class that anything in the execution context heirarchy inherits from and "target->Calculate (exe_ctx)" didn't always tell you what it was really trying to do unless you look at the parameter. llvm-svn: 115485
2010-10-04 09:05:56 +08:00
func_addr = sc->function->GetAddressRange().GetBaseAddress();
Fixed and issue where we weren't seeing inlined functions anymore. We also now show the correct pc-offset within the inlined function. llvm-svn: 115522
2010-10-05 01:26:49 +08:00
if (sc->block)
{
// Check to make sure we aren't in an inline
// function. If we are, use the inline block
// range that contains "format_addr" since
// blocks can be discontiguous.
Block *inline_block = sc->block->GetContainingInlinedBlock ();
AddressRange inline_range;
if (inline_block && inline_block->GetRangeContainingAddress (format_addr, inline_range))
func_addr = inline_range.GetBaseAddress();
}
}
<rdar://problem/10997402> This fix really needed to happen as a previous fix I had submitted for calculating symbol sizes made many symbols appear to have zero size since the function that was calculating the symbol size was calling another function that would cause the calculation to happen again. This resulted in some symbols having zero size when they shouldn't. This could then cause infinite stack traces and many other side affects. llvm-svn: 152244
2012-03-08 05:03:09 +08:00
else if (sc->symbol && sc->symbol->ValueIsAddress())
func_addr = sc->symbol->GetAddress();
There are now to new "settings set" variables that live in each debugger instance: settings set frame-format <string> settings set thread-format <string> This allows users to control the information that is seen when dumping threads and frames. The default values are set such that they do what they used to do prior to changing over the the user defined formats. This allows users with terminals that can display color to make different items different colors using the escape control codes. A few alias examples that will colorize your thread and frame prompts are: settings set frame-format 'frame #${frame.index}: \033[0;33m${frame.pc}\033[0m{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{ \033[0;35mat \033[1;35m${line.file.basename}:${line.number}}\033[0m\n' settings set thread-format 'thread #${thread.index}: \033[1;33mtid\033[0;33m = ${thread.id}\033[0m{, \033[0;33m${frame.pc}\033[0m}{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{, \033[1;35mstop reason\033[0;35m = ${thread.stop-reason}\033[0m}{, \033[1;36mname = \033[0;36m${thread.name}\033[0m}{, \033[1;32mqueue = \033[0;32m${thread.queue}}\033[0m\n' A quick web search for "colorize terminal output" should allow you to see what you can do to make your output look like you want it. The "settings set" commands above can of course be added to your ~/.lldbinit file for permanent use. Changed the pure virtual void ExecutionContextScope::Calculate (ExecutionContext&); To: void ExecutionContextScope::CalculateExecutionContext (ExecutionContext&); I did this because this is a class that anything in the execution context heirarchy inherits from and "target->Calculate (exe_ctx)" didn't always tell you what it was really trying to do unless you look at the parameter. llvm-svn: 115485
2010-10-04 09:05:56 +08:00
}
if (func_addr.IsValid())
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
{
if (func_addr.GetSection() == format_addr.GetSection())
{
addr_t func_file_addr = func_addr.GetFileAddress();
addr_t addr_file_addr = format_addr.GetFileAddress();
if (addr_file_addr > func_file_addr)
s.Printf(" + %llu", addr_file_addr - func_file_addr);
else if (addr_file_addr < func_file_addr)
s.Printf(" - %llu", func_file_addr - addr_file_addr);
There are now to new "settings set" variables that live in each debugger instance: settings set frame-format <string> settings set thread-format <string> This allows users to control the information that is seen when dumping threads and frames. The default values are set such that they do what they used to do prior to changing over the the user defined formats. This allows users with terminals that can display color to make different items different colors using the escape control codes. A few alias examples that will colorize your thread and frame prompts are: settings set frame-format 'frame #${frame.index}: \033[0;33m${frame.pc}\033[0m{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{ \033[0;35mat \033[1;35m${line.file.basename}:${line.number}}\033[0m\n' settings set thread-format 'thread #${thread.index}: \033[1;33mtid\033[0;33m = ${thread.id}\033[0m{, \033[0;33m${frame.pc}\033[0m}{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{, \033[1;35mstop reason\033[0;35m = ${thread.stop-reason}\033[0m}{, \033[1;36mname = \033[0;36m${thread.name}\033[0m}{, \033[1;32mqueue = \033[0;32m${thread.queue}}\033[0m\n' A quick web search for "colorize terminal output" should allow you to see what you can do to make your output look like you want it. The "settings set" commands above can of course be added to your ~/.lldbinit file for permanent use. Changed the pure virtual void ExecutionContextScope::Calculate (ExecutionContext&); To: void ExecutionContextScope::CalculateExecutionContext (ExecutionContext&); I did this because this is a class that anything in the execution context heirarchy inherits from and "target->Calculate (exe_ctx)" didn't always tell you what it was really trying to do unless you look at the parameter. llvm-svn: 115485
2010-10-04 09:05:56 +08:00
var_success = true;
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
}
else
There are now to new "settings set" variables that live in each debugger instance: settings set frame-format <string> settings set thread-format <string> This allows users to control the information that is seen when dumping threads and frames. The default values are set such that they do what they used to do prior to changing over the the user defined formats. This allows users with terminals that can display color to make different items different colors using the escape control codes. A few alias examples that will colorize your thread and frame prompts are: settings set frame-format 'frame #${frame.index}: \033[0;33m${frame.pc}\033[0m{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{ \033[0;35mat \033[1;35m${line.file.basename}:${line.number}}\033[0m\n' settings set thread-format 'thread #${thread.index}: \033[1;33mtid\033[0;33m = ${thread.id}\033[0m{, \033[0;33m${frame.pc}\033[0m}{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{, \033[1;35mstop reason\033[0;35m = ${thread.stop-reason}\033[0m}{, \033[1;36mname = \033[0;36m${thread.name}\033[0m}{, \033[1;32mqueue = \033[0;32m${thread.queue}}\033[0m\n' A quick web search for "colorize terminal output" should allow you to see what you can do to make your output look like you want it. The "settings set" commands above can of course be added to your ~/.lldbinit file for permanent use. Changed the pure virtual void ExecutionContextScope::Calculate (ExecutionContext&); To: void ExecutionContextScope::CalculateExecutionContext (ExecutionContext&); I did this because this is a class that anything in the execution context heirarchy inherits from and "target->Calculate (exe_ctx)" didn't always tell you what it was really trying to do unless you look at the parameter. llvm-svn: 115485
2010-10-04 09:05:56 +08:00
{
Target *target = Target::GetTargetFromContexts (exe_ctx, sc);
if (target)
{
addr_t func_load_addr = func_addr.GetLoadAddress (target);
addr_t addr_load_addr = format_addr.GetLoadAddress (target);
if (addr_load_addr > func_load_addr)
s.Printf(" + %llu", addr_load_addr - func_load_addr);
else if (addr_load_addr < func_load_addr)
s.Printf(" - %llu", func_load_addr - addr_load_addr);
var_success = true;
}
}
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
}
}
else
{
There are now to new "settings set" variables that live in each debugger instance: settings set frame-format <string> settings set thread-format <string> This allows users to control the information that is seen when dumping threads and frames. The default values are set such that they do what they used to do prior to changing over the the user defined formats. This allows users with terminals that can display color to make different items different colors using the escape control codes. A few alias examples that will colorize your thread and frame prompts are: settings set frame-format 'frame #${frame.index}: \033[0;33m${frame.pc}\033[0m{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{ \033[0;35mat \033[1;35m${line.file.basename}:${line.number}}\033[0m\n' settings set thread-format 'thread #${thread.index}: \033[1;33mtid\033[0;33m = ${thread.id}\033[0m{, \033[0;33m${frame.pc}\033[0m}{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{, \033[1;35mstop reason\033[0;35m = ${thread.stop-reason}\033[0m}{, \033[1;36mname = \033[0;36m${thread.name}\033[0m}{, \033[1;32mqueue = \033[0;32m${thread.queue}}\033[0m\n' A quick web search for "colorize terminal output" should allow you to see what you can do to make your output look like you want it. The "settings set" commands above can of course be added to your ~/.lldbinit file for permanent use. Changed the pure virtual void ExecutionContextScope::Calculate (ExecutionContext&); To: void ExecutionContextScope::CalculateExecutionContext (ExecutionContext&); I did this because this is a class that anything in the execution context heirarchy inherits from and "target->Calculate (exe_ctx)" didn't always tell you what it was really trying to do unless you look at the parameter. llvm-svn: 115485
2010-10-04 09:05:56 +08:00
Target *target = Target::GetTargetFromContexts (exe_ctx, sc);
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
addr_t vaddr = LLDB_INVALID_ADDRESS;
There are now to new "settings set" variables that live in each debugger instance: settings set frame-format <string> settings set thread-format <string> This allows users to control the information that is seen when dumping threads and frames. The default values are set such that they do what they used to do prior to changing over the the user defined formats. This allows users with terminals that can display color to make different items different colors using the escape control codes. A few alias examples that will colorize your thread and frame prompts are: settings set frame-format 'frame #${frame.index}: \033[0;33m${frame.pc}\033[0m{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{ \033[0;35mat \033[1;35m${line.file.basename}:${line.number}}\033[0m\n' settings set thread-format 'thread #${thread.index}: \033[1;33mtid\033[0;33m = ${thread.id}\033[0m{, \033[0;33m${frame.pc}\033[0m}{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{, \033[1;35mstop reason\033[0;35m = ${thread.stop-reason}\033[0m}{, \033[1;36mname = \033[0;36m${thread.name}\033[0m}{, \033[1;32mqueue = \033[0;32m${thread.queue}}\033[0m\n' A quick web search for "colorize terminal output" should allow you to see what you can do to make your output look like you want it. The "settings set" commands above can of course be added to your ~/.lldbinit file for permanent use. Changed the pure virtual void ExecutionContextScope::Calculate (ExecutionContext&); To: void ExecutionContextScope::CalculateExecutionContext (ExecutionContext&); I did this because this is a class that anything in the execution context heirarchy inherits from and "target->Calculate (exe_ctx)" didn't always tell you what it was really trying to do unless you look at the parameter. llvm-svn: 115485
2010-10-04 09:05:56 +08:00
if (exe_ctx && !target->GetSectionLoadList().IsEmpty())
vaddr = format_addr.GetLoadAddress (target);
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
if (vaddr == LLDB_INVALID_ADDRESS)
vaddr = format_addr.GetFileAddress ();
if (vaddr != LLDB_INVALID_ADDRESS)
There are now to new "settings set" variables that live in each debugger instance: settings set frame-format <string> settings set thread-format <string> This allows users to control the information that is seen when dumping threads and frames. The default values are set such that they do what they used to do prior to changing over the the user defined formats. This allows users with terminals that can display color to make different items different colors using the escape control codes. A few alias examples that will colorize your thread and frame prompts are: settings set frame-format 'frame #${frame.index}: \033[0;33m${frame.pc}\033[0m{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{ \033[0;35mat \033[1;35m${line.file.basename}:${line.number}}\033[0m\n' settings set thread-format 'thread #${thread.index}: \033[1;33mtid\033[0;33m = ${thread.id}\033[0m{, \033[0;33m${frame.pc}\033[0m}{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{, \033[1;35mstop reason\033[0;35m = ${thread.stop-reason}\033[0m}{, \033[1;36mname = \033[0;36m${thread.name}\033[0m}{, \033[1;32mqueue = \033[0;32m${thread.queue}}\033[0m\n' A quick web search for "colorize terminal output" should allow you to see what you can do to make your output look like you want it. The "settings set" commands above can of course be added to your ~/.lldbinit file for permanent use. Changed the pure virtual void ExecutionContextScope::Calculate (ExecutionContext&); To: void ExecutionContextScope::CalculateExecutionContext (ExecutionContext&); I did this because this is a class that anything in the execution context heirarchy inherits from and "target->Calculate (exe_ctx)" didn't always tell you what it was really trying to do unless you look at the parameter. llvm-svn: 115485
2010-10-04 09:05:56 +08:00
{
Made lldb_private::ArchSpec contain much more than just an architecture. It now, in addition to cpu type/subtype and architecture flavor, contains: - byte order (big endian, little endian) - address size in bytes - llvm::Triple for true target triple support and for more powerful plug-in selection. llvm-svn: 125602
2011-02-16 05:59:32 +08:00
int addr_width = target->GetArchitecture().GetAddressByteSize() * 2;
Print out addresses with the correct width for 32 bit programs. llvm-svn: 119786
2010-11-19 12:16:11 +08:00
if (addr_width == 0)
addr_width = 16;
s.Printf("0x%*.*llx", addr_width, addr_width, vaddr);
There are now to new "settings set" variables that live in each debugger instance: settings set frame-format <string> settings set thread-format <string> This allows users to control the information that is seen when dumping threads and frames. The default values are set such that they do what they used to do prior to changing over the the user defined formats. This allows users with terminals that can display color to make different items different colors using the escape control codes. A few alias examples that will colorize your thread and frame prompts are: settings set frame-format 'frame #${frame.index}: \033[0;33m${frame.pc}\033[0m{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{ \033[0;35mat \033[1;35m${line.file.basename}:${line.number}}\033[0m\n' settings set thread-format 'thread #${thread.index}: \033[1;33mtid\033[0;33m = ${thread.id}\033[0m{, \033[0;33m${frame.pc}\033[0m}{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{, \033[1;35mstop reason\033[0;35m = ${thread.stop-reason}\033[0m}{, \033[1;36mname = \033[0;36m${thread.name}\033[0m}{, \033[1;32mqueue = \033[0;32m${thread.queue}}\033[0m\n' A quick web search for "colorize terminal output" should allow you to see what you can do to make your output look like you want it. The "settings set" commands above can of course be added to your ~/.lldbinit file for permanent use. Changed the pure virtual void ExecutionContextScope::Calculate (ExecutionContext&); To: void ExecutionContextScope::CalculateExecutionContext (ExecutionContext&); I did this because this is a class that anything in the execution context heirarchy inherits from and "target->Calculate (exe_ctx)" didn't always tell you what it was really trying to do unless you look at the parameter. llvm-svn: 115485
2010-10-04 09:05:56 +08:00
var_success = true;
}
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
}
}
}
if (var_success == false)
success = false;
}
p = var_name_end;
}
else
break;
}
else
{
// We got a dollar sign with no '{' after it, it must just be a dollar sign
s.PutChar(*p);
}
}
else if (*p == '\\')
{
++p; // skip the slash
switch (*p)
{
case 'a': s.PutChar ('\a'); break;
case 'b': s.PutChar ('\b'); break;
case 'f': s.PutChar ('\f'); break;
case 'n': s.PutChar ('\n'); break;
case 'r': s.PutChar ('\r'); break;
case 't': s.PutChar ('\t'); break;
case 'v': s.PutChar ('\v'); break;
case '\'': s.PutChar ('\''); break;
case '\\': s.PutChar ('\\'); break;
case '0':
// 1 to 3 octal chars
{
There are now to new "settings set" variables that live in each debugger instance: settings set frame-format <string> settings set thread-format <string> This allows users to control the information that is seen when dumping threads and frames. The default values are set such that they do what they used to do prior to changing over the the user defined formats. This allows users with terminals that can display color to make different items different colors using the escape control codes. A few alias examples that will colorize your thread and frame prompts are: settings set frame-format 'frame #${frame.index}: \033[0;33m${frame.pc}\033[0m{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{ \033[0;35mat \033[1;35m${line.file.basename}:${line.number}}\033[0m\n' settings set thread-format 'thread #${thread.index}: \033[1;33mtid\033[0;33m = ${thread.id}\033[0m{, \033[0;33m${frame.pc}\033[0m}{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{, \033[1;35mstop reason\033[0;35m = ${thread.stop-reason}\033[0m}{, \033[1;36mname = \033[0;36m${thread.name}\033[0m}{, \033[1;32mqueue = \033[0;32m${thread.queue}}\033[0m\n' A quick web search for "colorize terminal output" should allow you to see what you can do to make your output look like you want it. The "settings set" commands above can of course be added to your ~/.lldbinit file for permanent use. Changed the pure virtual void ExecutionContextScope::Calculate (ExecutionContext&); To: void ExecutionContextScope::CalculateExecutionContext (ExecutionContext&); I did this because this is a class that anything in the execution context heirarchy inherits from and "target->Calculate (exe_ctx)" didn't always tell you what it was really trying to do unless you look at the parameter. llvm-svn: 115485
2010-10-04 09:05:56 +08:00
// Make a string that can hold onto the initial zero char,
// up to 3 octal digits, and a terminating NULL.
char oct_str[5] = { 0, 0, 0, 0, 0 };
int i;
for (i=0; (p[i] >= '0' && p[i] <= '7') && i<4; ++i)
oct_str[i] = p[i];
// We don't want to consume the last octal character since
// the main for loop will do this for us, so we advance p by
// one less than i (even if i is zero)
p += i - 1;
unsigned long octal_value = ::strtoul (oct_str, NULL, 8);
if (octal_value <= UINT8_MAX)
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
{
There are now to new "settings set" variables that live in each debugger instance: settings set frame-format <string> settings set thread-format <string> This allows users to control the information that is seen when dumping threads and frames. The default values are set such that they do what they used to do prior to changing over the the user defined formats. This allows users with terminals that can display color to make different items different colors using the escape control codes. A few alias examples that will colorize your thread and frame prompts are: settings set frame-format 'frame #${frame.index}: \033[0;33m${frame.pc}\033[0m{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{ \033[0;35mat \033[1;35m${line.file.basename}:${line.number}}\033[0m\n' settings set thread-format 'thread #${thread.index}: \033[1;33mtid\033[0;33m = ${thread.id}\033[0m{, \033[0;33m${frame.pc}\033[0m}{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{, \033[1;35mstop reason\033[0;35m = ${thread.stop-reason}\033[0m}{, \033[1;36mname = \033[0;36m${thread.name}\033[0m}{, \033[1;32mqueue = \033[0;32m${thread.queue}}\033[0m\n' A quick web search for "colorize terminal output" should allow you to see what you can do to make your output look like you want it. The "settings set" commands above can of course be added to your ~/.lldbinit file for permanent use. Changed the pure virtual void ExecutionContextScope::Calculate (ExecutionContext&); To: void ExecutionContextScope::CalculateExecutionContext (ExecutionContext&); I did this because this is a class that anything in the execution context heirarchy inherits from and "target->Calculate (exe_ctx)" didn't always tell you what it was really trying to do unless you look at the parameter. llvm-svn: 115485
2010-10-04 09:05:56 +08:00
char octal_char = octal_value;
s.Write (&octal_char, 1);
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
}
}
break;
case 'x':
// hex number in the format
There are now to new "settings set" variables that live in each debugger instance: settings set frame-format <string> settings set thread-format <string> This allows users to control the information that is seen when dumping threads and frames. The default values are set such that they do what they used to do prior to changing over the the user defined formats. This allows users with terminals that can display color to make different items different colors using the escape control codes. A few alias examples that will colorize your thread and frame prompts are: settings set frame-format 'frame #${frame.index}: \033[0;33m${frame.pc}\033[0m{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{ \033[0;35mat \033[1;35m${line.file.basename}:${line.number}}\033[0m\n' settings set thread-format 'thread #${thread.index}: \033[1;33mtid\033[0;33m = ${thread.id}\033[0m{, \033[0;33m${frame.pc}\033[0m}{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{, \033[1;35mstop reason\033[0;35m = ${thread.stop-reason}\033[0m}{, \033[1;36mname = \033[0;36m${thread.name}\033[0m}{, \033[1;32mqueue = \033[0;32m${thread.queue}}\033[0m\n' A quick web search for "colorize terminal output" should allow you to see what you can do to make your output look like you want it. The "settings set" commands above can of course be added to your ~/.lldbinit file for permanent use. Changed the pure virtual void ExecutionContextScope::Calculate (ExecutionContext&); To: void ExecutionContextScope::CalculateExecutionContext (ExecutionContext&); I did this because this is a class that anything in the execution context heirarchy inherits from and "target->Calculate (exe_ctx)" didn't always tell you what it was really trying to do unless you look at the parameter. llvm-svn: 115485
2010-10-04 09:05:56 +08:00
if (isxdigit(p[1]))
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
{
There are now to new "settings set" variables that live in each debugger instance: settings set frame-format <string> settings set thread-format <string> This allows users to control the information that is seen when dumping threads and frames. The default values are set such that they do what they used to do prior to changing over the the user defined formats. This allows users with terminals that can display color to make different items different colors using the escape control codes. A few alias examples that will colorize your thread and frame prompts are: settings set frame-format 'frame #${frame.index}: \033[0;33m${frame.pc}\033[0m{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{ \033[0;35mat \033[1;35m${line.file.basename}:${line.number}}\033[0m\n' settings set thread-format 'thread #${thread.index}: \033[1;33mtid\033[0;33m = ${thread.id}\033[0m{, \033[0;33m${frame.pc}\033[0m}{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{, \033[1;35mstop reason\033[0;35m = ${thread.stop-reason}\033[0m}{, \033[1;36mname = \033[0;36m${thread.name}\033[0m}{, \033[1;32mqueue = \033[0;32m${thread.queue}}\033[0m\n' A quick web search for "colorize terminal output" should allow you to see what you can do to make your output look like you want it. The "settings set" commands above can of course be added to your ~/.lldbinit file for permanent use. Changed the pure virtual void ExecutionContextScope::Calculate (ExecutionContext&); To: void ExecutionContextScope::CalculateExecutionContext (ExecutionContext&); I did this because this is a class that anything in the execution context heirarchy inherits from and "target->Calculate (exe_ctx)" didn't always tell you what it was really trying to do unless you look at the parameter. llvm-svn: 115485
2010-10-04 09:05:56 +08:00
++p; // Skip the 'x'
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
There are now to new "settings set" variables that live in each debugger instance: settings set frame-format <string> settings set thread-format <string> This allows users to control the information that is seen when dumping threads and frames. The default values are set such that they do what they used to do prior to changing over the the user defined formats. This allows users with terminals that can display color to make different items different colors using the escape control codes. A few alias examples that will colorize your thread and frame prompts are: settings set frame-format 'frame #${frame.index}: \033[0;33m${frame.pc}\033[0m{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{ \033[0;35mat \033[1;35m${line.file.basename}:${line.number}}\033[0m\n' settings set thread-format 'thread #${thread.index}: \033[1;33mtid\033[0;33m = ${thread.id}\033[0m{, \033[0;33m${frame.pc}\033[0m}{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{, \033[1;35mstop reason\033[0;35m = ${thread.stop-reason}\033[0m}{, \033[1;36mname = \033[0;36m${thread.name}\033[0m}{, \033[1;32mqueue = \033[0;32m${thread.queue}}\033[0m\n' A quick web search for "colorize terminal output" should allow you to see what you can do to make your output look like you want it. The "settings set" commands above can of course be added to your ~/.lldbinit file for permanent use. Changed the pure virtual void ExecutionContextScope::Calculate (ExecutionContext&); To: void ExecutionContextScope::CalculateExecutionContext (ExecutionContext&); I did this because this is a class that anything in the execution context heirarchy inherits from and "target->Calculate (exe_ctx)" didn't always tell you what it was really trying to do unless you look at the parameter. llvm-svn: 115485
2010-10-04 09:05:56 +08:00
// Make a string that can hold onto two hex chars plus a
// NULL terminator
char hex_str[3] = { 0,0,0 };
hex_str[0] = *p;
if (isxdigit(p[1]))
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
{
There are now to new "settings set" variables that live in each debugger instance: settings set frame-format <string> settings set thread-format <string> This allows users to control the information that is seen when dumping threads and frames. The default values are set such that they do what they used to do prior to changing over the the user defined formats. This allows users with terminals that can display color to make different items different colors using the escape control codes. A few alias examples that will colorize your thread and frame prompts are: settings set frame-format 'frame #${frame.index}: \033[0;33m${frame.pc}\033[0m{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{ \033[0;35mat \033[1;35m${line.file.basename}:${line.number}}\033[0m\n' settings set thread-format 'thread #${thread.index}: \033[1;33mtid\033[0;33m = ${thread.id}\033[0m{, \033[0;33m${frame.pc}\033[0m}{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{, \033[1;35mstop reason\033[0;35m = ${thread.stop-reason}\033[0m}{, \033[1;36mname = \033[0;36m${thread.name}\033[0m}{, \033[1;32mqueue = \033[0;32m${thread.queue}}\033[0m\n' A quick web search for "colorize terminal output" should allow you to see what you can do to make your output look like you want it. The "settings set" commands above can of course be added to your ~/.lldbinit file for permanent use. Changed the pure virtual void ExecutionContextScope::Calculate (ExecutionContext&); To: void ExecutionContextScope::CalculateExecutionContext (ExecutionContext&); I did this because this is a class that anything in the execution context heirarchy inherits from and "target->Calculate (exe_ctx)" didn't always tell you what it was really trying to do unless you look at the parameter. llvm-svn: 115485
2010-10-04 09:05:56 +08:00
++p; // Skip the first of the two hex chars
hex_str[1] = *p;
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
}
There are now to new "settings set" variables that live in each debugger instance: settings set frame-format <string> settings set thread-format <string> This allows users to control the information that is seen when dumping threads and frames. The default values are set such that they do what they used to do prior to changing over the the user defined formats. This allows users with terminals that can display color to make different items different colors using the escape control codes. A few alias examples that will colorize your thread and frame prompts are: settings set frame-format 'frame #${frame.index}: \033[0;33m${frame.pc}\033[0m{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{ \033[0;35mat \033[1;35m${line.file.basename}:${line.number}}\033[0m\n' settings set thread-format 'thread #${thread.index}: \033[1;33mtid\033[0;33m = ${thread.id}\033[0m{, \033[0;33m${frame.pc}\033[0m}{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{, \033[1;35mstop reason\033[0;35m = ${thread.stop-reason}\033[0m}{, \033[1;36mname = \033[0;36m${thread.name}\033[0m}{, \033[1;32mqueue = \033[0;32m${thread.queue}}\033[0m\n' A quick web search for "colorize terminal output" should allow you to see what you can do to make your output look like you want it. The "settings set" commands above can of course be added to your ~/.lldbinit file for permanent use. Changed the pure virtual void ExecutionContextScope::Calculate (ExecutionContext&); To: void ExecutionContextScope::CalculateExecutionContext (ExecutionContext&); I did this because this is a class that anything in the execution context heirarchy inherits from and "target->Calculate (exe_ctx)" didn't always tell you what it was really trying to do unless you look at the parameter. llvm-svn: 115485
2010-10-04 09:05:56 +08:00
unsigned long hex_value = strtoul (hex_str, NULL, 16);
if (hex_value <= UINT8_MAX)
s.PutChar (hex_value);
}
else
{
s.PutChar('x');
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
}
break;
default:
There are now to new "settings set" variables that live in each debugger instance: settings set frame-format <string> settings set thread-format <string> This allows users to control the information that is seen when dumping threads and frames. The default values are set such that they do what they used to do prior to changing over the the user defined formats. This allows users with terminals that can display color to make different items different colors using the escape control codes. A few alias examples that will colorize your thread and frame prompts are: settings set frame-format 'frame #${frame.index}: \033[0;33m${frame.pc}\033[0m{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{ \033[0;35mat \033[1;35m${line.file.basename}:${line.number}}\033[0m\n' settings set thread-format 'thread #${thread.index}: \033[1;33mtid\033[0;33m = ${thread.id}\033[0m{, \033[0;33m${frame.pc}\033[0m}{ \033[1;4;36m${module.file.basename}\033[0;36m ${function.name}{${function.pc-offset}}\033[0m}{, \033[1;35mstop reason\033[0;35m = ${thread.stop-reason}\033[0m}{, \033[1;36mname = \033[0;36m${thread.name}\033[0m}{, \033[1;32mqueue = \033[0;32m${thread.queue}}\033[0m\n' A quick web search for "colorize terminal output" should allow you to see what you can do to make your output look like you want it. The "settings set" commands above can of course be added to your ~/.lldbinit file for permanent use. Changed the pure virtual void ExecutionContextScope::Calculate (ExecutionContext&); To: void ExecutionContextScope::CalculateExecutionContext (ExecutionContext&); I did this because this is a class that anything in the execution context heirarchy inherits from and "target->Calculate (exe_ctx)" didn't always tell you what it was really trying to do unless you look at the parameter. llvm-svn: 115485
2010-10-04 09:05:56 +08:00
// Just desensitize any other character by just printing what
// came after the '\'
s << *p;
Added code that will allow completely customizable prompts for use in replacing the "(lldb)" prompt, the "frame #1..." displays when doing stack backtracing and the "thread #1....". This will allow you to see exactly the information that you want to see where you want to see it. This currently isn't hookup up to the prompts yet, but it will be soon. So what is the format of the prompts? Prompts can contain variables that have access to the current program state. Variables are text that appears in between a prefix of "${" and ends with a "}". Some of the interesting variables include: // The frame index (0, 1, 2, 3...) ${frame.index} // common frame registers with generic names ${frame.pc} ${frame.sp} ${frame.fp} ${frame.ra} ${frame.flags} // Access to any frame registers by name where REGNAME is any register name: ${frame.reg.REGNAME} // The current compile unit file where the frame is located ${file.basename} ${file.fullpath} // Function information ${function.name} ${function.pc-offset} // Process info ${process.file.basename} ${process.file.fullpath} ${process.id} ${process.name} // Thread info ${thread.id} ${thread.index} ${thread.name} ${thread.queue} ${thread.stop-reason} // Target information ${target.arch} // The current module for the current frame (the shared library or executable // that contains the current frame PC value): ${module.file.basename} ${module.file.fullpath} // Access to the line entry for where the current frame is when your thread // is stopped: ${line.file.basename} ${line.file.fullpath} ${line.number} ${line.start-addr} ${line.end-addr} Many times the information that you might have in your prompt might not be available and you won't want it to print out if it isn't valid. To take care of this you can enclose everything that must resolve into a scope. A scope is starts with '{' and ends with '}'. For example in order to only display the current file and line number when the information is available the format would be: "{ at {$line.file.basename}:${line.number}}" Broken down this is: start the scope: "{" format whose content will only be displayed if all information is available: "at {$line.file.basename}:${line.number}" end the scope: "}" We currently can represent the infomration we see when stopped at a frame: frame #0: 0x0000000100000e85 a.out`main + 4 at test.c:19 with the following format: "frame #${frame.index}: ${frame.pc} {${module.file.basename}`}{${function.name}{${function.pc-offset}}{ at ${line.file.basename}:${line.number}}\n" This breaks down to always print: "frame #${frame.index}: ${frame.pc} " only print the module followed by a tick if we have a valid module: "{${module.file.basename}`}" print the function name with optional offset: "{${function.name}{${function.pc-offset}}" print the line info if it is available: "{ at ${line.file.basename}:${line.number}}" then finish off with a newline: "\n" Notice you can also put newlines ("\n") and tabs and everything else you are used to putting in a format string when desensitized with the \ character. Cleaned up some of the user settings controller subclasses. All of them do not have any global settings variables and were all implementing stubs for the get/set global settings variable. Now there is a default version in UserSettingsController that will do nothing. llvm-svn: 114306
2010-09-19 10:33:57 +08:00
break;
}
}
}
if (end)
*end = p;
return success;
}
Add a logging mode that takes a callback and flush'es to that callback. Also add SB API's to set this callback, and to enable the log channels. llvm-svn: 151018
2012-02-21 10:23:08 +08:00
void
Debugger::SetLoggingCallback (lldb::LogOutputCallback log_callback, void *baton)
{
Make Debugger::SetLoggingCallback public, and expose it through the SB API. Sometimes it is not convenient to provide a log callback right when the debugger is created. llvm-svn: 151209
2012-02-23 06:49:20 +08:00
// For simplicity's sake, I am not going to deal with how to close down any
// open logging streams, I just redirect everything from here on out to the
// callback.
Add a logging mode that takes a callback and flush'es to that callback. Also add SB API's to set this callback, and to enable the log channels. llvm-svn: 151018
2012-02-21 10:23:08 +08:00
m_log_callback_stream_sp.reset (new StreamCallback (log_callback, baton));
}
bool
Debugger::EnableLog (const char *channel, const char **categories, const char *log_file, uint32_t log_options, Stream &error_stream)
{
Log::Callbacks log_callbacks;
StreamSP log_stream_sp;
Removed explicit NULL checks for shared pointers and instead made us use implicit casts to bool. This generated a warning in C++11. <rdar://problem/11930775> llvm-svn: 161559
2012-08-09 08:50:26 +08:00
if (m_log_callback_stream_sp)
Add a logging mode that takes a callback and flush'es to that callback. Also add SB API's to set this callback, and to enable the log channels. llvm-svn: 151018
2012-02-21 10:23:08 +08:00
{
log_stream_sp = m_log_callback_stream_sp;
// For now when using the callback mode you always get thread & timestamp.
log_options |= LLDB_LOG_OPTION_PREPEND_TIMESTAMP | LLDB_LOG_OPTION_PREPEND_THREAD_NAME;
}
else if (log_file == NULL || *log_file == '\0')
{
log_stream_sp.reset(new StreamFile(GetOutputFile().GetDescriptor(), false));
}
else
{
LogStreamMap::iterator pos = m_log_streams.find(log_file);
if (pos == m_log_streams.end())
{
log_stream_sp.reset (new StreamFile (log_file));
m_log_streams[log_file] = log_stream_sp;
}
else
log_stream_sp = pos->second;
}
assert (log_stream_sp.get());
if (log_options == 0)
log_options = LLDB_LOG_OPTION_PREPEND_THREAD_NAME | LLDB_LOG_OPTION_THREADSAFE;
if (Log::GetLogChannelCallbacks (channel, log_callbacks))
{
log_callbacks.enable (log_stream_sp, log_options, categories, &error_stream);
return true;
}
else
{
LogChannelSP log_channel_sp (LogChannel::FindPlugin (channel));
if (log_channel_sp)
{
if (log_channel_sp->Enable (log_stream_sp, log_options, &error_stream, categories))
{
return true;
}
else
{
error_stream.Printf ("Invalid log channel '%s'.\n", channel);
return false;
}
}
else
{
error_stream.Printf ("Invalid log channel '%s'.\n", channel);
return false;
}
}
return false;
}