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

2171 lines
93 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
//===-- StackFrame.cpp ------------------------------------------*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
// C Includes
// C++ Includes
// Other libraries and framework includes
// Project includes
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Target; other minor fixes. llvm-svn: 261242
2016-02-19 02:52:47 +08:00
#include "lldb/Target/StackFrame.h"
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
#include "lldb/Core/Debugger.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
#include "lldb/Core/Disassembler.h"
Get rid of Debugger::FormatPrompt() and replace it with the new FormatEntity class. Why? Debugger::FormatPrompt() would run through the format prompt every time and parse it and emit it piece by piece. It also did formatting differently depending on which key/value pair it was parsing. The new code improves on this with the following features: 1 - Allow format strings to be parsed into a FormatEntity::Entry which can contain multiple child FormatEntity::Entry objects. This FormatEntity::Entry is a parsed version of what was previously always done in Debugger::FormatPrompt() so it is more efficient to emit formatted strings using the new parsed FormatEntity::Entry. 2 - Allows errors in format strings to be shown immediately when setting the settings (frame-format, thread-format, disassembly-format 3 - Allows auto completion by implementing a new OptionValueFormatEntity and switching frame-format, thread-format, and disassembly-format settings over to using it. 4 - The FormatEntity::Entry for each of the frame-format, thread-format, disassembly-format settings only replaces the old one if the format parses correctly 5 - Combines all consecutive string values together for efficient output. This means all "${ansi.*}" keys and all desensitized characters like "\n" "\t" "\0721" "\x23" will get combined with their previous strings 6 - ${*.script:} (like "${var.script:mymodule.my_var_function}") have all been switched over to use ${script.*:} "${script.var:mymodule.my_var_function}") to make the format easier to parse as I don't believe anyone was using these format string power user features. 7 - All key values pairs are defined in simple C arrays of entries so it is much easier to add new entries. These changes pave the way for subsequent modifications where we can modify formats to do more (like control the width of value strings can do more and add more functionality more easily like string formatting to control the width, printf formats and more). llvm-svn: 228207
2015-02-05 06:00:53 +08:00
#include "lldb/Core/FormatEntity.h"
Improve the 'type lookup' command such that it guesses to use the current's frame language as the one to start searching from. llvm-svn: 263592
2016-03-16 05:50:51 +08:00
#include "lldb/Core/Mangled.h"
#include "lldb/Core/Module.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
#include "lldb/Core/Value.h"
StackFrame objects now own ValueObjects for any frame variables (locals, args, function statics, file globals and static variables) that a frame contains. The StackFrame objects can give out ValueObjects instances for each variable which allows us to track when a variable changes and doesn't depend on variable names when getting value objects. StackFrame::GetVariableList now takes a boolean to indicate if we want to get the frame compile unit globals and static variables. The value objects in the stack frames can now correctly track when they have been modified. There are a few more tweaks needed to complete this work. The biggest issue is when stepping creates partial stacks (just frame zero usually) and causes previous stack frames not to match up with the current stack frames because the previous frames only has frame zero. We don't really want to require that all previous frames be complete since stepping often must check stack frames to complete their jobs. I will fix this issue tomorrow. llvm-svn: 112800
2010-09-02 10:59:18 +08:00
#include "lldb/Core/ValueObjectVariable.h"
Fixed the "expression" command object to use the StackFrame::GetValueForExpressionPath() function and also hooked up better error reporting for when things fail. Fixed issues with trying to display children of pointers when none are supposed to be shown (no children for function pointers, and more like this). This was causing child value objects to be made that were correctly firing an assertion. llvm-svn: 121841
2010-12-15 13:08:08 +08:00
#include "lldb/Core/ValueObjectConstResult.h"
Added the "frame diagnose" command and use its output to make crash info better. When a process stops due to a crash, we get the crashing instruction and the crashing memory location (if there is one). From the user's perspective it is often unclear what the reason for the crash is in a symbolic sense. To address this, I have added new fuctionality to StackFrame to parse the disassembly and reconstruct the sequence of dereferneces and offsets that were applied to a known variable (or fuction retrn value) to obtain the invalid pointer. This makes use of enhancements in the disassembler, as well as new information provided by the DWARF expression infrastructure, and is exposed through a "frame diagnose" command. It is also used to provide symbolic information, when available, in the event of a crash. The algorithm is very rudimentary, and it needs a bunch of work, including - better parsing for assembly, preferably with help from LLVM - support for non-Apple platforms - cleanup of the algorithm core, preferably to make it all work in terms of Operands instead of register/offset pairs - improvement of the GetExpressioPath() logic to make prettier expression paths, and - better handling of vtables. I welcome all suggestios, improvements, and testcases. llvm-svn: 280692
2016-09-06 12:48:36 +08:00
#include "lldb/Core/ValueObjectMemory.h"
<rdar://problem/11757916> Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes: - Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file". - modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly - Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was. - modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile() Cleaned up header includes a bit as well. llvm-svn: 162860
2012-08-30 05:13:06 +08:00
#include "lldb/Symbol/CompileUnit.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
#include "lldb/Symbol/Function.h"
<rdar://problem/11757916> Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes: - Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file". - modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly - Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was. - modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile() Cleaned up header includes a bit as well. llvm-svn: 162860
2012-08-30 05:13:06 +08:00
#include "lldb/Symbol/Symbol.h"
#include "lldb/Symbol/SymbolContextScope.h"
Fix up LLDB for a change in the way clang represents anonymous unions such that the 'frame variable' command can still find the members of such union as if they were top-level variables in the current scope llvm-svn: 253613
2015-11-20 06:28:58 +08:00
#include "lldb/Symbol/Type.h"
StackFrame objects now own ValueObjects for any frame variables (locals, args, function statics, file globals and static variables) that a frame contains. The StackFrame objects can give out ValueObjects instances for each variable which allows us to track when a variable changes and doesn't depend on variable names when getting value objects. StackFrame::GetVariableList now takes a boolean to indicate if we want to get the frame compile unit globals and static variables. The value objects in the stack frames can now correctly track when they have been modified. There are a few more tweaks needed to complete this work. The biggest issue is when stepping creates partial stacks (just frame zero usually) and causes previous stack frames not to match up with the current stack frames because the previous frames only has frame zero. We don't really want to require that all previous frames be complete since stepping often must check stack frames to complete their jobs. I will fix this issue tomorrow. llvm-svn: 112800
2010-09-02 10:59:18 +08:00
#include "lldb/Symbol/VariableList.h"
Added the "frame diagnose" command and use its output to make crash info better. When a process stops due to a crash, we get the crashing instruction and the crashing memory location (if there is one). From the user's perspective it is often unclear what the reason for the crash is in a symbolic sense. To address this, I have added new fuctionality to StackFrame to parse the disassembly and reconstruct the sequence of dereferneces and offsets that were applied to a known variable (or fuction retrn value) to obtain the invalid pointer. This makes use of enhancements in the disassembler, as well as new information provided by the DWARF expression infrastructure, and is exposed through a "frame diagnose" command. It is also used to provide symbolic information, when available, in the event of a crash. The algorithm is very rudimentary, and it needs a bunch of work, including - better parsing for assembly, preferably with help from LLVM - support for non-Apple platforms - cleanup of the algorithm core, preferably to make it all work in terms of Operands instead of register/offset pairs - improvement of the GetExpressioPath() logic to make prettier expression paths, and - better handling of vtables. I welcome all suggestios, improvements, and testcases. llvm-svn: 280692
2016-09-06 12:48:36 +08:00
#include "lldb/Target/ABI.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
#include "lldb/Target/ExecutionContext.h"
#include "lldb/Target/Process.h"
#include "lldb/Target/RegisterContext.h"
#include "lldb/Target/Target.h"
#include "lldb/Target/Thread.h"
using namespace lldb;
using namespace lldb_private;
// The first bits in the flags are reserved for the SymbolContext::Scope bits
// so we know if we have tried to look up information in our internal symbol
// context (m_sc) already.
Clarified the intent of the SymbolContextScope class in the header documentation. Symbol now inherits from the symbol context scope so that the StackID can use a "SymbolContextScope *" instead of a blockID (which could have been the same as some other blockID from another symbol file). Modified the stacks that are created on subsequent stops to reuse the previous stack frame objects which will allow for some internal optimization using pointer comparisons during stepping. llvm-svn: 112495
2010-08-31 02:11:35 +08:00
#define RESOLVED_FRAME_CODE_ADDR (uint32_t(eSymbolContextEverything + 1))
Added a new bool parameter to many of the DumpStopContext() methods that might dump file paths that allows the dumping of full paths or just the basenames. Switched the stack frame dumping code to use just the basenames for the files instead of the full path. Modified the StackID class to no rely on needing the start PC for the current function/symbol since we can use the SymbolContextScope to uniquely identify that, unless there is no symbol context scope. In that case we can rely upon the current PC value. This saves the StackID from having to calculate the start PC when the StackFrame::GetStackID() accessor is called. Also improved the StackID less than operator to correctly handle inlined stack frames in the same stack. llvm-svn: 112867
2010-09-03 05:44:10 +08:00
#define RESOLVED_FRAME_ID_SYMBOL_SCOPE (RESOLVED_FRAME_CODE_ADDR << 1)
Clarified the intent of the SymbolContextScope class in the header documentation. Symbol now inherits from the symbol context scope so that the StackID can use a "SymbolContextScope *" instead of a blockID (which could have been the same as some other blockID from another symbol file). Modified the stacks that are created on subsequent stops to reuse the previous stack frame objects which will allow for some internal optimization using pointer comparisons during stepping. llvm-svn: 112495
2010-08-31 02:11:35 +08:00
#define GOT_FRAME_BASE (RESOLVED_FRAME_ID_SYMBOL_SCOPE << 1)
#define RESOLVED_VARIABLES (GOT_FRAME_BASE << 1)
Fixed StackFrame::GetVariableList to add global variables to the list of found variables if they have not yet been added. llvm-svn: 117896
2010-11-01 12:38:59 +08:00
#define RESOLVED_GLOBAL_VARIABLES (RESOLVED_VARIABLES << 1)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
second pass over removal of Mutex and Condition llvm-svn: 270024
2016-05-19 13:13:57 +08:00
StackFrame::StackFrame(const ThreadSP &thread_sp, user_id_t frame_idx, user_id_t unwind_frame_index, addr_t cfa,
bool cfa_is_valid, addr_t pc, uint32_t stop_id, bool stop_id_is_valid, bool is_history_frame,
const SymbolContext *sc_ptr)
: m_thread_wp(thread_sp),
m_frame_index(frame_idx),
m_concrete_frame_index(unwind_frame_index),
m_reg_context_sp(),
m_id(pc, cfa, nullptr),
m_frame_code_addr(pc),
m_sc(),
m_flags(),
m_frame_base(),
m_frame_base_error(),
m_cfa_is_valid(cfa_is_valid),
m_stop_id(stop_id),
m_stop_id_is_valid(stop_id_is_valid),
m_is_history_frame(is_history_frame),
m_variable_list_sp(),
m_variable_list_value_objects(),
m_disassembly(),
m_mutex()
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Add new ivars to StackFrame so it can represent a stack collected at some point in the past. We may have nothing more than a pc value for this type of stack frame -- hopefully we'll have a pc and a stop_id so we can track module loads and unloads over time and symbolicate the pc at the correct point in time. Also add a flag to indicate if the CFA for the frame is available (a bit different from a CFA of LLDB_INVALID_ADDRESS) and also an overall setting to indicate whether this is a history stack frame or not. A history stack frame may not have a CFA, it may not have a register context, it may not have variables, it may not have a frame pointer or a stack pointer. <rdar://problem/15314068> llvm-svn: 193987
2013-11-04 19:02:52 +08:00
// If we don't have a CFA value, use the frame index for our StackID so that recursive
// functions properly aren't confused with one another on a history stack.
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Target; other minor fixes. llvm-svn: 261242
2016-02-19 02:52:47 +08:00
if (m_is_history_frame && !m_cfa_is_valid)
Add new ivars to StackFrame so it can represent a stack collected at some point in the past. We may have nothing more than a pc value for this type of stack frame -- hopefully we'll have a pc and a stop_id so we can track module loads and unloads over time and symbolicate the pc at the correct point in time. Also add a flag to indicate if the CFA for the frame is available (a bit different from a CFA of LLDB_INVALID_ADDRESS) and also an overall setting to indicate whether this is a history stack frame or not. A history stack frame may not have a CFA, it may not have a register context, it may not have variables, it may not have a frame pointer or a stack pointer. <rdar://problem/15314068> llvm-svn: 193987
2013-11-04 19:02:52 +08:00
{
second pass over removal of Mutex and Condition llvm-svn: 270024
2016-05-19 13:13:57 +08:00
m_id.SetCFA(m_frame_index);
Add new ivars to StackFrame so it can represent a stack collected at some point in the past. We may have nothing more than a pc value for this type of stack frame -- hopefully we'll have a pc and a stop_id so we can track module loads and unloads over time and symbolicate the pc at the correct point in time. Also add a flag to indicate if the CFA for the frame is available (a bit different from a CFA of LLDB_INVALID_ADDRESS) and also an overall setting to indicate whether this is a history stack frame or not. A history stack frame may not have a CFA, it may not have a register context, it may not have variables, it may not have a frame pointer or a stack pointer. <rdar://problem/15314068> llvm-svn: 193987
2013-11-04 19:02:52 +08:00
}
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Target; other minor fixes. llvm-svn: 261242
2016-02-19 02:52:47 +08:00
if (sc_ptr != nullptr)
Added support for inlined stack frames being represented as real stack frames which is now on by default. Frames are gotten from the unwinder as concrete frames, then if inline frames are to be shown, extra information to track and reconstruct these frames is cached with each Thread and exanded as needed. I added an inline height as part of the lldb_private::StackID class, the class that helps us uniquely identify stack frames. This allows for two frames to shared the same call frame address, yet differ only in inline height. Fixed setting breakpoint by address to not require addresses to resolve. A quick example: % cat main.cpp % ./build/Debug/lldb test/stl/a.out Current executable set to 'test/stl/a.out' (x86_64). (lldb) breakpoint set --address 0x0000000100000d31 Breakpoint created: 1: address = 0x0000000100000d31, locations = 1 (lldb) r Launching 'a.out' (x86_64) (lldb) Process 38031 Stopped * thread #1: tid = 0x2e03, pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280, stop reason = breakpoint 1.1, queue = com.apple.main-thread 277 278 _CharT* 279 _M_data() const 280 -> { return _M_dataplus._M_p; } 281 282 _CharT* 283 _M_data(_CharT* __p) (lldb) bt thread #1: tid = 0x2e03, stop reason = breakpoint 1.1, queue = com.apple.main-thread frame #0: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280 frame #1: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_rep() const at /usr/include/c++/4.2.1/bits/basic_string.h:288 frame #2: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::size() const at /usr/include/c++/4.2.1/bits/basic_string.h:606 frame #3: pc = 0x0000000100000d31, where = a.out`main [inlined] operator<< <char, std::char_traits<char>, std::allocator<char> > at /usr/include/c++/4.2.1/bits/basic_string.h:2414 frame #4: pc = 0x0000000100000d31, where = a.out`main + 33 at /Volumes/work/gclayton/Documents/src/lldb/test/stl/main.cpp:14 frame #5: pc = 0x0000000100000d08, where = a.out`start + 52 Each inline frame contains only the variables that they contain and each inlined stack frame is treated as a single entity. llvm-svn: 111877
2010-08-24 08:45:41 +08:00
{
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
m_sc = *sc_ptr;
second pass over removal of Mutex and Condition llvm-svn: 270024
2016-05-19 13:13:57 +08:00
m_flags.Set(m_sc.GetResolvedMask());
Added support for inlined stack frames being represented as real stack frames which is now on by default. Frames are gotten from the unwinder as concrete frames, then if inline frames are to be shown, extra information to track and reconstruct these frames is cached with each Thread and exanded as needed. I added an inline height as part of the lldb_private::StackID class, the class that helps us uniquely identify stack frames. This allows for two frames to shared the same call frame address, yet differ only in inline height. Fixed setting breakpoint by address to not require addresses to resolve. A quick example: % cat main.cpp % ./build/Debug/lldb test/stl/a.out Current executable set to 'test/stl/a.out' (x86_64). (lldb) breakpoint set --address 0x0000000100000d31 Breakpoint created: 1: address = 0x0000000100000d31, locations = 1 (lldb) r Launching 'a.out' (x86_64) (lldb) Process 38031 Stopped * thread #1: tid = 0x2e03, pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280, stop reason = breakpoint 1.1, queue = com.apple.main-thread 277 278 _CharT* 279 _M_data() const 280 -> { return _M_dataplus._M_p; } 281 282 _CharT* 283 _M_data(_CharT* __p) (lldb) bt thread #1: tid = 0x2e03, stop reason = breakpoint 1.1, queue = com.apple.main-thread frame #0: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280 frame #1: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_rep() const at /usr/include/c++/4.2.1/bits/basic_string.h:288 frame #2: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::size() const at /usr/include/c++/4.2.1/bits/basic_string.h:606 frame #3: pc = 0x0000000100000d31, where = a.out`main [inlined] operator<< <char, std::char_traits<char>, std::allocator<char> > at /usr/include/c++/4.2.1/bits/basic_string.h:2414 frame #4: pc = 0x0000000100000d31, where = a.out`main + 33 at /Volumes/work/gclayton/Documents/src/lldb/test/stl/main.cpp:14 frame #5: pc = 0x0000000100000d08, where = a.out`start + 52 Each inline frame contains only the variables that they contain and each inlined stack frame is treated as a single entity. llvm-svn: 111877
2010-08-24 08:45:41 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
second pass over removal of Mutex and Condition llvm-svn: 270024
2016-05-19 13:13:57 +08:00
StackFrame::StackFrame(const ThreadSP &thread_sp, user_id_t frame_idx, user_id_t unwind_frame_index,
const RegisterContextSP &reg_context_sp, addr_t cfa, addr_t pc, const SymbolContext *sc_ptr)
: m_thread_wp(thread_sp),
m_frame_index(frame_idx),
m_concrete_frame_index(unwind_frame_index),
m_reg_context_sp(reg_context_sp),
m_id(pc, cfa, nullptr),
m_frame_code_addr(pc),
m_sc(),
m_flags(),
m_frame_base(),
m_frame_base_error(),
m_cfa_is_valid(true),
m_stop_id(0),
m_stop_id_is_valid(false),
m_is_history_frame(false),
m_variable_list_sp(),
m_variable_list_value_objects(),
m_disassembly(),
m_mutex()
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Target; other minor fixes. llvm-svn: 261242
2016-02-19 02:52:47 +08:00
if (sc_ptr != nullptr)
Added support for inlined stack frames being represented as real stack frames which is now on by default. Frames are gotten from the unwinder as concrete frames, then if inline frames are to be shown, extra information to track and reconstruct these frames is cached with each Thread and exanded as needed. I added an inline height as part of the lldb_private::StackID class, the class that helps us uniquely identify stack frames. This allows for two frames to shared the same call frame address, yet differ only in inline height. Fixed setting breakpoint by address to not require addresses to resolve. A quick example: % cat main.cpp % ./build/Debug/lldb test/stl/a.out Current executable set to 'test/stl/a.out' (x86_64). (lldb) breakpoint set --address 0x0000000100000d31 Breakpoint created: 1: address = 0x0000000100000d31, locations = 1 (lldb) r Launching 'a.out' (x86_64) (lldb) Process 38031 Stopped * thread #1: tid = 0x2e03, pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280, stop reason = breakpoint 1.1, queue = com.apple.main-thread 277 278 _CharT* 279 _M_data() const 280 -> { return _M_dataplus._M_p; } 281 282 _CharT* 283 _M_data(_CharT* __p) (lldb) bt thread #1: tid = 0x2e03, stop reason = breakpoint 1.1, queue = com.apple.main-thread frame #0: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280 frame #1: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_rep() const at /usr/include/c++/4.2.1/bits/basic_string.h:288 frame #2: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::size() const at /usr/include/c++/4.2.1/bits/basic_string.h:606 frame #3: pc = 0x0000000100000d31, where = a.out`main [inlined] operator<< <char, std::char_traits<char>, std::allocator<char> > at /usr/include/c++/4.2.1/bits/basic_string.h:2414 frame #4: pc = 0x0000000100000d31, where = a.out`main + 33 at /Volumes/work/gclayton/Documents/src/lldb/test/stl/main.cpp:14 frame #5: pc = 0x0000000100000d08, where = a.out`start + 52 Each inline frame contains only the variables that they contain and each inlined stack frame is treated as a single entity. llvm-svn: 111877
2010-08-24 08:45:41 +08:00
{
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
m_sc = *sc_ptr;
second pass over removal of Mutex and Condition llvm-svn: 270024
2016-05-19 13:13:57 +08:00
m_flags.Set(m_sc.GetResolvedMask());
Added support for inlined stack frames being represented as real stack frames which is now on by default. Frames are gotten from the unwinder as concrete frames, then if inline frames are to be shown, extra information to track and reconstruct these frames is cached with each Thread and exanded as needed. I added an inline height as part of the lldb_private::StackID class, the class that helps us uniquely identify stack frames. This allows for two frames to shared the same call frame address, yet differ only in inline height. Fixed setting breakpoint by address to not require addresses to resolve. A quick example: % cat main.cpp % ./build/Debug/lldb test/stl/a.out Current executable set to 'test/stl/a.out' (x86_64). (lldb) breakpoint set --address 0x0000000100000d31 Breakpoint created: 1: address = 0x0000000100000d31, locations = 1 (lldb) r Launching 'a.out' (x86_64) (lldb) Process 38031 Stopped * thread #1: tid = 0x2e03, pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280, stop reason = breakpoint 1.1, queue = com.apple.main-thread 277 278 _CharT* 279 _M_data() const 280 -> { return _M_dataplus._M_p; } 281 282 _CharT* 283 _M_data(_CharT* __p) (lldb) bt thread #1: tid = 0x2e03, stop reason = breakpoint 1.1, queue = com.apple.main-thread frame #0: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280 frame #1: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_rep() const at /usr/include/c++/4.2.1/bits/basic_string.h:288 frame #2: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::size() const at /usr/include/c++/4.2.1/bits/basic_string.h:606 frame #3: pc = 0x0000000100000d31, where = a.out`main [inlined] operator<< <char, std::char_traits<char>, std::allocator<char> > at /usr/include/c++/4.2.1/bits/basic_string.h:2414 frame #4: pc = 0x0000000100000d31, where = a.out`main + 33 at /Volumes/work/gclayton/Documents/src/lldb/test/stl/main.cpp:14 frame #5: pc = 0x0000000100000d08, where = a.out`start + 52 Each inline frame contains only the variables that they contain and each inlined stack frame is treated as a single entity. llvm-svn: 111877
2010-08-24 08:45:41 +08:00
}
second pass over removal of Mutex and Condition llvm-svn: 270024
2016-05-19 13:13:57 +08:00
Added support for inlined stack frames being represented as real stack frames which is now on by default. Frames are gotten from the unwinder as concrete frames, then if inline frames are to be shown, extra information to track and reconstruct these frames is cached with each Thread and exanded as needed. I added an inline height as part of the lldb_private::StackID class, the class that helps us uniquely identify stack frames. This allows for two frames to shared the same call frame address, yet differ only in inline height. Fixed setting breakpoint by address to not require addresses to resolve. A quick example: % cat main.cpp % ./build/Debug/lldb test/stl/a.out Current executable set to 'test/stl/a.out' (x86_64). (lldb) breakpoint set --address 0x0000000100000d31 Breakpoint created: 1: address = 0x0000000100000d31, locations = 1 (lldb) r Launching 'a.out' (x86_64) (lldb) Process 38031 Stopped * thread #1: tid = 0x2e03, pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280, stop reason = breakpoint 1.1, queue = com.apple.main-thread 277 278 _CharT* 279 _M_data() const 280 -> { return _M_dataplus._M_p; } 281 282 _CharT* 283 _M_data(_CharT* __p) (lldb) bt thread #1: tid = 0x2e03, stop reason = breakpoint 1.1, queue = com.apple.main-thread frame #0: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280 frame #1: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_rep() const at /usr/include/c++/4.2.1/bits/basic_string.h:288 frame #2: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::size() const at /usr/include/c++/4.2.1/bits/basic_string.h:606 frame #3: pc = 0x0000000100000d31, where = a.out`main [inlined] operator<< <char, std::char_traits<char>, std::allocator<char> > at /usr/include/c++/4.2.1/bits/basic_string.h:2414 frame #4: pc = 0x0000000100000d31, where = a.out`main + 33 at /Volumes/work/gclayton/Documents/src/lldb/test/stl/main.cpp:14 frame #5: pc = 0x0000000100000d08, where = a.out`start + 52 Each inline frame contains only the variables that they contain and each inlined stack frame is treated as a single entity. llvm-svn: 111877
2010-08-24 08:45:41 +08:00
if (reg_context_sp && !m_sc.target_sp)
{
The second part in thread hardening the internals of LLDB where we make the lldb_private::StackFrame objects hold onto a weak pointer to the thread object. The lldb_private::StackFrame objects the the most volatile objects we have as when we are doing single stepping, frames can often get lost or thrown away, only to be re-created as another object that still refers to the same frame. We have another bug tracking that. But we need to be able to have frames no longer be able to get the thread when they are not part of a thread anymore, and this is the first step (this fix makes that possible but doesn't implement it yet). Also changed lldb_private::ExecutionContextScope to return shared pointers to all objects in the execution context to further thread harden the internals. llvm-svn: 150871
2012-02-18 13:35:26 +08:00
m_sc.target_sp = reg_context_sp->CalculateTarget();
if (m_sc.target_sp)
second pass over removal of Mutex and Condition llvm-svn: 270024
2016-05-19 13:13:57 +08:00
m_flags.Set(eSymbolContextTarget);
Added support for inlined stack frames being represented as real stack frames which is now on by default. Frames are gotten from the unwinder as concrete frames, then if inline frames are to be shown, extra information to track and reconstruct these frames is cached with each Thread and exanded as needed. I added an inline height as part of the lldb_private::StackID class, the class that helps us uniquely identify stack frames. This allows for two frames to shared the same call frame address, yet differ only in inline height. Fixed setting breakpoint by address to not require addresses to resolve. A quick example: % cat main.cpp % ./build/Debug/lldb test/stl/a.out Current executable set to 'test/stl/a.out' (x86_64). (lldb) breakpoint set --address 0x0000000100000d31 Breakpoint created: 1: address = 0x0000000100000d31, locations = 1 (lldb) r Launching 'a.out' (x86_64) (lldb) Process 38031 Stopped * thread #1: tid = 0x2e03, pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280, stop reason = breakpoint 1.1, queue = com.apple.main-thread 277 278 _CharT* 279 _M_data() const 280 -> { return _M_dataplus._M_p; } 281 282 _CharT* 283 _M_data(_CharT* __p) (lldb) bt thread #1: tid = 0x2e03, stop reason = breakpoint 1.1, queue = com.apple.main-thread frame #0: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280 frame #1: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_rep() const at /usr/include/c++/4.2.1/bits/basic_string.h:288 frame #2: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::size() const at /usr/include/c++/4.2.1/bits/basic_string.h:606 frame #3: pc = 0x0000000100000d31, where = a.out`main [inlined] operator<< <char, std::char_traits<char>, std::allocator<char> > at /usr/include/c++/4.2.1/bits/basic_string.h:2414 frame #4: pc = 0x0000000100000d31, where = a.out`main + 33 at /Volumes/work/gclayton/Documents/src/lldb/test/stl/main.cpp:14 frame #5: pc = 0x0000000100000d08, where = a.out`start + 52 Each inline frame contains only the variables that they contain and each inlined stack frame is treated as a single entity. llvm-svn: 111877
2010-08-24 08:45:41 +08:00
}
}
second pass over removal of Mutex and Condition llvm-svn: 270024
2016-05-19 13:13:57 +08:00
StackFrame::StackFrame(const ThreadSP &thread_sp, user_id_t frame_idx, user_id_t unwind_frame_index,
const RegisterContextSP &reg_context_sp, addr_t cfa, const Address &pc_addr,
const SymbolContext *sc_ptr)
: m_thread_wp(thread_sp),
m_frame_index(frame_idx),
m_concrete_frame_index(unwind_frame_index),
m_reg_context_sp(reg_context_sp),
m_id(pc_addr.GetLoadAddress(thread_sp->CalculateTarget().get()), cfa, nullptr),
m_frame_code_addr(pc_addr),
m_sc(),
m_flags(),
m_frame_base(),
m_frame_base_error(),
m_cfa_is_valid(true),
m_stop_id(0),
m_stop_id_is_valid(false),
m_is_history_frame(false),
m_variable_list_sp(),
m_variable_list_value_objects(),
m_disassembly(),
m_mutex()
Added support for inlined stack frames being represented as real stack frames which is now on by default. Frames are gotten from the unwinder as concrete frames, then if inline frames are to be shown, extra information to track and reconstruct these frames is cached with each Thread and exanded as needed. I added an inline height as part of the lldb_private::StackID class, the class that helps us uniquely identify stack frames. This allows for two frames to shared the same call frame address, yet differ only in inline height. Fixed setting breakpoint by address to not require addresses to resolve. A quick example: % cat main.cpp % ./build/Debug/lldb test/stl/a.out Current executable set to 'test/stl/a.out' (x86_64). (lldb) breakpoint set --address 0x0000000100000d31 Breakpoint created: 1: address = 0x0000000100000d31, locations = 1 (lldb) r Launching 'a.out' (x86_64) (lldb) Process 38031 Stopped * thread #1: tid = 0x2e03, pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280, stop reason = breakpoint 1.1, queue = com.apple.main-thread 277 278 _CharT* 279 _M_data() const 280 -> { return _M_dataplus._M_p; } 281 282 _CharT* 283 _M_data(_CharT* __p) (lldb) bt thread #1: tid = 0x2e03, stop reason = breakpoint 1.1, queue = com.apple.main-thread frame #0: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280 frame #1: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_rep() const at /usr/include/c++/4.2.1/bits/basic_string.h:288 frame #2: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::size() const at /usr/include/c++/4.2.1/bits/basic_string.h:606 frame #3: pc = 0x0000000100000d31, where = a.out`main [inlined] operator<< <char, std::char_traits<char>, std::allocator<char> > at /usr/include/c++/4.2.1/bits/basic_string.h:2414 frame #4: pc = 0x0000000100000d31, where = a.out`main + 33 at /Volumes/work/gclayton/Documents/src/lldb/test/stl/main.cpp:14 frame #5: pc = 0x0000000100000d08, where = a.out`start + 52 Each inline frame contains only the variables that they contain and each inlined stack frame is treated as a single entity. llvm-svn: 111877
2010-08-24 08:45:41 +08:00
{
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Target; other minor fixes. llvm-svn: 261242
2016-02-19 02:52:47 +08:00
if (sc_ptr != nullptr)
Added support for inlined stack frames being represented as real stack frames which is now on by default. Frames are gotten from the unwinder as concrete frames, then if inline frames are to be shown, extra information to track and reconstruct these frames is cached with each Thread and exanded as needed. I added an inline height as part of the lldb_private::StackID class, the class that helps us uniquely identify stack frames. This allows for two frames to shared the same call frame address, yet differ only in inline height. Fixed setting breakpoint by address to not require addresses to resolve. A quick example: % cat main.cpp % ./build/Debug/lldb test/stl/a.out Current executable set to 'test/stl/a.out' (x86_64). (lldb) breakpoint set --address 0x0000000100000d31 Breakpoint created: 1: address = 0x0000000100000d31, locations = 1 (lldb) r Launching 'a.out' (x86_64) (lldb) Process 38031 Stopped * thread #1: tid = 0x2e03, pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280, stop reason = breakpoint 1.1, queue = com.apple.main-thread 277 278 _CharT* 279 _M_data() const 280 -> { return _M_dataplus._M_p; } 281 282 _CharT* 283 _M_data(_CharT* __p) (lldb) bt thread #1: tid = 0x2e03, stop reason = breakpoint 1.1, queue = com.apple.main-thread frame #0: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280 frame #1: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_rep() const at /usr/include/c++/4.2.1/bits/basic_string.h:288 frame #2: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::size() const at /usr/include/c++/4.2.1/bits/basic_string.h:606 frame #3: pc = 0x0000000100000d31, where = a.out`main [inlined] operator<< <char, std::char_traits<char>, std::allocator<char> > at /usr/include/c++/4.2.1/bits/basic_string.h:2414 frame #4: pc = 0x0000000100000d31, where = a.out`main + 33 at /Volumes/work/gclayton/Documents/src/lldb/test/stl/main.cpp:14 frame #5: pc = 0x0000000100000d08, where = a.out`start + 52 Each inline frame contains only the variables that they contain and each inlined stack frame is treated as a single entity. llvm-svn: 111877
2010-08-24 08:45:41 +08:00
{
m_sc = *sc_ptr;
second pass over removal of Mutex and Condition llvm-svn: 270024
2016-05-19 13:13:57 +08:00
m_flags.Set(m_sc.GetResolvedMask());
Added support for inlined stack frames being represented as real stack frames which is now on by default. Frames are gotten from the unwinder as concrete frames, then if inline frames are to be shown, extra information to track and reconstruct these frames is cached with each Thread and exanded as needed. I added an inline height as part of the lldb_private::StackID class, the class that helps us uniquely identify stack frames. This allows for two frames to shared the same call frame address, yet differ only in inline height. Fixed setting breakpoint by address to not require addresses to resolve. A quick example: % cat main.cpp % ./build/Debug/lldb test/stl/a.out Current executable set to 'test/stl/a.out' (x86_64). (lldb) breakpoint set --address 0x0000000100000d31 Breakpoint created: 1: address = 0x0000000100000d31, locations = 1 (lldb) r Launching 'a.out' (x86_64) (lldb) Process 38031 Stopped * thread #1: tid = 0x2e03, pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280, stop reason = breakpoint 1.1, queue = com.apple.main-thread 277 278 _CharT* 279 _M_data() const 280 -> { return _M_dataplus._M_p; } 281 282 _CharT* 283 _M_data(_CharT* __p) (lldb) bt thread #1: tid = 0x2e03, stop reason = breakpoint 1.1, queue = com.apple.main-thread frame #0: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280 frame #1: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_rep() const at /usr/include/c++/4.2.1/bits/basic_string.h:288 frame #2: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::size() const at /usr/include/c++/4.2.1/bits/basic_string.h:606 frame #3: pc = 0x0000000100000d31, where = a.out`main [inlined] operator<< <char, std::char_traits<char>, std::allocator<char> > at /usr/include/c++/4.2.1/bits/basic_string.h:2414 frame #4: pc = 0x0000000100000d31, where = a.out`main + 33 at /Volumes/work/gclayton/Documents/src/lldb/test/stl/main.cpp:14 frame #5: pc = 0x0000000100000d08, where = a.out`start + 52 Each inline frame contains only the variables that they contain and each inlined stack frame is treated as a single entity. llvm-svn: 111877
2010-08-24 08:45:41 +08:00
}
second pass over removal of Mutex and Condition llvm-svn: 270024
2016-05-19 13:13:57 +08:00
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Target; other minor fixes. llvm-svn: 261242
2016-02-19 02:52:47 +08:00
if (!m_sc.target_sp && reg_context_sp)
Added support for inlined stack frames being represented as real stack frames which is now on by default. Frames are gotten from the unwinder as concrete frames, then if inline frames are to be shown, extra information to track and reconstruct these frames is cached with each Thread and exanded as needed. I added an inline height as part of the lldb_private::StackID class, the class that helps us uniquely identify stack frames. This allows for two frames to shared the same call frame address, yet differ only in inline height. Fixed setting breakpoint by address to not require addresses to resolve. A quick example: % cat main.cpp % ./build/Debug/lldb test/stl/a.out Current executable set to 'test/stl/a.out' (x86_64). (lldb) breakpoint set --address 0x0000000100000d31 Breakpoint created: 1: address = 0x0000000100000d31, locations = 1 (lldb) r Launching 'a.out' (x86_64) (lldb) Process 38031 Stopped * thread #1: tid = 0x2e03, pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280, stop reason = breakpoint 1.1, queue = com.apple.main-thread 277 278 _CharT* 279 _M_data() const 280 -> { return _M_dataplus._M_p; } 281 282 _CharT* 283 _M_data(_CharT* __p) (lldb) bt thread #1: tid = 0x2e03, stop reason = breakpoint 1.1, queue = com.apple.main-thread frame #0: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280 frame #1: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_rep() const at /usr/include/c++/4.2.1/bits/basic_string.h:288 frame #2: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::size() const at /usr/include/c++/4.2.1/bits/basic_string.h:606 frame #3: pc = 0x0000000100000d31, where = a.out`main [inlined] operator<< <char, std::char_traits<char>, std::allocator<char> > at /usr/include/c++/4.2.1/bits/basic_string.h:2414 frame #4: pc = 0x0000000100000d31, where = a.out`main + 33 at /Volumes/work/gclayton/Documents/src/lldb/test/stl/main.cpp:14 frame #5: pc = 0x0000000100000d08, where = a.out`start + 52 Each inline frame contains only the variables that they contain and each inlined stack frame is treated as a single entity. llvm-svn: 111877
2010-08-24 08:45:41 +08:00
{
The second part in thread hardening the internals of LLDB where we make the lldb_private::StackFrame objects hold onto a weak pointer to the thread object. The lldb_private::StackFrame objects the the most volatile objects we have as when we are doing single stepping, frames can often get lost or thrown away, only to be re-created as another object that still refers to the same frame. We have another bug tracking that. But we need to be able to have frames no longer be able to get the thread when they are not part of a thread anymore, and this is the first step (this fix makes that possible but doesn't implement it yet). Also changed lldb_private::ExecutionContextScope to return shared pointers to all objects in the execution context to further thread harden the internals. llvm-svn: 150871
2012-02-18 13:35:26 +08:00
m_sc.target_sp = reg_context_sp->CalculateTarget();
if (m_sc.target_sp)
second pass over removal of Mutex and Condition llvm-svn: 270024
2016-05-19 13:13:57 +08:00
m_flags.Set(eSymbolContextTarget);
Added support for inlined stack frames being represented as real stack frames which is now on by default. Frames are gotten from the unwinder as concrete frames, then if inline frames are to be shown, extra information to track and reconstruct these frames is cached with each Thread and exanded as needed. I added an inline height as part of the lldb_private::StackID class, the class that helps us uniquely identify stack frames. This allows for two frames to shared the same call frame address, yet differ only in inline height. Fixed setting breakpoint by address to not require addresses to resolve. A quick example: % cat main.cpp % ./build/Debug/lldb test/stl/a.out Current executable set to 'test/stl/a.out' (x86_64). (lldb) breakpoint set --address 0x0000000100000d31 Breakpoint created: 1: address = 0x0000000100000d31, locations = 1 (lldb) r Launching 'a.out' (x86_64) (lldb) Process 38031 Stopped * thread #1: tid = 0x2e03, pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280, stop reason = breakpoint 1.1, queue = com.apple.main-thread 277 278 _CharT* 279 _M_data() const 280 -> { return _M_dataplus._M_p; } 281 282 _CharT* 283 _M_data(_CharT* __p) (lldb) bt thread #1: tid = 0x2e03, stop reason = breakpoint 1.1, queue = com.apple.main-thread frame #0: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280 frame #1: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_rep() const at /usr/include/c++/4.2.1/bits/basic_string.h:288 frame #2: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::size() const at /usr/include/c++/4.2.1/bits/basic_string.h:606 frame #3: pc = 0x0000000100000d31, where = a.out`main [inlined] operator<< <char, std::char_traits<char>, std::allocator<char> > at /usr/include/c++/4.2.1/bits/basic_string.h:2414 frame #4: pc = 0x0000000100000d31, where = a.out`main + 33 at /Volumes/work/gclayton/Documents/src/lldb/test/stl/main.cpp:14 frame #5: pc = 0x0000000100000d08, where = a.out`start + 52 Each inline frame contains only the variables that they contain and each inlined stack frame is treated as a single entity. llvm-svn: 111877
2010-08-24 08:45:41 +08:00
}
second pass over removal of Mutex and Condition llvm-svn: 270024
2016-05-19 13:13:57 +08:00
ModuleSP pc_module_sp(pc_addr.GetModule());
<rdar://problem/10103468> I started work on being able to add symbol files after a debug session had started with a new "target symfile add" command and quickly ran into problems with stale Address objects in breakpoint locations that had lldb_private::Section pointers into modules that had been removed or replaced. This also let to grabbing stale modules from those sections. So I needed to thread harded the Address, Section and related objects. To do this I modified the ModuleChild class to now require a ModuleSP on initialization so that a weak reference can created. I also changed all places that were handing out "Section *" to have them hand out SectionSP. All ObjectFile, SymbolFile and SymbolVendors were inheriting from ModuleChild so all of the find plug-in, static creation function and constructors now require ModuleSP references instead of Module *. Address objects now have weak references to their sections which can safely go stale when a module gets destructed. This checkin doesn't complete the "target symfile add" command, but it does get us a lot clioser to being able to do such things without a high risk of crashing or memory corruption. llvm-svn: 151336
2012-02-24 09:59:29 +08:00
if (!m_sc.module_sp || m_sc.module_sp != pc_module_sp)
Added support for inlined stack frames being represented as real stack frames which is now on by default. Frames are gotten from the unwinder as concrete frames, then if inline frames are to be shown, extra information to track and reconstruct these frames is cached with each Thread and exanded as needed. I added an inline height as part of the lldb_private::StackID class, the class that helps us uniquely identify stack frames. This allows for two frames to shared the same call frame address, yet differ only in inline height. Fixed setting breakpoint by address to not require addresses to resolve. A quick example: % cat main.cpp % ./build/Debug/lldb test/stl/a.out Current executable set to 'test/stl/a.out' (x86_64). (lldb) breakpoint set --address 0x0000000100000d31 Breakpoint created: 1: address = 0x0000000100000d31, locations = 1 (lldb) r Launching 'a.out' (x86_64) (lldb) Process 38031 Stopped * thread #1: tid = 0x2e03, pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280, stop reason = breakpoint 1.1, queue = com.apple.main-thread 277 278 _CharT* 279 _M_data() const 280 -> { return _M_dataplus._M_p; } 281 282 _CharT* 283 _M_data(_CharT* __p) (lldb) bt thread #1: tid = 0x2e03, stop reason = breakpoint 1.1, queue = com.apple.main-thread frame #0: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280 frame #1: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_rep() const at /usr/include/c++/4.2.1/bits/basic_string.h:288 frame #2: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::size() const at /usr/include/c++/4.2.1/bits/basic_string.h:606 frame #3: pc = 0x0000000100000d31, where = a.out`main [inlined] operator<< <char, std::char_traits<char>, std::allocator<char> > at /usr/include/c++/4.2.1/bits/basic_string.h:2414 frame #4: pc = 0x0000000100000d31, where = a.out`main + 33 at /Volumes/work/gclayton/Documents/src/lldb/test/stl/main.cpp:14 frame #5: pc = 0x0000000100000d08, where = a.out`start + 52 Each inline frame contains only the variables that they contain and each inlined stack frame is treated as a single entity. llvm-svn: 111877
2010-08-24 08:45:41 +08:00
{
<rdar://problem/10103468> I started work on being able to add symbol files after a debug session had started with a new "target symfile add" command and quickly ran into problems with stale Address objects in breakpoint locations that had lldb_private::Section pointers into modules that had been removed or replaced. This also let to grabbing stale modules from those sections. So I needed to thread harded the Address, Section and related objects. To do this I modified the ModuleChild class to now require a ModuleSP on initialization so that a weak reference can created. I also changed all places that were handing out "Section *" to have them hand out SectionSP. All ObjectFile, SymbolFile and SymbolVendors were inheriting from ModuleChild so all of the find plug-in, static creation function and constructors now require ModuleSP references instead of Module *. Address objects now have weak references to their sections which can safely go stale when a module gets destructed. This checkin doesn't complete the "target symfile add" command, but it does get us a lot clioser to being able to do such things without a high risk of crashing or memory corruption. llvm-svn: 151336
2012-02-24 09:59:29 +08:00
if (pc_module_sp)
Added support for inlined stack frames being represented as real stack frames which is now on by default. Frames are gotten from the unwinder as concrete frames, then if inline frames are to be shown, extra information to track and reconstruct these frames is cached with each Thread and exanded as needed. I added an inline height as part of the lldb_private::StackID class, the class that helps us uniquely identify stack frames. This allows for two frames to shared the same call frame address, yet differ only in inline height. Fixed setting breakpoint by address to not require addresses to resolve. A quick example: % cat main.cpp % ./build/Debug/lldb test/stl/a.out Current executable set to 'test/stl/a.out' (x86_64). (lldb) breakpoint set --address 0x0000000100000d31 Breakpoint created: 1: address = 0x0000000100000d31, locations = 1 (lldb) r Launching 'a.out' (x86_64) (lldb) Process 38031 Stopped * thread #1: tid = 0x2e03, pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280, stop reason = breakpoint 1.1, queue = com.apple.main-thread 277 278 _CharT* 279 _M_data() const 280 -> { return _M_dataplus._M_p; } 281 282 _CharT* 283 _M_data(_CharT* __p) (lldb) bt thread #1: tid = 0x2e03, stop reason = breakpoint 1.1, queue = com.apple.main-thread frame #0: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280 frame #1: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_rep() const at /usr/include/c++/4.2.1/bits/basic_string.h:288 frame #2: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::size() const at /usr/include/c++/4.2.1/bits/basic_string.h:606 frame #3: pc = 0x0000000100000d31, where = a.out`main [inlined] operator<< <char, std::char_traits<char>, std::allocator<char> > at /usr/include/c++/4.2.1/bits/basic_string.h:2414 frame #4: pc = 0x0000000100000d31, where = a.out`main + 33 at /Volumes/work/gclayton/Documents/src/lldb/test/stl/main.cpp:14 frame #5: pc = 0x0000000100000d08, where = a.out`start + 52 Each inline frame contains only the variables that they contain and each inlined stack frame is treated as a single entity. llvm-svn: 111877
2010-08-24 08:45:41 +08:00
{
<rdar://problem/10103468> I started work on being able to add symbol files after a debug session had started with a new "target symfile add" command and quickly ran into problems with stale Address objects in breakpoint locations that had lldb_private::Section pointers into modules that had been removed or replaced. This also let to grabbing stale modules from those sections. So I needed to thread harded the Address, Section and related objects. To do this I modified the ModuleChild class to now require a ModuleSP on initialization so that a weak reference can created. I also changed all places that were handing out "Section *" to have them hand out SectionSP. All ObjectFile, SymbolFile and SymbolVendors were inheriting from ModuleChild so all of the find plug-in, static creation function and constructors now require ModuleSP references instead of Module *. Address objects now have weak references to their sections which can safely go stale when a module gets destructed. This checkin doesn't complete the "target symfile add" command, but it does get us a lot clioser to being able to do such things without a high risk of crashing or memory corruption. llvm-svn: 151336
2012-02-24 09:59:29 +08:00
m_sc.module_sp = pc_module_sp;
second pass over removal of Mutex and Condition llvm-svn: 270024
2016-05-19 13:13:57 +08:00
m_flags.Set(eSymbolContextModule);
Added support for inlined stack frames being represented as real stack frames which is now on by default. Frames are gotten from the unwinder as concrete frames, then if inline frames are to be shown, extra information to track and reconstruct these frames is cached with each Thread and exanded as needed. I added an inline height as part of the lldb_private::StackID class, the class that helps us uniquely identify stack frames. This allows for two frames to shared the same call frame address, yet differ only in inline height. Fixed setting breakpoint by address to not require addresses to resolve. A quick example: % cat main.cpp % ./build/Debug/lldb test/stl/a.out Current executable set to 'test/stl/a.out' (x86_64). (lldb) breakpoint set --address 0x0000000100000d31 Breakpoint created: 1: address = 0x0000000100000d31, locations = 1 (lldb) r Launching 'a.out' (x86_64) (lldb) Process 38031 Stopped * thread #1: tid = 0x2e03, pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280, stop reason = breakpoint 1.1, queue = com.apple.main-thread 277 278 _CharT* 279 _M_data() const 280 -> { return _M_dataplus._M_p; } 281 282 _CharT* 283 _M_data(_CharT* __p) (lldb) bt thread #1: tid = 0x2e03, stop reason = breakpoint 1.1, queue = com.apple.main-thread frame #0: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280 frame #1: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_rep() const at /usr/include/c++/4.2.1/bits/basic_string.h:288 frame #2: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::size() const at /usr/include/c++/4.2.1/bits/basic_string.h:606 frame #3: pc = 0x0000000100000d31, where = a.out`main [inlined] operator<< <char, std::char_traits<char>, std::allocator<char> > at /usr/include/c++/4.2.1/bits/basic_string.h:2414 frame #4: pc = 0x0000000100000d31, where = a.out`main + 33 at /Volumes/work/gclayton/Documents/src/lldb/test/stl/main.cpp:14 frame #5: pc = 0x0000000100000d08, where = a.out`start + 52 Each inline frame contains only the variables that they contain and each inlined stack frame is treated as a single entity. llvm-svn: 111877
2010-08-24 08:45:41 +08:00
}
Fixed an assertion that happened when debugging DWARF in .o files with debug map on macosx. llvm-svn: 113737
2010-09-13 12:34:30 +08:00
else
{
m_sc.module_sp.reset();
}
Added support for inlined stack frames being represented as real stack frames which is now on by default. Frames are gotten from the unwinder as concrete frames, then if inline frames are to be shown, extra information to track and reconstruct these frames is cached with each Thread and exanded as needed. I added an inline height as part of the lldb_private::StackID class, the class that helps us uniquely identify stack frames. This allows for two frames to shared the same call frame address, yet differ only in inline height. Fixed setting breakpoint by address to not require addresses to resolve. A quick example: % cat main.cpp % ./build/Debug/lldb test/stl/a.out Current executable set to 'test/stl/a.out' (x86_64). (lldb) breakpoint set --address 0x0000000100000d31 Breakpoint created: 1: address = 0x0000000100000d31, locations = 1 (lldb) r Launching 'a.out' (x86_64) (lldb) Process 38031 Stopped * thread #1: tid = 0x2e03, pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280, stop reason = breakpoint 1.1, queue = com.apple.main-thread 277 278 _CharT* 279 _M_data() const 280 -> { return _M_dataplus._M_p; } 281 282 _CharT* 283 _M_data(_CharT* __p) (lldb) bt thread #1: tid = 0x2e03, stop reason = breakpoint 1.1, queue = com.apple.main-thread frame #0: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280 frame #1: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_rep() const at /usr/include/c++/4.2.1/bits/basic_string.h:288 frame #2: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::size() const at /usr/include/c++/4.2.1/bits/basic_string.h:606 frame #3: pc = 0x0000000100000d31, where = a.out`main [inlined] operator<< <char, std::char_traits<char>, std::allocator<char> > at /usr/include/c++/4.2.1/bits/basic_string.h:2414 frame #4: pc = 0x0000000100000d31, where = a.out`main + 33 at /Volumes/work/gclayton/Documents/src/lldb/test/stl/main.cpp:14 frame #5: pc = 0x0000000100000d08, where = a.out`start + 52 Each inline frame contains only the variables that they contain and each inlined stack frame is treated as a single entity. llvm-svn: 111877
2010-08-24 08:45:41 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Target; other minor fixes. llvm-svn: 261242
2016-02-19 02:52:47 +08:00
StackFrame::~StackFrame() = default;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
StackID&
StackFrame::GetStackID()
{
second pass over removal of Mutex and Condition llvm-svn: 270024
2016-05-19 13:13:57 +08:00
std::lock_guard<std::recursive_mutex> guard(m_mutex);
Added a new bool parameter to many of the DumpStopContext() methods that might dump file paths that allows the dumping of full paths or just the basenames. Switched the stack frame dumping code to use just the basenames for the files instead of the full path. Modified the StackID class to no rely on needing the start PC for the current function/symbol since we can use the SymbolContextScope to uniquely identify that, unless there is no symbol context scope. In that case we can rely upon the current PC value. This saves the StackID from having to calculate the start PC when the StackFrame::GetStackID() accessor is called. Also improved the StackID less than operator to correctly handle inlined stack frames in the same stack. llvm-svn: 112867
2010-09-03 05:44:10 +08:00
// Make sure we have resolved the StackID object's symbol context scope if
// we already haven't looked it up.
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Clarified the intent of the SymbolContextScope class in the header documentation. Symbol now inherits from the symbol context scope so that the StackID can use a "SymbolContextScope *" instead of a blockID (which could have been the same as some other blockID from another symbol file). Modified the stacks that are created on subsequent stops to reuse the previous stack frame objects which will allow for some internal optimization using pointer comparisons during stepping. llvm-svn: 112495
2010-08-31 02:11:35 +08:00
if (m_flags.IsClear (RESOLVED_FRAME_ID_SYMBOL_SCOPE))
{
Fixed the StackFrame to correctly resolve the StackID's SymbolContextScope. Added extra logging for stepping. Fixed an issue where cached stack frame data could be lost between runs when the thread plans read a stack frame. llvm-svn: 112973
2010-09-04 01:10:42 +08:00
if (m_id.GetSymbolContextScope ())
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Added more API to lldb::SBBlock to allow getting the block parent, sibling and first child block, and access to the inline function information. Added an accessor the StackFrame: Block * lldb_private::StackFrame::GetFrameBlock(); LLDB represents inline functions as lexical blocks that have inlined function information in them. The function above allows us to easily get the top most lexical block that defines a stack frame. When there are no inline functions in function, the block returned ends up being the top most block for the function. When the PC is in an inlined funciton for a frame, this will return the first parent block that has inlined function information. The other accessor: StackFrame::GetBlock() will return the deepest block that matches the frame's PC value. Since most debuggers want to display all variables in the current frame, the Block returned by StackFrame::GetFrameBlock can be used to retrieve all variables for the current frame. Fixed the lldb_private::Block::DumpStopContext(...) to properly display inline frames a block should display all of its inlined functions. Prior to this fix, one of the call sites was being skipped. This is a separate code path from the current default where inlined functions get their own frames. Fixed an issue where a block would always grab variables for any child inline function blocks. llvm-svn: 113195
2010-09-07 12:20:48 +08:00
// We already have a symbol context scope, we just don't have our
// flag bit set.
Clarified the intent of the SymbolContextScope class in the header documentation. Symbol now inherits from the symbol context scope so that the StackID can use a "SymbolContextScope *" instead of a blockID (which could have been the same as some other blockID from another symbol file). Modified the stacks that are created on subsequent stops to reuse the previous stack frame objects which will allow for some internal optimization using pointer comparisons during stepping. llvm-svn: 112495
2010-08-31 02:11:35 +08:00
m_flags.Set (RESOLVED_FRAME_ID_SYMBOL_SCOPE);
Got a lot of the kinks worked out in the inline support after debugging more complex inlined examples. StackFrame classes don't have a "GetPC" anymore, they have "GetFrameCodeAddress()". This is because inlined frames will have a PC value that is the same as the concrete frame that owns the inlined frame, yet the code locations for the frame can be different. We also need to be able to get the real PC value for a given frame so that variables evaluate correctly. To get the actual PC value for a frame you can use: addr_t pc = frame->GetRegisterContext()->GetPC(); Some issues with the StackFrame stomping on its own symbol context were resolved which were causing the information to change for a frame when the stack ID was calculated. Also the StackFrame will now correctly store the symbol context resolve flags for any extra bits of information that were looked up (if you ask for a block only and you find one, you will alwasy have the compile unit and function). llvm-svn: 111964
2010-08-25 05:05:24 +08:00
}
Clarified the intent of the SymbolContextScope class in the header documentation. Symbol now inherits from the symbol context scope so that the StackID can use a "SymbolContextScope *" instead of a blockID (which could have been the same as some other blockID from another symbol file). Modified the stacks that are created on subsequent stops to reuse the previous stack frame objects which will allow for some internal optimization using pointer comparisons during stepping. llvm-svn: 112495
2010-08-31 02:11:35 +08:00
else
Got a lot of the kinks worked out in the inline support after debugging more complex inlined examples. StackFrame classes don't have a "GetPC" anymore, they have "GetFrameCodeAddress()". This is because inlined frames will have a PC value that is the same as the concrete frame that owns the inlined frame, yet the code locations for the frame can be different. We also need to be able to get the real PC value for a given frame so that variables evaluate correctly. To get the actual PC value for a frame you can use: addr_t pc = frame->GetRegisterContext()->GetPC(); Some issues with the StackFrame stomping on its own symbol context were resolved which were causing the information to change for a frame when the stack ID was calculated. Also the StackFrame will now correctly store the symbol context resolve flags for any extra bits of information that were looked up (if you ask for a block only and you find one, you will alwasy have the compile unit and function). llvm-svn: 111964
2010-08-25 05:05:24 +08:00
{
Added more API to lldb::SBBlock to allow getting the block parent, sibling and first child block, and access to the inline function information. Added an accessor the StackFrame: Block * lldb_private::StackFrame::GetFrameBlock(); LLDB represents inline functions as lexical blocks that have inlined function information in them. The function above allows us to easily get the top most lexical block that defines a stack frame. When there are no inline functions in function, the block returned ends up being the top most block for the function. When the PC is in an inlined funciton for a frame, this will return the first parent block that has inlined function information. The other accessor: StackFrame::GetBlock() will return the deepest block that matches the frame's PC value. Since most debuggers want to display all variables in the current frame, the Block returned by StackFrame::GetFrameBlock can be used to retrieve all variables for the current frame. Fixed the lldb_private::Block::DumpStopContext(...) to properly display inline frames a block should display all of its inlined functions. Prior to this fix, one of the call sites was being skipped. This is a separate code path from the current default where inlined functions get their own frames. Fixed an issue where a block would always grab variables for any child inline function blocks. llvm-svn: 113195
2010-09-07 12:20:48 +08:00
// Calculate the frame block and use this for the stack ID symbol
// context scope if we have one.
SymbolContextScope *scope = GetFrameBlock ();
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Target; other minor fixes. llvm-svn: 261242
2016-02-19 02:52:47 +08:00
if (scope == nullptr)
Clarified the intent of the SymbolContextScope class in the header documentation. Symbol now inherits from the symbol context scope so that the StackID can use a "SymbolContextScope *" instead of a blockID (which could have been the same as some other blockID from another symbol file). Modified the stacks that are created on subsequent stops to reuse the previous stack frame objects which will allow for some internal optimization using pointer comparisons during stepping. llvm-svn: 112495
2010-08-31 02:11:35 +08:00
{
Added more API to lldb::SBBlock to allow getting the block parent, sibling and first child block, and access to the inline function information. Added an accessor the StackFrame: Block * lldb_private::StackFrame::GetFrameBlock(); LLDB represents inline functions as lexical blocks that have inlined function information in them. The function above allows us to easily get the top most lexical block that defines a stack frame. When there are no inline functions in function, the block returned ends up being the top most block for the function. When the PC is in an inlined funciton for a frame, this will return the first parent block that has inlined function information. The other accessor: StackFrame::GetBlock() will return the deepest block that matches the frame's PC value. Since most debuggers want to display all variables in the current frame, the Block returned by StackFrame::GetFrameBlock can be used to retrieve all variables for the current frame. Fixed the lldb_private::Block::DumpStopContext(...) to properly display inline frames a block should display all of its inlined functions. Prior to this fix, one of the call sites was being skipped. This is a separate code path from the current default where inlined functions get their own frames. Fixed an issue where a block would always grab variables for any child inline function blocks. llvm-svn: 113195
2010-09-07 12:20:48 +08:00
// We don't have a block, so use the symbol
if (m_flags.IsClear (eSymbolContextSymbol))
GetSymbolContext (eSymbolContextSymbol);
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Target; other minor fixes. llvm-svn: 261242
2016-02-19 02:52:47 +08:00
// It is ok if m_sc.symbol is nullptr here
Added more API to lldb::SBBlock to allow getting the block parent, sibling and first child block, and access to the inline function information. Added an accessor the StackFrame: Block * lldb_private::StackFrame::GetFrameBlock(); LLDB represents inline functions as lexical blocks that have inlined function information in them. The function above allows us to easily get the top most lexical block that defines a stack frame. When there are no inline functions in function, the block returned ends up being the top most block for the function. When the PC is in an inlined funciton for a frame, this will return the first parent block that has inlined function information. The other accessor: StackFrame::GetBlock() will return the deepest block that matches the frame's PC value. Since most debuggers want to display all variables in the current frame, the Block returned by StackFrame::GetFrameBlock can be used to retrieve all variables for the current frame. Fixed the lldb_private::Block::DumpStopContext(...) to properly display inline frames a block should display all of its inlined functions. Prior to this fix, one of the call sites was being skipped. This is a separate code path from the current default where inlined functions get their own frames. Fixed an issue where a block would always grab variables for any child inline function blocks. llvm-svn: 113195
2010-09-07 12:20:48 +08:00
scope = m_sc.symbol;
Clarified the intent of the SymbolContextScope class in the header documentation. Symbol now inherits from the symbol context scope so that the StackID can use a "SymbolContextScope *" instead of a blockID (which could have been the same as some other blockID from another symbol file). Modified the stacks that are created on subsequent stops to reuse the previous stack frame objects which will allow for some internal optimization using pointer comparisons during stepping. llvm-svn: 112495
2010-08-31 02:11:35 +08:00
}
Added more API to lldb::SBBlock to allow getting the block parent, sibling and first child block, and access to the inline function information. Added an accessor the StackFrame: Block * lldb_private::StackFrame::GetFrameBlock(); LLDB represents inline functions as lexical blocks that have inlined function information in them. The function above allows us to easily get the top most lexical block that defines a stack frame. When there are no inline functions in function, the block returned ends up being the top most block for the function. When the PC is in an inlined funciton for a frame, this will return the first parent block that has inlined function information. The other accessor: StackFrame::GetBlock() will return the deepest block that matches the frame's PC value. Since most debuggers want to display all variables in the current frame, the Block returned by StackFrame::GetFrameBlock can be used to retrieve all variables for the current frame. Fixed the lldb_private::Block::DumpStopContext(...) to properly display inline frames a block should display all of its inlined functions. Prior to this fix, one of the call sites was being skipped. This is a separate code path from the current default where inlined functions get their own frames. Fixed an issue where a block would always grab variables for any child inline function blocks. llvm-svn: 113195
2010-09-07 12:20:48 +08:00
// Set the symbol context scope (the accessor will set the
// RESOLVED_FRAME_ID_SYMBOL_SCOPE bit in m_flags).
SetSymbolContextScope (scope);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
}
return m_id;
}
Initial check-in of "fancy" inlined stepping. Doesn't do anything useful unless you switch LLDB_FANCY_INLINED_STEPPING to true. With that on, basic inlined stepping works, including step-over of inlined functions. But for some as yet mysterious reason i386 debugging gets an assert and dies immediately. So for now its off. llvm-svn: 163044
2012-09-01 09:02:41 +08:00
uint32_t
StackFrame::GetFrameIndex () const
{
ThreadSP thread_sp = GetThread();
if (thread_sp)
Roll back the changes I made in r193907 which created a new Frame pure virtual base class and made StackFrame a subclass of that. As I started to build on top of that arrangement today, I found that it wasn't working out like I intended. Instead I'll try sticking with the single StackFrame class -- there's too much code duplication to make a more complicated class hierarchy sensible I think. llvm-svn: 193983
2013-11-04 17:33:30 +08:00
return thread_sp->GetStackFrameList()->GetVisibleStackFrameIndex(m_frame_index);
Initial check-in of "fancy" inlined stepping. Doesn't do anything useful unless you switch LLDB_FANCY_INLINED_STEPPING to true. With that on, basic inlined stepping works, including step-over of inlined functions. But for some as yet mysterious reason i386 debugging gets an assert and dies immediately. So for now its off. llvm-svn: 163044
2012-09-01 09:02:41 +08:00
else
return m_frame_index;
}
Clarified the intent of the SymbolContextScope class in the header documentation. Symbol now inherits from the symbol context scope so that the StackID can use a "SymbolContextScope *" instead of a blockID (which could have been the same as some other blockID from another symbol file). Modified the stacks that are created on subsequent stops to reuse the previous stack frame objects which will allow for some internal optimization using pointer comparisons during stepping. llvm-svn: 112495
2010-08-31 02:11:35 +08:00
void
StackFrame::SetSymbolContextScope (SymbolContextScope *symbol_scope)
{
second pass over removal of Mutex and Condition llvm-svn: 270024
2016-05-19 13:13:57 +08:00
std::lock_guard<std::recursive_mutex> guard(m_mutex);
Clarified the intent of the SymbolContextScope class in the header documentation. Symbol now inherits from the symbol context scope so that the StackID can use a "SymbolContextScope *" instead of a blockID (which could have been the same as some other blockID from another symbol file). Modified the stacks that are created on subsequent stops to reuse the previous stack frame objects which will allow for some internal optimization using pointer comparisons during stepping. llvm-svn: 112495
2010-08-31 02:11:35 +08:00
m_flags.Set (RESOLVED_FRAME_ID_SYMBOL_SCOPE);
m_id.SetSymbolContextScope (symbol_scope);
}
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 Address&
Got a lot of the kinks worked out in the inline support after debugging more complex inlined examples. StackFrame classes don't have a "GetPC" anymore, they have "GetFrameCodeAddress()". This is because inlined frames will have a PC value that is the same as the concrete frame that owns the inlined frame, yet the code locations for the frame can be different. We also need to be able to get the real PC value for a given frame so that variables evaluate correctly. To get the actual PC value for a frame you can use: addr_t pc = frame->GetRegisterContext()->GetPC(); Some issues with the StackFrame stomping on its own symbol context were resolved which were causing the information to change for a frame when the stack ID was calculated. Also the StackFrame will now correctly store the symbol context resolve flags for any extra bits of information that were looked up (if you ask for a block only and you find one, you will alwasy have the compile unit and function). llvm-svn: 111964
2010-08-25 05:05:24 +08:00
StackFrame::GetFrameCodeAddress()
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
second pass over removal of Mutex and Condition llvm-svn: 270024
2016-05-19 13:13:57 +08:00
std::lock_guard<std::recursive_mutex> guard(m_mutex);
Clarified the intent of the SymbolContextScope class in the header documentation. Symbol now inherits from the symbol context scope so that the StackID can use a "SymbolContextScope *" instead of a blockID (which could have been the same as some other blockID from another symbol file). Modified the stacks that are created on subsequent stops to reuse the previous stack frame objects which will allow for some internal optimization using pointer comparisons during stepping. llvm-svn: 112495
2010-08-31 02:11:35 +08:00
if (m_flags.IsClear(RESOLVED_FRAME_CODE_ADDR) && !m_frame_code_addr.IsSectionOffset())
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Clarified the intent of the SymbolContextScope class in the header documentation. Symbol now inherits from the symbol context scope so that the StackID can use a "SymbolContextScope *" instead of a blockID (which could have been the same as some other blockID from another symbol file). Modified the stacks that are created on subsequent stops to reuse the previous stack frame objects which will allow for some internal optimization using pointer comparisons during stepping. llvm-svn: 112495
2010-08-31 02:11:35 +08:00
m_flags.Set (RESOLVED_FRAME_CODE_ADDR);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
// Resolve the PC into a temporary address because if ResolveLoadAddress
// fails to resolve the address, it will clear the address object...
The second part in thread hardening the internals of LLDB where we make the lldb_private::StackFrame objects hold onto a weak pointer to the thread object. The lldb_private::StackFrame objects the the most volatile objects we have as when we are doing single stepping, frames can often get lost or thrown away, only to be re-created as another object that still refers to the same frame. We have another bug tracking that. But we need to be able to have frames no longer be able to get the thread when they are not part of a thread anymore, and this is the first step (this fix makes that possible but doesn't implement it yet). Also changed lldb_private::ExecutionContextScope to return shared pointers to all objects in the execution context to further thread harden the internals. llvm-svn: 150871
2012-02-18 13:35:26 +08:00
ThreadSP thread_sp (GetThread());
if (thread_sp)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
The second part in thread hardening the internals of LLDB where we make the lldb_private::StackFrame objects hold onto a weak pointer to the thread object. The lldb_private::StackFrame objects the the most volatile objects we have as when we are doing single stepping, frames can often get lost or thrown away, only to be re-created as another object that still refers to the same frame. We have another bug tracking that. But we need to be able to have frames no longer be able to get the thread when they are not part of a thread anymore, and this is the first step (this fix makes that possible but doesn't implement it yet). Also changed lldb_private::ExecutionContextScope to return shared pointers to all objects in the execution context to further thread harden the internals. llvm-svn: 150871
2012-02-18 13:35:26 +08:00
TargetSP target_sp (thread_sp->CalculateTarget());
if (target_sp)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Use eAddressClassCode for address lookup for opcodes for stack frames It is required because of the following edge case on arm: bx <addr> Non-tail call in a no return function [data-pool] Marked with $d mapping symbol The return address of the function call will point to the data pool but we have to treat it as code so the StackFrame can calculate the symbols correctly. Differential revision: http://reviews.llvm.org/D12556 llvm-svn: 246958
2015-09-07 17:58:09 +08:00
if (m_frame_code_addr.SetOpcodeLoadAddress (m_frame_code_addr.GetOffset(), target_sp.get(), eAddressClassCode))
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
<rdar://problem/10103468> I started work on being able to add symbol files after a debug session had started with a new "target symfile add" command and quickly ran into problems with stale Address objects in breakpoint locations that had lldb_private::Section pointers into modules that had been removed or replaced. This also let to grabbing stale modules from those sections. So I needed to thread harded the Address, Section and related objects. To do this I modified the ModuleChild class to now require a ModuleSP on initialization so that a weak reference can created. I also changed all places that were handing out "Section *" to have them hand out SectionSP. All ObjectFile, SymbolFile and SymbolVendors were inheriting from ModuleChild so all of the find plug-in, static creation function and constructors now require ModuleSP references instead of Module *. Address objects now have weak references to their sections which can safely go stale when a module gets destructed. This checkin doesn't complete the "target symfile add" command, but it does get us a lot clioser to being able to do such things without a high risk of crashing or memory corruption. llvm-svn: 151336
2012-02-24 09:59:29 +08:00
ModuleSP module_sp (m_frame_code_addr.GetModule());
if (module_sp)
The second part in thread hardening the internals of LLDB where we make the lldb_private::StackFrame objects hold onto a weak pointer to the thread object. The lldb_private::StackFrame objects the the most volatile objects we have as when we are doing single stepping, frames can often get lost or thrown away, only to be re-created as another object that still refers to the same frame. We have another bug tracking that. But we need to be able to have frames no longer be able to get the thread when they are not part of a thread anymore, and this is the first step (this fix makes that possible but doesn't implement it yet). Also changed lldb_private::ExecutionContextScope to return shared pointers to all objects in the execution context to further thread harden the internals. llvm-svn: 150871
2012-02-18 13:35:26 +08:00
{
<rdar://problem/10103468> I started work on being able to add symbol files after a debug session had started with a new "target symfile add" command and quickly ran into problems with stale Address objects in breakpoint locations that had lldb_private::Section pointers into modules that had been removed or replaced. This also let to grabbing stale modules from those sections. So I needed to thread harded the Address, Section and related objects. To do this I modified the ModuleChild class to now require a ModuleSP on initialization so that a weak reference can created. I also changed all places that were handing out "Section *" to have them hand out SectionSP. All ObjectFile, SymbolFile and SymbolVendors were inheriting from ModuleChild so all of the find plug-in, static creation function and constructors now require ModuleSP references instead of Module *. Address objects now have weak references to their sections which can safely go stale when a module gets destructed. This checkin doesn't complete the "target symfile add" command, but it does get us a lot clioser to being able to do such things without a high risk of crashing or memory corruption. llvm-svn: 151336
2012-02-24 09:59:29 +08:00
m_sc.module_sp = module_sp;
m_flags.Set(eSymbolContextModule);
The second part in thread hardening the internals of LLDB where we make the lldb_private::StackFrame objects hold onto a weak pointer to the thread object. The lldb_private::StackFrame objects the the most volatile objects we have as when we are doing single stepping, frames can often get lost or thrown away, only to be re-created as another object that still refers to the same frame. We have another bug tracking that. But we need to be able to have frames no longer be able to get the thread when they are not part of a thread anymore, and this is the first step (this fix makes that possible but doesn't implement it yet). Also changed lldb_private::ExecutionContextScope to return shared pointers to all objects in the execution context to further thread harden the internals. llvm-svn: 150871
2012-02-18 13:35:26 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
}
}
}
Changed the StackID to store its start PC address as a load address instead of a section offset address. Fixed up some very inefficient STL code. llvm-svn: 112230
2010-08-27 06:05:43 +08:00
return m_frame_code_addr;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Add new ivars to StackFrame so it can represent a stack collected at some point in the past. We may have nothing more than a pc value for this type of stack frame -- hopefully we'll have a pc and a stop_id so we can track module loads and unloads over time and symbolicate the pc at the correct point in time. Also add a flag to indicate if the CFA for the frame is available (a bit different from a CFA of LLDB_INVALID_ADDRESS) and also an overall setting to indicate whether this is a history stack frame or not. A history stack frame may not have a CFA, it may not have a register context, it may not have variables, it may not have a frame pointer or a stack pointer. <rdar://problem/15314068> llvm-svn: 193987
2013-11-04 19:02:52 +08:00
bool
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
StackFrame::ChangePC (addr_t pc)
{
second pass over removal of Mutex and Condition llvm-svn: 270024
2016-05-19 13:13:57 +08:00
std::lock_guard<std::recursive_mutex> guard(m_mutex);
Add new ivars to StackFrame so it can represent a stack collected at some point in the past. We may have nothing more than a pc value for this type of stack frame -- hopefully we'll have a pc and a stop_id so we can track module loads and unloads over time and symbolicate the pc at the correct point in time. Also add a flag to indicate if the CFA for the frame is available (a bit different from a CFA of LLDB_INVALID_ADDRESS) and also an overall setting to indicate whether this is a history stack frame or not. A history stack frame may not have a CFA, it may not have a register context, it may not have variables, it may not have a frame pointer or a stack pointer. <rdar://problem/15314068> llvm-svn: 193987
2013-11-04 19:02:52 +08:00
// We can't change the pc value of a history stack frame - it is immutable.
if (m_is_history_frame)
return false;
<rdar://problem/10103468> I started work on being able to add symbol files after a debug session had started with a new "target symfile add" command and quickly ran into problems with stale Address objects in breakpoint locations that had lldb_private::Section pointers into modules that had been removed or replaced. This also let to grabbing stale modules from those sections. So I needed to thread harded the Address, Section and related objects. To do this I modified the ModuleChild class to now require a ModuleSP on initialization so that a weak reference can created. I also changed all places that were handing out "Section *" to have them hand out SectionSP. All ObjectFile, SymbolFile and SymbolVendors were inheriting from ModuleChild so all of the find plug-in, static creation function and constructors now require ModuleSP references instead of Module *. Address objects now have weak references to their sections which can safely go stale when a module gets destructed. This checkin doesn't complete the "target symfile add" command, but it does get us a lot clioser to being able to do such things without a high risk of crashing or memory corruption. llvm-svn: 151336
2012-02-24 09:59:29 +08:00
m_frame_code_addr.SetRawAddress(pc);
<rdar://problem/13265297> StackFrame assumes m_sc is additive, but m_sc can lose its target. So now the SymbolContext::Clear() method takes a bool that indicates if the target should be cleared. Modified all existing code to properly set the bool argument. llvm-svn: 175953
2013-02-23 12:12:47 +08:00
m_sc.Clear(false);
Updated the lldb_private::Flags class to have better method names and made all of the calls inlined in the header file for better performance. Fixed the summary for C string types (array of chars (with any combo if modifiers), and pointers to chars) work in all cases. Fixed an issue where a forward declaration to a clang type could cause itself to resolve itself more than once if, during the resolving of the type itself it caused something to try and resolve itself again. We now remove the clang type from the forward declaration map in the DWARF parser when we start to resolve it and avoid this additional call. This should stop any duplicate members from appearing and throwing all the alignment of structs, unions and classes. llvm-svn: 117437
2010-10-27 11:32:59 +08:00
m_flags.Reset(0);
The second part in thread hardening the internals of LLDB where we make the lldb_private::StackFrame objects hold onto a weak pointer to the thread object. The lldb_private::StackFrame objects the the most volatile objects we have as when we are doing single stepping, frames can often get lost or thrown away, only to be re-created as another object that still refers to the same frame. We have another bug tracking that. But we need to be able to have frames no longer be able to get the thread when they are not part of a thread anymore, and this is the first step (this fix makes that possible but doesn't implement it yet). Also changed lldb_private::ExecutionContextScope to return shared pointers to all objects in the execution context to further thread harden the internals. llvm-svn: 150871
2012-02-18 13:35:26 +08:00
ThreadSP thread_sp (GetThread());
if (thread_sp)
thread_sp->ClearStackFrames ();
Add new ivars to StackFrame so it can represent a stack collected at some point in the past. We may have nothing more than a pc value for this type of stack frame -- hopefully we'll have a pc and a stop_id so we can track module loads and unloads over time and symbolicate the pc at the correct point in time. Also add a flag to indicate if the CFA for the frame is available (a bit different from a CFA of LLDB_INVALID_ADDRESS) and also an overall setting to indicate whether this is a history stack frame or not. A history stack frame may not have a CFA, it may not have a register context, it may not have variables, it may not have a frame pointer or a stack pointer. <rdar://problem/15314068> llvm-svn: 193987
2013-11-04 19:02:52 +08:00
return true;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
const char *
StackFrame::Disassemble ()
{
second pass over removal of Mutex and Condition llvm-svn: 270024
2016-05-19 13:13:57 +08:00
std::lock_guard<std::recursive_mutex> guard(m_mutex);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (m_disassembly.GetSize() == 0)
{
The second part in thread hardening the internals of LLDB where we make the lldb_private::StackFrame objects hold onto a weak pointer to the thread object. The lldb_private::StackFrame objects the the most volatile objects we have as when we are doing single stepping, frames can often get lost or thrown away, only to be re-created as another object that still refers to the same frame. We have another bug tracking that. But we need to be able to have frames no longer be able to get the thread when they are not part of a thread anymore, and this is the first step (this fix makes that possible but doesn't implement it yet). Also changed lldb_private::ExecutionContextScope to return shared pointers to all objects in the execution context to further thread harden the internals. llvm-svn: 150871
2012-02-18 13:35:26 +08:00
ExecutionContext exe_ctx (shared_from_this());
Target *target = exe_ctx.GetTargetPtr();
if (target)
{
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Target; other minor fixes. llvm-svn: 261242
2016-02-19 02:52:47 +08:00
const char *plugin_name = nullptr;
const char *flavor = nullptr;
The second part in thread hardening the internals of LLDB where we make the lldb_private::StackFrame objects hold onto a weak pointer to the thread object. The lldb_private::StackFrame objects the the most volatile objects we have as when we are doing single stepping, frames can often get lost or thrown away, only to be re-created as another object that still refers to the same frame. We have another bug tracking that. But we need to be able to have frames no longer be able to get the thread when they are not part of a thread anymore, and this is the first step (this fix makes that possible but doesn't implement it yet). Also changed lldb_private::ExecutionContextScope to return shared pointers to all objects in the execution context to further thread harden the internals. llvm-svn: 150871
2012-02-18 13:35:26 +08:00
Disassembler::Disassemble (target->GetDebugger(),
target->GetArchitecture(),
Convert from the C-based LLVM Disassembler shim to the full MC Disassembler API's. Calculate "can branch" using the MC API's rather than our hand-rolled regex'es. As extra credit, allow setting the disassembly flavor for x86 based architectures to intel or att. <rdar://problem/11319574> <rdar://problem/9329275> llvm-svn: 176392
2013-03-02 08:26:47 +08:00
plugin_name,
flavor,
The second part in thread hardening the internals of LLDB where we make the lldb_private::StackFrame objects hold onto a weak pointer to the thread object. The lldb_private::StackFrame objects the the most volatile objects we have as when we are doing single stepping, frames can often get lost or thrown away, only to be re-created as another object that still refers to the same frame. We have another bug tracking that. But we need to be able to have frames no longer be able to get the thread when they are not part of a thread anymore, and this is the first step (this fix makes that possible but doesn't implement it yet). Also changed lldb_private::ExecutionContextScope to return shared pointers to all objects in the execution context to further thread harden the internals. llvm-svn: 150871
2012-02-18 13:35:26 +08:00
exe_ctx,
0,
0,
0,
m_disassembly);
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (m_disassembly.GetSize() == 0)
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Target; other minor fixes. llvm-svn: 261242
2016-02-19 02:52:47 +08:00
return nullptr;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
return m_disassembly.GetData();
}
Added more API to lldb::SBBlock to allow getting the block parent, sibling and first child block, and access to the inline function information. Added an accessor the StackFrame: Block * lldb_private::StackFrame::GetFrameBlock(); LLDB represents inline functions as lexical blocks that have inlined function information in them. The function above allows us to easily get the top most lexical block that defines a stack frame. When there are no inline functions in function, the block returned ends up being the top most block for the function. When the PC is in an inlined funciton for a frame, this will return the first parent block that has inlined function information. The other accessor: StackFrame::GetBlock() will return the deepest block that matches the frame's PC value. Since most debuggers want to display all variables in the current frame, the Block returned by StackFrame::GetFrameBlock can be used to retrieve all variables for the current frame. Fixed the lldb_private::Block::DumpStopContext(...) to properly display inline frames a block should display all of its inlined functions. Prior to this fix, one of the call sites was being skipped. This is a separate code path from the current default where inlined functions get their own frames. Fixed an issue where a block would always grab variables for any child inline function blocks. llvm-svn: 113195
2010-09-07 12:20:48 +08:00
Block *
StackFrame::GetFrameBlock ()
{
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Target; other minor fixes. llvm-svn: 261242
2016-02-19 02:52:47 +08:00
if (m_sc.block == nullptr && m_flags.IsClear(eSymbolContextBlock))
Added more API to lldb::SBBlock to allow getting the block parent, sibling and first child block, and access to the inline function information. Added an accessor the StackFrame: Block * lldb_private::StackFrame::GetFrameBlock(); LLDB represents inline functions as lexical blocks that have inlined function information in them. The function above allows us to easily get the top most lexical block that defines a stack frame. When there are no inline functions in function, the block returned ends up being the top most block for the function. When the PC is in an inlined funciton for a frame, this will return the first parent block that has inlined function information. The other accessor: StackFrame::GetBlock() will return the deepest block that matches the frame's PC value. Since most debuggers want to display all variables in the current frame, the Block returned by StackFrame::GetFrameBlock can be used to retrieve all variables for the current frame. Fixed the lldb_private::Block::DumpStopContext(...) to properly display inline frames a block should display all of its inlined functions. Prior to this fix, one of the call sites was being skipped. This is a separate code path from the current default where inlined functions get their own frames. Fixed an issue where a block would always grab variables for any child inline function blocks. llvm-svn: 113195
2010-09-07 12:20:48 +08:00
GetSymbolContext (eSymbolContextBlock);
if (m_sc.block)
{
Block *inline_block = m_sc.block->GetContainingInlinedBlock();
if (inline_block)
{
// Use the block with the inlined function info
// as the frame block we want this frame to have only the variables
// for the inlined function and its non-inlined block child blocks.
return inline_block;
}
else
{
Typo corrections identified by codespell Submitted by giffunip@yahoo.com; I fixed a couple of nearby errors and incorrect changes in the patch. llvm.org/pr27634 llvm-svn: 275983
2016-07-19 23:28:02 +08:00
// This block is not contained within any inlined function blocks
Added more API to lldb::SBBlock to allow getting the block parent, sibling and first child block, and access to the inline function information. Added an accessor the StackFrame: Block * lldb_private::StackFrame::GetFrameBlock(); LLDB represents inline functions as lexical blocks that have inlined function information in them. The function above allows us to easily get the top most lexical block that defines a stack frame. When there are no inline functions in function, the block returned ends up being the top most block for the function. When the PC is in an inlined funciton for a frame, this will return the first parent block that has inlined function information. The other accessor: StackFrame::GetBlock() will return the deepest block that matches the frame's PC value. Since most debuggers want to display all variables in the current frame, the Block returned by StackFrame::GetFrameBlock can be used to retrieve all variables for the current frame. Fixed the lldb_private::Block::DumpStopContext(...) to properly display inline frames a block should display all of its inlined functions. Prior to this fix, one of the call sites was being skipped. This is a separate code path from the current default where inlined functions get their own frames. Fixed an issue where a block would always grab variables for any child inline function blocks. llvm-svn: 113195
2010-09-07 12:20:48 +08:00
// with so we want to use the top most function block.
return &m_sc.function->GetBlock (false);
}
}
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Target; other minor fixes. llvm-svn: 261242
2016-02-19 02:52:47 +08:00
return nullptr;
Added more API to lldb::SBBlock to allow getting the block parent, sibling and first child block, and access to the inline function information. Added an accessor the StackFrame: Block * lldb_private::StackFrame::GetFrameBlock(); LLDB represents inline functions as lexical blocks that have inlined function information in them. The function above allows us to easily get the top most lexical block that defines a stack frame. When there are no inline functions in function, the block returned ends up being the top most block for the function. When the PC is in an inlined funciton for a frame, this will return the first parent block that has inlined function information. The other accessor: StackFrame::GetBlock() will return the deepest block that matches the frame's PC value. Since most debuggers want to display all variables in the current frame, the Block returned by StackFrame::GetFrameBlock can be used to retrieve all variables for the current frame. Fixed the lldb_private::Block::DumpStopContext(...) to properly display inline frames a block should display all of its inlined functions. Prior to this fix, one of the call sites was being skipped. This is a separate code path from the current default where inlined functions get their own frames. Fixed an issue where a block would always grab variables for any child inline function blocks. llvm-svn: 113195
2010-09-07 12:20:48 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
//----------------------------------------------------------------------
// Get the symbol context if we already haven't done so by resolving the
// PC address as much as possible. This way when we pass around a
// StackFrame object, everyone will have as much information as
// possible and no one will ever have to look things up manually.
//----------------------------------------------------------------------
const SymbolContext&
StackFrame::GetSymbolContext (uint32_t resolve_scope)
{
second pass over removal of Mutex and Condition llvm-svn: 270024
2016-05-19 13:13:57 +08:00
std::lock_guard<std::recursive_mutex> guard(m_mutex);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
// Copy our internal symbol context into "sc".
Updated the lldb_private::Flags class to have better method names and made all of the calls inlined in the header file for better performance. Fixed the summary for C string types (array of chars (with any combo if modifiers), and pointers to chars) work in all cases. Fixed an issue where a forward declaration to a clang type could cause itself to resolve itself more than once if, during the resolving of the type itself it caused something to try and resolve itself again. We now remove the clang type from the forward declaration map in the DWARF parser when we start to resolve it and avoid this additional call. This should stop any duplicate members from appearing and throwing all the alignment of structs, unions and classes. llvm-svn: 117437
2010-10-27 11:32:59 +08:00
if ((m_flags.Get() & resolve_scope) != resolve_scope)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
<rdar://problem/12445557> Make stack frames fix up their line table entries when the target has source remappings. Also rearranged how the m_sc.target_sp was filled in so it can be used during the StackFrame::GetSymbolContext(...) function. llvm-svn: 168845
2012-11-29 08:53:06 +08:00
uint32_t resolved = 0;
// If the target was requested add that:
if (!m_sc.target_sp)
{
m_sc.target_sp = CalculateTarget();
if (m_sc.target_sp)
resolved |= eSymbolContextTarget;
}
Fix typos. llvm-svn: 212553
2014-07-09 02:05:41 +08:00
// Resolve our PC to section offset if we haven't already done so
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
// and if we don't have a module. The resolved address section will
// contain the module to which it belongs
Clarified the intent of the SymbolContextScope class in the header documentation. Symbol now inherits from the symbol context scope so that the StackID can use a "SymbolContextScope *" instead of a blockID (which could have been the same as some other blockID from another symbol file). Modified the stacks that are created on subsequent stops to reuse the previous stack frame objects which will allow for some internal optimization using pointer comparisons during stepping. llvm-svn: 112495
2010-08-31 02:11:35 +08:00
if (!m_sc.module_sp && m_flags.IsClear(RESOLVED_FRAME_CODE_ADDR))
Got a lot of the kinks worked out in the inline support after debugging more complex inlined examples. StackFrame classes don't have a "GetPC" anymore, they have "GetFrameCodeAddress()". This is because inlined frames will have a PC value that is the same as the concrete frame that owns the inlined frame, yet the code locations for the frame can be different. We also need to be able to get the real PC value for a given frame so that variables evaluate correctly. To get the actual PC value for a frame you can use: addr_t pc = frame->GetRegisterContext()->GetPC(); Some issues with the StackFrame stomping on its own symbol context were resolved which were causing the information to change for a frame when the stack ID was calculated. Also the StackFrame will now correctly store the symbol context resolve flags for any extra bits of information that were looked up (if you ask for a block only and you find one, you will alwasy have the compile unit and function). llvm-svn: 111964
2010-08-25 05:05:24 +08:00
GetFrameCodeAddress();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
// If this is not frame zero, then we need to subtract 1 from the PC
// value when doing address lookups since the PC will be on the
// instruction following the function call instruction...
Got a lot of the kinks worked out in the inline support after debugging more complex inlined examples. StackFrame classes don't have a "GetPC" anymore, they have "GetFrameCodeAddress()". This is because inlined frames will have a PC value that is the same as the concrete frame that owns the inlined frame, yet the code locations for the frame can be different. We also need to be able to get the real PC value for a given frame so that variables evaluate correctly. To get the actual PC value for a frame you can use: addr_t pc = frame->GetRegisterContext()->GetPC(); Some issues with the StackFrame stomping on its own symbol context were resolved which were causing the information to change for a frame when the stack ID was calculated. Also the StackFrame will now correctly store the symbol context resolve flags for any extra bits of information that were looked up (if you ask for a block only and you find one, you will alwasy have the compile unit and function). llvm-svn: 111964
2010-08-25 05:05:24 +08:00
Address lookup_addr(GetFrameCodeAddress());
Added support for inlined stack frames being represented as real stack frames which is now on by default. Frames are gotten from the unwinder as concrete frames, then if inline frames are to be shown, extra information to track and reconstruct these frames is cached with each Thread and exanded as needed. I added an inline height as part of the lldb_private::StackID class, the class that helps us uniquely identify stack frames. This allows for two frames to shared the same call frame address, yet differ only in inline height. Fixed setting breakpoint by address to not require addresses to resolve. A quick example: % cat main.cpp % ./build/Debug/lldb test/stl/a.out Current executable set to 'test/stl/a.out' (x86_64). (lldb) breakpoint set --address 0x0000000100000d31 Breakpoint created: 1: address = 0x0000000100000d31, locations = 1 (lldb) r Launching 'a.out' (x86_64) (lldb) Process 38031 Stopped * thread #1: tid = 0x2e03, pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280, stop reason = breakpoint 1.1, queue = com.apple.main-thread 277 278 _CharT* 279 _M_data() const 280 -> { return _M_dataplus._M_p; } 281 282 _CharT* 283 _M_data(_CharT* __p) (lldb) bt thread #1: tid = 0x2e03, stop reason = breakpoint 1.1, queue = com.apple.main-thread frame #0: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280 frame #1: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_rep() const at /usr/include/c++/4.2.1/bits/basic_string.h:288 frame #2: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::size() const at /usr/include/c++/4.2.1/bits/basic_string.h:606 frame #3: pc = 0x0000000100000d31, where = a.out`main [inlined] operator<< <char, std::char_traits<char>, std::allocator<char> > at /usr/include/c++/4.2.1/bits/basic_string.h:2414 frame #4: pc = 0x0000000100000d31, where = a.out`main + 33 at /Volumes/work/gclayton/Documents/src/lldb/test/stl/main.cpp:14 frame #5: pc = 0x0000000100000d08, where = a.out`start + 52 Each inline frame contains only the variables that they contain and each inlined stack frame is treated as a single entity. llvm-svn: 111877
2010-08-24 08:45:41 +08:00
if (m_frame_index > 0 && lookup_addr.IsValid())
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
addr_t offset = lookup_addr.GetOffset();
if (offset > 0)
Fix a corner case with the handling of noreturn functions. If a noreturn function was the last function in a section, we wouldn't correctly back up the saved-pc value into the correct section leading to us showing the wrong function in the backtrace. Also add a backtrace test with an attempt to elicit this particular layout. It happens to work out with clang -Os but other compilers may not quite get the same layout I'm getting at that opt setting. We'll still be exercising the basic noreturn handling in the unwinder even if we don't get one function at the very end of a section. <rdar://problem/16051613> llvm-svn: 221575
2014-11-08 13:38:17 +08:00
{
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
lookup_addr.SetOffset(offset - 1);
Fix a corner case with the handling of noreturn functions. If a noreturn function was the last function in a section, we wouldn't correctly back up the saved-pc value into the correct section leading to us showing the wrong function in the backtrace. Also add a backtrace test with an attempt to elicit this particular layout. It happens to work out with clang -Os but other compilers may not quite get the same layout I'm getting at that opt setting. We'll still be exercising the basic noreturn handling in the unwinder even if we don't get one function at the very end of a section. <rdar://problem/16051613> llvm-svn: 221575
2014-11-08 13:38:17 +08:00
}
else
{
// lookup_addr is the start of a section. We need
// do the math on the actual load address and re-compute
// the section. We're working with a 'noreturn' function
// at the end of a section.
ThreadSP thread_sp (GetThread());
if (thread_sp)
{
TargetSP target_sp (thread_sp->CalculateTarget());
if (target_sp)
{
addr_t addr_minus_one = lookup_addr.GetLoadAddress(target_sp.get()) - 1;
lookup_addr.SetLoadAddress (addr_minus_one, target_sp.get());
}
else
{
lookup_addr.SetOffset(offset - 1);
}
}
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
if (m_sc.module_sp)
{
// We have something in our stack frame symbol context, lets check
// if we haven't already tried to lookup one of those things. If we
// haven't then we will do the query.
Added support for inlined stack frames being represented as real stack frames which is now on by default. Frames are gotten from the unwinder as concrete frames, then if inline frames are to be shown, extra information to track and reconstruct these frames is cached with each Thread and exanded as needed. I added an inline height as part of the lldb_private::StackID class, the class that helps us uniquely identify stack frames. This allows for two frames to shared the same call frame address, yet differ only in inline height. Fixed setting breakpoint by address to not require addresses to resolve. A quick example: % cat main.cpp % ./build/Debug/lldb test/stl/a.out Current executable set to 'test/stl/a.out' (x86_64). (lldb) breakpoint set --address 0x0000000100000d31 Breakpoint created: 1: address = 0x0000000100000d31, locations = 1 (lldb) r Launching 'a.out' (x86_64) (lldb) Process 38031 Stopped * thread #1: tid = 0x2e03, pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280, stop reason = breakpoint 1.1, queue = com.apple.main-thread 277 278 _CharT* 279 _M_data() const 280 -> { return _M_dataplus._M_p; } 281 282 _CharT* 283 _M_data(_CharT* __p) (lldb) bt thread #1: tid = 0x2e03, stop reason = breakpoint 1.1, queue = com.apple.main-thread frame #0: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280 frame #1: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_rep() const at /usr/include/c++/4.2.1/bits/basic_string.h:288 frame #2: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::size() const at /usr/include/c++/4.2.1/bits/basic_string.h:606 frame #3: pc = 0x0000000100000d31, where = a.out`main [inlined] operator<< <char, std::char_traits<char>, std::allocator<char> > at /usr/include/c++/4.2.1/bits/basic_string.h:2414 frame #4: pc = 0x0000000100000d31, where = a.out`main + 33 at /Volumes/work/gclayton/Documents/src/lldb/test/stl/main.cpp:14 frame #5: pc = 0x0000000100000d08, where = a.out`start + 52 Each inline frame contains only the variables that they contain and each inlined stack frame is treated as a single entity. llvm-svn: 111877
2010-08-24 08:45:41 +08:00
uint32_t actual_resolve_scope = 0;
if (resolve_scope & eSymbolContextCompUnit)
{
if (m_flags.IsClear (eSymbolContextCompUnit))
{
if (m_sc.comp_unit)
Got a lot of the kinks worked out in the inline support after debugging more complex inlined examples. StackFrame classes don't have a "GetPC" anymore, they have "GetFrameCodeAddress()". This is because inlined frames will have a PC value that is the same as the concrete frame that owns the inlined frame, yet the code locations for the frame can be different. We also need to be able to get the real PC value for a given frame so that variables evaluate correctly. To get the actual PC value for a frame you can use: addr_t pc = frame->GetRegisterContext()->GetPC(); Some issues with the StackFrame stomping on its own symbol context were resolved which were causing the information to change for a frame when the stack ID was calculated. Also the StackFrame will now correctly store the symbol context resolve flags for any extra bits of information that were looked up (if you ask for a block only and you find one, you will alwasy have the compile unit and function). llvm-svn: 111964
2010-08-25 05:05:24 +08:00
resolved |= eSymbolContextCompUnit;
Added support for inlined stack frames being represented as real stack frames which is now on by default. Frames are gotten from the unwinder as concrete frames, then if inline frames are to be shown, extra information to track and reconstruct these frames is cached with each Thread and exanded as needed. I added an inline height as part of the lldb_private::StackID class, the class that helps us uniquely identify stack frames. This allows for two frames to shared the same call frame address, yet differ only in inline height. Fixed setting breakpoint by address to not require addresses to resolve. A quick example: % cat main.cpp % ./build/Debug/lldb test/stl/a.out Current executable set to 'test/stl/a.out' (x86_64). (lldb) breakpoint set --address 0x0000000100000d31 Breakpoint created: 1: address = 0x0000000100000d31, locations = 1 (lldb) r Launching 'a.out' (x86_64) (lldb) Process 38031 Stopped * thread #1: tid = 0x2e03, pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280, stop reason = breakpoint 1.1, queue = com.apple.main-thread 277 278 _CharT* 279 _M_data() const 280 -> { return _M_dataplus._M_p; } 281 282 _CharT* 283 _M_data(_CharT* __p) (lldb) bt thread #1: tid = 0x2e03, stop reason = breakpoint 1.1, queue = com.apple.main-thread frame #0: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280 frame #1: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_rep() const at /usr/include/c++/4.2.1/bits/basic_string.h:288 frame #2: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::size() const at /usr/include/c++/4.2.1/bits/basic_string.h:606 frame #3: pc = 0x0000000100000d31, where = a.out`main [inlined] operator<< <char, std::char_traits<char>, std::allocator<char> > at /usr/include/c++/4.2.1/bits/basic_string.h:2414 frame #4: pc = 0x0000000100000d31, where = a.out`main + 33 at /Volumes/work/gclayton/Documents/src/lldb/test/stl/main.cpp:14 frame #5: pc = 0x0000000100000d08, where = a.out`start + 52 Each inline frame contains only the variables that they contain and each inlined stack frame is treated as a single entity. llvm-svn: 111877
2010-08-24 08:45:41 +08:00
else
actual_resolve_scope |= eSymbolContextCompUnit;
}
}
if (resolve_scope & eSymbolContextFunction)
{
if (m_flags.IsClear (eSymbolContextFunction))
{
if (m_sc.function)
Got a lot of the kinks worked out in the inline support after debugging more complex inlined examples. StackFrame classes don't have a "GetPC" anymore, they have "GetFrameCodeAddress()". This is because inlined frames will have a PC value that is the same as the concrete frame that owns the inlined frame, yet the code locations for the frame can be different. We also need to be able to get the real PC value for a given frame so that variables evaluate correctly. To get the actual PC value for a frame you can use: addr_t pc = frame->GetRegisterContext()->GetPC(); Some issues with the StackFrame stomping on its own symbol context were resolved which were causing the information to change for a frame when the stack ID was calculated. Also the StackFrame will now correctly store the symbol context resolve flags for any extra bits of information that were looked up (if you ask for a block only and you find one, you will alwasy have the compile unit and function). llvm-svn: 111964
2010-08-25 05:05:24 +08:00
resolved |= eSymbolContextFunction;
Added support for inlined stack frames being represented as real stack frames which is now on by default. Frames are gotten from the unwinder as concrete frames, then if inline frames are to be shown, extra information to track and reconstruct these frames is cached with each Thread and exanded as needed. I added an inline height as part of the lldb_private::StackID class, the class that helps us uniquely identify stack frames. This allows for two frames to shared the same call frame address, yet differ only in inline height. Fixed setting breakpoint by address to not require addresses to resolve. A quick example: % cat main.cpp % ./build/Debug/lldb test/stl/a.out Current executable set to 'test/stl/a.out' (x86_64). (lldb) breakpoint set --address 0x0000000100000d31 Breakpoint created: 1: address = 0x0000000100000d31, locations = 1 (lldb) r Launching 'a.out' (x86_64) (lldb) Process 38031 Stopped * thread #1: tid = 0x2e03, pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280, stop reason = breakpoint 1.1, queue = com.apple.main-thread 277 278 _CharT* 279 _M_data() const 280 -> { return _M_dataplus._M_p; } 281 282 _CharT* 283 _M_data(_CharT* __p) (lldb) bt thread #1: tid = 0x2e03, stop reason = breakpoint 1.1, queue = com.apple.main-thread frame #0: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280 frame #1: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_rep() const at /usr/include/c++/4.2.1/bits/basic_string.h:288 frame #2: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::size() const at /usr/include/c++/4.2.1/bits/basic_string.h:606 frame #3: pc = 0x0000000100000d31, where = a.out`main [inlined] operator<< <char, std::char_traits<char>, std::allocator<char> > at /usr/include/c++/4.2.1/bits/basic_string.h:2414 frame #4: pc = 0x0000000100000d31, where = a.out`main + 33 at /Volumes/work/gclayton/Documents/src/lldb/test/stl/main.cpp:14 frame #5: pc = 0x0000000100000d08, where = a.out`start + 52 Each inline frame contains only the variables that they contain and each inlined stack frame is treated as a single entity. llvm-svn: 111877
2010-08-24 08:45:41 +08:00
else
actual_resolve_scope |= eSymbolContextFunction;
}
}
if (resolve_scope & eSymbolContextBlock)
{
if (m_flags.IsClear (eSymbolContextBlock))
{
if (m_sc.block)
Got a lot of the kinks worked out in the inline support after debugging more complex inlined examples. StackFrame classes don't have a "GetPC" anymore, they have "GetFrameCodeAddress()". This is because inlined frames will have a PC value that is the same as the concrete frame that owns the inlined frame, yet the code locations for the frame can be different. We also need to be able to get the real PC value for a given frame so that variables evaluate correctly. To get the actual PC value for a frame you can use: addr_t pc = frame->GetRegisterContext()->GetPC(); Some issues with the StackFrame stomping on its own symbol context were resolved which were causing the information to change for a frame when the stack ID was calculated. Also the StackFrame will now correctly store the symbol context resolve flags for any extra bits of information that were looked up (if you ask for a block only and you find one, you will alwasy have the compile unit and function). llvm-svn: 111964
2010-08-25 05:05:24 +08:00
resolved |= eSymbolContextBlock;
Added support for inlined stack frames being represented as real stack frames which is now on by default. Frames are gotten from the unwinder as concrete frames, then if inline frames are to be shown, extra information to track and reconstruct these frames is cached with each Thread and exanded as needed. I added an inline height as part of the lldb_private::StackID class, the class that helps us uniquely identify stack frames. This allows for two frames to shared the same call frame address, yet differ only in inline height. Fixed setting breakpoint by address to not require addresses to resolve. A quick example: % cat main.cpp % ./build/Debug/lldb test/stl/a.out Current executable set to 'test/stl/a.out' (x86_64). (lldb) breakpoint set --address 0x0000000100000d31 Breakpoint created: 1: address = 0x0000000100000d31, locations = 1 (lldb) r Launching 'a.out' (x86_64) (lldb) Process 38031 Stopped * thread #1: tid = 0x2e03, pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280, stop reason = breakpoint 1.1, queue = com.apple.main-thread 277 278 _CharT* 279 _M_data() const 280 -> { return _M_dataplus._M_p; } 281 282 _CharT* 283 _M_data(_CharT* __p) (lldb) bt thread #1: tid = 0x2e03, stop reason = breakpoint 1.1, queue = com.apple.main-thread frame #0: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280 frame #1: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_rep() const at /usr/include/c++/4.2.1/bits/basic_string.h:288 frame #2: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::size() const at /usr/include/c++/4.2.1/bits/basic_string.h:606 frame #3: pc = 0x0000000100000d31, where = a.out`main [inlined] operator<< <char, std::char_traits<char>, std::allocator<char> > at /usr/include/c++/4.2.1/bits/basic_string.h:2414 frame #4: pc = 0x0000000100000d31, where = a.out`main + 33 at /Volumes/work/gclayton/Documents/src/lldb/test/stl/main.cpp:14 frame #5: pc = 0x0000000100000d08, where = a.out`start + 52 Each inline frame contains only the variables that they contain and each inlined stack frame is treated as a single entity. llvm-svn: 111877
2010-08-24 08:45:41 +08:00
else
actual_resolve_scope |= eSymbolContextBlock;
}
}
if (resolve_scope & eSymbolContextSymbol)
{
if (m_flags.IsClear (eSymbolContextSymbol))
{
if (m_sc.symbol)
Got a lot of the kinks worked out in the inline support after debugging more complex inlined examples. StackFrame classes don't have a "GetPC" anymore, they have "GetFrameCodeAddress()". This is because inlined frames will have a PC value that is the same as the concrete frame that owns the inlined frame, yet the code locations for the frame can be different. We also need to be able to get the real PC value for a given frame so that variables evaluate correctly. To get the actual PC value for a frame you can use: addr_t pc = frame->GetRegisterContext()->GetPC(); Some issues with the StackFrame stomping on its own symbol context were resolved which were causing the information to change for a frame when the stack ID was calculated. Also the StackFrame will now correctly store the symbol context resolve flags for any extra bits of information that were looked up (if you ask for a block only and you find one, you will alwasy have the compile unit and function). llvm-svn: 111964
2010-08-25 05:05:24 +08:00
resolved |= eSymbolContextSymbol;
Added support for inlined stack frames being represented as real stack frames which is now on by default. Frames are gotten from the unwinder as concrete frames, then if inline frames are to be shown, extra information to track and reconstruct these frames is cached with each Thread and exanded as needed. I added an inline height as part of the lldb_private::StackID class, the class that helps us uniquely identify stack frames. This allows for two frames to shared the same call frame address, yet differ only in inline height. Fixed setting breakpoint by address to not require addresses to resolve. A quick example: % cat main.cpp % ./build/Debug/lldb test/stl/a.out Current executable set to 'test/stl/a.out' (x86_64). (lldb) breakpoint set --address 0x0000000100000d31 Breakpoint created: 1: address = 0x0000000100000d31, locations = 1 (lldb) r Launching 'a.out' (x86_64) (lldb) Process 38031 Stopped * thread #1: tid = 0x2e03, pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280, stop reason = breakpoint 1.1, queue = com.apple.main-thread 277 278 _CharT* 279 _M_data() const 280 -> { return _M_dataplus._M_p; } 281 282 _CharT* 283 _M_data(_CharT* __p) (lldb) bt thread #1: tid = 0x2e03, stop reason = breakpoint 1.1, queue = com.apple.main-thread frame #0: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280 frame #1: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_rep() const at /usr/include/c++/4.2.1/bits/basic_string.h:288 frame #2: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::size() const at /usr/include/c++/4.2.1/bits/basic_string.h:606 frame #3: pc = 0x0000000100000d31, where = a.out`main [inlined] operator<< <char, std::char_traits<char>, std::allocator<char> > at /usr/include/c++/4.2.1/bits/basic_string.h:2414 frame #4: pc = 0x0000000100000d31, where = a.out`main + 33 at /Volumes/work/gclayton/Documents/src/lldb/test/stl/main.cpp:14 frame #5: pc = 0x0000000100000d08, where = a.out`start + 52 Each inline frame contains only the variables that they contain and each inlined stack frame is treated as a single entity. llvm-svn: 111877
2010-08-24 08:45:41 +08:00
else
actual_resolve_scope |= eSymbolContextSymbol;
}
}
if (resolve_scope & eSymbolContextLineEntry)
{
if (m_flags.IsClear (eSymbolContextLineEntry))
{
if (m_sc.line_entry.IsValid())
Got a lot of the kinks worked out in the inline support after debugging more complex inlined examples. StackFrame classes don't have a "GetPC" anymore, they have "GetFrameCodeAddress()". This is because inlined frames will have a PC value that is the same as the concrete frame that owns the inlined frame, yet the code locations for the frame can be different. We also need to be able to get the real PC value for a given frame so that variables evaluate correctly. To get the actual PC value for a frame you can use: addr_t pc = frame->GetRegisterContext()->GetPC(); Some issues with the StackFrame stomping on its own symbol context were resolved which were causing the information to change for a frame when the stack ID was calculated. Also the StackFrame will now correctly store the symbol context resolve flags for any extra bits of information that were looked up (if you ask for a block only and you find one, you will alwasy have the compile unit and function). llvm-svn: 111964
2010-08-25 05:05:24 +08:00
resolved |= eSymbolContextLineEntry;
Added support for inlined stack frames being represented as real stack frames which is now on by default. Frames are gotten from the unwinder as concrete frames, then if inline frames are to be shown, extra information to track and reconstruct these frames is cached with each Thread and exanded as needed. I added an inline height as part of the lldb_private::StackID class, the class that helps us uniquely identify stack frames. This allows for two frames to shared the same call frame address, yet differ only in inline height. Fixed setting breakpoint by address to not require addresses to resolve. A quick example: % cat main.cpp % ./build/Debug/lldb test/stl/a.out Current executable set to 'test/stl/a.out' (x86_64). (lldb) breakpoint set --address 0x0000000100000d31 Breakpoint created: 1: address = 0x0000000100000d31, locations = 1 (lldb) r Launching 'a.out' (x86_64) (lldb) Process 38031 Stopped * thread #1: tid = 0x2e03, pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280, stop reason = breakpoint 1.1, queue = com.apple.main-thread 277 278 _CharT* 279 _M_data() const 280 -> { return _M_dataplus._M_p; } 281 282 _CharT* 283 _M_data(_CharT* __p) (lldb) bt thread #1: tid = 0x2e03, stop reason = breakpoint 1.1, queue = com.apple.main-thread frame #0: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280 frame #1: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_rep() const at /usr/include/c++/4.2.1/bits/basic_string.h:288 frame #2: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::size() const at /usr/include/c++/4.2.1/bits/basic_string.h:606 frame #3: pc = 0x0000000100000d31, where = a.out`main [inlined] operator<< <char, std::char_traits<char>, std::allocator<char> > at /usr/include/c++/4.2.1/bits/basic_string.h:2414 frame #4: pc = 0x0000000100000d31, where = a.out`main + 33 at /Volumes/work/gclayton/Documents/src/lldb/test/stl/main.cpp:14 frame #5: pc = 0x0000000100000d08, where = a.out`start + 52 Each inline frame contains only the variables that they contain and each inlined stack frame is treated as a single entity. llvm-svn: 111877
2010-08-24 08:45:41 +08:00
else
actual_resolve_scope |= eSymbolContextLineEntry;
}
}
if (actual_resolve_scope)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
// We might be resolving less information than what is already
// in our current symbol context so resolve into a temporary
// symbol context "sc" so we don't clear out data we have
// already found in "m_sc"
SymbolContext sc;
// Set flags that indicate what we have tried to resolve
Got a lot of the kinks worked out in the inline support after debugging more complex inlined examples. StackFrame classes don't have a "GetPC" anymore, they have "GetFrameCodeAddress()". This is because inlined frames will have a PC value that is the same as the concrete frame that owns the inlined frame, yet the code locations for the frame can be different. We also need to be able to get the real PC value for a given frame so that variables evaluate correctly. To get the actual PC value for a frame you can use: addr_t pc = frame->GetRegisterContext()->GetPC(); Some issues with the StackFrame stomping on its own symbol context were resolved which were causing the information to change for a frame when the stack ID was calculated. Also the StackFrame will now correctly store the symbol context resolve flags for any extra bits of information that were looked up (if you ask for a block only and you find one, you will alwasy have the compile unit and function). llvm-svn: 111964
2010-08-25 05:05:24 +08:00
resolved |= m_sc.module_sp->ResolveSymbolContextForAddress (lookup_addr, actual_resolve_scope, sc);
Added support for inlined stack frames being represented as real stack frames which is now on by default. Frames are gotten from the unwinder as concrete frames, then if inline frames are to be shown, extra information to track and reconstruct these frames is cached with each Thread and exanded as needed. I added an inline height as part of the lldb_private::StackID class, the class that helps us uniquely identify stack frames. This allows for two frames to shared the same call frame address, yet differ only in inline height. Fixed setting breakpoint by address to not require addresses to resolve. A quick example: % cat main.cpp % ./build/Debug/lldb test/stl/a.out Current executable set to 'test/stl/a.out' (x86_64). (lldb) breakpoint set --address 0x0000000100000d31 Breakpoint created: 1: address = 0x0000000100000d31, locations = 1 (lldb) r Launching 'a.out' (x86_64) (lldb) Process 38031 Stopped * thread #1: tid = 0x2e03, pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280, stop reason = breakpoint 1.1, queue = com.apple.main-thread 277 278 _CharT* 279 _M_data() const 280 -> { return _M_dataplus._M_p; } 281 282 _CharT* 283 _M_data(_CharT* __p) (lldb) bt thread #1: tid = 0x2e03, stop reason = breakpoint 1.1, queue = com.apple.main-thread frame #0: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280 frame #1: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_rep() const at /usr/include/c++/4.2.1/bits/basic_string.h:288 frame #2: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::size() const at /usr/include/c++/4.2.1/bits/basic_string.h:606 frame #3: pc = 0x0000000100000d31, where = a.out`main [inlined] operator<< <char, std::char_traits<char>, std::allocator<char> > at /usr/include/c++/4.2.1/bits/basic_string.h:2414 frame #4: pc = 0x0000000100000d31, where = a.out`main + 33 at /Volumes/work/gclayton/Documents/src/lldb/test/stl/main.cpp:14 frame #5: pc = 0x0000000100000d08, where = a.out`start + 52 Each inline frame contains only the variables that they contain and each inlined stack frame is treated as a single entity. llvm-svn: 111877
2010-08-24 08:45:41 +08:00
// Only replace what we didn't already have as we may have
// information for an inlined function scope that won't match
// what a standard lookup by address would match
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Target; other minor fixes. llvm-svn: 261242
2016-02-19 02:52:47 +08:00
if ((resolved & eSymbolContextCompUnit) && m_sc.comp_unit == nullptr)
Got a lot of the kinks worked out in the inline support after debugging more complex inlined examples. StackFrame classes don't have a "GetPC" anymore, they have "GetFrameCodeAddress()". This is because inlined frames will have a PC value that is the same as the concrete frame that owns the inlined frame, yet the code locations for the frame can be different. We also need to be able to get the real PC value for a given frame so that variables evaluate correctly. To get the actual PC value for a frame you can use: addr_t pc = frame->GetRegisterContext()->GetPC(); Some issues with the StackFrame stomping on its own symbol context were resolved which were causing the information to change for a frame when the stack ID was calculated. Also the StackFrame will now correctly store the symbol context resolve flags for any extra bits of information that were looked up (if you ask for a block only and you find one, you will alwasy have the compile unit and function). llvm-svn: 111964
2010-08-25 05:05:24 +08:00
m_sc.comp_unit = sc.comp_unit;
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Target; other minor fixes. llvm-svn: 261242
2016-02-19 02:52:47 +08:00
if ((resolved & eSymbolContextFunction) && m_sc.function == nullptr)
Got a lot of the kinks worked out in the inline support after debugging more complex inlined examples. StackFrame classes don't have a "GetPC" anymore, they have "GetFrameCodeAddress()". This is because inlined frames will have a PC value that is the same as the concrete frame that owns the inlined frame, yet the code locations for the frame can be different. We also need to be able to get the real PC value for a given frame so that variables evaluate correctly. To get the actual PC value for a frame you can use: addr_t pc = frame->GetRegisterContext()->GetPC(); Some issues with the StackFrame stomping on its own symbol context were resolved which were causing the information to change for a frame when the stack ID was calculated. Also the StackFrame will now correctly store the symbol context resolve flags for any extra bits of information that were looked up (if you ask for a block only and you find one, you will alwasy have the compile unit and function). llvm-svn: 111964
2010-08-25 05:05:24 +08:00
m_sc.function = sc.function;
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Target; other minor fixes. llvm-svn: 261242
2016-02-19 02:52:47 +08:00
if ((resolved & eSymbolContextBlock) && m_sc.block == nullptr)
Got a lot of the kinks worked out in the inline support after debugging more complex inlined examples. StackFrame classes don't have a "GetPC" anymore, they have "GetFrameCodeAddress()". This is because inlined frames will have a PC value that is the same as the concrete frame that owns the inlined frame, yet the code locations for the frame can be different. We also need to be able to get the real PC value for a given frame so that variables evaluate correctly. To get the actual PC value for a frame you can use: addr_t pc = frame->GetRegisterContext()->GetPC(); Some issues with the StackFrame stomping on its own symbol context were resolved which were causing the information to change for a frame when the stack ID was calculated. Also the StackFrame will now correctly store the symbol context resolve flags for any extra bits of information that were looked up (if you ask for a block only and you find one, you will alwasy have the compile unit and function). llvm-svn: 111964
2010-08-25 05:05:24 +08:00
m_sc.block = sc.block;
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Target; other minor fixes. llvm-svn: 261242
2016-02-19 02:52:47 +08:00
if ((resolved & eSymbolContextSymbol) && m_sc.symbol == nullptr)
Got a lot of the kinks worked out in the inline support after debugging more complex inlined examples. StackFrame classes don't have a "GetPC" anymore, they have "GetFrameCodeAddress()". This is because inlined frames will have a PC value that is the same as the concrete frame that owns the inlined frame, yet the code locations for the frame can be different. We also need to be able to get the real PC value for a given frame so that variables evaluate correctly. To get the actual PC value for a frame you can use: addr_t pc = frame->GetRegisterContext()->GetPC(); Some issues with the StackFrame stomping on its own symbol context were resolved which were causing the information to change for a frame when the stack ID was calculated. Also the StackFrame will now correctly store the symbol context resolve flags for any extra bits of information that were looked up (if you ask for a block only and you find one, you will alwasy have the compile unit and function). llvm-svn: 111964
2010-08-25 05:05:24 +08:00
m_sc.symbol = sc.symbol;
<rdar://problem/12445557> Make stack frames fix up their line table entries when the target has source remappings. Also rearranged how the m_sc.target_sp was filled in so it can be used during the StackFrame::GetSymbolContext(...) function. llvm-svn: 168845
2012-11-29 08:53:06 +08:00
if ((resolved & eSymbolContextLineEntry) && !m_sc.line_entry.IsValid())
{
Got a lot of the kinks worked out in the inline support after debugging more complex inlined examples. StackFrame classes don't have a "GetPC" anymore, they have "GetFrameCodeAddress()". This is because inlined frames will have a PC value that is the same as the concrete frame that owns the inlined frame, yet the code locations for the frame can be different. We also need to be able to get the real PC value for a given frame so that variables evaluate correctly. To get the actual PC value for a frame you can use: addr_t pc = frame->GetRegisterContext()->GetPC(); Some issues with the StackFrame stomping on its own symbol context were resolved which were causing the information to change for a frame when the stack ID was calculated. Also the StackFrame will now correctly store the symbol context resolve flags for any extra bits of information that were looked up (if you ask for a block only and you find one, you will alwasy have the compile unit and function). llvm-svn: 111964
2010-08-25 05:05:24 +08:00
m_sc.line_entry = sc.line_entry;
Keep original source path and mapped path in LineEntry Summary: The "file" variable in a LineEntry was mapped using target.source-map, except when stepping through inlined code. This patch adds a new variable to LineEntry, "original_file", that contains the original file from the debug info. "file" will continue to (possibly) be mapped. Some code has been changed to use "original_file". This is code dealing with symbols. Code dealing with source files will still use "file". Reviewers, please confirm that these particular changes are correct. Tests run on Ubuntu 12.04 show no regression. Reviewers: clayborg, jingham Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D20135 llvm-svn: 269250
2016-05-12 06:46:53 +08:00
m_sc.line_entry.ApplyFileMappings(m_sc.target_sp);
<rdar://problem/12445557> Make stack frames fix up their line table entries when the target has source remappings. Also rearranged how the m_sc.target_sp was filled in so it can be used during the StackFrame::GetSymbolContext(...) function. llvm-svn: 168845
2012-11-29 08:53:06 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
}
else
{
// If we don't have a module, then we can't have the compile unit,
// function, block, line entry or symbol, so we can safely call
// ResolveSymbolContextForAddress with our symbol context member m_sc.
Got a lot of the kinks worked out in the inline support after debugging more complex inlined examples. StackFrame classes don't have a "GetPC" anymore, they have "GetFrameCodeAddress()". This is because inlined frames will have a PC value that is the same as the concrete frame that owns the inlined frame, yet the code locations for the frame can be different. We also need to be able to get the real PC value for a given frame so that variables evaluate correctly. To get the actual PC value for a frame you can use: addr_t pc = frame->GetRegisterContext()->GetPC(); Some issues with the StackFrame stomping on its own symbol context were resolved which were causing the information to change for a frame when the stack ID was calculated. Also the StackFrame will now correctly store the symbol context resolve flags for any extra bits of information that were looked up (if you ask for a block only and you find one, you will alwasy have the compile unit and function). llvm-svn: 111964
2010-08-25 05:05:24 +08:00
if (m_sc.target_sp)
Fixed a case where a stack frame could lose track of its own target. <rdar://problem/13121412> llvm-svn: 175794
2013-02-22 04:54:33 +08:00
{
<rdar://problem/12445557> Make stack frames fix up their line table entries when the target has source remappings. Also rearranged how the m_sc.target_sp was filled in so it can be used during the StackFrame::GetSymbolContext(...) function. llvm-svn: 168845
2012-11-29 08:53:06 +08:00
resolved |= m_sc.target_sp->GetImages().ResolveSymbolContextForAddress (lookup_addr, resolve_scope, m_sc);
Fixed a case where a stack frame could lose track of its own target. <rdar://problem/13121412> llvm-svn: 175794
2013-02-22 04:54:33 +08:00
}
Got a lot of the kinks worked out in the inline support after debugging more complex inlined examples. StackFrame classes don't have a "GetPC" anymore, they have "GetFrameCodeAddress()". This is because inlined frames will have a PC value that is the same as the concrete frame that owns the inlined frame, yet the code locations for the frame can be different. We also need to be able to get the real PC value for a given frame so that variables evaluate correctly. To get the actual PC value for a frame you can use: addr_t pc = frame->GetRegisterContext()->GetPC(); Some issues with the StackFrame stomping on its own symbol context were resolved which were causing the information to change for a frame when the stack ID was calculated. Also the StackFrame will now correctly store the symbol context resolve flags for any extra bits of information that were looked up (if you ask for a block only and you find one, you will alwasy have the compile unit and function). llvm-svn: 111964
2010-08-25 05:05:24 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
// Update our internal flags so we remember what we have tried to locate so
// we don't have to keep trying when more calls to this function are made.
Got a lot of the kinks worked out in the inline support after debugging more complex inlined examples. StackFrame classes don't have a "GetPC" anymore, they have "GetFrameCodeAddress()". This is because inlined frames will have a PC value that is the same as the concrete frame that owns the inlined frame, yet the code locations for the frame can be different. We also need to be able to get the real PC value for a given frame so that variables evaluate correctly. To get the actual PC value for a frame you can use: addr_t pc = frame->GetRegisterContext()->GetPC(); Some issues with the StackFrame stomping on its own symbol context were resolved which were causing the information to change for a frame when the stack ID was calculated. Also the StackFrame will now correctly store the symbol context resolve flags for any extra bits of information that were looked up (if you ask for a block only and you find one, you will alwasy have the compile unit and function). llvm-svn: 111964
2010-08-25 05:05:24 +08:00
// We might have dug up more information that was requested (for example
// if we were asked to only get the block, we will have gotten the
// compile unit, and function) so set any additional bits that we resolved
m_flags.Set (resolve_scope | resolved);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
// Return the symbol context with everything that was possible to resolve
// resolved.
return m_sc;
}
VariableList *
StackFrame objects now own ValueObjects for any frame variables (locals, args, function statics, file globals and static variables) that a frame contains. The StackFrame objects can give out ValueObjects instances for each variable which allows us to track when a variable changes and doesn't depend on variable names when getting value objects. StackFrame::GetVariableList now takes a boolean to indicate if we want to get the frame compile unit globals and static variables. The value objects in the stack frames can now correctly track when they have been modified. There are a few more tweaks needed to complete this work. The biggest issue is when stepping creates partial stacks (just frame zero usually) and causes previous stack frames not to match up with the current stack frames because the previous frames only has frame zero. We don't really want to require that all previous frames be complete since stepping often must check stack frames to complete their jobs. I will fix this issue tomorrow. llvm-svn: 112800
2010-09-02 10:59:18 +08:00
StackFrame::GetVariableList (bool get_file_globals)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
second pass over removal of Mutex and Condition llvm-svn: 270024
2016-05-19 13:13:57 +08:00
std::lock_guard<std::recursive_mutex> guard(m_mutex);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (m_flags.IsClear(RESOLVED_VARIABLES))
{
m_flags.Set(RESOLVED_VARIABLES);
Added more API to lldb::SBBlock to allow getting the block parent, sibling and first child block, and access to the inline function information. Added an accessor the StackFrame: Block * lldb_private::StackFrame::GetFrameBlock(); LLDB represents inline functions as lexical blocks that have inlined function information in them. The function above allows us to easily get the top most lexical block that defines a stack frame. When there are no inline functions in function, the block returned ends up being the top most block for the function. When the PC is in an inlined funciton for a frame, this will return the first parent block that has inlined function information. The other accessor: StackFrame::GetBlock() will return the deepest block that matches the frame's PC value. Since most debuggers want to display all variables in the current frame, the Block returned by StackFrame::GetFrameBlock can be used to retrieve all variables for the current frame. Fixed the lldb_private::Block::DumpStopContext(...) to properly display inline frames a block should display all of its inlined functions. Prior to this fix, one of the call sites was being skipped. This is a separate code path from the current default where inlined functions get their own frames. Fixed an issue where a block would always grab variables for any child inline function blocks. llvm-svn: 113195
2010-09-07 12:20:48 +08:00
Block *frame_block = GetFrameBlock();
if (frame_block)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Added more API to lldb::SBBlock to allow getting the block parent, sibling and first child block, and access to the inline function information. Added an accessor the StackFrame: Block * lldb_private::StackFrame::GetFrameBlock(); LLDB represents inline functions as lexical blocks that have inlined function information in them. The function above allows us to easily get the top most lexical block that defines a stack frame. When there are no inline functions in function, the block returned ends up being the top most block for the function. When the PC is in an inlined funciton for a frame, this will return the first parent block that has inlined function information. The other accessor: StackFrame::GetBlock() will return the deepest block that matches the frame's PC value. Since most debuggers want to display all variables in the current frame, the Block returned by StackFrame::GetFrameBlock can be used to retrieve all variables for the current frame. Fixed the lldb_private::Block::DumpStopContext(...) to properly display inline frames a block should display all of its inlined functions. Prior to this fix, one of the call sites was being skipped. This is a separate code path from the current default where inlined functions get their own frames. Fixed an issue where a block would always grab variables for any child inline function blocks. llvm-svn: 113195
2010-09-07 12:20:48 +08:00
const bool get_child_variables = true;
const bool can_create = true;
Fixed variable parsing to not parse block variables over and over due to an issue in the way block variables are marked as parsed. In the DWARF parser we always parse all blocks for a function at once, so we can mark all blocks as having all variables parsed and avoid recursive function calls to try and reparse things that have already been handled. Fixed an issue with how variables get scoped into blocks. The DWARF parser can now handle abtract class definitions that contain concrete static variables. When the concrete instance of the class functions get instantiated, they will track down the concrete block for the abtract block and add the variable to each block. llvm-svn: 133302
2011-06-18 06:10:16 +08:00
const bool stop_if_child_block_is_inlined_function = true;
m_variable_list_sp.reset(new VariableList());
Handle the case when a variable is only valid in part of the enclosing scope DWARF stores this information in the DW_AT_start_scope attribute. This CL add support for this attribute and also changes the functions displaying frame variables to only display the variables currently in scope. Differential revision: http://reviews.llvm.org/D17449 llvm-svn: 261858
2016-02-25 20:23:37 +08:00
frame_block->AppendBlockVariables(can_create,
get_child_variables,
stop_if_child_block_is_inlined_function,
Fix StackFrame::GetVariables(...) function that was broken by 261858 when lambda functions were added to Block::AppendBlockVariables(). The Stackframe::GetVariables(...) function should get all variables regardless if they are in scope. This wasn't caught by the test suite so I added a test for it. llvm-svn: 267478
2016-04-26 05:54:10 +08:00
[this](Variable* v) { return true; },
Handle the case when a variable is only valid in part of the enclosing scope DWARF stores this information in the DW_AT_start_scope attribute. This CL add support for this attribute and also changes the functions displaying frame variables to only display the variables currently in scope. Differential revision: http://reviews.llvm.org/D17449 llvm-svn: 261858
2016-02-25 20:23:37 +08:00
m_variable_list_sp.get());
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Fixed StackFrame::GetVariableList to add global variables to the list of found variables if they have not yet been added. llvm-svn: 117896
2010-11-01 12:38:59 +08:00
}
if (m_flags.IsClear(RESOLVED_GLOBAL_VARIABLES) &&
get_file_globals)
{
m_flags.Set(RESOLVED_GLOBAL_VARIABLES);
if (m_flags.IsClear (eSymbolContextCompUnit))
GetSymbolContext (eSymbolContextCompUnit);
StackFrame objects now own ValueObjects for any frame variables (locals, args, function statics, file globals and static variables) that a frame contains. The StackFrame objects can give out ValueObjects instances for each variable which allows us to track when a variable changes and doesn't depend on variable names when getting value objects. StackFrame::GetVariableList now takes a boolean to indicate if we want to get the frame compile unit globals and static variables. The value objects in the stack frames can now correctly track when they have been modified. There are a few more tweaks needed to complete this work. The biggest issue is when stepping creates partial stacks (just frame zero usually) and causes previous stack frames not to match up with the current stack frames because the previous frames only has frame zero. We don't really want to require that all previous frames be complete since stepping often must check stack frames to complete their jobs. I will fix this issue tomorrow. llvm-svn: 112800
2010-09-02 10:59:18 +08:00
Fixed StackFrame::GetVariableList to add global variables to the list of found variables if they have not yet been added. llvm-svn: 117896
2010-11-01 12:38:59 +08:00
if (m_sc.comp_unit)
StackFrame objects now own ValueObjects for any frame variables (locals, args, function statics, file globals and static variables) that a frame contains. The StackFrame objects can give out ValueObjects instances for each variable which allows us to track when a variable changes and doesn't depend on variable names when getting value objects. StackFrame::GetVariableList now takes a boolean to indicate if we want to get the frame compile unit globals and static variables. The value objects in the stack frames can now correctly track when they have been modified. There are a few more tweaks needed to complete this work. The biggest issue is when stepping creates partial stacks (just frame zero usually) and causes previous stack frames not to match up with the current stack frames because the previous frames only has frame zero. We don't really want to require that all previous frames be complete since stepping often must check stack frames to complete their jobs. I will fix this issue tomorrow. llvm-svn: 112800
2010-09-02 10:59:18 +08:00
{
Fixed StackFrame::GetVariableList to add global variables to the list of found variables if they have not yet been added. llvm-svn: 117896
2010-11-01 12:38:59 +08:00
VariableListSP global_variable_list_sp (m_sc.comp_unit->GetVariableList(true));
if (m_variable_list_sp)
m_variable_list_sp->AddVariables (global_variable_list_sp.get());
else
m_variable_list_sp = global_variable_list_sp;
StackFrame objects now own ValueObjects for any frame variables (locals, args, function statics, file globals and static variables) that a frame contains. The StackFrame objects can give out ValueObjects instances for each variable which allows us to track when a variable changes and doesn't depend on variable names when getting value objects. StackFrame::GetVariableList now takes a boolean to indicate if we want to get the frame compile unit globals and static variables. The value objects in the stack frames can now correctly track when they have been modified. There are a few more tweaks needed to complete this work. The biggest issue is when stepping creates partial stacks (just frame zero usually) and causes previous stack frames not to match up with the current stack frames because the previous frames only has frame zero. We don't really want to require that all previous frames be complete since stepping often must check stack frames to complete their jobs. I will fix this issue tomorrow. llvm-svn: 112800
2010-09-02 10:59:18 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Fixed StackFrame::GetVariableList to add global variables to the list of found variables if they have not yet been added. llvm-svn: 117896
2010-11-01 12:38:59 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return m_variable_list_sp.get();
}
Fixed an issue where StackFrame::GetValueForVariableExpressionPath(...) was previously using the entire frame variable list instead of using the in scope variable list. I added a new function to a stack frame: lldb::VariableListSP StackFrame::GetInScopeVariableList (bool get_file_globals); This gets only variables that are in scope and they will be ordered such that the variables from the current scope are first. llvm-svn: 136745
2011-08-03 07:35:43 +08:00
VariableListSP
When building the list of variables we're going to write "using $_lldb_local_vars" statements for, be sure not to include variables that have no locations. We wouldn't be able to realize them, and that will cause all expressions to fail. llvm-svn: 267500
2016-04-26 08:29:59 +08:00
StackFrame::GetInScopeVariableList (bool get_file_globals, bool must_have_valid_location)
Fixed an issue where StackFrame::GetValueForVariableExpressionPath(...) was previously using the entire frame variable list instead of using the in scope variable list. I added a new function to a stack frame: lldb::VariableListSP StackFrame::GetInScopeVariableList (bool get_file_globals); This gets only variables that are in scope and they will be ordered such that the variables from the current scope are first. llvm-svn: 136745
2011-08-03 07:35:43 +08:00
{
second pass over removal of Mutex and Condition llvm-svn: 270024
2016-05-19 13:13:57 +08:00
std::lock_guard<std::recursive_mutex> guard(m_mutex);
Add new ivars to StackFrame so it can represent a stack collected at some point in the past. We may have nothing more than a pc value for this type of stack frame -- hopefully we'll have a pc and a stop_id so we can track module loads and unloads over time and symbolicate the pc at the correct point in time. Also add a flag to indicate if the CFA for the frame is available (a bit different from a CFA of LLDB_INVALID_ADDRESS) and also an overall setting to indicate whether this is a history stack frame or not. A history stack frame may not have a CFA, it may not have a register context, it may not have variables, it may not have a frame pointer or a stack pointer. <rdar://problem/15314068> llvm-svn: 193987
2013-11-04 19:02:52 +08:00
// We can't fetch variable information for a history stack frame.
if (m_is_history_frame)
return VariableListSP();
Fixed an issue where StackFrame::GetValueForVariableExpressionPath(...) was previously using the entire frame variable list instead of using the in scope variable list. I added a new function to a stack frame: lldb::VariableListSP StackFrame::GetInScopeVariableList (bool get_file_globals); This gets only variables that are in scope and they will be ordered such that the variables from the current scope are first. llvm-svn: 136745
2011-08-03 07:35:43 +08:00
VariableListSP var_list_sp(new VariableList);
GetSymbolContext (eSymbolContextCompUnit | eSymbolContextBlock);
if (m_sc.block)
{
const bool can_create = true;
const bool get_parent_variables = true;
const bool stop_if_block_is_inlined_function = true;
m_sc.block->AppendVariables (can_create,
get_parent_variables,
stop_if_block_is_inlined_function,
When building the list of variables we're going to write "using $_lldb_local_vars" statements for, be sure not to include variables that have no locations. We wouldn't be able to realize them, and that will cause all expressions to fail. llvm-svn: 267500
2016-04-26 08:29:59 +08:00
[this, must_have_valid_location](Variable* v)
{
return v->IsInScope(this) && (!must_have_valid_location || v->LocationIsValidForFrame(this));
},
Fixed an issue where StackFrame::GetValueForVariableExpressionPath(...) was previously using the entire frame variable list instead of using the in scope variable list. I added a new function to a stack frame: lldb::VariableListSP StackFrame::GetInScopeVariableList (bool get_file_globals); This gets only variables that are in scope and they will be ordered such that the variables from the current scope are first. llvm-svn: 136745
2011-08-03 07:35:43 +08:00
var_list_sp.get());
}
Fix a thinko in StackFrame::GetInScopeVariableList. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D16745 llvm-svn: 259607
2016-02-03 07:49:41 +08:00
if (m_sc.comp_unit && get_file_globals)
Fixed an issue where StackFrame::GetValueForVariableExpressionPath(...) was previously using the entire frame variable list instead of using the in scope variable list. I added a new function to a stack frame: lldb::VariableListSP StackFrame::GetInScopeVariableList (bool get_file_globals); This gets only variables that are in scope and they will be ordered such that the variables from the current scope are first. llvm-svn: 136745
2011-08-03 07:35:43 +08:00
{
VariableListSP global_variable_list_sp (m_sc.comp_unit->GetVariableList(true));
if (global_variable_list_sp)
var_list_sp->AddVariables (global_variable_list_sp.get());
}
return var_list_sp;
}
Modified LLDB expressions to not have to JIT and run code just to see variable values or persistent expression variables. Now if an expression consists of a value that is a child of a variable, or of a persistent variable only, we will create a value object for it and make a ValueObjectConstResult from it to freeze the value (for program variables only, not persistent variables) and avoid running JITed code. For everything else we still parse up and JIT code and run it in the inferior. There was also a lot of clean up in the expression code. I made the ClangExpressionVariables be stored in collections of shared pointers instead of in collections of objects. This will help stop a lot of copy constructors on these large objects and also cleans up the code considerably. The persistent clang expression variables were moved over to the Target to ensure they persist across process executions. Added the ability for lldb_private::Target objects to evaluate expressions. We want to evaluate expressions at the target level in case we aren't running yet, or we have just completed running. We still want to be able to access the persistent expression variables between runs, and also evaluate constant expressions. Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects can now dump their contents with the UUID, arch and full paths being logged with appropriate prefix values. Thread hardened the Communication class a bit by making the connection auto_ptr member into a shared pointer member and then making a local copy of the shared pointer in each method that uses it to make sure another thread can't nuke the connection object while it is being used by another thread. Added a new file to the lldb/test/load_unload test that causes the test a.out file to link to the libd.dylib file all the time. This will allow us to test using the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else. llvm-svn: 121745
2010-12-14 10:59:59 +08:00
ValueObjectSP
<rdar://problem/11870357> Allow "frame variable" to find ivars without the need for "this->" or "self->". llvm-svn: 160211
2012-07-14 08:53:55 +08:00
StackFrame::GetValueForVariableExpressionPath (const char *var_expr_cstr,
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
DynamicValueType use_dynamic,
Change "frame var" over to using OptionGroups (and thus the OptionGroupVariableObjectDisplay). Change the boolean "use_dynamic" over to a tri-state, no-dynamic, dynamic-w/o running target, and dynamic with running target. llvm-svn: 130832
2011-05-04 11:43:18 +08:00
uint32_t options,
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
VariableSP &var_sp,
Change "frame var" over to using OptionGroups (and thus the OptionGroupVariableObjectDisplay). Change the boolean "use_dynamic" over to a tri-state, no-dynamic, dynamic-w/o running target, and dynamic with running target. llvm-svn: 130832
2011-05-04 11:43:18 +08:00
Error &error)
Modified LLDB expressions to not have to JIT and run code just to see variable values or persistent expression variables. Now if an expression consists of a value that is a child of a variable, or of a persistent variable only, we will create a value object for it and make a ValueObjectConstResult from it to freeze the value (for program variables only, not persistent variables) and avoid running JITed code. For everything else we still parse up and JIT code and run it in the inferior. There was also a lot of clean up in the expression code. I made the ClangExpressionVariables be stored in collections of shared pointers instead of in collections of objects. This will help stop a lot of copy constructors on these large objects and also cleans up the code considerably. The persistent clang expression variables were moved over to the Target to ensure they persist across process executions. Added the ability for lldb_private::Target objects to evaluate expressions. We want to evaluate expressions at the target level in case we aren't running yet, or we have just completed running. We still want to be able to access the persistent expression variables between runs, and also evaluate constant expressions. Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects can now dump their contents with the UUID, arch and full paths being logged with appropriate prefix values. Thread hardened the Communication class a bit by making the connection auto_ptr member into a shared pointer member and then making a local copy of the shared pointer in each method that uses it to make sure another thread can't nuke the connection object while it is being used by another thread. Added a new file to the lldb/test/load_unload test that causes the test a.out file to link to the libd.dylib file all the time. This will allow us to test using the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else. llvm-svn: 121745
2010-12-14 10:59:59 +08:00
{
Add new ivars to StackFrame so it can represent a stack collected at some point in the past. We may have nothing more than a pc value for this type of stack frame -- hopefully we'll have a pc and a stop_id so we can track module loads and unloads over time and symbolicate the pc at the correct point in time. Also add a flag to indicate if the CFA for the frame is available (a bit different from a CFA of LLDB_INVALID_ADDRESS) and also an overall setting to indicate whether this is a history stack frame or not. A history stack frame may not have a CFA, it may not have a register context, it may not have variables, it may not have a frame pointer or a stack pointer. <rdar://problem/15314068> llvm-svn: 193987
2013-11-04 19:02:52 +08:00
// We can't fetch variable information for a history stack frame.
if (m_is_history_frame)
return ValueObjectSP();
Fixed the "expression" command object to use the StackFrame::GetValueForExpressionPath() function and also hooked up better error reporting for when things fail. Fixed issues with trying to display children of pointers when none are supposed to be shown (no children for function pointers, and more like this). This was causing child value objects to be made that were correctly firing an assertion. llvm-svn: 121841
2010-12-15 13:08:08 +08:00
if (var_expr_cstr && var_expr_cstr[0])
Modified LLDB expressions to not have to JIT and run code just to see variable values or persistent expression variables. Now if an expression consists of a value that is a child of a variable, or of a persistent variable only, we will create a value object for it and make a ValueObjectConstResult from it to freeze the value (for program variables only, not persistent variables) and avoid running JITed code. For everything else we still parse up and JIT code and run it in the inferior. There was also a lot of clean up in the expression code. I made the ClangExpressionVariables be stored in collections of shared pointers instead of in collections of objects. This will help stop a lot of copy constructors on these large objects and also cleans up the code considerably. The persistent clang expression variables were moved over to the Target to ensure they persist across process executions. Added the ability for lldb_private::Target objects to evaluate expressions. We want to evaluate expressions at the target level in case we aren't running yet, or we have just completed running. We still want to be able to access the persistent expression variables between runs, and also evaluate constant expressions. Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects can now dump their contents with the UUID, arch and full paths being logged with appropriate prefix values. Thread hardened the Communication class a bit by making the connection auto_ptr member into a shared pointer member and then making a local copy of the shared pointer in each method that uses it to make sure another thread can't nuke the connection object while it is being used by another thread. Added a new file to the lldb/test/load_unload test that causes the test a.out file to link to the libd.dylib file all the time. This will allow us to test using the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else. llvm-svn: 121745
2010-12-14 10:59:59 +08:00
{
Added the ability to StackFrame::GetValueForVariableExpressionPath(...) to avoid fragile ivars if requested. This was done by changing the previous second parameter to an options bitfield that can be populated by logical OR'ing the new StackFrame::ExpressionPathOption enum values together: typedef enum ExpressionPathOption { eExpressionPathOptionCheckPtrVsMember = (1u << 0), eExpressionPathOptionsNoFragileObjcIvar = (1u << 1), }; So the old function was: lldb::ValueObjectSP StackFrame::GetValueForVariableExpressionPath (const char *var_expr, bool check_ptr_vs_member, Error &error); But it is now: lldb::ValueObjectSP StackFrame::GetValueForVariableExpressionPath (const char *var_expr, uint32_t options, Error &error); This allows the expression parser in Target::EvaluateExpression(...) to avoid using simple frame variable expression paths when evaluating something that might be a fragile ivar. llvm-svn: 123938
2011-01-21 03:27:18 +08:00
const bool check_ptr_vs_member = (options & eExpressionPathOptionCheckPtrVsMember) != 0;
const bool no_fragile_ivar = (options & eExpressionPathOptionsNoFragileObjcIvar) != 0;
Basic support for reading synthetic children by index: if your datatype provides synthetic children, "frame variable object[index]" should now do the right thing in cases where the above syntax would have been rejected before, i.e. object is not a pointer nor an array (frame variable ignores potential overload of []) object is a pointer to an Objective-C class (which cannot be dereferenced) expression will still run operator[] if available and complain if it cannot do so synthetic children by name do not work yet llvm-svn: 137097
2011-08-09 09:04:56 +08:00
const bool no_synth_child = (options & eExpressionPathOptionsNoSyntheticChildren) != 0;
Taking care of an issue with using lldb_private types in SBCommandInterpreter.cpp ; Making NSString test case work on Snow Leopard ; Removing an unused variable warning llvm-svn: 138105
2011-08-20 05:56:10 +08:00
//const bool no_synth_array = (options & eExpressionPathOptionsNoSyntheticArrayRange) != 0;
Fixed the "expression" command object to use the StackFrame::GetValueForExpressionPath() function and also hooked up better error reporting for when things fail. Fixed issues with trying to display children of pointers when none are supposed to be shown (no children for function pointers, and more like this). This was causing child value objects to be made that were correctly firing an assertion. llvm-svn: 121841
2010-12-15 13:08:08 +08:00
error.Clear();
bool deref = false;
bool address_of = false;
ValueObjectSP valobj_sp;
const bool get_file_globals = true;
Fixed an issue where StackFrame::GetValueForVariableExpressionPath(...) was previously using the entire frame variable list instead of using the in scope variable list. I added a new function to a stack frame: lldb::VariableListSP StackFrame::GetInScopeVariableList (bool get_file_globals); This gets only variables that are in scope and they will be ordered such that the variables from the current scope are first. llvm-svn: 136745
2011-08-03 07:35:43 +08:00
// When looking up a variable for an expression, we need only consider the
// variables that are in scope.
VariableListSP var_list_sp (GetInScopeVariableList (get_file_globals));
VariableList *variable_list = var_list_sp.get();
Fixed the "expression" command object to use the StackFrame::GetValueForExpressionPath() function and also hooked up better error reporting for when things fail. Fixed issues with trying to display children of pointers when none are supposed to be shown (no children for function pointers, and more like this). This was causing child value objects to be made that were correctly firing an assertion. llvm-svn: 121841
2010-12-15 13:08:08 +08:00
if (variable_list)
Modified LLDB expressions to not have to JIT and run code just to see variable values or persistent expression variables. Now if an expression consists of a value that is a child of a variable, or of a persistent variable only, we will create a value object for it and make a ValueObjectConstResult from it to freeze the value (for program variables only, not persistent variables) and avoid running JITed code. For everything else we still parse up and JIT code and run it in the inferior. There was also a lot of clean up in the expression code. I made the ClangExpressionVariables be stored in collections of shared pointers instead of in collections of objects. This will help stop a lot of copy constructors on these large objects and also cleans up the code considerably. The persistent clang expression variables were moved over to the Target to ensure they persist across process executions. Added the ability for lldb_private::Target objects to evaluate expressions. We want to evaluate expressions at the target level in case we aren't running yet, or we have just completed running. We still want to be able to access the persistent expression variables between runs, and also evaluate constant expressions. Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects can now dump their contents with the UUID, arch and full paths being logged with appropriate prefix values. Thread hardened the Communication class a bit by making the connection auto_ptr member into a shared pointer member and then making a local copy of the shared pointer in each method that uses it to make sure another thread can't nuke the connection object while it is being used by another thread. Added a new file to the lldb/test/load_unload test that causes the test a.out file to link to the libd.dylib file all the time. This will allow us to test using the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else. llvm-svn: 121745
2010-12-14 10:59:59 +08:00
{
Fixed the "expression" command object to use the StackFrame::GetValueForExpressionPath() function and also hooked up better error reporting for when things fail. Fixed issues with trying to display children of pointers when none are supposed to be shown (no children for function pointers, and more like this). This was causing child value objects to be made that were correctly firing an assertion. llvm-svn: 121841
2010-12-15 13:08:08 +08:00
// If first character is a '*', then show pointer contents
const char *var_expr = var_expr_cstr;
if (var_expr[0] == '*')
{
deref = true;
var_expr++; // Skip the '*'
}
else if (var_expr[0] == '&')
{
address_of = true;
var_expr++; // Skip the '&'
}
Modified LLDB expressions to not have to JIT and run code just to see variable values or persistent expression variables. Now if an expression consists of a value that is a child of a variable, or of a persistent variable only, we will create a value object for it and make a ValueObjectConstResult from it to freeze the value (for program variables only, not persistent variables) and avoid running JITed code. For everything else we still parse up and JIT code and run it in the inferior. There was also a lot of clean up in the expression code. I made the ClangExpressionVariables be stored in collections of shared pointers instead of in collections of objects. This will help stop a lot of copy constructors on these large objects and also cleans up the code considerably. The persistent clang expression variables were moved over to the Target to ensure they persist across process executions. Added the ability for lldb_private::Target objects to evaluate expressions. We want to evaluate expressions at the target level in case we aren't running yet, or we have just completed running. We still want to be able to access the persistent expression variables between runs, and also evaluate constant expressions. Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects can now dump their contents with the UUID, arch and full paths being logged with appropriate prefix values. Thread hardened the Communication class a bit by making the connection auto_ptr member into a shared pointer member and then making a local copy of the shared pointer in each method that uses it to make sure another thread can't nuke the connection object while it is being used by another thread. Added a new file to the lldb/test/load_unload test that causes the test a.out file to link to the libd.dylib file all the time. This will allow us to test using the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else. llvm-svn: 121745
2010-12-14 10:59:59 +08:00
Fixed the "expression" command object to use the StackFrame::GetValueForExpressionPath() function and also hooked up better error reporting for when things fail. Fixed issues with trying to display children of pointers when none are supposed to be shown (no children for function pointers, and more like this). This was causing child value objects to be made that were correctly firing an assertion. llvm-svn: 121841
2010-12-15 13:08:08 +08:00
std::string var_path (var_expr);
size_t separator_idx = var_path.find_first_of(".-[=+~|&^%#@!/?,<>{}");
StreamString var_expr_path_strm;
Modified LLDB expressions to not have to JIT and run code just to see variable values or persistent expression variables. Now if an expression consists of a value that is a child of a variable, or of a persistent variable only, we will create a value object for it and make a ValueObjectConstResult from it to freeze the value (for program variables only, not persistent variables) and avoid running JITed code. For everything else we still parse up and JIT code and run it in the inferior. There was also a lot of clean up in the expression code. I made the ClangExpressionVariables be stored in collections of shared pointers instead of in collections of objects. This will help stop a lot of copy constructors on these large objects and also cleans up the code considerably. The persistent clang expression variables were moved over to the Target to ensure they persist across process executions. Added the ability for lldb_private::Target objects to evaluate expressions. We want to evaluate expressions at the target level in case we aren't running yet, or we have just completed running. We still want to be able to access the persistent expression variables between runs, and also evaluate constant expressions. Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects can now dump their contents with the UUID, arch and full paths being logged with appropriate prefix values. Thread hardened the Communication class a bit by making the connection auto_ptr member into a shared pointer member and then making a local copy of the shared pointer in each method that uses it to make sure another thread can't nuke the connection object while it is being used by another thread. Added a new file to the lldb/test/load_unload test that causes the test a.out file to link to the libd.dylib file all the time. This will allow us to test using the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else. llvm-svn: 121745
2010-12-14 10:59:59 +08:00
Fixed the "expression" command object to use the StackFrame::GetValueForExpressionPath() function and also hooked up better error reporting for when things fail. Fixed issues with trying to display children of pointers when none are supposed to be shown (no children for function pointers, and more like this). This was causing child value objects to be made that were correctly firing an assertion. llvm-svn: 121841
2010-12-15 13:08:08 +08:00
ConstString name_const_string;
if (separator_idx == std::string::npos)
name_const_string.SetCString (var_path.c_str());
else
name_const_string.SetCStringWithLength (var_path.c_str(), separator_idx);
Modified LLDB expressions to not have to JIT and run code just to see variable values or persistent expression variables. Now if an expression consists of a value that is a child of a variable, or of a persistent variable only, we will create a value object for it and make a ValueObjectConstResult from it to freeze the value (for program variables only, not persistent variables) and avoid running JITed code. For everything else we still parse up and JIT code and run it in the inferior. There was also a lot of clean up in the expression code. I made the ClangExpressionVariables be stored in collections of shared pointers instead of in collections of objects. This will help stop a lot of copy constructors on these large objects and also cleans up the code considerably. The persistent clang expression variables were moved over to the Target to ensure they persist across process executions. Added the ability for lldb_private::Target objects to evaluate expressions. We want to evaluate expressions at the target level in case we aren't running yet, or we have just completed running. We still want to be able to access the persistent expression variables between runs, and also evaluate constant expressions. Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects can now dump their contents with the UUID, arch and full paths being logged with appropriate prefix values. Thread hardened the Communication class a bit by making the connection auto_ptr member into a shared pointer member and then making a local copy of the shared pointer in each method that uses it to make sure another thread can't nuke the connection object while it is being used by another thread. Added a new file to the lldb/test/load_unload test that causes the test a.out file to link to the libd.dylib file all the time. This will allow us to test using the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else. llvm-svn: 121745
2010-12-14 10:59:59 +08:00
Fix resolution conflict between global and class static variables in C++ llvm-svn: 245381
2015-08-19 06:46:57 +08:00
var_sp = variable_list->FindVariable(name_const_string, false);
<rdar://problem/11870357> Allow "frame variable" to find ivars without the need for "this->" or "self->". llvm-svn: 160211
2012-07-14 08:53:55 +08:00
bool synthetically_added_instance_object = false;
if (var_sp)
{
var_path.erase (0, name_const_string.GetLength ());
}
Fix up LLDB for a change in the way clang represents anonymous unions such that the 'frame variable' command can still find the members of such union as if they were top-level variables in the current scope llvm-svn: 253613
2015-11-20 06:28:58 +08:00
if (!var_sp && (options & eExpressionPathOptionsAllowDirectIVarAccess))
<rdar://problem/11870357> Allow "frame variable" to find ivars without the need for "this->" or "self->". llvm-svn: 160211
2012-07-14 08:53:55 +08:00
{
// Check for direct ivars access which helps us with implicit
// access to ivars with the "this->" or "self->"
GetSymbolContext(eSymbolContextFunction|eSymbolContextBlock);
lldb::LanguageType method_language = eLanguageTypeUnknown;
bool is_instance_method = false;
ConstString method_object_name;
if (m_sc.GetFunctionMethodInfo (method_language, is_instance_method, method_object_name))
{
if (is_instance_method && method_object_name)
{
var_sp = variable_list->FindVariable(method_object_name);
if (var_sp)
{
separator_idx = 0;
var_path.insert(0, "->");
synthetically_added_instance_object = true;
}
}
}
}
Fix up LLDB for a change in the way clang represents anonymous unions such that the 'frame variable' command can still find the members of such union as if they were top-level variables in the current scope llvm-svn: 253613
2015-11-20 06:28:58 +08:00
if (!var_sp && (options & eExpressionPathOptionsInspectAnonymousUnions))
{
// Check if any anonymous unions are there which contain a variable with the name we need
for (size_t i = 0;
i < variable_list->GetSize();
i++)
{
if (VariableSP variable_sp = variable_list->GetVariableAtIndex(i))
{
if (variable_sp->GetName().IsEmpty())
{
if (Type *var_type = variable_sp->GetType())
{
if (var_type->GetForwardCompilerType().IsAnonymousType())
{
valobj_sp = GetValueObjectForFrameVariable (variable_sp, use_dynamic);
if (!valobj_sp)
return valobj_sp;
valobj_sp = valobj_sp->GetChildMemberWithName(name_const_string, true);
if (valobj_sp)
break;
}
}
}
}
}
}
<rdar://problem/11870357> Allow "frame variable" to find ivars without the need for "this->" or "self->". llvm-svn: 160211
2012-07-14 08:53:55 +08:00
Fix up LLDB for a change in the way clang represents anonymous unions such that the 'frame variable' command can still find the members of such union as if they were top-level variables in the current scope llvm-svn: 253613
2015-11-20 06:28:58 +08:00
if (var_sp && !valobj_sp)
Modified LLDB expressions to not have to JIT and run code just to see variable values or persistent expression variables. Now if an expression consists of a value that is a child of a variable, or of a persistent variable only, we will create a value object for it and make a ValueObjectConstResult from it to freeze the value (for program variables only, not persistent variables) and avoid running JITed code. For everything else we still parse up and JIT code and run it in the inferior. There was also a lot of clean up in the expression code. I made the ClangExpressionVariables be stored in collections of shared pointers instead of in collections of objects. This will help stop a lot of copy constructors on these large objects and also cleans up the code considerably. The persistent clang expression variables were moved over to the Target to ensure they persist across process executions. Added the ability for lldb_private::Target objects to evaluate expressions. We want to evaluate expressions at the target level in case we aren't running yet, or we have just completed running. We still want to be able to access the persistent expression variables between runs, and also evaluate constant expressions. Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects can now dump their contents with the UUID, arch and full paths being logged with appropriate prefix values. Thread hardened the Communication class a bit by making the connection auto_ptr member into a shared pointer member and then making a local copy of the shared pointer in each method that uses it to make sure another thread can't nuke the connection object while it is being used by another thread. Added a new file to the lldb/test/load_unload test that causes the test a.out file to link to the libd.dylib file all the time. This will allow us to test using the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else. llvm-svn: 121745
2010-12-14 10:59:59 +08:00
{
Change "frame var" over to using OptionGroups (and thus the OptionGroupVariableObjectDisplay). Change the boolean "use_dynamic" over to a tri-state, no-dynamic, dynamic-w/o running target, and dynamic with running target. llvm-svn: 130832
2011-05-04 11:43:18 +08:00
valobj_sp = GetValueObjectForFrameVariable (var_sp, use_dynamic);
Add support for "dynamic values" for C++ classes. This currently only works for "frame var" and for the expressions that are simple enough to get passed to the "frame var" underpinnings. The parser code will have to be changed to also query for the dynamic types & offsets as it is looking up variables. The behavior of "frame var" is controlled in two ways. You can pass "-d {true/false} to the frame var command to get the dynamic or static value of the variables you are printing. There's also a general setting: target.prefer-dynamic-value (boolean) = 'true' which is consulted if you call "frame var" without supplying a value for the -d option. llvm-svn: 129623
2011-04-16 08:01:13 +08:00
if (!valobj_sp)
return valobj_sp;
Fix up LLDB for a change in the way clang represents anonymous unions such that the 'frame variable' command can still find the members of such union as if they were top-level variables in the current scope llvm-svn: 253613
2015-11-20 06:28:58 +08:00
}
if (valobj_sp)
{
Fixed the "expression" command object to use the StackFrame::GetValueForExpressionPath() function and also hooked up better error reporting for when things fail. Fixed issues with trying to display children of pointers when none are supposed to be shown (no children for function pointers, and more like this). This was causing child value objects to be made that were correctly firing an assertion. llvm-svn: 121841
2010-12-15 13:08:08 +08:00
// We are dumping at least one child
while (separator_idx != std::string::npos)
{
// Calculate the next separator index ahead of time
ValueObjectSP child_valobj_sp;
const char separator_type = var_path[0];
switch (separator_type)
Modified LLDB expressions to not have to JIT and run code just to see variable values or persistent expression variables. Now if an expression consists of a value that is a child of a variable, or of a persistent variable only, we will create a value object for it and make a ValueObjectConstResult from it to freeze the value (for program variables only, not persistent variables) and avoid running JITed code. For everything else we still parse up and JIT code and run it in the inferior. There was also a lot of clean up in the expression code. I made the ClangExpressionVariables be stored in collections of shared pointers instead of in collections of objects. This will help stop a lot of copy constructors on these large objects and also cleans up the code considerably. The persistent clang expression variables were moved over to the Target to ensure they persist across process executions. Added the ability for lldb_private::Target objects to evaluate expressions. We want to evaluate expressions at the target level in case we aren't running yet, or we have just completed running. We still want to be able to access the persistent expression variables between runs, and also evaluate constant expressions. Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects can now dump their contents with the UUID, arch and full paths being logged with appropriate prefix values. Thread hardened the Communication class a bit by making the connection auto_ptr member into a shared pointer member and then making a local copy of the shared pointer in each method that uses it to make sure another thread can't nuke the connection object while it is being used by another thread. Added a new file to the lldb/test/load_unload test that causes the test a.out file to link to the libd.dylib file all the time. This will allow us to test using the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else. llvm-svn: 121745
2010-12-14 10:59:59 +08:00
{
Fixed the "expression" command object to use the StackFrame::GetValueForExpressionPath() function and also hooked up better error reporting for when things fail. Fixed issues with trying to display children of pointers when none are supposed to be shown (no children for function pointers, and more like this). This was causing child value objects to be made that were correctly firing an assertion. llvm-svn: 121841
2010-12-15 13:08:08 +08:00
case '-':
if (var_path.size() >= 2 && var_path[1] != '>')
Modified LLDB expressions to not have to JIT and run code just to see variable values or persistent expression variables. Now if an expression consists of a value that is a child of a variable, or of a persistent variable only, we will create a value object for it and make a ValueObjectConstResult from it to freeze the value (for program variables only, not persistent variables) and avoid running JITed code. For everything else we still parse up and JIT code and run it in the inferior. There was also a lot of clean up in the expression code. I made the ClangExpressionVariables be stored in collections of shared pointers instead of in collections of objects. This will help stop a lot of copy constructors on these large objects and also cleans up the code considerably. The persistent clang expression variables were moved over to the Target to ensure they persist across process executions. Added the ability for lldb_private::Target objects to evaluate expressions. We want to evaluate expressions at the target level in case we aren't running yet, or we have just completed running. We still want to be able to access the persistent expression variables between runs, and also evaluate constant expressions. Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects can now dump their contents with the UUID, arch and full paths being logged with appropriate prefix values. Thread hardened the Communication class a bit by making the connection auto_ptr member into a shared pointer member and then making a local copy of the shared pointer in each method that uses it to make sure another thread can't nuke the connection object while it is being used by another thread. Added a new file to the lldb/test/load_unload test that causes the test a.out file to link to the libd.dylib file all the time. This will allow us to test using the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else. llvm-svn: 121745
2010-12-14 10:59:59 +08:00
return ValueObjectSP();
Added the ability to StackFrame::GetValueForVariableExpressionPath(...) to avoid fragile ivars if requested. This was done by changing the previous second parameter to an options bitfield that can be populated by logical OR'ing the new StackFrame::ExpressionPathOption enum values together: typedef enum ExpressionPathOption { eExpressionPathOptionCheckPtrVsMember = (1u << 0), eExpressionPathOptionsNoFragileObjcIvar = (1u << 1), }; So the old function was: lldb::ValueObjectSP StackFrame::GetValueForVariableExpressionPath (const char *var_expr, bool check_ptr_vs_member, Error &error); But it is now: lldb::ValueObjectSP StackFrame::GetValueForVariableExpressionPath (const char *var_expr, uint32_t options, Error &error); This allows the expression parser in Target::EvaluateExpression(...) to avoid using simple frame variable expression paths when evaluating something that might be a fragile ivar. llvm-svn: 123938
2011-01-21 03:27:18 +08:00
if (no_fragile_ivar)
{
// Make sure we aren't trying to deref an objective
// C ivar if this is not allowed
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Target; other minor fixes. llvm-svn: 261242
2016-02-19 02:52:47 +08:00
const uint32_t pointer_type_flags = valobj_sp->GetCompilerType().GetTypeInfo(nullptr);
Expose the type-info flags at the public API layer. These flags provide much more informational content to consumers of the LLDB API than the existing TypeClass. Part of the fix for rdar://18517593 llvm-svn: 220322
2014-10-22 04:52:14 +08:00
if ((pointer_type_flags & eTypeIsObjC) &&
(pointer_type_flags & eTypeIsPointer))
Added the ability to StackFrame::GetValueForVariableExpressionPath(...) to avoid fragile ivars if requested. This was done by changing the previous second parameter to an options bitfield that can be populated by logical OR'ing the new StackFrame::ExpressionPathOption enum values together: typedef enum ExpressionPathOption { eExpressionPathOptionCheckPtrVsMember = (1u << 0), eExpressionPathOptionsNoFragileObjcIvar = (1u << 1), }; So the old function was: lldb::ValueObjectSP StackFrame::GetValueForVariableExpressionPath (const char *var_expr, bool check_ptr_vs_member, Error &error); But it is now: lldb::ValueObjectSP StackFrame::GetValueForVariableExpressionPath (const char *var_expr, uint32_t options, Error &error); This allows the expression parser in Target::EvaluateExpression(...) to avoid using simple frame variable expression paths when evaluating something that might be a fragile ivar. llvm-svn: 123938
2011-01-21 03:27:18 +08:00
{
// This was an objective C object pointer and
// it was requested we skip any fragile ivars
// so return nothing here
return ValueObjectSP();
}
}
Fixed the "expression" command object to use the StackFrame::GetValueForExpressionPath() function and also hooked up better error reporting for when things fail. Fixed issues with trying to display children of pointers when none are supposed to be shown (no children for function pointers, and more like this). This was causing child value objects to be made that were correctly firing an assertion. llvm-svn: 121841
2010-12-15 13:08:08 +08:00
var_path.erase (0, 1); // Remove the '-'
Add -Wimplicit-fallthrough command line option to clang in the xcode project file to catch switch statements that have a case that falls through unintentionally. Define LLVM_FALLTHROUGH to indicate instances where a case has code and intends to fall through. This should be in llvm/Support/Compiler.h; Peter Collingbourne originally checked in there (r237766), then reverted (r237941) because he didn't have time to mark up all the 'case' statements that were intended to fall through. I put together a patch to get this back in llvm http://reviews.llvm.org/D17063 but it hasn't been approved in the past week. I added a new lldb-private-defines.h to hold the definition for now. Every place in lldb where there is a comment that the fall-through is intentional, I added LLVM_FALLTHROUGH to silence the warning. I haven't tried to identify whether the fallthrough is a bug or not in the other places. I haven't tried to add this to the cmake option build flags. This warning will only work for clang. This build cleanly (with some new warnings) on macosx with clang under xcodebuild, but if this causes problems for people on other configurations, I'll back it out. llvm-svn: 260930
2016-02-16 12:14:33 +08:00
LLVM_FALLTHROUGH;
Fixed the "expression" command object to use the StackFrame::GetValueForExpressionPath() function and also hooked up better error reporting for when things fail. Fixed issues with trying to display children of pointers when none are supposed to be shown (no children for function pointers, and more like this). This was causing child value objects to be made that were correctly firing an assertion. llvm-svn: 121841
2010-12-15 13:08:08 +08:00
case '.':
Modified LLDB expressions to not have to JIT and run code just to see variable values or persistent expression variables. Now if an expression consists of a value that is a child of a variable, or of a persistent variable only, we will create a value object for it and make a ValueObjectConstResult from it to freeze the value (for program variables only, not persistent variables) and avoid running JITed code. For everything else we still parse up and JIT code and run it in the inferior. There was also a lot of clean up in the expression code. I made the ClangExpressionVariables be stored in collections of shared pointers instead of in collections of objects. This will help stop a lot of copy constructors on these large objects and also cleans up the code considerably. The persistent clang expression variables were moved over to the Target to ensure they persist across process executions. Added the ability for lldb_private::Target objects to evaluate expressions. We want to evaluate expressions at the target level in case we aren't running yet, or we have just completed running. We still want to be able to access the persistent expression variables between runs, and also evaluate constant expressions. Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects can now dump their contents with the UUID, arch and full paths being logged with appropriate prefix values. Thread hardened the Communication class a bit by making the connection auto_ptr member into a shared pointer member and then making a local copy of the shared pointer in each method that uses it to make sure another thread can't nuke the connection object while it is being used by another thread. Added a new file to the lldb/test/load_unload test that causes the test a.out file to link to the libd.dylib file all the time. This will allow us to test using the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else. llvm-svn: 121745
2010-12-14 10:59:59 +08:00
{
Fixed the "expression" command object to use the StackFrame::GetValueForExpressionPath() function and also hooked up better error reporting for when things fail. Fixed issues with trying to display children of pointers when none are supposed to be shown (no children for function pointers, and more like this). This was causing child value objects to be made that were correctly firing an assertion. llvm-svn: 121841
2010-12-15 13:08:08 +08:00
const bool expr_is_ptr = var_path[0] == '>';
Modified LLDB expressions to not have to JIT and run code just to see variable values or persistent expression variables. Now if an expression consists of a value that is a child of a variable, or of a persistent variable only, we will create a value object for it and make a ValueObjectConstResult from it to freeze the value (for program variables only, not persistent variables) and avoid running JITed code. For everything else we still parse up and JIT code and run it in the inferior. There was also a lot of clean up in the expression code. I made the ClangExpressionVariables be stored in collections of shared pointers instead of in collections of objects. This will help stop a lot of copy constructors on these large objects and also cleans up the code considerably. The persistent clang expression variables were moved over to the Target to ensure they persist across process executions. Added the ability for lldb_private::Target objects to evaluate expressions. We want to evaluate expressions at the target level in case we aren't running yet, or we have just completed running. We still want to be able to access the persistent expression variables between runs, and also evaluate constant expressions. Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects can now dump their contents with the UUID, arch and full paths being logged with appropriate prefix values. Thread hardened the Communication class a bit by making the connection auto_ptr member into a shared pointer member and then making a local copy of the shared pointer in each method that uses it to make sure another thread can't nuke the connection object while it is being used by another thread. Added a new file to the lldb/test/load_unload test that causes the test a.out file to link to the libd.dylib file all the time. This will allow us to test using the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else. llvm-svn: 121745
2010-12-14 10:59:59 +08:00
Fixed the "expression" command object to use the StackFrame::GetValueForExpressionPath() function and also hooked up better error reporting for when things fail. Fixed issues with trying to display children of pointers when none are supposed to be shown (no children for function pointers, and more like this). This was causing child value objects to be made that were correctly firing an assertion. llvm-svn: 121841
2010-12-15 13:08:08 +08:00
var_path.erase (0, 1); // Remove the '.' or '>'
separator_idx = var_path.find_first_of(".-[");
ConstString child_name;
if (separator_idx == std::string::npos)
child_name.SetCString (var_path.c_str());
Modified LLDB expressions to not have to JIT and run code just to see variable values or persistent expression variables. Now if an expression consists of a value that is a child of a variable, or of a persistent variable only, we will create a value object for it and make a ValueObjectConstResult from it to freeze the value (for program variables only, not persistent variables) and avoid running JITed code. For everything else we still parse up and JIT code and run it in the inferior. There was also a lot of clean up in the expression code. I made the ClangExpressionVariables be stored in collections of shared pointers instead of in collections of objects. This will help stop a lot of copy constructors on these large objects and also cleans up the code considerably. The persistent clang expression variables were moved over to the Target to ensure they persist across process executions. Added the ability for lldb_private::Target objects to evaluate expressions. We want to evaluate expressions at the target level in case we aren't running yet, or we have just completed running. We still want to be able to access the persistent expression variables between runs, and also evaluate constant expressions. Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects can now dump their contents with the UUID, arch and full paths being logged with appropriate prefix values. Thread hardened the Communication class a bit by making the connection auto_ptr member into a shared pointer member and then making a local copy of the shared pointer in each method that uses it to make sure another thread can't nuke the connection object while it is being used by another thread. Added a new file to the lldb/test/load_unload test that causes the test a.out file to link to the libd.dylib file all the time. This will allow us to test using the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else. llvm-svn: 121745
2010-12-14 10:59:59 +08:00
else
Fixed the "expression" command object to use the StackFrame::GetValueForExpressionPath() function and also hooked up better error reporting for when things fail. Fixed issues with trying to display children of pointers when none are supposed to be shown (no children for function pointers, and more like this). This was causing child value objects to be made that were correctly firing an assertion. llvm-svn: 121841
2010-12-15 13:08:08 +08:00
child_name.SetCStringWithLength(var_path.c_str(), separator_idx);
if (check_ptr_vs_member)
Modified LLDB expressions to not have to JIT and run code just to see variable values or persistent expression variables. Now if an expression consists of a value that is a child of a variable, or of a persistent variable only, we will create a value object for it and make a ValueObjectConstResult from it to freeze the value (for program variables only, not persistent variables) and avoid running JITed code. For everything else we still parse up and JIT code and run it in the inferior. There was also a lot of clean up in the expression code. I made the ClangExpressionVariables be stored in collections of shared pointers instead of in collections of objects. This will help stop a lot of copy constructors on these large objects and also cleans up the code considerably. The persistent clang expression variables were moved over to the Target to ensure they persist across process executions. Added the ability for lldb_private::Target objects to evaluate expressions. We want to evaluate expressions at the target level in case we aren't running yet, or we have just completed running. We still want to be able to access the persistent expression variables between runs, and also evaluate constant expressions. Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects can now dump their contents with the UUID, arch and full paths being logged with appropriate prefix values. Thread hardened the Communication class a bit by making the connection auto_ptr member into a shared pointer member and then making a local copy of the shared pointer in each method that uses it to make sure another thread can't nuke the connection object while it is being used by another thread. Added a new file to the lldb/test/load_unload test that causes the test a.out file to link to the libd.dylib file all the time. This will allow us to test using the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else. llvm-svn: 121745
2010-12-14 10:59:59 +08:00
{
Fixed the "expression" command object to use the StackFrame::GetValueForExpressionPath() function and also hooked up better error reporting for when things fail. Fixed issues with trying to display children of pointers when none are supposed to be shown (no children for function pointers, and more like this). This was causing child value objects to be made that were correctly firing an assertion. llvm-svn: 121841
2010-12-15 13:08:08 +08:00
// We either have a pointer type and need to verify
// valobj_sp is a pointer, or we have a member of a
// class/union/struct being accessed with the . syntax
// and need to verify we don't have a pointer.
const bool actual_is_ptr = valobj_sp->IsPointerType ();
if (actual_is_ptr != expr_is_ptr)
{
// Incorrect use of "." with a pointer, or "->" with
// a class/union/struct instance or reference.
A few of the issue I have been trying to track down and fix have been due to the way LLDB lazily gets complete definitions for types within the debug info. When we run across a class/struct/union definition in the DWARF, we will only parse the full definition if we need to. This works fine for top level types that are assigned directly to variables and arguments, but when we have a variable with a class, lets say "A" for this example, that has a member: "B *m_b". Initially we don't need to hunt down a definition for this class unless we are ever asked to do something with it ("expr m_b->getDecl()" for example). With my previous approach to lazy type completion, we would be able to take a "A *a" and get a complete type for it, but we wouldn't be able to then do an "a->m_b->getDecl()" unless we always expanded all types within a class prior to handing out the type. Expanding everything is very costly and it would be great if there were a better way. A few months ago I worked with the llvm/clang folks to have the ExternalASTSource class be able to complete classes if there weren't completed yet: class ExternalASTSource { .... virtual void CompleteType (clang::TagDecl *Tag); virtual void CompleteType (clang::ObjCInterfaceDecl *Class); }; This was great, because we can now have the class that is producing the AST (SymbolFileDWARF and SymbolFileDWARFDebugMap) sign up as external AST sources and the object that creates the forward declaration types can now also complete them anywhere within the clang type system. This patch makes a few major changes: - lldb_private::Module classes now own the AST context. Previously the TypeList objects did. - The DWARF parsers now sign up as an external AST sources so they can complete types. - All of the pure clang type system wrapper code we have in LLDB (ClangASTContext, ClangASTType, and more) can now be iterating through children of any type, and if a class/union/struct type (clang::RecordType or ObjC interface) is found that is incomplete, we can ask the AST to get the definition. - The SymbolFileDWARFDebugMap class now will create and use a single AST that all child SymbolFileDWARF classes will share (much like what happens when we have a complete linked DWARF for an executable). We will need to modify some of the ClangUserExpression code to take more advantage of this completion ability in the near future. Meanwhile we should be better off now that we can be accessing any children of variables through pointers and always be able to resolve the clang type if needed. llvm-svn: 123613
2011-01-17 11:46:26 +08:00
valobj_sp->GetExpressionPath (var_expr_path_strm, false);
Fixed the "expression" command object to use the StackFrame::GetValueForExpressionPath() function and also hooked up better error reporting for when things fail. Fixed issues with trying to display children of pointers when none are supposed to be shown (no children for function pointers, and more like this). This was causing child value objects to be made that were correctly firing an assertion. llvm-svn: 121841
2010-12-15 13:08:08 +08:00
if (actual_is_ptr)
error.SetErrorStringWithFormat ("\"%s\" is a pointer and . was used to attempt to access \"%s\". Did you mean \"%s->%s\"?",
var_expr_path_strm.GetString().c_str(),
child_name.GetCString(),
var_expr_path_strm.GetString().c_str(),
var_path.c_str());
else
error.SetErrorStringWithFormat ("\"%s\" is not a pointer and -> was used to attempt to access \"%s\". Did you mean \"%s.%s\"?",
var_expr_path_strm.GetString().c_str(),
child_name.GetCString(),
var_expr_path_strm.GetString().c_str(),
var_path.c_str());
return ValueObjectSP();
}
Modified LLDB expressions to not have to JIT and run code just to see variable values or persistent expression variables. Now if an expression consists of a value that is a child of a variable, or of a persistent variable only, we will create a value object for it and make a ValueObjectConstResult from it to freeze the value (for program variables only, not persistent variables) and avoid running JITed code. For everything else we still parse up and JIT code and run it in the inferior. There was also a lot of clean up in the expression code. I made the ClangExpressionVariables be stored in collections of shared pointers instead of in collections of objects. This will help stop a lot of copy constructors on these large objects and also cleans up the code considerably. The persistent clang expression variables were moved over to the Target to ensure they persist across process executions. Added the ability for lldb_private::Target objects to evaluate expressions. We want to evaluate expressions at the target level in case we aren't running yet, or we have just completed running. We still want to be able to access the persistent expression variables between runs, and also evaluate constant expressions. Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects can now dump their contents with the UUID, arch and full paths being logged with appropriate prefix values. Thread hardened the Communication class a bit by making the connection auto_ptr member into a shared pointer member and then making a local copy of the shared pointer in each method that uses it to make sure another thread can't nuke the connection object while it is being used by another thread. Added a new file to the lldb/test/load_unload test that causes the test a.out file to link to the libd.dylib file all the time. This will allow us to test using the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else. llvm-svn: 121745
2010-12-14 10:59:59 +08:00
}
Fixed the "expression" command object to use the StackFrame::GetValueForExpressionPath() function and also hooked up better error reporting for when things fail. Fixed issues with trying to display children of pointers when none are supposed to be shown (no children for function pointers, and more like this). This was causing child value objects to be made that were correctly firing an assertion. llvm-svn: 121841
2010-12-15 13:08:08 +08:00
child_valobj_sp = valobj_sp->GetChildMemberWithName (child_name, true);
Modified LLDB expressions to not have to JIT and run code just to see variable values or persistent expression variables. Now if an expression consists of a value that is a child of a variable, or of a persistent variable only, we will create a value object for it and make a ValueObjectConstResult from it to freeze the value (for program variables only, not persistent variables) and avoid running JITed code. For everything else we still parse up and JIT code and run it in the inferior. There was also a lot of clean up in the expression code. I made the ClangExpressionVariables be stored in collections of shared pointers instead of in collections of objects. This will help stop a lot of copy constructors on these large objects and also cleans up the code considerably. The persistent clang expression variables were moved over to the Target to ensure they persist across process executions. Added the ability for lldb_private::Target objects to evaluate expressions. We want to evaluate expressions at the target level in case we aren't running yet, or we have just completed running. We still want to be able to access the persistent expression variables between runs, and also evaluate constant expressions. Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects can now dump their contents with the UUID, arch and full paths being logged with appropriate prefix values. Thread hardened the Communication class a bit by making the connection auto_ptr member into a shared pointer member and then making a local copy of the shared pointer in each method that uses it to make sure another thread can't nuke the connection object while it is being used by another thread. Added a new file to the lldb/test/load_unload test that causes the test a.out file to link to the libd.dylib file all the time. This will allow us to test using the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else. llvm-svn: 121745
2010-12-14 10:59:59 +08:00
if (!child_valobj_sp)
{
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Target; other minor fixes. llvm-svn: 261242
2016-02-19 02:52:47 +08:00
if (!no_synth_child)
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
{
child_valobj_sp = valobj_sp->GetSyntheticValue();
if (child_valobj_sp)
child_valobj_sp = child_valobj_sp->GetChildMemberWithName (child_name, true);
}
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
if (no_synth_child || !child_valobj_sp)
Fixed the "expression" command object to use the StackFrame::GetValueForExpressionPath() function and also hooked up better error reporting for when things fail. Fixed issues with trying to display children of pointers when none are supposed to be shown (no children for function pointers, and more like this). This was causing child value objects to be made that were correctly firing an assertion. llvm-svn: 121841
2010-12-15 13:08:08 +08:00
{
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
// No child member with name "child_name"
<rdar://problem/11870357> Allow "frame variable" to find ivars without the need for "this->" or "self->". llvm-svn: 160211
2012-07-14 08:53:55 +08:00
if (synthetically_added_instance_object)
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
{
<rdar://problem/11870357> Allow "frame variable" to find ivars without the need for "this->" or "self->". llvm-svn: 160211
2012-07-14 08:53:55 +08:00
// We added a "this->" or "self->" to the beginning of the expression
// and this is the first pointer ivar access, so just return the normal
// error
error.SetErrorStringWithFormat("no variable or instance variable named '%s' found in this frame",
name_const_string.GetCString());
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
}
else
{
<rdar://problem/11870357> Allow "frame variable" to find ivars without the need for "this->" or "self->". llvm-svn: 160211
2012-07-14 08:53:55 +08:00
valobj_sp->GetExpressionPath (var_expr_path_strm, false);
if (child_name)
{
error.SetErrorStringWithFormat ("\"%s\" is not a member of \"(%s) %s\"",
child_name.GetCString(),
valobj_sp->GetTypeName().AsCString("<invalid type>"),
var_expr_path_strm.GetString().c_str());
}
else
{
error.SetErrorStringWithFormat ("incomplete expression path after \"%s\" in \"%s\"",
var_expr_path_strm.GetString().c_str(),
var_expr_cstr);
}
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
}
return ValueObjectSP();
Fixed the "expression" command object to use the StackFrame::GetValueForExpressionPath() function and also hooked up better error reporting for when things fail. Fixed issues with trying to display children of pointers when none are supposed to be shown (no children for function pointers, and more like this). This was causing child value objects to be made that were correctly firing an assertion. llvm-svn: 121841
2010-12-15 13:08:08 +08:00
}
Modified LLDB expressions to not have to JIT and run code just to see variable values or persistent expression variables. Now if an expression consists of a value that is a child of a variable, or of a persistent variable only, we will create a value object for it and make a ValueObjectConstResult from it to freeze the value (for program variables only, not persistent variables) and avoid running JITed code. For everything else we still parse up and JIT code and run it in the inferior. There was also a lot of clean up in the expression code. I made the ClangExpressionVariables be stored in collections of shared pointers instead of in collections of objects. This will help stop a lot of copy constructors on these large objects and also cleans up the code considerably. The persistent clang expression variables were moved over to the Target to ensure they persist across process executions. Added the ability for lldb_private::Target objects to evaluate expressions. We want to evaluate expressions at the target level in case we aren't running yet, or we have just completed running. We still want to be able to access the persistent expression variables between runs, and also evaluate constant expressions. Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects can now dump their contents with the UUID, arch and full paths being logged with appropriate prefix values. Thread hardened the Communication class a bit by making the connection auto_ptr member into a shared pointer member and then making a local copy of the shared pointer in each method that uses it to make sure another thread can't nuke the connection object while it is being used by another thread. Added a new file to the lldb/test/load_unload test that causes the test a.out file to link to the libd.dylib file all the time. This will allow us to test using the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else. llvm-svn: 121745
2010-12-14 10:59:59 +08:00
}
<rdar://problem/11870357> Allow "frame variable" to find ivars without the need for "this->" or "self->". llvm-svn: 160211
2012-07-14 08:53:55 +08:00
synthetically_added_instance_object = false;
Fixed the "expression" command object to use the StackFrame::GetValueForExpressionPath() function and also hooked up better error reporting for when things fail. Fixed issues with trying to display children of pointers when none are supposed to be shown (no children for function pointers, and more like this). This was causing child value objects to be made that were correctly firing an assertion. llvm-svn: 121841
2010-12-15 13:08:08 +08:00
// Remove the child name from the path
var_path.erase(0, child_name.GetLength());
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
if (use_dynamic != eNoDynamicValues)
Add support for "dynamic values" for C++ classes. This currently only works for "frame var" and for the expressions that are simple enough to get passed to the "frame var" underpinnings. The parser code will have to be changed to also query for the dynamic types & offsets as it is looking up variables. The behavior of "frame var" is controlled in two ways. You can pass "-d {true/false} to the frame var command to get the dynamic or static value of the variables you are printing. There's also a general setting: target.prefer-dynamic-value (boolean) = 'true' which is consulted if you call "frame var" without supplying a value for the -d option. llvm-svn: 129623
2011-04-16 08:01:13 +08:00
{
Change "frame var" over to using OptionGroups (and thus the OptionGroupVariableObjectDisplay). Change the boolean "use_dynamic" over to a tri-state, no-dynamic, dynamic-w/o running target, and dynamic with running target. llvm-svn: 130832
2011-05-04 11:43:18 +08:00
ValueObjectSP dynamic_value_sp(child_valobj_sp->GetDynamicValue(use_dynamic));
Add support for "dynamic values" for C++ classes. This currently only works for "frame var" and for the expressions that are simple enough to get passed to the "frame var" underpinnings. The parser code will have to be changed to also query for the dynamic types & offsets as it is looking up variables. The behavior of "frame var" is controlled in two ways. You can pass "-d {true/false} to the frame var command to get the dynamic or static value of the variables you are printing. There's also a general setting: target.prefer-dynamic-value (boolean) = 'true' which is consulted if you call "frame var" without supplying a value for the -d option. llvm-svn: 129623
2011-04-16 08:01:13 +08:00
if (dynamic_value_sp)
child_valobj_sp = dynamic_value_sp;
}
Fixed the "expression" command object to use the StackFrame::GetValueForExpressionPath() function and also hooked up better error reporting for when things fail. Fixed issues with trying to display children of pointers when none are supposed to be shown (no children for function pointers, and more like this). This was causing child value objects to be made that were correctly firing an assertion. llvm-svn: 121841
2010-12-15 13:08:08 +08:00
}
break;
Modified LLDB expressions to not have to JIT and run code just to see variable values or persistent expression variables. Now if an expression consists of a value that is a child of a variable, or of a persistent variable only, we will create a value object for it and make a ValueObjectConstResult from it to freeze the value (for program variables only, not persistent variables) and avoid running JITed code. For everything else we still parse up and JIT code and run it in the inferior. There was also a lot of clean up in the expression code. I made the ClangExpressionVariables be stored in collections of shared pointers instead of in collections of objects. This will help stop a lot of copy constructors on these large objects and also cleans up the code considerably. The persistent clang expression variables were moved over to the Target to ensure they persist across process executions. Added the ability for lldb_private::Target objects to evaluate expressions. We want to evaluate expressions at the target level in case we aren't running yet, or we have just completed running. We still want to be able to access the persistent expression variables between runs, and also evaluate constant expressions. Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects can now dump their contents with the UUID, arch and full paths being logged with appropriate prefix values. Thread hardened the Communication class a bit by making the connection auto_ptr member into a shared pointer member and then making a local copy of the shared pointer in each method that uses it to make sure another thread can't nuke the connection object while it is being used by another thread. Added a new file to the lldb/test/load_unload test that causes the test a.out file to link to the libd.dylib file all the time. This will allow us to test using the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else. llvm-svn: 121745
2010-12-14 10:59:59 +08:00
Fixed the "expression" command object to use the StackFrame::GetValueForExpressionPath() function and also hooked up better error reporting for when things fail. Fixed issues with trying to display children of pointers when none are supposed to be shown (no children for function pointers, and more like this). This was causing child value objects to be made that were correctly firing an assertion. llvm-svn: 121841
2010-12-15 13:08:08 +08:00
case '[':
// Array member access, or treating pointer as an array
if (var_path.size() > 2) // Need at least two brackets and a number
{
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Target; other minor fixes. llvm-svn: 261242
2016-02-19 02:52:47 +08:00
char *end = nullptr;
Enabled extra warnings and fixed a bunch of small issues. llvm-svn: 124250
2011-01-26 07:55:37 +08:00
long child_index = ::strtol (&var_path[1], &end, 0);
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 (end && *end == ']'
&& *(end-1) != '[') // this code forces an error in the case of arr[]. as bitfield[] is not a good syntax we're good to go
Fixed the "expression" command object to use the StackFrame::GetValueForExpressionPath() function and also hooked up better error reporting for when things fail. Fixed issues with trying to display children of pointers when none are supposed to be shown (no children for function pointers, and more like this). This was causing child value objects to be made that were correctly firing an assertion. llvm-svn: 121841
2010-12-15 13:08:08 +08:00
{
Final bit of type system cleanup that abstracts declaration contexts into lldb_private::CompilerDeclContext and renames ClangType to CompilerType in many accessors and functions. Create a new "lldb_private::CompilerDeclContext" class that will replace all direct uses of "clang::DeclContext" when used in compiler agnostic code, yet still allow for conversion to clang::DeclContext subclasses by clang specific code. This completes the abstraction of type parsing by removing all "clang::" references from the SymbolFileDWARF. The new "lldb_private::CompilerDeclContext" class abstracts decl contexts found in compiler type systems so they can be used in internal API calls. The TypeSystem is required to support CompilerDeclContexts with new pure virtual functions that start with "DeclContext" in the member function names. Converted all code that used lldb_private::ClangNamespaceDecl over to use the new CompilerDeclContext class and removed the ClangNamespaceDecl.cpp and ClangNamespaceDecl.h files. Removed direct use of clang APIs from SBType and now use the abstract type systems to correctly explore types. Bulk renames for things that used to return a ClangASTType which is now CompilerType: "Type::GetClangFullType()" to "Type::GetFullCompilerType()" "Type::GetClangLayoutType()" to "Type::GetLayoutCompilerType()" "Type::GetClangForwardType()" to "Type::GetForwardCompilerType()" "Value::GetClangType()" to "Value::GetCompilerType()" "Value::SetClangType (const CompilerType &)" to "Value::SetCompilerType (const CompilerType &)" "ValueObject::GetClangType ()" to "ValueObject::GetCompilerType()" many more renames that are similar. llvm-svn: 245905
2015-08-25 07:46:31 +08:00
if (valobj_sp->GetCompilerType().IsPointerToScalarType() && deref)
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
{
// what we have is *ptr[low]. the most similar C++ syntax is to deref ptr
// and extract bit low out of it. reading array item low
// would be done by saying ptr[low], without a deref * sign
Error error;
ValueObjectSP temp(valobj_sp->Dereference(error));
if (error.Fail())
{
valobj_sp->GetExpressionPath (var_expr_path_strm, false);
error.SetErrorStringWithFormat ("could not dereference \"(%s) %s\"",
valobj_sp->GetTypeName().AsCString("<invalid type>"),
var_expr_path_strm.GetString().c_str());
return ValueObjectSP();
}
valobj_sp = temp;
deref = false;
}
Final bit of type system cleanup that abstracts declaration contexts into lldb_private::CompilerDeclContext and renames ClangType to CompilerType in many accessors and functions. Create a new "lldb_private::CompilerDeclContext" class that will replace all direct uses of "clang::DeclContext" when used in compiler agnostic code, yet still allow for conversion to clang::DeclContext subclasses by clang specific code. This completes the abstraction of type parsing by removing all "clang::" references from the SymbolFileDWARF. The new "lldb_private::CompilerDeclContext" class abstracts decl contexts found in compiler type systems so they can be used in internal API calls. The TypeSystem is required to support CompilerDeclContexts with new pure virtual functions that start with "DeclContext" in the member function names. Converted all code that used lldb_private::ClangNamespaceDecl over to use the new CompilerDeclContext class and removed the ClangNamespaceDecl.cpp and ClangNamespaceDecl.h files. Removed direct use of clang APIs from SBType and now use the abstract type systems to correctly explore types. Bulk renames for things that used to return a ClangASTType which is now CompilerType: "Type::GetClangFullType()" to "Type::GetFullCompilerType()" "Type::GetClangLayoutType()" to "Type::GetLayoutCompilerType()" "Type::GetClangForwardType()" to "Type::GetForwardCompilerType()" "Value::GetClangType()" to "Value::GetCompilerType()" "Value::SetClangType (const CompilerType &)" to "Value::SetCompilerType (const CompilerType &)" "ValueObject::GetClangType ()" to "ValueObject::GetCompilerType()" many more renames that are similar. llvm-svn: 245905
2015-08-25 07:46:31 +08:00
else if (valobj_sp->GetCompilerType().IsArrayOfScalarType() && deref)
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
{
// what we have is *arr[low]. the most similar C++ syntax is to get arr[0]
// (an operation that is equivalent to deref-ing arr)
// and extract bit low out of it. reading array item low
// would be done by saying arr[low], without a deref * sign
Error error;
ValueObjectSP temp(valobj_sp->GetChildAtIndex (0, true));
if (error.Fail())
{
valobj_sp->GetExpressionPath (var_expr_path_strm, false);
error.SetErrorStringWithFormat ("could not get item 0 for \"(%s) %s\"",
valobj_sp->GetTypeName().AsCString("<invalid type>"),
var_expr_path_strm.GetString().c_str());
return ValueObjectSP();
}
valobj_sp = temp;
deref = false;
}
<rdar://problem/12560257> Fixed zero sized arrays to work correctly. This will only happen once we get a clang that emits correct debug info for zero sized arrays. For now I have marked the TestStructTypes.py as an expected failure. llvm-svn: 169465
2012-12-06 10:33:54 +08:00
bool is_incomplete_array = false;
Fixed the "expression" command object to use the StackFrame::GetValueForExpressionPath() function and also hooked up better error reporting for when things fail. Fixed issues with trying to display children of pointers when none are supposed to be shown (no children for function pointers, and more like this). This was causing child value objects to be made that were correctly firing an assertion. llvm-svn: 121841
2010-12-15 13:08:08 +08:00
if (valobj_sp->IsPointerType ())
{
Updated the revision of LLVM/Clang used by LLDB. This takes two important changes: - Calling blocks is now supported. You need to cast their return values, but that works fine. - We now can correctly run JIT-compiled expressions that use floating-point numbers. Also, we have taken a fix that allows us to ignore access control in Objective-C as in C++. llvm-svn: 152286
2012-03-08 10:39:03 +08:00
bool is_objc_pointer = true;
Final bit of type system cleanup that abstracts declaration contexts into lldb_private::CompilerDeclContext and renames ClangType to CompilerType in many accessors and functions. Create a new "lldb_private::CompilerDeclContext" class that will replace all direct uses of "clang::DeclContext" when used in compiler agnostic code, yet still allow for conversion to clang::DeclContext subclasses by clang specific code. This completes the abstraction of type parsing by removing all "clang::" references from the SymbolFileDWARF. The new "lldb_private::CompilerDeclContext" class abstracts decl contexts found in compiler type systems so they can be used in internal API calls. The TypeSystem is required to support CompilerDeclContexts with new pure virtual functions that start with "DeclContext" in the member function names. Converted all code that used lldb_private::ClangNamespaceDecl over to use the new CompilerDeclContext class and removed the ClangNamespaceDecl.cpp and ClangNamespaceDecl.h files. Removed direct use of clang APIs from SBType and now use the abstract type systems to correctly explore types. Bulk renames for things that used to return a ClangASTType which is now CompilerType: "Type::GetClangFullType()" to "Type::GetFullCompilerType()" "Type::GetClangLayoutType()" to "Type::GetLayoutCompilerType()" "Type::GetClangForwardType()" to "Type::GetForwardCompilerType()" "Value::GetClangType()" to "Value::GetCompilerType()" "Value::SetClangType (const CompilerType &)" to "Value::SetCompilerType (const CompilerType &)" "ValueObject::GetClangType ()" to "ValueObject::GetCompilerType()" many more renames that are similar. llvm-svn: 245905
2015-08-25 07:46:31 +08:00
if (valobj_sp->GetCompilerType().GetMinimumLanguage() != eLanguageTypeObjC)
Updated the revision of LLVM/Clang used by LLDB. This takes two important changes: - Calling blocks is now supported. You need to cast their return values, but that works fine. - We now can correctly run JIT-compiled expressions that use floating-point numbers. Also, we have taken a fix that allows us to ignore access control in Objective-C as in C++. llvm-svn: 152286
2012-03-08 10:39:03 +08:00
is_objc_pointer = false;
Final bit of type system cleanup that abstracts declaration contexts into lldb_private::CompilerDeclContext and renames ClangType to CompilerType in many accessors and functions. Create a new "lldb_private::CompilerDeclContext" class that will replace all direct uses of "clang::DeclContext" when used in compiler agnostic code, yet still allow for conversion to clang::DeclContext subclasses by clang specific code. This completes the abstraction of type parsing by removing all "clang::" references from the SymbolFileDWARF. The new "lldb_private::CompilerDeclContext" class abstracts decl contexts found in compiler type systems so they can be used in internal API calls. The TypeSystem is required to support CompilerDeclContexts with new pure virtual functions that start with "DeclContext" in the member function names. Converted all code that used lldb_private::ClangNamespaceDecl over to use the new CompilerDeclContext class and removed the ClangNamespaceDecl.cpp and ClangNamespaceDecl.h files. Removed direct use of clang APIs from SBType and now use the abstract type systems to correctly explore types. Bulk renames for things that used to return a ClangASTType which is now CompilerType: "Type::GetClangFullType()" to "Type::GetFullCompilerType()" "Type::GetClangLayoutType()" to "Type::GetLayoutCompilerType()" "Type::GetClangForwardType()" to "Type::GetForwardCompilerType()" "Value::GetClangType()" to "Value::GetCompilerType()" "Value::SetClangType (const CompilerType &)" to "Value::SetCompilerType (const CompilerType &)" "ValueObject::GetClangType ()" to "ValueObject::GetCompilerType()" many more renames that are similar. llvm-svn: 245905
2015-08-25 07:46:31 +08:00
else if (!valobj_sp->GetCompilerType().IsPointerType())
Updated the revision of LLVM/Clang used by LLDB. This takes two important changes: - Calling blocks is now supported. You need to cast their return values, but that works fine. - We now can correctly run JIT-compiled expressions that use floating-point numbers. Also, we have taken a fix that allows us to ignore access control in Objective-C as in C++. llvm-svn: 152286
2012-03-08 10:39:03 +08:00
is_objc_pointer = false;
if (no_synth_child && is_objc_pointer)
Fixed the "expression" command object to use the StackFrame::GetValueForExpressionPath() function and also hooked up better error reporting for when things fail. Fixed issues with trying to display children of pointers when none are supposed to be shown (no children for function pointers, and more like this). This was causing child value objects to be made that were correctly firing an assertion. llvm-svn: 121841
2010-12-15 13:08:08 +08:00
{
Updated the revision of LLVM/Clang used by LLDB. This takes two important changes: - Calling blocks is now supported. You need to cast their return values, but that works fine. - We now can correctly run JIT-compiled expressions that use floating-point numbers. Also, we have taken a fix that allows us to ignore access control in Objective-C as in C++. llvm-svn: 152286
2012-03-08 10:39:03 +08:00
error.SetErrorStringWithFormat("\"(%s) %s\" is an Objective-C pointer, and cannot be subscripted",
valobj_sp->GetTypeName().AsCString("<invalid type>"),
var_expr_path_strm.GetString().c_str());
return ValueObjectSP();
}
else if (is_objc_pointer)
{
Basic support for reading synthetic children by index: if your datatype provides synthetic children, "frame variable object[index]" should now do the right thing in cases where the above syntax would have been rejected before, i.e. object is not a pointer nor an array (frame variable ignores potential overload of []) object is a pointer to an Objective-C class (which cannot be dereferenced) expression will still run operator[] if available and complain if it cannot do so synthetic children by name do not work yet llvm-svn: 137097
2011-08-09 09:04:56 +08:00
// dereferencing ObjC variables is not valid.. so let's try and recur to synthetic children
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
ValueObjectSP synthetic = valobj_sp->GetSyntheticValue();
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Target; other minor fixes. llvm-svn: 261242
2016-02-19 02:52:47 +08:00
if (!synthetic /* no synthetic */
Basic support for reading synthetic children by index: if your datatype provides synthetic children, "frame variable object[index]" should now do the right thing in cases where the above syntax would have been rejected before, i.e. object is not a pointer nor an array (frame variable ignores potential overload of []) object is a pointer to an Objective-C class (which cannot be dereferenced) expression will still run operator[] if available and complain if it cannot do so synthetic children by name do not work yet llvm-svn: 137097
2011-08-09 09:04:56 +08:00
|| synthetic == valobj_sp) /* synthetic is the same as the original object */
{
valobj_sp->GetExpressionPath (var_expr_path_strm, false);
error.SetErrorStringWithFormat ("\"(%s) %s\" is not an array type",
valobj_sp->GetTypeName().AsCString("<invalid type>"),
var_expr_path_strm.GetString().c_str());
}
sanitise sign comparisons This is a mechanical change addressing the various sign comparison warnings that are identified by both clang and gcc. This helps cleanup some of the warning spew that occurs during builds. llvm-svn: 205390
2014-04-02 11:51:35 +08:00
else if (static_cast<uint32_t>(child_index) >= synthetic->GetNumChildren() /* synthetic does not have that many values */)
Basic support for reading synthetic children by index: if your datatype provides synthetic children, "frame variable object[index]" should now do the right thing in cases where the above syntax would have been rejected before, i.e. object is not a pointer nor an array (frame variable ignores potential overload of []) object is a pointer to an Objective-C class (which cannot be dereferenced) expression will still run operator[] if available and complain if it cannot do so synthetic children by name do not work yet llvm-svn: 137097
2011-08-09 09:04:56 +08:00
{
valobj_sp->GetExpressionPath (var_expr_path_strm, false);
Change Error::SetErrorStringWithFormat() prototype to use an __attribute__ format so the compiler knows that this method takes printf style formatter arguments and checks that it's being used correctly. Fix a couple dozen incorrect SetErrorStringWithFormat() calls throughout the sources. llvm-svn: 140115
2011-09-20 08:26:08 +08:00
error.SetErrorStringWithFormat ("array index %ld is not valid for \"(%s) %s\"",
Basic support for reading synthetic children by index: if your datatype provides synthetic children, "frame variable object[index]" should now do the right thing in cases where the above syntax would have been rejected before, i.e. object is not a pointer nor an array (frame variable ignores potential overload of []) object is a pointer to an Objective-C class (which cannot be dereferenced) expression will still run operator[] if available and complain if it cannot do so synthetic children by name do not work yet llvm-svn: 137097
2011-08-09 09:04:56 +08:00
child_index,
valobj_sp->GetTypeName().AsCString("<invalid type>"),
var_expr_path_strm.GetString().c_str());
}
else
{
child_valobj_sp = synthetic->GetChildAtIndex(child_index, true);
if (!child_valobj_sp)
{
valobj_sp->GetExpressionPath (var_expr_path_strm, false);
Change Error::SetErrorStringWithFormat() prototype to use an __attribute__ format so the compiler knows that this method takes printf style formatter arguments and checks that it's being used correctly. Fix a couple dozen incorrect SetErrorStringWithFormat() calls throughout the sources. llvm-svn: 140115
2011-09-20 08:26:08 +08:00
error.SetErrorStringWithFormat ("array index %ld is not valid for \"(%s) %s\"",
Basic support for reading synthetic children by index: if your datatype provides synthetic children, "frame variable object[index]" should now do the right thing in cases where the above syntax would have been rejected before, i.e. object is not a pointer nor an array (frame variable ignores potential overload of []) object is a pointer to an Objective-C class (which cannot be dereferenced) expression will still run operator[] if available and complain if it cannot do so synthetic children by name do not work yet llvm-svn: 137097
2011-08-09 09:04:56 +08:00
child_index,
valobj_sp->GetTypeName().AsCString("<invalid type>"),
var_expr_path_strm.GetString().c_str());
}
}
}
else
{
Remove duplicated code for synthetic array members. Summary: The code for GetSyntheticArrayMemberFromPointer and GetSyntheticArrayMemberFromArray was identical, so just collapse the the methods into one. Reviewers: granata.enrico, clayborg Reviewed By: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D7911 llvm-svn: 230708
2015-02-27 07:55:39 +08:00
child_valobj_sp = valobj_sp->GetSyntheticArrayMember (child_index, true);
Basic support for reading synthetic children by index: if your datatype provides synthetic children, "frame variable object[index]" should now do the right thing in cases where the above syntax would have been rejected before, i.e. object is not a pointer nor an array (frame variable ignores potential overload of []) object is a pointer to an Objective-C class (which cannot be dereferenced) expression will still run operator[] if available and complain if it cannot do so synthetic children by name do not work yet llvm-svn: 137097
2011-08-09 09:04:56 +08:00
if (!child_valobj_sp)
{
valobj_sp->GetExpressionPath (var_expr_path_strm, false);
Change Error::SetErrorStringWithFormat() prototype to use an __attribute__ format so the compiler knows that this method takes printf style formatter arguments and checks that it's being used correctly. Fix a couple dozen incorrect SetErrorStringWithFormat() calls throughout the sources. llvm-svn: 140115
2011-09-20 08:26:08 +08:00
error.SetErrorStringWithFormat ("failed to use pointer as array for index %ld for \"(%s) %s\"",
Basic support for reading synthetic children by index: if your datatype provides synthetic children, "frame variable object[index]" should now do the right thing in cases where the above syntax would have been rejected before, i.e. object is not a pointer nor an array (frame variable ignores potential overload of []) object is a pointer to an Objective-C class (which cannot be dereferenced) expression will still run operator[] if available and complain if it cannot do so synthetic children by name do not work yet llvm-svn: 137097
2011-08-09 09:04:56 +08:00
child_index,
valobj_sp->GetTypeName().AsCString("<invalid type>"),
var_expr_path_strm.GetString().c_str());
}
Fixed the "expression" command object to use the StackFrame::GetValueForExpressionPath() function and also hooked up better error reporting for when things fail. Fixed issues with trying to display children of pointers when none are supposed to be shown (no children for function pointers, and more like this). This was causing child value objects to be made that were correctly firing an assertion. llvm-svn: 121841
2010-12-15 13:08:08 +08:00
}
}
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Target; other minor fixes. llvm-svn: 261242
2016-02-19 02:52:47 +08:00
else if (valobj_sp->GetCompilerType().IsArrayType(nullptr, nullptr, &is_incomplete_array))
Fixed the "expression" command object to use the StackFrame::GetValueForExpressionPath() function and also hooked up better error reporting for when things fail. Fixed issues with trying to display children of pointers when none are supposed to be shown (no children for function pointers, and more like this). This was causing child value objects to be made that were correctly firing an assertion. llvm-svn: 121841
2010-12-15 13:08:08 +08:00
{
Add support for "dynamic values" for C++ classes. This currently only works for "frame var" and for the expressions that are simple enough to get passed to the "frame var" underpinnings. The parser code will have to be changed to also query for the dynamic types & offsets as it is looking up variables. The behavior of "frame var" is controlled in two ways. You can pass "-d {true/false} to the frame var command to get the dynamic or static value of the variables you are printing. There's also a general setting: target.prefer-dynamic-value (boolean) = 'true' which is consulted if you call "frame var" without supplying a value for the -d option. llvm-svn: 129623
2011-04-16 08:01:13 +08:00
// Pass false to dynamic_value here so we can tell the difference between
// no dynamic value and no member of this type...
Fixed the "expression" command object to use the StackFrame::GetValueForExpressionPath() function and also hooked up better error reporting for when things fail. Fixed issues with trying to display children of pointers when none are supposed to be shown (no children for function pointers, and more like this). This was causing child value objects to be made that were correctly firing an assertion. llvm-svn: 121841
2010-12-15 13:08:08 +08:00
child_valobj_sp = valobj_sp->GetChildAtIndex (child_index, true);
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Target; other minor fixes. llvm-svn: 261242
2016-02-19 02:52:47 +08:00
if (!child_valobj_sp && (is_incomplete_array || !no_synth_child))
<rdar://problem/12560257> Fixed zero sized arrays to work correctly. This will only happen once we get a clang that emits correct debug info for zero sized arrays. For now I have marked the TestStructTypes.py as an expected failure. llvm-svn: 169465
2012-12-06 10:33:54 +08:00
child_valobj_sp = valobj_sp->GetSyntheticArrayMember (child_index, true);
Fixed the "expression" command object to use the StackFrame::GetValueForExpressionPath() function and also hooked up better error reporting for when things fail. Fixed issues with trying to display children of pointers when none are supposed to be shown (no children for function pointers, and more like this). This was causing child value objects to be made that were correctly firing an assertion. llvm-svn: 121841
2010-12-15 13:08:08 +08:00
if (!child_valobj_sp)
{
A few of the issue I have been trying to track down and fix have been due to the way LLDB lazily gets complete definitions for types within the debug info. When we run across a class/struct/union definition in the DWARF, we will only parse the full definition if we need to. This works fine for top level types that are assigned directly to variables and arguments, but when we have a variable with a class, lets say "A" for this example, that has a member: "B *m_b". Initially we don't need to hunt down a definition for this class unless we are ever asked to do something with it ("expr m_b->getDecl()" for example). With my previous approach to lazy type completion, we would be able to take a "A *a" and get a complete type for it, but we wouldn't be able to then do an "a->m_b->getDecl()" unless we always expanded all types within a class prior to handing out the type. Expanding everything is very costly and it would be great if there were a better way. A few months ago I worked with the llvm/clang folks to have the ExternalASTSource class be able to complete classes if there weren't completed yet: class ExternalASTSource { .... virtual void CompleteType (clang::TagDecl *Tag); virtual void CompleteType (clang::ObjCInterfaceDecl *Class); }; This was great, because we can now have the class that is producing the AST (SymbolFileDWARF and SymbolFileDWARFDebugMap) sign up as external AST sources and the object that creates the forward declaration types can now also complete them anywhere within the clang type system. This patch makes a few major changes: - lldb_private::Module classes now own the AST context. Previously the TypeList objects did. - The DWARF parsers now sign up as an external AST sources so they can complete types. - All of the pure clang type system wrapper code we have in LLDB (ClangASTContext, ClangASTType, and more) can now be iterating through children of any type, and if a class/union/struct type (clang::RecordType or ObjC interface) is found that is incomplete, we can ask the AST to get the definition. - The SymbolFileDWARFDebugMap class now will create and use a single AST that all child SymbolFileDWARF classes will share (much like what happens when we have a complete linked DWARF for an executable). We will need to modify some of the ClangUserExpression code to take more advantage of this completion ability in the near future. Meanwhile we should be better off now that we can be accessing any children of variables through pointers and always be able to resolve the clang type if needed. llvm-svn: 123613
2011-01-17 11:46:26 +08:00
valobj_sp->GetExpressionPath (var_expr_path_strm, false);
Change Error::SetErrorStringWithFormat() prototype to use an __attribute__ format so the compiler knows that this method takes printf style formatter arguments and checks that it's being used correctly. Fix a couple dozen incorrect SetErrorStringWithFormat() calls throughout the sources. llvm-svn: 140115
2011-09-20 08:26:08 +08:00
error.SetErrorStringWithFormat ("array index %ld is not valid for \"(%s) %s\"",
Fixed the "expression" command object to use the StackFrame::GetValueForExpressionPath() function and also hooked up better error reporting for when things fail. Fixed issues with trying to display children of pointers when none are supposed to be shown (no children for function pointers, and more like this). This was causing child value objects to be made that were correctly firing an assertion. llvm-svn: 121841
2010-12-15 13:08:08 +08:00
child_index,
valobj_sp->GetTypeName().AsCString("<invalid type>"),
var_expr_path_strm.GetString().c_str());
}
}
Final bit of type system cleanup that abstracts declaration contexts into lldb_private::CompilerDeclContext and renames ClangType to CompilerType in many accessors and functions. Create a new "lldb_private::CompilerDeclContext" class that will replace all direct uses of "clang::DeclContext" when used in compiler agnostic code, yet still allow for conversion to clang::DeclContext subclasses by clang specific code. This completes the abstraction of type parsing by removing all "clang::" references from the SymbolFileDWARF. The new "lldb_private::CompilerDeclContext" class abstracts decl contexts found in compiler type systems so they can be used in internal API calls. The TypeSystem is required to support CompilerDeclContexts with new pure virtual functions that start with "DeclContext" in the member function names. Converted all code that used lldb_private::ClangNamespaceDecl over to use the new CompilerDeclContext class and removed the ClangNamespaceDecl.cpp and ClangNamespaceDecl.h files. Removed direct use of clang APIs from SBType and now use the abstract type systems to correctly explore types. Bulk renames for things that used to return a ClangASTType which is now CompilerType: "Type::GetClangFullType()" to "Type::GetFullCompilerType()" "Type::GetClangLayoutType()" to "Type::GetLayoutCompilerType()" "Type::GetClangForwardType()" to "Type::GetForwardCompilerType()" "Value::GetClangType()" to "Value::GetCompilerType()" "Value::SetClangType (const CompilerType &)" to "Value::SetCompilerType (const CompilerType &)" "ValueObject::GetClangType ()" to "ValueObject::GetCompilerType()" many more renames that are similar. llvm-svn: 245905
2015-08-25 07:46:31 +08:00
else if (valobj_sp->GetCompilerType().IsScalarType())
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 is a bitfield asking to display just one bit
child_valobj_sp = valobj_sp->GetSyntheticBitFieldChild(child_index, child_index, true);
if (!child_valobj_sp)
{
valobj_sp->GetExpressionPath (var_expr_path_strm, false);
Change Error::SetErrorStringWithFormat() prototype to use an __attribute__ format so the compiler knows that this method takes printf style formatter arguments and checks that it's being used correctly. Fix a couple dozen incorrect SetErrorStringWithFormat() calls throughout the sources. llvm-svn: 140115
2011-09-20 08:26:08 +08:00
error.SetErrorStringWithFormat ("bitfield range %ld-%ld is not valid for \"(%s) %s\"",
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
child_index, child_index,
valobj_sp->GetTypeName().AsCString("<invalid type>"),
var_expr_path_strm.GetString().c_str());
}
}
Fixed the "expression" command object to use the StackFrame::GetValueForExpressionPath() function and also hooked up better error reporting for when things fail. Fixed issues with trying to display children of pointers when none are supposed to be shown (no children for function pointers, and more like this). This was causing child value objects to be made that were correctly firing an assertion. llvm-svn: 121841
2010-12-15 13:08:08 +08:00
else
{
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
ValueObjectSP synthetic = valobj_sp->GetSyntheticValue();
Basic support for reading synthetic children by index: if your datatype provides synthetic children, "frame variable object[index]" should now do the right thing in cases where the above syntax would have been rejected before, i.e. object is not a pointer nor an array (frame variable ignores potential overload of []) object is a pointer to an Objective-C class (which cannot be dereferenced) expression will still run operator[] if available and complain if it cannot do so synthetic children by name do not work yet llvm-svn: 137097
2011-08-09 09:04:56 +08:00
if (no_synth_child /* synthetic is forbidden */ ||
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Target; other minor fixes. llvm-svn: 261242
2016-02-19 02:52:47 +08:00
!synthetic /* no synthetic */
Basic support for reading synthetic children by index: if your datatype provides synthetic children, "frame variable object[index]" should now do the right thing in cases where the above syntax would have been rejected before, i.e. object is not a pointer nor an array (frame variable ignores potential overload of []) object is a pointer to an Objective-C class (which cannot be dereferenced) expression will still run operator[] if available and complain if it cannot do so synthetic children by name do not work yet llvm-svn: 137097
2011-08-09 09:04:56 +08:00
|| synthetic == valobj_sp) /* synthetic is the same as the original object */
{
valobj_sp->GetExpressionPath (var_expr_path_strm, false);
error.SetErrorStringWithFormat ("\"(%s) %s\" is not an array type",
valobj_sp->GetTypeName().AsCString("<invalid type>"),
var_expr_path_strm.GetString().c_str());
}
sanitise sign comparisons This is a mechanical change addressing the various sign comparison warnings that are identified by both clang and gcc. This helps cleanup some of the warning spew that occurs during builds. llvm-svn: 205390
2014-04-02 11:51:35 +08:00
else if (static_cast<uint32_t>(child_index) >= synthetic->GetNumChildren() /* synthetic does not have that many values */)
Basic support for reading synthetic children by index: if your datatype provides synthetic children, "frame variable object[index]" should now do the right thing in cases where the above syntax would have been rejected before, i.e. object is not a pointer nor an array (frame variable ignores potential overload of []) object is a pointer to an Objective-C class (which cannot be dereferenced) expression will still run operator[] if available and complain if it cannot do so synthetic children by name do not work yet llvm-svn: 137097
2011-08-09 09:04:56 +08:00
{
valobj_sp->GetExpressionPath (var_expr_path_strm, false);
Change Error::SetErrorStringWithFormat() prototype to use an __attribute__ format so the compiler knows that this method takes printf style formatter arguments and checks that it's being used correctly. Fix a couple dozen incorrect SetErrorStringWithFormat() calls throughout the sources. llvm-svn: 140115
2011-09-20 08:26:08 +08:00
error.SetErrorStringWithFormat ("array index %ld is not valid for \"(%s) %s\"",
Basic support for reading synthetic children by index: if your datatype provides synthetic children, "frame variable object[index]" should now do the right thing in cases where the above syntax would have been rejected before, i.e. object is not a pointer nor an array (frame variable ignores potential overload of []) object is a pointer to an Objective-C class (which cannot be dereferenced) expression will still run operator[] if available and complain if it cannot do so synthetic children by name do not work yet llvm-svn: 137097
2011-08-09 09:04:56 +08:00
child_index,
valobj_sp->GetTypeName().AsCString("<invalid type>"),
var_expr_path_strm.GetString().c_str());
}
else
{
child_valobj_sp = synthetic->GetChildAtIndex(child_index, true);
if (!child_valobj_sp)
{
valobj_sp->GetExpressionPath (var_expr_path_strm, false);
Change Error::SetErrorStringWithFormat() prototype to use an __attribute__ format so the compiler knows that this method takes printf style formatter arguments and checks that it's being used correctly. Fix a couple dozen incorrect SetErrorStringWithFormat() calls throughout the sources. llvm-svn: 140115
2011-09-20 08:26:08 +08:00
error.SetErrorStringWithFormat ("array index %ld is not valid for \"(%s) %s\"",
Basic support for reading synthetic children by index: if your datatype provides synthetic children, "frame variable object[index]" should now do the right thing in cases where the above syntax would have been rejected before, i.e. object is not a pointer nor an array (frame variable ignores potential overload of []) object is a pointer to an Objective-C class (which cannot be dereferenced) expression will still run operator[] if available and complain if it cannot do so synthetic children by name do not work yet llvm-svn: 137097
2011-08-09 09:04:56 +08:00
child_index,
valobj_sp->GetTypeName().AsCString("<invalid type>"),
var_expr_path_strm.GetString().c_str());
}
}
Fixed the "expression" command object to use the StackFrame::GetValueForExpressionPath() function and also hooked up better error reporting for when things fail. Fixed issues with trying to display children of pointers when none are supposed to be shown (no children for function pointers, and more like this). This was causing child value objects to be made that were correctly firing an assertion. llvm-svn: 121841
2010-12-15 13:08:08 +08:00
}
if (!child_valobj_sp)
{
// Invalid array index...
return ValueObjectSP();
}
// Erase the array member specification '[%i]' where
// %i is the array index
var_path.erase(0, (end - var_path.c_str()) + 1);
separator_idx = var_path.find_first_of(".-[");
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
if (use_dynamic != eNoDynamicValues)
Add support for "dynamic values" for C++ classes. This currently only works for "frame var" and for the expressions that are simple enough to get passed to the "frame var" underpinnings. The parser code will have to be changed to also query for the dynamic types & offsets as it is looking up variables. The behavior of "frame var" is controlled in two ways. You can pass "-d {true/false} to the frame var command to get the dynamic or static value of the variables you are printing. There's also a general setting: target.prefer-dynamic-value (boolean) = 'true' which is consulted if you call "frame var" without supplying a value for the -d option. llvm-svn: 129623
2011-04-16 08:01:13 +08:00
{
Change "frame var" over to using OptionGroups (and thus the OptionGroupVariableObjectDisplay). Change the boolean "use_dynamic" over to a tri-state, no-dynamic, dynamic-w/o running target, and dynamic with running target. llvm-svn: 130832
2011-05-04 11:43:18 +08:00
ValueObjectSP dynamic_value_sp(child_valobj_sp->GetDynamicValue(use_dynamic));
Add support for "dynamic values" for C++ classes. This currently only works for "frame var" and for the expressions that are simple enough to get passed to the "frame var" underpinnings. The parser code will have to be changed to also query for the dynamic types & offsets as it is looking up variables. The behavior of "frame var" is controlled in two ways. You can pass "-d {true/false} to the frame var command to get the dynamic or static value of the variables you are printing. There's also a general setting: target.prefer-dynamic-value (boolean) = 'true' which is consulted if you call "frame var" without supplying a value for the -d option. llvm-svn: 129623
2011-04-16 08:01:13 +08:00
if (dynamic_value_sp)
child_valobj_sp = dynamic_value_sp;
}
Fixed the "expression" command object to use the StackFrame::GetValueForExpressionPath() function and also hooked up better error reporting for when things fail. Fixed issues with trying to display children of pointers when none are supposed to be shown (no children for function pointers, and more like this). This was causing child value objects to be made that were correctly firing an assertion. llvm-svn: 121841
2010-12-15 13:08:08 +08:00
// Break out early from the switch since we were
// able to find the child member
break;
}
The implementation of categories is now synchronization safe Code cleanup: - The Format Manager implementation is now split between two files: FormatClasses.{h|cpp} where the actual formatter classes (ValueFormat, SummaryFormat, ...) are implemented and FormatManager.{h|cpp} where the infrastructure classes (FormatNavigator, FormatManager, ...) are contained. The wrapper code always remains in Debugger.{h|cpp} - Several leftover fields, methods and comments from previous design choices have been removed type category subcommands (enable, disable, delete) now can take a list of category names as input - for type category enable, saying "enable A B C" is the same as saying enable C enable B enable A (the ordering is relevant in enabling categories, and it is expected that a user typing enable A B C wants to look into category A, then into B, then into C and not the other way round) - for the other two commands, the order is not really relevant (however, the same inverted ordering is used for consistency) llvm-svn: 135494
2011-07-20 02:03:25 +08:00
else if (end && *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
{
// this is most probably a BitField, let's take a look
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Target; other minor fixes. llvm-svn: 261242
2016-02-19 02:52:47 +08:00
char *real_end = nullptr;
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
long final_index = ::strtol (end+1, &real_end, 0);
- 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
bool expand_bitfield = true;
The implementation of categories is now synchronization safe Code cleanup: - The Format Manager implementation is now split between two files: FormatClasses.{h|cpp} where the actual formatter classes (ValueFormat, SummaryFormat, ...) are implemented and FormatManager.{h|cpp} where the infrastructure classes (FormatNavigator, FormatManager, ...) are contained. The wrapper code always remains in Debugger.{h|cpp} - Several leftover fields, methods and comments from previous design choices have been removed type category subcommands (enable, disable, delete) now can take a list of category names as input - for type category enable, saying "enable A B C" is the same as saying enable C enable B enable A (the ordering is relevant in enabling categories, and it is expected that a user typing enable A B C wants to look into category A, then into B, then into C and not the other way round) - for the other two commands, the order is not really relevant (however, the same inverted ordering is used for consistency) llvm-svn: 135494
2011-07-20 02:03:25 +08:00
if (real_end && *real_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
{
// if the format given is [high-low], swap range
The implementation of categories is now synchronization safe Code cleanup: - The Format Manager implementation is now split between two files: FormatClasses.{h|cpp} where the actual formatter classes (ValueFormat, SummaryFormat, ...) are implemented and FormatManager.{h|cpp} where the infrastructure classes (FormatNavigator, FormatManager, ...) are contained. The wrapper code always remains in Debugger.{h|cpp} - Several leftover fields, methods and comments from previous design choices have been removed type category subcommands (enable, disable, delete) now can take a list of category names as input - for type category enable, saying "enable A B C" is the same as saying enable C enable B enable A (the ordering is relevant in enabling categories, and it is expected that a user typing enable A B C wants to look into category A, then into B, then into C and not the other way round) - for the other two commands, the order is not really relevant (however, the same inverted ordering is used for consistency) llvm-svn: 135494
2011-07-20 02:03:25 +08:00
if (child_index > final_index)
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
{
long temp = child_index;
child_index = final_index;
final_index = temp;
}
Final bit of type system cleanup that abstracts declaration contexts into lldb_private::CompilerDeclContext and renames ClangType to CompilerType in many accessors and functions. Create a new "lldb_private::CompilerDeclContext" class that will replace all direct uses of "clang::DeclContext" when used in compiler agnostic code, yet still allow for conversion to clang::DeclContext subclasses by clang specific code. This completes the abstraction of type parsing by removing all "clang::" references from the SymbolFileDWARF. The new "lldb_private::CompilerDeclContext" class abstracts decl contexts found in compiler type systems so they can be used in internal API calls. The TypeSystem is required to support CompilerDeclContexts with new pure virtual functions that start with "DeclContext" in the member function names. Converted all code that used lldb_private::ClangNamespaceDecl over to use the new CompilerDeclContext class and removed the ClangNamespaceDecl.cpp and ClangNamespaceDecl.h files. Removed direct use of clang APIs from SBType and now use the abstract type systems to correctly explore types. Bulk renames for things that used to return a ClangASTType which is now CompilerType: "Type::GetClangFullType()" to "Type::GetFullCompilerType()" "Type::GetClangLayoutType()" to "Type::GetLayoutCompilerType()" "Type::GetClangForwardType()" to "Type::GetForwardCompilerType()" "Value::GetClangType()" to "Value::GetCompilerType()" "Value::SetClangType (const CompilerType &)" to "Value::SetCompilerType (const CompilerType &)" "ValueObject::GetClangType ()" to "ValueObject::GetCompilerType()" many more renames that are similar. llvm-svn: 245905
2015-08-25 07:46:31 +08:00
if (valobj_sp->GetCompilerType().IsPointerToScalarType() && deref)
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
{
// what we have is *ptr[low-high]. the most similar C++ syntax is to deref ptr
// and extract bits low thru high out of it. reading array items low thru high
// would be done by saying ptr[low-high], without a deref * sign
Error error;
ValueObjectSP temp(valobj_sp->Dereference(error));
if (error.Fail())
{
valobj_sp->GetExpressionPath (var_expr_path_strm, false);
error.SetErrorStringWithFormat ("could not dereference \"(%s) %s\"",
valobj_sp->GetTypeName().AsCString("<invalid type>"),
var_expr_path_strm.GetString().c_str());
return ValueObjectSP();
}
valobj_sp = temp;
deref = false;
}
Final bit of type system cleanup that abstracts declaration contexts into lldb_private::CompilerDeclContext and renames ClangType to CompilerType in many accessors and functions. Create a new "lldb_private::CompilerDeclContext" class that will replace all direct uses of "clang::DeclContext" when used in compiler agnostic code, yet still allow for conversion to clang::DeclContext subclasses by clang specific code. This completes the abstraction of type parsing by removing all "clang::" references from the SymbolFileDWARF. The new "lldb_private::CompilerDeclContext" class abstracts decl contexts found in compiler type systems so they can be used in internal API calls. The TypeSystem is required to support CompilerDeclContexts with new pure virtual functions that start with "DeclContext" in the member function names. Converted all code that used lldb_private::ClangNamespaceDecl over to use the new CompilerDeclContext class and removed the ClangNamespaceDecl.cpp and ClangNamespaceDecl.h files. Removed direct use of clang APIs from SBType and now use the abstract type systems to correctly explore types. Bulk renames for things that used to return a ClangASTType which is now CompilerType: "Type::GetClangFullType()" to "Type::GetFullCompilerType()" "Type::GetClangLayoutType()" to "Type::GetLayoutCompilerType()" "Type::GetClangForwardType()" to "Type::GetForwardCompilerType()" "Value::GetClangType()" to "Value::GetCompilerType()" "Value::SetClangType (const CompilerType &)" to "Value::SetCompilerType (const CompilerType &)" "ValueObject::GetClangType ()" to "ValueObject::GetCompilerType()" many more renames that are similar. llvm-svn: 245905
2015-08-25 07:46:31 +08:00
else if (valobj_sp->GetCompilerType().IsArrayOfScalarType() && deref)
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
{
// what we have is *arr[low-high]. the most similar C++ syntax is to get arr[0]
// (an operation that is equivalent to deref-ing arr)
// and extract bits low thru high out of it. reading array items low thru high
// would be done by saying arr[low-high], without a deref * sign
Error error;
ValueObjectSP temp(valobj_sp->GetChildAtIndex (0, true));
if (error.Fail())
{
valobj_sp->GetExpressionPath (var_expr_path_strm, false);
error.SetErrorStringWithFormat ("could not get item 0 for \"(%s) %s\"",
valobj_sp->GetTypeName().AsCString("<invalid type>"),
var_expr_path_strm.GetString().c_str());
return ValueObjectSP();
}
valobj_sp = temp;
deref = false;
}
- 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 (valobj_sp->IsArrayType() || valobj_sp->IsPointerType())
{
child_valobj_sp = valobj_sp->GetSyntheticArrayRangeChild(child_index, final_index, true);
expand_bitfield = false;
if (!child_valobj_sp)
{
valobj_sp->GetExpressionPath (var_expr_path_strm, false);
error.SetErrorStringWithFormat ("array range %i-%i is not valid for \"(%s) %s\"",
child_index, final_index,
valobj_sp->GetTypeName().AsCString("<invalid type>"),
var_expr_path_strm.GetString().c_str());
}
}*/
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
- 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 (expand_bitfield)
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
{
- 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
child_valobj_sp = valobj_sp->GetSyntheticBitFieldChild(child_index, final_index, true);
if (!child_valobj_sp)
{
valobj_sp->GetExpressionPath (var_expr_path_strm, false);
Change Error::SetErrorStringWithFormat() prototype to use an __attribute__ format so the compiler knows that this method takes printf style formatter arguments and checks that it's being used correctly. Fix a couple dozen incorrect SetErrorStringWithFormat() calls throughout the sources. llvm-svn: 140115
2011-09-20 08:26:08 +08:00
error.SetErrorStringWithFormat ("bitfield range %ld-%ld is not valid for \"(%s) %s\"",
- 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
child_index, final_index,
valobj_sp->GetTypeName().AsCString("<invalid type>"),
var_expr_path_strm.GetString().c_str());
}
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 (!child_valobj_sp)
{
// Invalid bitfield range...
return ValueObjectSP();
}
// Erase the bitfield member specification '[%i-%i]' where
// %i is the index
var_path.erase(0, (real_end - var_path.c_str()) + 1);
separator_idx = var_path.find_first_of(".-[");
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
if (use_dynamic != eNoDynamicValues)
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
{
ValueObjectSP dynamic_value_sp(child_valobj_sp->GetDynamicValue(use_dynamic));
if (dynamic_value_sp)
child_valobj_sp = dynamic_value_sp;
}
// Break out early from the switch since we were
// able to find the child member
break;
}
}
else
{
error.SetErrorStringWithFormat("invalid square bracket encountered after \"%s\" in \"%s\"",
var_expr_path_strm.GetString().c_str(),
var_path.c_str());
Modified LLDB expressions to not have to JIT and run code just to see variable values or persistent expression variables. Now if an expression consists of a value that is a child of a variable, or of a persistent variable only, we will create a value object for it and make a ValueObjectConstResult from it to freeze the value (for program variables only, not persistent variables) and avoid running JITed code. For everything else we still parse up and JIT code and run it in the inferior. There was also a lot of clean up in the expression code. I made the ClangExpressionVariables be stored in collections of shared pointers instead of in collections of objects. This will help stop a lot of copy constructors on these large objects and also cleans up the code considerably. The persistent clang expression variables were moved over to the Target to ensure they persist across process executions. Added the ability for lldb_private::Target objects to evaluate expressions. We want to evaluate expressions at the target level in case we aren't running yet, or we have just completed running. We still want to be able to access the persistent expression variables between runs, and also evaluate constant expressions. Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects can now dump their contents with the UUID, arch and full paths being logged with appropriate prefix values. Thread hardened the Communication class a bit by making the connection auto_ptr member into a shared pointer member and then making a local copy of the shared pointer in each method that uses it to make sure another thread can't nuke the connection object while it is being used by another thread. Added a new file to the lldb/test/load_unload test that causes the test a.out file to link to the libd.dylib file all the time. This will allow us to test using the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else. llvm-svn: 121745
2010-12-14 10:59:59 +08:00
}
Fixed the "expression" command object to use the StackFrame::GetValueForExpressionPath() function and also hooked up better error reporting for when things fail. Fixed issues with trying to display children of pointers when none are supposed to be shown (no children for function pointers, and more like this). This was causing child value objects to be made that were correctly firing an assertion. llvm-svn: 121841
2010-12-15 13:08:08 +08:00
return ValueObjectSP();
Modified LLDB expressions to not have to JIT and run code just to see variable values or persistent expression variables. Now if an expression consists of a value that is a child of a variable, or of a persistent variable only, we will create a value object for it and make a ValueObjectConstResult from it to freeze the value (for program variables only, not persistent variables) and avoid running JITed code. For everything else we still parse up and JIT code and run it in the inferior. There was also a lot of clean up in the expression code. I made the ClangExpressionVariables be stored in collections of shared pointers instead of in collections of objects. This will help stop a lot of copy constructors on these large objects and also cleans up the code considerably. The persistent clang expression variables were moved over to the Target to ensure they persist across process executions. Added the ability for lldb_private::Target objects to evaluate expressions. We want to evaluate expressions at the target level in case we aren't running yet, or we have just completed running. We still want to be able to access the persistent expression variables between runs, and also evaluate constant expressions. Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects can now dump their contents with the UUID, arch and full paths being logged with appropriate prefix values. Thread hardened the Communication class a bit by making the connection auto_ptr member into a shared pointer member and then making a local copy of the shared pointer in each method that uses it to make sure another thread can't nuke the connection object while it is being used by another thread. Added a new file to the lldb/test/load_unload test that causes the test a.out file to link to the libd.dylib file all the time. This will allow us to test using the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else. llvm-svn: 121745
2010-12-14 10:59:59 +08:00
Fixed the "expression" command object to use the StackFrame::GetValueForExpressionPath() function and also hooked up better error reporting for when things fail. Fixed issues with trying to display children of pointers when none are supposed to be shown (no children for function pointers, and more like this). This was causing child value objects to be made that were correctly firing an assertion. llvm-svn: 121841
2010-12-15 13:08:08 +08:00
default:
// Failure...
{
A few of the issue I have been trying to track down and fix have been due to the way LLDB lazily gets complete definitions for types within the debug info. When we run across a class/struct/union definition in the DWARF, we will only parse the full definition if we need to. This works fine for top level types that are assigned directly to variables and arguments, but when we have a variable with a class, lets say "A" for this example, that has a member: "B *m_b". Initially we don't need to hunt down a definition for this class unless we are ever asked to do something with it ("expr m_b->getDecl()" for example). With my previous approach to lazy type completion, we would be able to take a "A *a" and get a complete type for it, but we wouldn't be able to then do an "a->m_b->getDecl()" unless we always expanded all types within a class prior to handing out the type. Expanding everything is very costly and it would be great if there were a better way. A few months ago I worked with the llvm/clang folks to have the ExternalASTSource class be able to complete classes if there weren't completed yet: class ExternalASTSource { .... virtual void CompleteType (clang::TagDecl *Tag); virtual void CompleteType (clang::ObjCInterfaceDecl *Class); }; This was great, because we can now have the class that is producing the AST (SymbolFileDWARF and SymbolFileDWARFDebugMap) sign up as external AST sources and the object that creates the forward declaration types can now also complete them anywhere within the clang type system. This patch makes a few major changes: - lldb_private::Module classes now own the AST context. Previously the TypeList objects did. - The DWARF parsers now sign up as an external AST sources so they can complete types. - All of the pure clang type system wrapper code we have in LLDB (ClangASTContext, ClangASTType, and more) can now be iterating through children of any type, and if a class/union/struct type (clang::RecordType or ObjC interface) is found that is incomplete, we can ask the AST to get the definition. - The SymbolFileDWARFDebugMap class now will create and use a single AST that all child SymbolFileDWARF classes will share (much like what happens when we have a complete linked DWARF for an executable). We will need to modify some of the ClangUserExpression code to take more advantage of this completion ability in the near future. Meanwhile we should be better off now that we can be accessing any children of variables through pointers and always be able to resolve the clang type if needed. llvm-svn: 123613
2011-01-17 11:46:26 +08:00
valobj_sp->GetExpressionPath (var_expr_path_strm, false);
Fixed the "expression" command object to use the StackFrame::GetValueForExpressionPath() function and also hooked up better error reporting for when things fail. Fixed issues with trying to display children of pointers when none are supposed to be shown (no children for function pointers, and more like this). This was causing child value objects to be made that were correctly firing an assertion. llvm-svn: 121841
2010-12-15 13:08:08 +08:00
error.SetErrorStringWithFormat ("unexpected char '%c' encountered after \"%s\" in \"%s\"",
separator_type,
var_expr_path_strm.GetString().c_str(),
var_path.c_str());
return ValueObjectSP();
}
}
Modified LLDB expressions to not have to JIT and run code just to see variable values or persistent expression variables. Now if an expression consists of a value that is a child of a variable, or of a persistent variable only, we will create a value object for it and make a ValueObjectConstResult from it to freeze the value (for program variables only, not persistent variables) and avoid running JITed code. For everything else we still parse up and JIT code and run it in the inferior. There was also a lot of clean up in the expression code. I made the ClangExpressionVariables be stored in collections of shared pointers instead of in collections of objects. This will help stop a lot of copy constructors on these large objects and also cleans up the code considerably. The persistent clang expression variables were moved over to the Target to ensure they persist across process executions. Added the ability for lldb_private::Target objects to evaluate expressions. We want to evaluate expressions at the target level in case we aren't running yet, or we have just completed running. We still want to be able to access the persistent expression variables between runs, and also evaluate constant expressions. Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects can now dump their contents with the UUID, arch and full paths being logged with appropriate prefix values. Thread hardened the Communication class a bit by making the connection auto_ptr member into a shared pointer member and then making a local copy of the shared pointer in each method that uses it to make sure another thread can't nuke the connection object while it is being used by another thread. Added a new file to the lldb/test/load_unload test that causes the test a.out file to link to the libd.dylib file all the time. This will allow us to test using the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else. llvm-svn: 121745
2010-12-14 10:59:59 +08:00
Fixed the "expression" command object to use the StackFrame::GetValueForExpressionPath() function and also hooked up better error reporting for when things fail. Fixed issues with trying to display children of pointers when none are supposed to be shown (no children for function pointers, and more like this). This was causing child value objects to be made that were correctly firing an assertion. llvm-svn: 121841
2010-12-15 13:08:08 +08:00
if (child_valobj_sp)
valobj_sp = child_valobj_sp;
Modified LLDB expressions to not have to JIT and run code just to see variable values or persistent expression variables. Now if an expression consists of a value that is a child of a variable, or of a persistent variable only, we will create a value object for it and make a ValueObjectConstResult from it to freeze the value (for program variables only, not persistent variables) and avoid running JITed code. For everything else we still parse up and JIT code and run it in the inferior. There was also a lot of clean up in the expression code. I made the ClangExpressionVariables be stored in collections of shared pointers instead of in collections of objects. This will help stop a lot of copy constructors on these large objects and also cleans up the code considerably. The persistent clang expression variables were moved over to the Target to ensure they persist across process executions. Added the ability for lldb_private::Target objects to evaluate expressions. We want to evaluate expressions at the target level in case we aren't running yet, or we have just completed running. We still want to be able to access the persistent expression variables between runs, and also evaluate constant expressions. Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects can now dump their contents with the UUID, arch and full paths being logged with appropriate prefix values. Thread hardened the Communication class a bit by making the connection auto_ptr member into a shared pointer member and then making a local copy of the shared pointer in each method that uses it to make sure another thread can't nuke the connection object while it is being used by another thread. Added a new file to the lldb/test/load_unload test that causes the test a.out file to link to the libd.dylib file all the time. This will allow us to test using the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else. llvm-svn: 121745
2010-12-14 10:59:59 +08:00
Fixed the "expression" command object to use the StackFrame::GetValueForExpressionPath() function and also hooked up better error reporting for when things fail. Fixed issues with trying to display children of pointers when none are supposed to be shown (no children for function pointers, and more like this). This was causing child value objects to be made that were correctly firing an assertion. llvm-svn: 121841
2010-12-15 13:08:08 +08:00
if (var_path.empty())
break;
Modified LLDB expressions to not have to JIT and run code just to see variable values or persistent expression variables. Now if an expression consists of a value that is a child of a variable, or of a persistent variable only, we will create a value object for it and make a ValueObjectConstResult from it to freeze the value (for program variables only, not persistent variables) and avoid running JITed code. For everything else we still parse up and JIT code and run it in the inferior. There was also a lot of clean up in the expression code. I made the ClangExpressionVariables be stored in collections of shared pointers instead of in collections of objects. This will help stop a lot of copy constructors on these large objects and also cleans up the code considerably. The persistent clang expression variables were moved over to the Target to ensure they persist across process executions. Added the ability for lldb_private::Target objects to evaluate expressions. We want to evaluate expressions at the target level in case we aren't running yet, or we have just completed running. We still want to be able to access the persistent expression variables between runs, and also evaluate constant expressions. Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects can now dump their contents with the UUID, arch and full paths being logged with appropriate prefix values. Thread hardened the Communication class a bit by making the connection auto_ptr member into a shared pointer member and then making a local copy of the shared pointer in each method that uses it to make sure another thread can't nuke the connection object while it is being used by another thread. Added a new file to the lldb/test/load_unload test that causes the test a.out file to link to the libd.dylib file all the time. This will allow us to test using the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else. llvm-svn: 121745
2010-12-14 10:59:59 +08:00
}
Fixed the "expression" command object to use the StackFrame::GetValueForExpressionPath() function and also hooked up better error reporting for when things fail. Fixed issues with trying to display children of pointers when none are supposed to be shown (no children for function pointers, and more like this). This was causing child value objects to be made that were correctly firing an assertion. llvm-svn: 121841
2010-12-15 13:08:08 +08:00
if (valobj_sp)
Modified LLDB expressions to not have to JIT and run code just to see variable values or persistent expression variables. Now if an expression consists of a value that is a child of a variable, or of a persistent variable only, we will create a value object for it and make a ValueObjectConstResult from it to freeze the value (for program variables only, not persistent variables) and avoid running JITed code. For everything else we still parse up and JIT code and run it in the inferior. There was also a lot of clean up in the expression code. I made the ClangExpressionVariables be stored in collections of shared pointers instead of in collections of objects. This will help stop a lot of copy constructors on these large objects and also cleans up the code considerably. The persistent clang expression variables were moved over to the Target to ensure they persist across process executions. Added the ability for lldb_private::Target objects to evaluate expressions. We want to evaluate expressions at the target level in case we aren't running yet, or we have just completed running. We still want to be able to access the persistent expression variables between runs, and also evaluate constant expressions. Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects can now dump their contents with the UUID, arch and full paths being logged with appropriate prefix values. Thread hardened the Communication class a bit by making the connection auto_ptr member into a shared pointer member and then making a local copy of the shared pointer in each method that uses it to make sure another thread can't nuke the connection object while it is being used by another thread. Added a new file to the lldb/test/load_unload test that causes the test a.out file to link to the libd.dylib file all the time. This will allow us to test using the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else. llvm-svn: 121745
2010-12-14 10:59:59 +08:00
{
Fixed the "expression" command object to use the StackFrame::GetValueForExpressionPath() function and also hooked up better error reporting for when things fail. Fixed issues with trying to display children of pointers when none are supposed to be shown (no children for function pointers, and more like this). This was causing child value objects to be made that were correctly firing an assertion. llvm-svn: 121841
2010-12-15 13:08:08 +08:00
if (deref)
{
The LLDB API (lldb::SB*) is now thread safe! llvm-svn: 122262
2010-12-21 04:49:23 +08:00
ValueObjectSP deref_valobj_sp (valobj_sp->Dereference(error));
Fixed the "expression" command object to use the StackFrame::GetValueForExpressionPath() function and also hooked up better error reporting for when things fail. Fixed issues with trying to display children of pointers when none are supposed to be shown (no children for function pointers, and more like this). This was causing child value objects to be made that were correctly firing an assertion. llvm-svn: 121841
2010-12-15 13:08:08 +08:00
valobj_sp = deref_valobj_sp;
}
else if (address_of)
{
ValueObjectSP address_of_valobj_sp (valobj_sp->AddressOf(error));
valobj_sp = address_of_valobj_sp;
}
Modified LLDB expressions to not have to JIT and run code just to see variable values or persistent expression variables. Now if an expression consists of a value that is a child of a variable, or of a persistent variable only, we will create a value object for it and make a ValueObjectConstResult from it to freeze the value (for program variables only, not persistent variables) and avoid running JITed code. For everything else we still parse up and JIT code and run it in the inferior. There was also a lot of clean up in the expression code. I made the ClangExpressionVariables be stored in collections of shared pointers instead of in collections of objects. This will help stop a lot of copy constructors on these large objects and also cleans up the code considerably. The persistent clang expression variables were moved over to the Target to ensure they persist across process executions. Added the ability for lldb_private::Target objects to evaluate expressions. We want to evaluate expressions at the target level in case we aren't running yet, or we have just completed running. We still want to be able to access the persistent expression variables between runs, and also evaluate constant expressions. Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects can now dump their contents with the UUID, arch and full paths being logged with appropriate prefix values. Thread hardened the Communication class a bit by making the connection auto_ptr member into a shared pointer member and then making a local copy of the shared pointer in each method that uses it to make sure another thread can't nuke the connection object while it is being used by another thread. Added a new file to the lldb/test/load_unload test that causes the test a.out file to link to the libd.dylib file all the time. This will allow us to test using the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else. llvm-svn: 121745
2010-12-14 10:59:59 +08:00
}
Fixed the "expression" command object to use the StackFrame::GetValueForExpressionPath() function and also hooked up better error reporting for when things fail. Fixed issues with trying to display children of pointers when none are supposed to be shown (no children for function pointers, and more like this). This was causing child value objects to be made that were correctly firing an assertion. llvm-svn: 121841
2010-12-15 13:08:08 +08:00
return valobj_sp;
}
else
{
Change "frame var" over to using OptionGroups (and thus the OptionGroupVariableObjectDisplay). Change the boolean "use_dynamic" over to a tri-state, no-dynamic, dynamic-w/o running target, and dynamic with running target. llvm-svn: 130832
2011-05-04 11:43:18 +08:00
error.SetErrorStringWithFormat("no variable named '%s' found in this frame",
name_const_string.GetCString());
Modified LLDB expressions to not have to JIT and run code just to see variable values or persistent expression variables. Now if an expression consists of a value that is a child of a variable, or of a persistent variable only, we will create a value object for it and make a ValueObjectConstResult from it to freeze the value (for program variables only, not persistent variables) and avoid running JITed code. For everything else we still parse up and JIT code and run it in the inferior. There was also a lot of clean up in the expression code. I made the ClangExpressionVariables be stored in collections of shared pointers instead of in collections of objects. This will help stop a lot of copy constructors on these large objects and also cleans up the code considerably. The persistent clang expression variables were moved over to the Target to ensure they persist across process executions. Added the ability for lldb_private::Target objects to evaluate expressions. We want to evaluate expressions at the target level in case we aren't running yet, or we have just completed running. We still want to be able to access the persistent expression variables between runs, and also evaluate constant expressions. Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects can now dump their contents with the UUID, arch and full paths being logged with appropriate prefix values. Thread hardened the Communication class a bit by making the connection auto_ptr member into a shared pointer member and then making a local copy of the shared pointer in each method that uses it to make sure another thread can't nuke the connection object while it is being used by another thread. Added a new file to the lldb/test/load_unload test that causes the test a.out file to link to the libd.dylib file all the time. This will allow us to test using the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else. llvm-svn: 121745
2010-12-14 10:59:59 +08:00
}
}
}
Fixed the "expression" command object to use the StackFrame::GetValueForExpressionPath() function and also hooked up better error reporting for when things fail. Fixed issues with trying to display children of pointers when none are supposed to be shown (no children for function pointers, and more like this). This was causing child value objects to be made that were correctly firing an assertion. llvm-svn: 121841
2010-12-15 13:08:08 +08:00
else
{
error.SetErrorStringWithFormat("invalid variable path '%s'", var_expr_cstr);
}
Modified LLDB expressions to not have to JIT and run code just to see variable values or persistent expression variables. Now if an expression consists of a value that is a child of a variable, or of a persistent variable only, we will create a value object for it and make a ValueObjectConstResult from it to freeze the value (for program variables only, not persistent variables) and avoid running JITed code. For everything else we still parse up and JIT code and run it in the inferior. There was also a lot of clean up in the expression code. I made the ClangExpressionVariables be stored in collections of shared pointers instead of in collections of objects. This will help stop a lot of copy constructors on these large objects and also cleans up the code considerably. The persistent clang expression variables were moved over to the Target to ensure they persist across process executions. Added the ability for lldb_private::Target objects to evaluate expressions. We want to evaluate expressions at the target level in case we aren't running yet, or we have just completed running. We still want to be able to access the persistent expression variables between runs, and also evaluate constant expressions. Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects can now dump their contents with the UUID, arch and full paths being logged with appropriate prefix values. Thread hardened the Communication class a bit by making the connection auto_ptr member into a shared pointer member and then making a local copy of the shared pointer in each method that uses it to make sure another thread can't nuke the connection object while it is being used by another thread. Added a new file to the lldb/test/load_unload test that causes the test a.out file to link to the libd.dylib file all the time. This will allow us to test using the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else. llvm-svn: 121745
2010-12-14 10:59:59 +08:00
return ValueObjectSP();
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
bool
StackFrame::GetFrameBaseValue (Scalar &frame_base, Error *error_ptr)
{
second pass over removal of Mutex and Condition llvm-svn: 270024
2016-05-19 13:13:57 +08:00
std::lock_guard<std::recursive_mutex> guard(m_mutex);
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Target; other minor fixes. llvm-svn: 261242
2016-02-19 02:52:47 +08:00
if (!m_cfa_is_valid)
Add new ivars to StackFrame so it can represent a stack collected at some point in the past. We may have nothing more than a pc value for this type of stack frame -- hopefully we'll have a pc and a stop_id so we can track module loads and unloads over time and symbolicate the pc at the correct point in time. Also add a flag to indicate if the CFA for the frame is available (a bit different from a CFA of LLDB_INVALID_ADDRESS) and also an overall setting to indicate whether this is a history stack frame or not. A history stack frame may not have a CFA, it may not have a register context, it may not have variables, it may not have a frame pointer or a stack pointer. <rdar://problem/15314068> llvm-svn: 193987
2013-11-04 19:02:52 +08:00
{
m_frame_base_error.SetErrorString("No frame base available for this historical stack frame.");
return false;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (m_flags.IsClear(GOT_FRAME_BASE))
{
if (m_sc.function)
{
m_frame_base.Clear();
m_frame_base_error.Clear();
m_flags.Set(GOT_FRAME_BASE);
The second part in thread hardening the internals of LLDB where we make the lldb_private::StackFrame objects hold onto a weak pointer to the thread object. The lldb_private::StackFrame objects the the most volatile objects we have as when we are doing single stepping, frames can often get lost or thrown away, only to be re-created as another object that still refers to the same frame. We have another bug tracking that. But we need to be able to have frames no longer be able to get the thread when they are not part of a thread anymore, and this is the first step (this fix makes that possible but doesn't implement it yet). Also changed lldb_private::ExecutionContextScope to return shared pointers to all objects in the execution context to further thread harden the internals. llvm-svn: 150871
2012-02-18 13:35:26 +08:00
ExecutionContext exe_ctx (shared_from_this());
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Value expr_value;
Looking at some of the test suite failures in DWARF in .o files with the debug map showed that the location lists in the .o files needed some refactoring in order to work. The case that was failing was where a function that was in the "__TEXT.__textcoal_nt" in the .o file, and in the "__TEXT.__text" section in the main executable. This made symbol lookup fail due to the way we were finding a real address in the debug map which was by finding the section that the function was in in the .o file and trying to find this in the main executable. Now the section list supports finding a linked address in a section or any child sections. After fixing this, we ran into issue that were due to DWARF and how it represents locations lists. DWARF makes a list of address ranges and expressions that go along with those address ranges. The location addresses are expressed in terms of a compile unit address + offset. This works fine as long as nothing moves around. When stuff moves around and offsets change between the remapped compile unit base address and the new function address, then we can run into trouble. To deal with this, we now store supply a location list slide amount to any location list expressions that will allow us to make the location list addresses into zero based offsets from the object that owns the location list (always a function in our case). With these fixes we can now re-link random address ranges inside the debugger for use with our DWARF + debug map, incremental linking, and more. Another issue that arose when doing the DWARF in the .o files was that GCC 4.2 emits a ".debug_aranges" that only mentions functions that are externally visible. This makes .debug_aranges useless to us and we now generate a real address range lookup table in the DWARF parser at the same time as we index the name tables (that are needed because .debug_pubnames is just as useless). llvm-gcc doesn't generate a .debug_aranges section, though this could be fixed, we aren't going to rely upon it. Renamed a bunch of "UINT_MAX" to "UINT32_MAX". llvm-svn: 113829
2010-09-14 10:20:48 +08:00
addr_t loclist_base_addr = LLDB_INVALID_ADDRESS;
if (m_sc.function->GetFrameBaseExpression().IsLocationList())
The second part in thread hardening the internals of LLDB where we make the lldb_private::StackFrame objects hold onto a weak pointer to the thread object. The lldb_private::StackFrame objects the the most volatile objects we have as when we are doing single stepping, frames can often get lost or thrown away, only to be re-created as another object that still refers to the same frame. We have another bug tracking that. But we need to be able to have frames no longer be able to get the thread when they are not part of a thread anymore, and this is the first step (this fix makes that possible but doesn't implement it yet). Also changed lldb_private::ExecutionContextScope to return shared pointers to all objects in the execution context to further thread harden the internals. llvm-svn: 150871
2012-02-18 13:35:26 +08:00
loclist_base_addr = m_sc.function->GetAddressRange().GetBaseAddress().GetLoadAddress (exe_ctx.GetTargetPtr());
Looking at some of the test suite failures in DWARF in .o files with the debug map showed that the location lists in the .o files needed some refactoring in order to work. The case that was failing was where a function that was in the "__TEXT.__textcoal_nt" in the .o file, and in the "__TEXT.__text" section in the main executable. This made symbol lookup fail due to the way we were finding a real address in the debug map which was by finding the section that the function was in in the .o file and trying to find this in the main executable. Now the section list supports finding a linked address in a section or any child sections. After fixing this, we ran into issue that were due to DWARF and how it represents locations lists. DWARF makes a list of address ranges and expressions that go along with those address ranges. The location addresses are expressed in terms of a compile unit address + offset. This works fine as long as nothing moves around. When stuff moves around and offsets change between the remapped compile unit base address and the new function address, then we can run into trouble. To deal with this, we now store supply a location list slide amount to any location list expressions that will allow us to make the location list addresses into zero based offsets from the object that owns the location list (always a function in our case). With these fixes we can now re-link random address ranges inside the debugger for use with our DWARF + debug map, incremental linking, and more. Another issue that arose when doing the DWARF in the .o files was that GCC 4.2 emits a ".debug_aranges" that only mentions functions that are externally visible. This makes .debug_aranges useless to us and we now generate a real address range lookup table in the DWARF parser at the same time as we index the name tables (that are needed because .debug_pubnames is just as useless). llvm-gcc doesn't generate a .debug_aranges section, though this could be fixed, we aren't going to rely upon it. Renamed a bunch of "UINT_MAX" to "UINT32_MAX". llvm-svn: 113829
2010-09-14 10:20:48 +08:00
Add support for DW_OP_push_object_address in dwarf expressions Additionally fix the type of some dwarf expression where we had a confusion between scalar and load address types after a dereference. Differential revision: http://reviews.llvm.org/D17604 llvm-svn: 262014
2016-02-26 22:21:10 +08:00
if (m_sc.function->GetFrameBaseExpression().Evaluate(&exe_ctx,
nullptr,
nullptr,
nullptr,
loclist_base_addr,
nullptr,
nullptr,
expr_value,
&m_frame_base_error) == false)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
// We should really have an error if evaluate returns, but in case
// we don't, lets set the error to something at least.
if (m_frame_base_error.Success())
m_frame_base_error.SetErrorString("Evaluation of the frame base expression failed.");
}
else
{
Huge change to clean up types. A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
2013-07-12 06:46:58 +08:00
m_frame_base = expr_value.ResolveValue(&exe_ctx);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
}
else
{
m_frame_base_error.SetErrorString ("No function in symbol context.");
}
}
if (m_frame_base_error.Success())
frame_base = m_frame_base;
if (error_ptr)
*error_ptr = m_frame_base_error;
return m_frame_base_error.Success();
}
Added the "frame diagnose" command and use its output to make crash info better. When a process stops due to a crash, we get the crashing instruction and the crashing memory location (if there is one). From the user's perspective it is often unclear what the reason for the crash is in a symbolic sense. To address this, I have added new fuctionality to StackFrame to parse the disassembly and reconstruct the sequence of dereferneces and offsets that were applied to a known variable (or fuction retrn value) to obtain the invalid pointer. This makes use of enhancements in the disassembler, as well as new information provided by the DWARF expression infrastructure, and is exposed through a "frame diagnose" command. It is also used to provide symbolic information, when available, in the event of a crash. The algorithm is very rudimentary, and it needs a bunch of work, including - better parsing for assembly, preferably with help from LLVM - support for non-Apple platforms - cleanup of the algorithm core, preferably to make it all work in terms of Operands instead of register/offset pairs - improvement of the GetExpressioPath() logic to make prettier expression paths, and - better handling of vtables. I welcome all suggestios, improvements, and testcases. llvm-svn: 280692
2016-09-06 12:48:36 +08:00
DWARFExpression *
StackFrame::GetFrameBaseExpression(Error *error_ptr)
{
if (!m_sc.function)
{
if (error_ptr)
{
error_ptr->SetErrorString ("No function in symbol context.");
}
return nullptr;
}
return &m_sc.function->GetFrameBaseExpression();
}
Fixed issues with RegisterContext classes and the subclasses. There was an issue with the way the UnwindLLDB was handing out RegisterContexts: it was making shared pointers to register contexts and then handing out just the pointers (which would get put into shared pointers in the thread and stack frame classes) and cause double free issues. MallocScribble helped to find these issues after I did some other cleanup. To help avoid any RegisterContext issue in the future, all code that deals with them now returns shared pointers to the register contexts so we don't end up with multiple deletions. Also now that the RegisterContext class doesn't require a stack frame, we patched a memory leak where a StackFrame object was being created and leaked. Made the RegisterContext class not have a pointer to a StackFrame object as one register context class can be used for N inlined stack frames so there is not a 1 - 1 mapping. Updates the ExecutionContextScope part of the RegisterContext class to never return a stack frame to indicate this when it is asked to recreate the execution context. Now register contexts point to the concrete frame using a concrete frame index. Concrete frames are all of the frames that are actually formed on the stack of a thread. These concrete frames can be turned into one or more user visible frames due to inlining. Each inlined stack frame has the exact same register context (shared via shared pointers) as any parent inlined stack frames all the way up to the concrete frame itself. So now the stack frames and the register contexts should behave much better. llvm-svn: 122976
2011-01-07 06:15:06 +08:00
RegisterContextSP
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
StackFrame::GetRegisterContext ()
{
second pass over removal of Mutex and Condition llvm-svn: 270024
2016-05-19 13:13:57 +08:00
std::lock_guard<std::recursive_mutex> guard(m_mutex);
Fixed issues with RegisterContext classes and the subclasses. There was an issue with the way the UnwindLLDB was handing out RegisterContexts: it was making shared pointers to register contexts and then handing out just the pointers (which would get put into shared pointers in the thread and stack frame classes) and cause double free issues. MallocScribble helped to find these issues after I did some other cleanup. To help avoid any RegisterContext issue in the future, all code that deals with them now returns shared pointers to the register contexts so we don't end up with multiple deletions. Also now that the RegisterContext class doesn't require a stack frame, we patched a memory leak where a StackFrame object was being created and leaked. Made the RegisterContext class not have a pointer to a StackFrame object as one register context class can be used for N inlined stack frames so there is not a 1 - 1 mapping. Updates the ExecutionContextScope part of the RegisterContext class to never return a stack frame to indicate this when it is asked to recreate the execution context. Now register contexts point to the concrete frame using a concrete frame index. Concrete frames are all of the frames that are actually formed on the stack of a thread. These concrete frames can be turned into one or more user visible frames due to inlining. Each inlined stack frame has the exact same register context (shared via shared pointers) as any parent inlined stack frames all the way up to the concrete frame itself. So now the stack frames and the register contexts should behave much better. llvm-svn: 122976
2011-01-07 06:15:06 +08:00
if (!m_reg_context_sp)
The second part in thread hardening the internals of LLDB where we make the lldb_private::StackFrame objects hold onto a weak pointer to the thread object. The lldb_private::StackFrame objects the the most volatile objects we have as when we are doing single stepping, frames can often get lost or thrown away, only to be re-created as another object that still refers to the same frame. We have another bug tracking that. But we need to be able to have frames no longer be able to get the thread when they are not part of a thread anymore, and this is the first step (this fix makes that possible but doesn't implement it yet). Also changed lldb_private::ExecutionContextScope to return shared pointers to all objects in the execution context to further thread harden the internals. llvm-svn: 150871
2012-02-18 13:35:26 +08:00
{
ThreadSP thread_sp (GetThread());
if (thread_sp)
m_reg_context_sp = thread_sp->CreateRegisterContextForFrame (this);
}
Fixed issues with RegisterContext classes and the subclasses. There was an issue with the way the UnwindLLDB was handing out RegisterContexts: it was making shared pointers to register contexts and then handing out just the pointers (which would get put into shared pointers in the thread and stack frame classes) and cause double free issues. MallocScribble helped to find these issues after I did some other cleanup. To help avoid any RegisterContext issue in the future, all code that deals with them now returns shared pointers to the register contexts so we don't end up with multiple deletions. Also now that the RegisterContext class doesn't require a stack frame, we patched a memory leak where a StackFrame object was being created and leaked. Made the RegisterContext class not have a pointer to a StackFrame object as one register context class can be used for N inlined stack frames so there is not a 1 - 1 mapping. Updates the ExecutionContextScope part of the RegisterContext class to never return a stack frame to indicate this when it is asked to recreate the execution context. Now register contexts point to the concrete frame using a concrete frame index. Concrete frames are all of the frames that are actually formed on the stack of a thread. These concrete frames can be turned into one or more user visible frames due to inlining. Each inlined stack frame has the exact same register context (shared via shared pointers) as any parent inlined stack frames all the way up to the concrete frame itself. So now the stack frames and the register contexts should behave much better. llvm-svn: 122976
2011-01-07 06:15:06 +08:00
return m_reg_context_sp;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
bool
StackFrame::HasDebugInformation ()
{
Got a lot of the kinks worked out in the inline support after debugging more complex inlined examples. StackFrame classes don't have a "GetPC" anymore, they have "GetFrameCodeAddress()". This is because inlined frames will have a PC value that is the same as the concrete frame that owns the inlined frame, yet the code locations for the frame can be different. We also need to be able to get the real PC value for a given frame so that variables evaluate correctly. To get the actual PC value for a frame you can use: addr_t pc = frame->GetRegisterContext()->GetPC(); Some issues with the StackFrame stomping on its own symbol context were resolved which were causing the information to change for a frame when the stack ID was calculated. Also the StackFrame will now correctly store the symbol context resolve flags for any extra bits of information that were looked up (if you ask for a block only and you find one, you will alwasy have the compile unit and function). llvm-svn: 111964
2010-08-25 05:05:24 +08:00
GetSymbolContext (eSymbolContextLineEntry);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return m_sc.line_entry.IsValid();
}
StackFrame objects now own ValueObjects for any frame variables (locals, args, function statics, file globals and static variables) that a frame contains. The StackFrame objects can give out ValueObjects instances for each variable which allows us to track when a variable changes and doesn't depend on variable names when getting value objects. StackFrame::GetVariableList now takes a boolean to indicate if we want to get the frame compile unit globals and static variables. The value objects in the stack frames can now correctly track when they have been modified. There are a few more tweaks needed to complete this work. The biggest issue is when stepping creates partial stacks (just frame zero usually) and causes previous stack frames not to match up with the current stack frames because the previous frames only has frame zero. We don't really want to require that all previous frames be complete since stepping often must check stack frames to complete their jobs. I will fix this issue tomorrow. llvm-svn: 112800
2010-09-02 10:59:18 +08:00
ValueObjectSP
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
StackFrame::GetValueObjectForFrameVariable (const VariableSP &variable_sp, DynamicValueType use_dynamic)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
second pass over removal of Mutex and Condition llvm-svn: 270024
2016-05-19 13:13:57 +08:00
std::lock_guard<std::recursive_mutex> guard(m_mutex);
StackFrame objects now own ValueObjects for any frame variables (locals, args, function statics, file globals and static variables) that a frame contains. The StackFrame objects can give out ValueObjects instances for each variable which allows us to track when a variable changes and doesn't depend on variable names when getting value objects. StackFrame::GetVariableList now takes a boolean to indicate if we want to get the frame compile unit globals and static variables. The value objects in the stack frames can now correctly track when they have been modified. There are a few more tweaks needed to complete this work. The biggest issue is when stepping creates partial stacks (just frame zero usually) and causes previous stack frames not to match up with the current stack frames because the previous frames only has frame zero. We don't really want to require that all previous frames be complete since stepping often must check stack frames to complete their jobs. I will fix this issue tomorrow. llvm-svn: 112800
2010-09-02 10:59:18 +08:00
ValueObjectSP valobj_sp;
Add new ivars to StackFrame so it can represent a stack collected at some point in the past. We may have nothing more than a pc value for this type of stack frame -- hopefully we'll have a pc and a stop_id so we can track module loads and unloads over time and symbolicate the pc at the correct point in time. Also add a flag to indicate if the CFA for the frame is available (a bit different from a CFA of LLDB_INVALID_ADDRESS) and also an overall setting to indicate whether this is a history stack frame or not. A history stack frame may not have a CFA, it may not have a register context, it may not have variables, it may not have a frame pointer or a stack pointer. <rdar://problem/15314068> llvm-svn: 193987
2013-11-04 19:02:52 +08:00
if (m_is_history_frame)
{
return valobj_sp;
}
StackFrame objects now own ValueObjects for any frame variables (locals, args, function statics, file globals and static variables) that a frame contains. The StackFrame objects can give out ValueObjects instances for each variable which allows us to track when a variable changes and doesn't depend on variable names when getting value objects. StackFrame::GetVariableList now takes a boolean to indicate if we want to get the frame compile unit globals and static variables. The value objects in the stack frames can now correctly track when they have been modified. There are a few more tweaks needed to complete this work. The biggest issue is when stepping creates partial stacks (just frame zero usually) and causes previous stack frames not to match up with the current stack frames because the previous frames only has frame zero. We don't really want to require that all previous frames be complete since stepping often must check stack frames to complete their jobs. I will fix this issue tomorrow. llvm-svn: 112800
2010-09-02 10:59:18 +08:00
VariableList *var_list = GetVariableList (true);
if (var_list)
{
// Make sure the variable is a frame variable
const uint32_t var_idx = var_list->FindIndexForVariable (variable_sp.get());
const uint32_t num_variables = var_list->GetSize();
if (var_idx < num_variables)
{
valobj_sp = m_variable_list_value_objects.GetValueObjectAtIndex (var_idx);
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Target; other minor fixes. llvm-svn: 261242
2016-02-19 02:52:47 +08:00
if (!valobj_sp)
StackFrame objects now own ValueObjects for any frame variables (locals, args, function statics, file globals and static variables) that a frame contains. The StackFrame objects can give out ValueObjects instances for each variable which allows us to track when a variable changes and doesn't depend on variable names when getting value objects. StackFrame::GetVariableList now takes a boolean to indicate if we want to get the frame compile unit globals and static variables. The value objects in the stack frames can now correctly track when they have been modified. There are a few more tweaks needed to complete this work. The biggest issue is when stepping creates partial stacks (just frame zero usually) and causes previous stack frames not to match up with the current stack frames because the previous frames only has frame zero. We don't really want to require that all previous frames be complete since stepping often must check stack frames to complete their jobs. I will fix this issue tomorrow. llvm-svn: 112800
2010-09-02 10:59:18 +08:00
{
if (m_variable_list_value_objects.GetSize() < num_variables)
m_variable_list_value_objects.Resize(num_variables);
Fix up how the ValueObjects manage their life cycle so that you can hand out a shared pointer to a ValueObject or any of its dependent ValueObjects, and the whole cluster will stay around as long as that shared pointer stays around. llvm-svn: 130035
2011-04-23 07:53:53 +08:00
valobj_sp = ValueObjectVariable::Create (this, variable_sp);
StackFrame objects now own ValueObjects for any frame variables (locals, args, function statics, file globals and static variables) that a frame contains. The StackFrame objects can give out ValueObjects instances for each variable which allows us to track when a variable changes and doesn't depend on variable names when getting value objects. StackFrame::GetVariableList now takes a boolean to indicate if we want to get the frame compile unit globals and static variables. The value objects in the stack frames can now correctly track when they have been modified. There are a few more tweaks needed to complete this work. The biggest issue is when stepping creates partial stacks (just frame zero usually) and causes previous stack frames not to match up with the current stack frames because the previous frames only has frame zero. We don't really want to require that all previous frames be complete since stepping often must check stack frames to complete their jobs. I will fix this issue tomorrow. llvm-svn: 112800
2010-09-02 10:59:18 +08:00
m_variable_list_value_objects.SetValueObjectAtIndex (var_idx, valobj_sp);
}
}
}
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
if (use_dynamic != eNoDynamicValues && valobj_sp)
Add support for "dynamic values" for C++ classes. This currently only works for "frame var" and for the expressions that are simple enough to get passed to the "frame var" underpinnings. The parser code will have to be changed to also query for the dynamic types & offsets as it is looking up variables. The behavior of "frame var" is controlled in two ways. You can pass "-d {true/false} to the frame var command to get the dynamic or static value of the variables you are printing. There's also a general setting: target.prefer-dynamic-value (boolean) = 'true' which is consulted if you call "frame var" without supplying a value for the -d option. llvm-svn: 129623
2011-04-16 08:01:13 +08:00
{
Change "frame var" over to using OptionGroups (and thus the OptionGroupVariableObjectDisplay). Change the boolean "use_dynamic" over to a tri-state, no-dynamic, dynamic-w/o running target, and dynamic with running target. llvm-svn: 130832
2011-05-04 11:43:18 +08:00
ValueObjectSP dynamic_sp = valobj_sp->GetDynamicValue (use_dynamic);
Add support for "dynamic values" for C++ classes. This currently only works for "frame var" and for the expressions that are simple enough to get passed to the "frame var" underpinnings. The parser code will have to be changed to also query for the dynamic types & offsets as it is looking up variables. The behavior of "frame var" is controlled in two ways. You can pass "-d {true/false} to the frame var command to get the dynamic or static value of the variables you are printing. There's also a general setting: target.prefer-dynamic-value (boolean) = 'true' which is consulted if you call "frame var" without supplying a value for the -d option. llvm-svn: 129623
2011-04-16 08:01:13 +08:00
if (dynamic_sp)
return dynamic_sp;
}
StackFrame objects now own ValueObjects for any frame variables (locals, args, function statics, file globals and static variables) that a frame contains. The StackFrame objects can give out ValueObjects instances for each variable which allows us to track when a variable changes and doesn't depend on variable names when getting value objects. StackFrame::GetVariableList now takes a boolean to indicate if we want to get the frame compile unit globals and static variables. The value objects in the stack frames can now correctly track when they have been modified. There are a few more tweaks needed to complete this work. The biggest issue is when stepping creates partial stacks (just frame zero usually) and causes previous stack frames not to match up with the current stack frames because the previous frames only has frame zero. We don't really want to require that all previous frames be complete since stepping often must check stack frames to complete their jobs. I will fix this issue tomorrow. llvm-svn: 112800
2010-09-02 10:59:18 +08:00
return valobj_sp;
}
ValueObjectSP
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
StackFrame::TrackGlobalVariable (const VariableSP &variable_sp, DynamicValueType use_dynamic)
StackFrame objects now own ValueObjects for any frame variables (locals, args, function statics, file globals and static variables) that a frame contains. The StackFrame objects can give out ValueObjects instances for each variable which allows us to track when a variable changes and doesn't depend on variable names when getting value objects. StackFrame::GetVariableList now takes a boolean to indicate if we want to get the frame compile unit globals and static variables. The value objects in the stack frames can now correctly track when they have been modified. There are a few more tweaks needed to complete this work. The biggest issue is when stepping creates partial stacks (just frame zero usually) and causes previous stack frames not to match up with the current stack frames because the previous frames only has frame zero. We don't really want to require that all previous frames be complete since stepping often must check stack frames to complete their jobs. I will fix this issue tomorrow. llvm-svn: 112800
2010-09-02 10:59:18 +08:00
{
second pass over removal of Mutex and Condition llvm-svn: 270024
2016-05-19 13:13:57 +08:00
std::lock_guard<std::recursive_mutex> guard(m_mutex);
Add new ivars to StackFrame so it can represent a stack collected at some point in the past. We may have nothing more than a pc value for this type of stack frame -- hopefully we'll have a pc and a stop_id so we can track module loads and unloads over time and symbolicate the pc at the correct point in time. Also add a flag to indicate if the CFA for the frame is available (a bit different from a CFA of LLDB_INVALID_ADDRESS) and also an overall setting to indicate whether this is a history stack frame or not. A history stack frame may not have a CFA, it may not have a register context, it may not have variables, it may not have a frame pointer or a stack pointer. <rdar://problem/15314068> llvm-svn: 193987
2013-11-04 19:02:52 +08:00
if (m_is_history_frame)
return ValueObjectSP();
StackFrame objects now own ValueObjects for any frame variables (locals, args, function statics, file globals and static variables) that a frame contains. The StackFrame objects can give out ValueObjects instances for each variable which allows us to track when a variable changes and doesn't depend on variable names when getting value objects. StackFrame::GetVariableList now takes a boolean to indicate if we want to get the frame compile unit globals and static variables. The value objects in the stack frames can now correctly track when they have been modified. There are a few more tweaks needed to complete this work. The biggest issue is when stepping creates partial stacks (just frame zero usually) and causes previous stack frames not to match up with the current stack frames because the previous frames only has frame zero. We don't really want to require that all previous frames be complete since stepping often must check stack frames to complete their jobs. I will fix this issue tomorrow. llvm-svn: 112800
2010-09-02 10:59:18 +08:00
// Check to make sure we aren't already tracking this variable?
Add support for "dynamic values" for C++ classes. This currently only works for "frame var" and for the expressions that are simple enough to get passed to the "frame var" underpinnings. The parser code will have to be changed to also query for the dynamic types & offsets as it is looking up variables. The behavior of "frame var" is controlled in two ways. You can pass "-d {true/false} to the frame var command to get the dynamic or static value of the variables you are printing. There's also a general setting: target.prefer-dynamic-value (boolean) = 'true' which is consulted if you call "frame var" without supplying a value for the -d option. llvm-svn: 129623
2011-04-16 08:01:13 +08:00
ValueObjectSP valobj_sp (GetValueObjectForFrameVariable (variable_sp, use_dynamic));
StackFrame objects now own ValueObjects for any frame variables (locals, args, function statics, file globals and static variables) that a frame contains. The StackFrame objects can give out ValueObjects instances for each variable which allows us to track when a variable changes and doesn't depend on variable names when getting value objects. StackFrame::GetVariableList now takes a boolean to indicate if we want to get the frame compile unit globals and static variables. The value objects in the stack frames can now correctly track when they have been modified. There are a few more tweaks needed to complete this work. The biggest issue is when stepping creates partial stacks (just frame zero usually) and causes previous stack frames not to match up with the current stack frames because the previous frames only has frame zero. We don't really want to require that all previous frames be complete since stepping often must check stack frames to complete their jobs. I will fix this issue tomorrow. llvm-svn: 112800
2010-09-02 10:59:18 +08:00
if (!valobj_sp)
{
// We aren't already tracking this global
VariableList *var_list = GetVariableList (true);
// If this frame has no variables, create a new list
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Target; other minor fixes. llvm-svn: 261242
2016-02-19 02:52:47 +08:00
if (var_list == nullptr)
StackFrame objects now own ValueObjects for any frame variables (locals, args, function statics, file globals and static variables) that a frame contains. The StackFrame objects can give out ValueObjects instances for each variable which allows us to track when a variable changes and doesn't depend on variable names when getting value objects. StackFrame::GetVariableList now takes a boolean to indicate if we want to get the frame compile unit globals and static variables. The value objects in the stack frames can now correctly track when they have been modified. There are a few more tweaks needed to complete this work. The biggest issue is when stepping creates partial stacks (just frame zero usually) and causes previous stack frames not to match up with the current stack frames because the previous frames only has frame zero. We don't really want to require that all previous frames be complete since stepping often must check stack frames to complete their jobs. I will fix this issue tomorrow. llvm-svn: 112800
2010-09-02 10:59:18 +08:00
m_variable_list_sp.reset (new VariableList());
// Add the global/static variable to this frame
m_variable_list_sp->AddVariable (variable_sp);
// Now make a value object for it so we can track its changes
Add support for "dynamic values" for C++ classes. This currently only works for "frame var" and for the expressions that are simple enough to get passed to the "frame var" underpinnings. The parser code will have to be changed to also query for the dynamic types & offsets as it is looking up variables. The behavior of "frame var" is controlled in two ways. You can pass "-d {true/false} to the frame var command to get the dynamic or static value of the variables you are printing. There's also a general setting: target.prefer-dynamic-value (boolean) = 'true' which is consulted if you call "frame var" without supplying a value for the -d option. llvm-svn: 129623
2011-04-16 08:01:13 +08:00
valobj_sp = GetValueObjectForFrameVariable (variable_sp, use_dynamic);
StackFrame objects now own ValueObjects for any frame variables (locals, args, function statics, file globals and static variables) that a frame contains. The StackFrame objects can give out ValueObjects instances for each variable which allows us to track when a variable changes and doesn't depend on variable names when getting value objects. StackFrame::GetVariableList now takes a boolean to indicate if we want to get the frame compile unit globals and static variables. The value objects in the stack frames can now correctly track when they have been modified. There are a few more tweaks needed to complete this work. The biggest issue is when stepping creates partial stacks (just frame zero usually) and causes previous stack frames not to match up with the current stack frames because the previous frames only has frame zero. We don't really want to require that all previous frames be complete since stepping often must check stack frames to complete their jobs. I will fix this issue tomorrow. llvm-svn: 112800
2010-09-02 10:59:18 +08:00
}
return valobj_sp;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Add StackFrame::IsInlined. llvm-svn: 112217
2010-08-27 04:44:45 +08:00
bool
StackFrame::IsInlined ()
{
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Target; other minor fixes. llvm-svn: 261242
2016-02-19 02:52:47 +08:00
if (m_sc.block == nullptr)
Clarified the intent of the SymbolContextScope class in the header documentation. Symbol now inherits from the symbol context scope so that the StackID can use a "SymbolContextScope *" instead of a blockID (which could have been the same as some other blockID from another symbol file). Modified the stacks that are created on subsequent stops to reuse the previous stack frame objects which will allow for some internal optimization using pointer comparisons during stepping. llvm-svn: 112495
2010-08-31 02:11:35 +08:00
GetSymbolContext (eSymbolContextBlock);
if (m_sc.block)
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Target; other minor fixes. llvm-svn: 261242
2016-02-19 02:52:47 +08:00
return m_sc.block->GetContainingInlinedBlock() != nullptr;
Clarified the intent of the SymbolContextScope class in the header documentation. Symbol now inherits from the symbol context scope so that the StackID can use a "SymbolContextScope *" instead of a blockID (which could have been the same as some other blockID from another symbol file). Modified the stacks that are created on subsequent stops to reuse the previous stack frame objects which will allow for some internal optimization using pointer comparisons during stepping. llvm-svn: 112495
2010-08-31 02:11:35 +08:00
return false;
Add StackFrame::IsInlined. llvm-svn: 112217
2010-08-27 04:44:45 +08:00
}
Set the default language to use when evaluating to that of the frame's CU. * Use the frame's context (instead of just the target's) when evaluating, so that the language of the frame's CU can be used to select the compiler and/or compiler options to use when parsing the expression. This allows for modules built with mixed languages to be parsed in the context of their frame. * Add all C and C++ language variants when determining the language options to set. * Enable C++ language options when language is C or ObjC as a workaround since the expression parser uses features of C++ to capture values. * Enable ObjC language options when language is C++ as a workaround for ObjC requirements. * Disable C++11 language options when language is C++03. * Add test TestMixedLanguages.py to check that the language being used for evaluation is that of the frame. * Fix test TestExprOptions.py to check for C++11 instead of C++ since C++ has to be enabled for C, and remove redundant expr --language test for ObjC. * Fix TestPersistentPtrUpdate.py to not require C++11 in C. Reviewed by: clayborg, spyffe, jingham Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D11102 llvm-svn: 246829
2015-09-04 09:02:30 +08:00
lldb::LanguageType
StackFrame::GetLanguage ()
{
CompileUnit *cu = GetSymbolContext(eSymbolContextCompUnit).comp_unit;
if (cu)
return cu->GetLanguage();
return lldb::eLanguageTypeUnknown;
}
Improve the 'type lookup' command such that it guesses to use the current's frame language as the one to start searching from. llvm-svn: 263592
2016-03-16 05:50:51 +08:00
lldb::LanguageType
StackFrame::GuessLanguage ()
{
LanguageType lang_type = GetLanguage();
if (lang_type == eLanguageTypeUnknown)
{
Function *f = GetSymbolContext(eSymbolContextFunction).function;
if (f)
{
lang_type = f->GetMangled().GuessLanguage();
}
}
return lang_type;
}
Added the "frame diagnose" command and use its output to make crash info better. When a process stops due to a crash, we get the crashing instruction and the crashing memory location (if there is one). From the user's perspective it is often unclear what the reason for the crash is in a symbolic sense. To address this, I have added new fuctionality to StackFrame to parse the disassembly and reconstruct the sequence of dereferneces and offsets that were applied to a known variable (or fuction retrn value) to obtain the invalid pointer. This makes use of enhancements in the disassembler, as well as new information provided by the DWARF expression infrastructure, and is exposed through a "frame diagnose" command. It is also used to provide symbolic information, when available, in the event of a crash. The algorithm is very rudimentary, and it needs a bunch of work, including - better parsing for assembly, preferably with help from LLVM - support for non-Apple platforms - cleanup of the algorithm core, preferably to make it all work in terms of Operands instead of register/offset pairs - improvement of the GetExpressioPath() logic to make prettier expression paths, and - better handling of vtables. I welcome all suggestios, improvements, and testcases. llvm-svn: 280692
2016-09-06 12:48:36 +08:00
namespace
{
std::pair<const Instruction::Operand *, int64_t>
GetBaseExplainingValue(const Instruction::Operand &operand,
RegisterContext &register_context,
lldb::addr_t value)
{
switch(operand.m_type)
{
case Instruction::Operand::Type::Dereference:
case Instruction::Operand::Type::Immediate:
case Instruction::Operand::Type::Invalid:
case Instruction::Operand::Type::Product:
// These are not currently interesting
return std::make_pair(nullptr, 0);
case Instruction::Operand::Type::Sum:
{
const Instruction::Operand *immediate_child = nullptr;
const Instruction::Operand *variable_child = nullptr;
if (operand.m_children[0].m_type == Instruction::Operand::Type::Immediate)
{
immediate_child = &operand.m_children[0];
variable_child = &operand.m_children[1];
}
else if (operand.m_children[1].m_type == Instruction::Operand::Type::Immediate)
{
immediate_child = &operand.m_children[1];
variable_child = &operand.m_children[0];
}
if (!immediate_child)
{
return std::make_pair(nullptr, 0);
}
lldb::addr_t adjusted_value = value;
if (immediate_child->m_negative)
{
adjusted_value += immediate_child->m_immediate;
}
else
{
adjusted_value -= immediate_child->m_immediate;
}
std::pair<const Instruction::Operand *, int64_t> base_and_offset = GetBaseExplainingValue(*variable_child, register_context, adjusted_value);
if (!base_and_offset.first)
{
return std::make_pair(nullptr, 0);
}
if (immediate_child->m_negative)
{
base_and_offset.second -= immediate_child->m_immediate;
}
else
{
base_and_offset.second += immediate_child->m_immediate;
}
return base_and_offset;
}
case Instruction::Operand::Type::Register:
{
const RegisterInfo *info = register_context.GetRegisterInfoByName(operand.m_register.AsCString());
if (!info)
{
return std::make_pair(nullptr, 0);
}
RegisterValue reg_value;
if (!register_context.ReadRegister(info, reg_value))
{
return std::make_pair(nullptr, 0);
}
if (reg_value.GetAsUInt64() == value)
{
return std::make_pair(&operand, 0);
}
else
{
return std::make_pair(nullptr, 0);
}
}
}
}
std::pair<const Instruction::Operand *, int64_t>
GetBaseExplainingDereference(const Instruction::Operand &operand,
RegisterContext &register_context,
lldb::addr_t addr)
{
if (operand.m_type == Instruction::Operand::Type::Dereference)
{
return GetBaseExplainingValue(operand.m_children[0],
register_context,
addr);
}
return std::make_pair(nullptr, 0);
}
};
lldb::ValueObjectSP
StackFrame::GuessValueForAddress(lldb::addr_t addr)
{
TargetSP target_sp = CalculateTarget();
const ArchSpec &target_arch = target_sp->GetArchitecture();
AddressRange pc_range;
pc_range.GetBaseAddress() = GetFrameCodeAddress();
pc_range.SetByteSize(target_arch.GetMaximumOpcodeByteSize());
ExecutionContext exe_ctx (shared_from_this());
const char *plugin_name = nullptr;
const char *flavor = nullptr;
const bool prefer_file_cache = false;
DisassemblerSP disassembler_sp = Disassembler::DisassembleRange (target_arch,
plugin_name,
flavor,
exe_ctx,
pc_range,
prefer_file_cache);
if (!disassembler_sp->GetInstructionList().GetSize())
{
return ValueObjectSP();
}
InstructionSP instruction_sp = disassembler_sp->GetInstructionList().GetInstructionAtIndex(0);
llvm::SmallVector<Instruction::Operand, 3> operands;
if (!instruction_sp->ParseOperands(operands))
{
return ValueObjectSP();
}
RegisterContextSP register_context_sp = GetRegisterContext();
if (!register_context_sp)
{
return ValueObjectSP();
}
for (const Instruction::Operand &operand : operands)
{
std::pair<const Instruction::Operand *, int64_t>
base_and_offset = GetBaseExplainingDereference(operand, *register_context_sp, addr);
if (!base_and_offset.first)
{
continue;
}
switch (base_and_offset.first->m_type)
{
case Instruction::Operand::Type::Immediate:
{
lldb_private::Address addr;
if (target_sp->ResolveLoadAddress(base_and_offset.first->m_immediate + base_and_offset.second, addr))
{
TypeSystem *c_type_system = target_sp->GetScratchTypeSystemForLanguage(nullptr, eLanguageTypeC);
if (!c_type_system)
{
return ValueObjectSP();
}
else
{
CompilerType void_ptr_type = c_type_system->GetBasicTypeFromAST(lldb::BasicType::eBasicTypeChar).GetPointerType();
return ValueObjectMemory::Create(this, "", addr, void_ptr_type);
}
}
else
{
return ValueObjectSP();
}
break;
}
case Instruction::Operand::Type::Register:
{
return GuessValueForRegisterAndOffset(base_and_offset.first->m_register, base_and_offset.second);
}
default:
return ValueObjectSP();
}
}
return ValueObjectSP();
}
namespace
{
ValueObjectSP
GetValueForOffset(StackFrame &frame, ValueObjectSP &parent, int64_t offset)
{
if (offset < 0 || offset >= parent->GetByteSize())
{
return ValueObjectSP();
}
if (parent->IsPointerOrReferenceType())
{
return parent;
}
for (int ci = 0, ce = parent->GetNumChildren(); ci != ce; ++ci)
{
const bool can_create = true;
ValueObjectSP child_sp = parent->GetChildAtIndex(ci, can_create);
if (!child_sp)
{
return ValueObjectSP();
}
int64_t child_offset = child_sp->GetByteOffset();
int64_t child_size = child_sp->GetByteSize();
if (offset >= child_offset &&
offset < (child_offset + child_size))
{
return GetValueForOffset(frame, child_sp, offset - child_offset);
}
}
if (offset == 0)
{
return parent;
}
else
{
return ValueObjectSP();
}
}
ValueObjectSP
GetValueForDereferincingOffset(StackFrame &frame, ValueObjectSP &base, int64_t offset)
{
// base is a pointer to something
// offset is the thing to add to the pointer
// We return the most sensible ValueObject for the result of *(base+offset)
if (!base->IsPointerOrReferenceType())
{
return ValueObjectSP();
}
Error error;
ValueObjectSP pointee = base->Dereference(error);
if (offset >= pointee->GetByteSize())
{
int64_t index = offset / pointee->GetByteSize();
offset = offset % pointee->GetByteSize();
const bool can_create = true;
pointee = base->GetSyntheticArrayMember(index, can_create);
}
if (!pointee || error.Fail())
{
return ValueObjectSP();
}
return GetValueForOffset(frame, pointee, offset);
}
//------------------------------------------------------------------
/// Attempt to reconstruct the ValueObject for the address contained in a
/// given register plus an offset.
///
/// @params [in] frame
/// The current stack frame.
///
/// @params [in] reg
/// The register.
///
/// @params [in] offset
/// The offset from the register.
///
/// @param [in] disassembler
/// A disassembler containing instructions valid up to the current PC.
///
/// @param [in] variables
/// The variable list from the current frame,
///
/// @param [in] pc
/// The program counter for the instruction considered the 'user'.
///
/// @return
/// A string describing the base for the ExpressionPath. This could be a
/// variable, a register value, an argument, or a function return value.
/// The ValueObject if found. If valid, it has a valid ExpressionPath.
//------------------------------------------------------------------
lldb::ValueObjectSP
DoGuessValueAt(StackFrame &frame, ConstString reg, int64_t offset, Disassembler &disassembler, VariableList &variables, const Address &pc)
{
// Example of operation for Intel:
//
// +14: movq -0x8(%rbp), %rdi
// +18: movq 0x8(%rdi), %rdi
// +22: addl 0x4(%rdi), %eax
//
// f, a pointer to a struct, is known to be at -0x8(%rbp).
//
// DoGuessValueAt(frame, rdi, 4, dis, vars, 0x22) finds the instruction at +18 that assigns to rdi, and calls itself recursively for that dereference
// DoGuessValueAt(frame, rdi, 8, dis, vars, 0x18) finds the instruction at +14 that assigns to rdi, and calls itself recursively for that derefernece
// DoGuessValueAt(frame, rbp, -8, dis, vars, 0x14) finds "f" in the variable list.
// Returns a ValueObject for f. (That's what was stored at rbp-8 at +14)
// Returns a ValueObject for *(f+8) or f->b (That's what was stored at rdi+8 at +18)
// Returns a ValueObject for *(f->b+4) or f->b->a (That's what was stored at rdi+4 at +22)
// First, check the variable list to see if anything is at the specified location.
for (size_t vi = 0, ve = variables.GetSize(); vi != ve; ++vi)
{
VariableSP var_sp = variables.GetVariableAtIndex(vi);
DWARFExpression &dwarf_expression = var_sp->LocationExpression();
const RegisterInfo *expression_reg;
int64_t expression_offset;
ExecutionContext exe_ctx;
if (dwarf_expression.IsDereferenceOfRegister(frame, expression_reg, expression_offset))
{
if ((reg == ConstString(expression_reg->name) ||
reg == ConstString(expression_reg->alt_name)) &&
expression_offset == offset)
{
return frame.GetValueObjectForFrameVariable(var_sp, eNoDynamicValues);
}
}
}
bool is_in_return_register = false;
ABISP abi_sp = frame.CalculateProcess()->GetABI();
RegisterInfo return_register_info;
if (abi_sp)
{
const char *return_register_name;
const RegisterInfo *reg_info = nullptr;
if (abi_sp->GetPointerReturnRegister(return_register_name) &&
reg == ConstString(return_register_name) &&
(reg_info = frame.GetRegisterContext()->GetRegisterInfoByName(return_register_name)))
{
is_in_return_register = true;
return_register_info = *reg_info;
}
}
const uint32_t current_inst = disassembler.GetInstructionList().GetIndexOfInstructionAtAddress(pc);
if (current_inst == UINT32_MAX)
{
return ValueObjectSP();
}
ValueObjectSP source_path;
for (uint32_t ii = current_inst - 1; ii != (uint32_t)-1; --ii)
{
// This is not an exact algorithm, and it sacrifices accuracy for generality.
// Recognizing "mov" and "ld" instructions –– and which are their source and
// destination operands -- is something the disassembler should do for us.
InstructionSP instruction_sp = disassembler.GetInstructionList().GetInstructionAtIndex(ii);
if (is_in_return_register && instruction_sp->IsCall())
{
llvm::SmallVector<Instruction::Operand, 1> operands;
if (!instruction_sp->ParseOperands(operands) || operands.size() != 1)
{
continue;
}
switch (operands[0].m_type)
{
default:
break;
case Instruction::Operand::Type::Immediate:
{
SymbolContext sc;
Address load_address;
if (!frame.CalculateTarget()->ResolveLoadAddress(operands[0].m_immediate, load_address))
{
break;
}
frame.CalculateTarget()->GetImages().ResolveSymbolContextForAddress(load_address, eSymbolContextFunction, sc);
if (!sc.function)
{
break;
}
CompilerType function_type = sc.function->GetCompilerType();
if (!function_type.IsFunctionType())
{
break;
}
CompilerType return_type = function_type.GetFunctionReturnType();
RegisterValue return_value;
if (!frame.GetRegisterContext()->ReadRegister(&return_register_info, return_value))
{
break;
}
std::string name_str(sc.function->GetName().AsCString("<unknown function>"));
name_str.append("()");
Address return_value_address(return_value.GetAsUInt64());
ValueObjectSP return_value_sp = ValueObjectMemory::Create(&frame, name_str.c_str(), return_value_address, return_type);
return GetValueForDereferincingOffset(frame, return_value_sp, offset);
}
}
continue;
}
llvm::SmallVector<Instruction::Operand, 2> operands;
if (!instruction_sp->ParseOperands(operands) || operands.size() != 2)
{
continue;
}
Instruction::Operand *register_operand = nullptr;
Instruction::Operand *origin_operand = nullptr;
if (operands[0].m_type == Instruction::Operand::Type::Register &&
operands[0].m_clobbered == true &&
operands[0].m_register == reg)
{
register_operand = &operands[0];
origin_operand = &operands[1];
}
else if (operands[1].m_type == Instruction::Operand::Type::Register &&
operands[1].m_clobbered == true &&
operands[1].m_register == reg)
{
register_operand = &operands[1];
origin_operand = &operands[0];
}
else
{
continue;
}
// We have an origin operand. Can we track its value down?
switch (origin_operand->m_type)
{
default:
break;
case Instruction::Operand::Type::Register:
source_path = DoGuessValueAt(frame, origin_operand->m_register, 0, disassembler, variables, instruction_sp->GetAddress());
break;
case Instruction::Operand::Type::Dereference:
{
const Instruction::Operand &pointer = origin_operand->m_children[0];
switch (pointer.m_type)
{
default:
break;
case Instruction::Operand::Type::Register:
source_path = DoGuessValueAt(frame, pointer.m_register, 0, disassembler, variables, instruction_sp->GetAddress());
if (source_path)
{
Error err;
source_path = source_path->Dereference(err);
if (!err.Success())
{
source_path.reset();
}
}
break;
case Instruction::Operand::Type::Sum:
{
const Instruction::Operand *origin_register = nullptr;
const Instruction::Operand *origin_offset = nullptr;
if (pointer.m_children.size() != 2)
{
break;
}
if (pointer.m_children[0].m_type == Instruction::Operand::Type::Register &&
pointer.m_children[1].m_type == Instruction::Operand::Type::Immediate)
{
origin_register = &pointer.m_children[0];
origin_offset = &pointer.m_children[1];
}
else if (pointer.m_children[1].m_type == Instruction::Operand::Type::Register &&
pointer.m_children[0].m_type == Instruction::Operand::Type::Immediate)
{
origin_register = &pointer.m_children[1];
origin_offset = &pointer.m_children[0];
}
if (!origin_register)
{
break;
}
int64_t signed_origin_offset = origin_offset->m_negative ? -((int64_t)origin_offset->m_immediate) : origin_offset->m_immediate;
source_path = DoGuessValueAt(frame, origin_register->m_register, signed_origin_offset, disassembler, variables, instruction_sp->GetAddress());
if (!source_path)
{
break;
}
source_path = GetValueForDereferincingOffset(frame, source_path, offset);
break;
}
}
}
}
if (source_path)
{
return source_path;
}
}
return ValueObjectSP();
}
}
lldb::ValueObjectSP
StackFrame::GuessValueForRegisterAndOffset(ConstString reg, int64_t offset)
{
TargetSP target_sp = CalculateTarget();
const ArchSpec &target_arch = target_sp->GetArchitecture();
Block *frame_block = GetFrameBlock();
if (!frame_block)
{
return ValueObjectSP();
}
Function *function = frame_block->CalculateSymbolContextFunction();
if (!function)
{
return ValueObjectSP();
}
AddressRange pc_range = function->GetAddressRange();
if (GetFrameCodeAddress().GetFileAddress() < pc_range.GetBaseAddress().GetFileAddress() ||
GetFrameCodeAddress().GetFileAddress() - pc_range.GetBaseAddress().GetFileAddress() >= pc_range.GetByteSize())
{
return ValueObjectSP();
}
ExecutionContext exe_ctx (shared_from_this());
const char *plugin_name = nullptr;
const char *flavor = nullptr;
const bool prefer_file_cache = false;
DisassemblerSP disassembler_sp = Disassembler::DisassembleRange (target_arch,
plugin_name,
flavor,
exe_ctx,
pc_range,
prefer_file_cache);
if (!disassembler_sp || !disassembler_sp->GetInstructionList().GetSize())
{
return ValueObjectSP();
}
const bool get_file_globals = false;
VariableList *variables = GetVariableList(get_file_globals);
if (!variables)
{
return ValueObjectSP();
}
return DoGuessValueAt(*this, reg, offset, *disassembler_sp, *variables, GetFrameCodeAddress());
}
The second part in thread hardening the internals of LLDB where we make the lldb_private::StackFrame objects hold onto a weak pointer to the thread object. The lldb_private::StackFrame objects the the most volatile objects we have as when we are doing single stepping, frames can often get lost or thrown away, only to be re-created as another object that still refers to the same frame. We have another bug tracking that. But we need to be able to have frames no longer be able to get the thread when they are not part of a thread anymore, and this is the first step (this fix makes that possible but doesn't implement it yet). Also changed lldb_private::ExecutionContextScope to return shared pointers to all objects in the execution context to further thread harden the internals. llvm-svn: 150871
2012-02-18 13:35:26 +08:00
TargetSP
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
StackFrame::CalculateTarget ()
{
The second part in thread hardening the internals of LLDB where we make the lldb_private::StackFrame objects hold onto a weak pointer to the thread object. The lldb_private::StackFrame objects the the most volatile objects we have as when we are doing single stepping, frames can often get lost or thrown away, only to be re-created as another object that still refers to the same frame. We have another bug tracking that. But we need to be able to have frames no longer be able to get the thread when they are not part of a thread anymore, and this is the first step (this fix makes that possible but doesn't implement it yet). Also changed lldb_private::ExecutionContextScope to return shared pointers to all objects in the execution context to further thread harden the internals. llvm-svn: 150871
2012-02-18 13:35:26 +08:00
TargetSP target_sp;
ThreadSP thread_sp(GetThread());
if (thread_sp)
{
ProcessSP process_sp (thread_sp->CalculateProcess());
if (process_sp)
target_sp = process_sp->CalculateTarget();
}
return target_sp;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
The second part in thread hardening the internals of LLDB where we make the lldb_private::StackFrame objects hold onto a weak pointer to the thread object. The lldb_private::StackFrame objects the the most volatile objects we have as when we are doing single stepping, frames can often get lost or thrown away, only to be re-created as another object that still refers to the same frame. We have another bug tracking that. But we need to be able to have frames no longer be able to get the thread when they are not part of a thread anymore, and this is the first step (this fix makes that possible but doesn't implement it yet). Also changed lldb_private::ExecutionContextScope to return shared pointers to all objects in the execution context to further thread harden the internals. llvm-svn: 150871
2012-02-18 13:35:26 +08:00
ProcessSP
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
StackFrame::CalculateProcess ()
{
The second part in thread hardening the internals of LLDB where we make the lldb_private::StackFrame objects hold onto a weak pointer to the thread object. The lldb_private::StackFrame objects the the most volatile objects we have as when we are doing single stepping, frames can often get lost or thrown away, only to be re-created as another object that still refers to the same frame. We have another bug tracking that. But we need to be able to have frames no longer be able to get the thread when they are not part of a thread anymore, and this is the first step (this fix makes that possible but doesn't implement it yet). Also changed lldb_private::ExecutionContextScope to return shared pointers to all objects in the execution context to further thread harden the internals. llvm-svn: 150871
2012-02-18 13:35:26 +08:00
ProcessSP process_sp;
ThreadSP thread_sp(GetThread());
if (thread_sp)
process_sp = thread_sp->CalculateProcess();
return process_sp;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
The second part in thread hardening the internals of LLDB where we make the lldb_private::StackFrame objects hold onto a weak pointer to the thread object. The lldb_private::StackFrame objects the the most volatile objects we have as when we are doing single stepping, frames can often get lost or thrown away, only to be re-created as another object that still refers to the same frame. We have another bug tracking that. But we need to be able to have frames no longer be able to get the thread when they are not part of a thread anymore, and this is the first step (this fix makes that possible but doesn't implement it yet). Also changed lldb_private::ExecutionContextScope to return shared pointers to all objects in the execution context to further thread harden the internals. llvm-svn: 150871
2012-02-18 13:35:26 +08:00
ThreadSP
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
StackFrame::CalculateThread ()
{
The second part in thread hardening the internals of LLDB where we make the lldb_private::StackFrame objects hold onto a weak pointer to the thread object. The lldb_private::StackFrame objects the the most volatile objects we have as when we are doing single stepping, frames can often get lost or thrown away, only to be re-created as another object that still refers to the same frame. We have another bug tracking that. But we need to be able to have frames no longer be able to get the thread when they are not part of a thread anymore, and this is the first step (this fix makes that possible but doesn't implement it yet). Also changed lldb_private::ExecutionContextScope to return shared pointers to all objects in the execution context to further thread harden the internals. llvm-svn: 150871
2012-02-18 13:35:26 +08:00
return GetThread();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Roll back the changes I made in r193907 which created a new Frame pure virtual base class and made StackFrame a subclass of that. As I started to build on top of that arrangement today, I found that it wasn't working out like I intended. Instead I'll try sticking with the single StackFrame class -- there's too much code duplication to make a more complicated class hierarchy sensible I think. llvm-svn: 193983
2013-11-04 17:33:30 +08:00
StackFrameSP
StackFrame::CalculateStackFrame ()
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
The second part in thread hardening the internals of LLDB where we make the lldb_private::StackFrame objects hold onto a weak pointer to the thread object. The lldb_private::StackFrame objects the the most volatile objects we have as when we are doing single stepping, frames can often get lost or thrown away, only to be re-created as another object that still refers to the same frame. We have another bug tracking that. But we need to be able to have frames no longer be able to get the thread when they are not part of a thread anymore, and this is the first step (this fix makes that possible but doesn't implement it yet). Also changed lldb_private::ExecutionContextScope to return shared pointers to all objects in the execution context to further thread harden the internals. llvm-svn: 150871
2012-02-18 13:35:26 +08:00
return shared_from_this();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
void
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
StackFrame::CalculateExecutionContext (ExecutionContext &exe_ctx)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
The second part in thread hardening the internals of LLDB where we make the lldb_private::StackFrame objects hold onto a weak pointer to the thread object. The lldb_private::StackFrame objects the the most volatile objects we have as when we are doing single stepping, frames can often get lost or thrown away, only to be re-created as another object that still refers to the same frame. We have another bug tracking that. But we need to be able to have frames no longer be able to get the thread when they are not part of a thread anymore, and this is the first step (this fix makes that possible but doesn't implement it yet). Also changed lldb_private::ExecutionContextScope to return shared pointers to all objects in the execution context to further thread harden the internals. llvm-svn: 150871
2012-02-18 13:35:26 +08:00
exe_ctx.SetContext (shared_from_this());
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +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
void
Mark the selected frame of the selected thread in backtraces. <rdar://problem/15252474> llvm-svn: 192989
2013-10-19 01:38:31 +08:00
StackFrame::DumpUsingSettingsFormat (Stream *strm, const char *frame_marker)
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
{
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Target; other minor fixes. llvm-svn: 261242
2016-02-19 02:52:47 +08:00
if (strm == nullptr)
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
return;
GetSymbolContext(eSymbolContextEverything);
The second part in thread hardening the internals of LLDB where we make the lldb_private::StackFrame objects hold onto a weak pointer to the thread object. The lldb_private::StackFrame objects the the most volatile objects we have as when we are doing single stepping, frames can often get lost or thrown away, only to be re-created as another object that still refers to the same frame. We have another bug tracking that. But we need to be able to have frames no longer be able to get the thread when they are not part of a thread anymore, and this is the first step (this fix makes that possible but doesn't implement it yet). Also changed lldb_private::ExecutionContextScope to return shared pointers to all objects in the execution context to further thread harden the internals. llvm-svn: 150871
2012-02-18 13:35:26 +08:00
ExecutionContext exe_ctx (shared_from_this());
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
StreamString s;
Mark the selected frame of the selected thread in backtraces. <rdar://problem/15252474> llvm-svn: 192989
2013-10-19 01:38:31 +08:00
if (frame_marker)
s.PutCString(frame_marker);
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Target; other minor fixes. llvm-svn: 261242
2016-02-19 02:52:47 +08:00
const FormatEntity::Entry *frame_format = nullptr;
The second part in thread hardening the internals of LLDB where we make the lldb_private::StackFrame objects hold onto a weak pointer to the thread object. The lldb_private::StackFrame objects the the most volatile objects we have as when we are doing single stepping, frames can often get lost or thrown away, only to be re-created as another object that still refers to the same frame. We have another bug tracking that. But we need to be able to have frames no longer be able to get the thread when they are not part of a thread anymore, and this is the first step (this fix makes that possible but doesn't implement it yet). Also changed lldb_private::ExecutionContextScope to return shared pointers to all objects in the execution context to further thread harden the internals. llvm-svn: 150871
2012-02-18 13:35:26 +08:00
Target *target = exe_ctx.GetTargetPtr();
if (target)
frame_format = target->GetDebugger().GetFrameFormat();
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Target; other minor fixes. llvm-svn: 261242
2016-02-19 02:52:47 +08:00
if (frame_format && FormatEntity::Format(*frame_format, s, &m_sc, &exe_ctx, nullptr, nullptr, false, false))
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
{
strm->Write(s.GetData(), s.GetSize());
}
else
{
Dump (strm, true, false);
strm->EOL();
}
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
void
Added a new bool parameter to many of the DumpStopContext() methods that might dump file paths that allows the dumping of full paths or just the basenames. Switched the stack frame dumping code to use just the basenames for the files instead of the full path. Modified the StackID class to no rely on needing the start PC for the current function/symbol since we can use the SymbolContextScope to uniquely identify that, unless there is no symbol context scope. In that case we can rely upon the current PC value. This saves the StackID from having to calculate the start PC when the StackFrame::GetStackID() accessor is called. Also improved the StackID less than operator to correctly handle inlined stack frames in the same stack. llvm-svn: 112867
2010-09-03 05:44:10 +08:00
StackFrame::Dump (Stream *strm, bool show_frame_index, bool show_fullpaths)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Target; other minor fixes. llvm-svn: 261242
2016-02-19 02:52:47 +08:00
if (strm == nullptr)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return;
if (show_frame_index)
Added support for inlined stack frames being represented as real stack frames which is now on by default. Frames are gotten from the unwinder as concrete frames, then if inline frames are to be shown, extra information to track and reconstruct these frames is cached with each Thread and exanded as needed. I added an inline height as part of the lldb_private::StackID class, the class that helps us uniquely identify stack frames. This allows for two frames to shared the same call frame address, yet differ only in inline height. Fixed setting breakpoint by address to not require addresses to resolve. A quick example: % cat main.cpp % ./build/Debug/lldb test/stl/a.out Current executable set to 'test/stl/a.out' (x86_64). (lldb) breakpoint set --address 0x0000000100000d31 Breakpoint created: 1: address = 0x0000000100000d31, locations = 1 (lldb) r Launching 'a.out' (x86_64) (lldb) Process 38031 Stopped * thread #1: tid = 0x2e03, pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280, stop reason = breakpoint 1.1, queue = com.apple.main-thread 277 278 _CharT* 279 _M_data() const 280 -> { return _M_dataplus._M_p; } 281 282 _CharT* 283 _M_data(_CharT* __p) (lldb) bt thread #1: tid = 0x2e03, stop reason = breakpoint 1.1, queue = com.apple.main-thread frame #0: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280 frame #1: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_rep() const at /usr/include/c++/4.2.1/bits/basic_string.h:288 frame #2: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::size() const at /usr/include/c++/4.2.1/bits/basic_string.h:606 frame #3: pc = 0x0000000100000d31, where = a.out`main [inlined] operator<< <char, std::char_traits<char>, std::allocator<char> > at /usr/include/c++/4.2.1/bits/basic_string.h:2414 frame #4: pc = 0x0000000100000d31, where = a.out`main + 33 at /Volumes/work/gclayton/Documents/src/lldb/test/stl/main.cpp:14 frame #5: pc = 0x0000000100000d08, where = a.out`start + 52 Each inline frame contains only the variables that they contain and each inlined stack frame is treated as a single entity. llvm-svn: 111877
2010-08-24 08:45:41 +08:00
strm->Printf("frame #%u: ", m_frame_index);
The second part in thread hardening the internals of LLDB where we make the lldb_private::StackFrame objects hold onto a weak pointer to the thread object. The lldb_private::StackFrame objects the the most volatile objects we have as when we are doing single stepping, frames can often get lost or thrown away, only to be re-created as another object that still refers to the same frame. We have another bug tracking that. But we need to be able to have frames no longer be able to get the thread when they are not part of a thread anymore, and this is the first step (this fix makes that possible but doesn't implement it yet). Also changed lldb_private::ExecutionContextScope to return shared pointers to all objects in the execution context to further thread harden the internals. llvm-svn: 150871
2012-02-18 13:35:26 +08:00
ExecutionContext exe_ctx (shared_from_this());
Target *target = exe_ctx.GetTargetPtr();
Resolve printf formatting warnings on Linux: - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
2012-11-30 05:49:15 +08:00
strm->Printf("0x%0*" PRIx64 " ",
The second part in thread hardening the internals of LLDB where we make the lldb_private::StackFrame objects hold onto a weak pointer to the thread object. The lldb_private::StackFrame objects the the most volatile objects we have as when we are doing single stepping, frames can often get lost or thrown away, only to be re-created as another object that still refers to the same frame. We have another bug tracking that. But we need to be able to have frames no longer be able to get the thread when they are not part of a thread anymore, and this is the first step (this fix makes that possible but doesn't implement it yet). Also changed lldb_private::ExecutionContextScope to return shared pointers to all objects in the execution context to further thread harden the internals. llvm-svn: 150871
2012-02-18 13:35:26 +08:00
target ? (target->GetArchitecture().GetAddressByteSize() * 2) : 16,
GetFrameCodeAddress().GetLoadAddress(target));
Got a lot of the kinks worked out in the inline support after debugging more complex inlined examples. StackFrame classes don't have a "GetPC" anymore, they have "GetFrameCodeAddress()". This is because inlined frames will have a PC value that is the same as the concrete frame that owns the inlined frame, yet the code locations for the frame can be different. We also need to be able to get the real PC value for a given frame so that variables evaluate correctly. To get the actual PC value for a frame you can use: addr_t pc = frame->GetRegisterContext()->GetPC(); Some issues with the StackFrame stomping on its own symbol context were resolved which were causing the information to change for a frame when the stack ID was calculated. Also the StackFrame will now correctly store the symbol context resolve flags for any extra bits of information that were looked up (if you ask for a block only and you find one, you will alwasy have the compile unit and function). llvm-svn: 111964
2010-08-25 05:05:24 +08:00
GetSymbolContext(eSymbolContextEverything);
Added support for inlined stack frames being represented as real stack frames which is now on by default. Frames are gotten from the unwinder as concrete frames, then if inline frames are to be shown, extra information to track and reconstruct these frames is cached with each Thread and exanded as needed. I added an inline height as part of the lldb_private::StackID class, the class that helps us uniquely identify stack frames. This allows for two frames to shared the same call frame address, yet differ only in inline height. Fixed setting breakpoint by address to not require addresses to resolve. A quick example: % cat main.cpp % ./build/Debug/lldb test/stl/a.out Current executable set to 'test/stl/a.out' (x86_64). (lldb) breakpoint set --address 0x0000000100000d31 Breakpoint created: 1: address = 0x0000000100000d31, locations = 1 (lldb) r Launching 'a.out' (x86_64) (lldb) Process 38031 Stopped * thread #1: tid = 0x2e03, pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280, stop reason = breakpoint 1.1, queue = com.apple.main-thread 277 278 _CharT* 279 _M_data() const 280 -> { return _M_dataplus._M_p; } 281 282 _CharT* 283 _M_data(_CharT* __p) (lldb) bt thread #1: tid = 0x2e03, stop reason = breakpoint 1.1, queue = com.apple.main-thread frame #0: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_data() const at /usr/include/c++/4.2.1/bits/basic_string.h:280 frame #1: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::_M_rep() const at /usr/include/c++/4.2.1/bits/basic_string.h:288 frame #2: pc = 0x0000000100000d31, where = a.out`main [inlined] std::string::size() const at /usr/include/c++/4.2.1/bits/basic_string.h:606 frame #3: pc = 0x0000000100000d31, where = a.out`main [inlined] operator<< <char, std::char_traits<char>, std::allocator<char> > at /usr/include/c++/4.2.1/bits/basic_string.h:2414 frame #4: pc = 0x0000000100000d31, where = a.out`main + 33 at /Volumes/work/gclayton/Documents/src/lldb/test/stl/main.cpp:14 frame #5: pc = 0x0000000100000d08, where = a.out`start + 52 Each inline frame contains only the variables that they contain and each inlined stack frame is treated as a single entity. llvm-svn: 111877
2010-08-24 08:45:41 +08:00
const bool show_module = true;
const bool show_inline = true;
Add a new disassembly-format specification so that the disassembler output style can be customized. Change the built-in default to be more similar to gdb's disassembly formatting. The disassembly-format for a gdb-like output is ${addr-file-or-load} <${function.name-without-args}${function.concrete-only-addr-offset-no-padding}>: The disassembly-format for the lldb style output is {${function.initial-function}{${module.file.basename}`}{${function.name-without-args}}:\n}{${function.changed}\n{${module.file.basename}`}{${function.name-without-args}}:\n}{${current-pc-arrow} }{${addr-file-or-load}}: The two backticks in the lldb style formatter triggers the sub-expression evaluation in CommandInterpreter::PreprocessCommand() so you can't use that one as-is ... changing to use ' characters instead of ` would work around that. <rdar://problem/9885398> llvm-svn: 219544
2014-10-11 07:07:36 +08:00
const bool show_function_arguments = true;
Change the default disassembly format again. First attempt at changing it was in r219544 - after living on that for a few months, I wanted to take another crack at this. The disassembly-format setting still exists and the old format can be user specified with a setting like ${current-pc-arrow}${addr-file-or-load}{ <${function.name-without-args}${function.concrete-only-addr-offset-no-padding}>}: This patch was discussed in http://reviews.llvm.org/D7578 <rdar://problem/19726421> llvm-svn: 229186
2015-02-14 07:24:21 +08:00
const bool show_function_name = true;
The second part in thread hardening the internals of LLDB where we make the lldb_private::StackFrame objects hold onto a weak pointer to the thread object. The lldb_private::StackFrame objects the the most volatile objects we have as when we are doing single stepping, frames can often get lost or thrown away, only to be re-created as another object that still refers to the same frame. We have another bug tracking that. But we need to be able to have frames no longer be able to get the thread when they are not part of a thread anymore, and this is the first step (this fix makes that possible but doesn't implement it yet). Also changed lldb_private::ExecutionContextScope to return shared pointers to all objects in the execution context to further thread harden the internals. llvm-svn: 150871
2012-02-18 13:35:26 +08:00
m_sc.DumpStopContext (strm,
exe_ctx.GetBestExecutionContextScope(),
GetFrameCodeAddress(),
show_fullpaths,
show_module,
Add a new disassembly-format specification so that the disassembler output style can be customized. Change the built-in default to be more similar to gdb's disassembly formatting. The disassembly-format for a gdb-like output is ${addr-file-or-load} <${function.name-without-args}${function.concrete-only-addr-offset-no-padding}>: The disassembly-format for the lldb style output is {${function.initial-function}{${module.file.basename}`}{${function.name-without-args}}:\n}{${function.changed}\n{${module.file.basename}`}{${function.name-without-args}}:\n}{${current-pc-arrow} }{${addr-file-or-load}}: The two backticks in the lldb style formatter triggers the sub-expression evaluation in CommandInterpreter::PreprocessCommand() so you can't use that one as-is ... changing to use ' characters instead of ` would work around that. <rdar://problem/9885398> llvm-svn: 219544
2014-10-11 07:07:36 +08:00
show_inline,
Change the default disassembly format again. First attempt at changing it was in r219544 - after living on that for a few months, I wanted to take another crack at this. The disassembly-format setting still exists and the old format can be user specified with a setting like ${current-pc-arrow}${addr-file-or-load}{ <${function.name-without-args}${function.concrete-only-addr-offset-no-padding}>}: This patch was discussed in http://reviews.llvm.org/D7578 <rdar://problem/19726421> llvm-svn: 229186
2015-02-14 07:24:21 +08:00
show_function_arguments,
show_function_name);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Simplified the StackFrameList class down to a single frames list again instead of trying to maintain the real frame list (unwind frames) and an inline frame list. The information is cheap to produce when we already have looked up a block and was making stack frame uniquing difficult when trying to use the previous stack when making the current stack. We now maintain the previous value object lists for common frames between a previous and current frames so we will be able to tell when variable values change. llvm-svn: 112277
2010-08-28 02:24:16 +08:00
void
Roll back the changes I made in r193907 which created a new Frame pure virtual base class and made StackFrame a subclass of that. As I started to build on top of that arrangement today, I found that it wasn't working out like I intended. Instead I'll try sticking with the single StackFrame class -- there's too much code duplication to make a more complicated class hierarchy sensible I think. llvm-svn: 193983
2013-11-04 17:33:30 +08:00
StackFrame::UpdateCurrentFrameFromPreviousFrame (StackFrame &prev_frame)
Simplified the StackFrameList class down to a single frames list again instead of trying to maintain the real frame list (unwind frames) and an inline frame list. The information is cheap to produce when we already have looked up a block and was making stack frame uniquing difficult when trying to use the previous stack when making the current stack. We now maintain the previous value object lists for common frames between a previous and current frames so we will be able to tell when variable values change. llvm-svn: 112277
2010-08-28 02:24:16 +08:00
{
second pass over removal of Mutex and Condition llvm-svn: 270024
2016-05-19 13:13:57 +08:00
std::lock_guard<std::recursive_mutex> guard(m_mutex);
Clarified the intent of the SymbolContextScope class in the header documentation. Symbol now inherits from the symbol context scope so that the StackID can use a "SymbolContextScope *" instead of a blockID (which could have been the same as some other blockID from another symbol file). Modified the stacks that are created on subsequent stops to reuse the previous stack frame objects which will allow for some internal optimization using pointer comparisons during stepping. llvm-svn: 112495
2010-08-31 02:11:35 +08:00
assert (GetStackID() == prev_frame.GetStackID()); // TODO: remove this after some testing
Roll back the changes I made in r193907 which created a new Frame pure virtual base class and made StackFrame a subclass of that. As I started to build on top of that arrangement today, I found that it wasn't working out like I intended. Instead I'll try sticking with the single StackFrame class -- there's too much code duplication to make a more complicated class hierarchy sensible I think. llvm-svn: 193983
2013-11-04 17:33:30 +08:00
m_variable_list_sp = prev_frame.m_variable_list_sp;
m_variable_list_value_objects.Swap (prev_frame.m_variable_list_value_objects);
if (!m_disassembly.GetString().empty())
m_disassembly.GetString().swap (m_disassembly.GetString());
Simplified the StackFrameList class down to a single frames list again instead of trying to maintain the real frame list (unwind frames) and an inline frame list. The information is cheap to produce when we already have looked up a block and was making stack frame uniquing difficult when trying to use the previous stack when making the current stack. We now maintain the previous value object lists for common frames between a previous and current frames so we will be able to tell when variable values change. llvm-svn: 112277
2010-08-28 02:24:16 +08:00
}
Made it so we update the current frames from the previous frames by doing STL swaps on the variable list, value object list, and disassembly. This avoids us having to try and update frame indexes and other things that were getting out of sync. llvm-svn: 112301
2010-08-28 05:47:54 +08:00
Clarified the intent of the SymbolContextScope class in the header documentation. Symbol now inherits from the symbol context scope so that the StackID can use a "SymbolContextScope *" instead of a blockID (which could have been the same as some other blockID from another symbol file). Modified the stacks that are created on subsequent stops to reuse the previous stack frame objects which will allow for some internal optimization using pointer comparisons during stepping. llvm-svn: 112495
2010-08-31 02:11:35 +08:00
void
Roll back the changes I made in r193907 which created a new Frame pure virtual base class and made StackFrame a subclass of that. As I started to build on top of that arrangement today, I found that it wasn't working out like I intended. Instead I'll try sticking with the single StackFrame class -- there's too much code duplication to make a more complicated class hierarchy sensible I think. llvm-svn: 193983
2013-11-04 17:33:30 +08:00
StackFrame::UpdatePreviousFrameFromCurrentFrame (StackFrame &curr_frame)
Clarified the intent of the SymbolContextScope class in the header documentation. Symbol now inherits from the symbol context scope so that the StackID can use a "SymbolContextScope *" instead of a blockID (which could have been the same as some other blockID from another symbol file). Modified the stacks that are created on subsequent stops to reuse the previous stack frame objects which will allow for some internal optimization using pointer comparisons during stepping. llvm-svn: 112495
2010-08-31 02:11:35 +08:00
{
second pass over removal of Mutex and Condition llvm-svn: 270024
2016-05-19 13:13:57 +08:00
std::lock_guard<std::recursive_mutex> guard(m_mutex);
Fixed the StackFrame to correctly resolve the StackID's SymbolContextScope. Added extra logging for stepping. Fixed an issue where cached stack frame data could be lost between runs when the thread plans read a stack frame. llvm-svn: 112973
2010-09-04 01:10:42 +08:00
assert (GetStackID() == curr_frame.GetStackID()); // TODO: remove this after some testing
Roll back the changes I made in r193907 which created a new Frame pure virtual base class and made StackFrame a subclass of that. As I started to build on top of that arrangement today, I found that it wasn't working out like I intended. Instead I'll try sticking with the single StackFrame class -- there's too much code duplication to make a more complicated class hierarchy sensible I think. llvm-svn: 193983
2013-11-04 17:33:30 +08:00
m_id.SetPC (curr_frame.m_id.GetPC()); // Update the Stack ID PC value
assert (GetThread() == curr_frame.GetThread());
m_frame_index = curr_frame.m_frame_index;
m_concrete_frame_index = curr_frame.m_concrete_frame_index;
m_reg_context_sp = curr_frame.m_reg_context_sp;
m_frame_code_addr = curr_frame.m_frame_code_addr;
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Target; other minor fixes. llvm-svn: 261242
2016-02-19 02:52:47 +08:00
assert (!m_sc.target_sp || !curr_frame.m_sc.target_sp || m_sc.target_sp.get() == curr_frame.m_sc.target_sp.get());
assert (!m_sc.module_sp || !curr_frame.m_sc.module_sp || m_sc.module_sp.get() == curr_frame.m_sc.module_sp.get());
assert (m_sc.comp_unit == nullptr || curr_frame.m_sc.comp_unit == nullptr || m_sc.comp_unit == curr_frame.m_sc.comp_unit);
assert (m_sc.function == nullptr || curr_frame.m_sc.function == nullptr || m_sc.function == curr_frame.m_sc.function);
Roll back the changes I made in r193907 which created a new Frame pure virtual base class and made StackFrame a subclass of that. As I started to build on top of that arrangement today, I found that it wasn't working out like I intended. Instead I'll try sticking with the single StackFrame class -- there's too much code duplication to make a more complicated class hierarchy sensible I think. llvm-svn: 193983
2013-11-04 17:33:30 +08:00
m_sc = curr_frame.m_sc;
m_flags.Clear(GOT_FRAME_BASE | eSymbolContextEverything);
m_flags.Set (m_sc.GetResolvedMask());
m_frame_base.Clear();
m_frame_base_error.Clear();
Clarified the intent of the SymbolContextScope class in the header documentation. Symbol now inherits from the symbol context scope so that the StackID can use a "SymbolContextScope *" instead of a blockID (which could have been the same as some other blockID from another symbol file). Modified the stacks that are created on subsequent stops to reuse the previous stack frame objects which will allow for some internal optimization using pointer comparisons during stepping. llvm-svn: 112495
2010-08-31 02:11:35 +08:00
}
Roll back the changes I made in r193907 which created a new Frame pure virtual base class and made StackFrame a subclass of that. As I started to build on top of that arrangement today, I found that it wasn't working out like I intended. Instead I'll try sticking with the single StackFrame class -- there's too much code duplication to make a more complicated class hierarchy sensible I think. llvm-svn: 193983
2013-11-04 17:33:30 +08:00
bool
StackFrame::HasCachedData () const
{
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Target; other minor fixes. llvm-svn: 261242
2016-02-19 02:52:47 +08:00
if (m_variable_list_sp)
Roll back the changes I made in r193907 which created a new Frame pure virtual base class and made StackFrame a subclass of that. As I started to build on top of that arrangement today, I found that it wasn't working out like I intended. Instead I'll try sticking with the single StackFrame class -- there's too much code duplication to make a more complicated class hierarchy sensible I think. llvm-svn: 193983
2013-11-04 17:33:30 +08:00
return true;
if (m_variable_list_value_objects.GetSize() > 0)
return true;
if (!m_disassembly.GetString().empty())
return true;
return false;
}
Centralized a lot of the status information for processes, threads, and stack frame down in the lldb_private::Process, lldb_private::Thread, lldb_private::StackFrameList and the lldb_private::StackFrame classes. We had some command line commands that had duplicate versions of the process status output ("thread list" and "process status" for example). Removed the "file" command and placed it where it should have been: "target create". Made an alias for "file" to "target create" so we stay compatible with GDB commands. We can now have multple usable targets in lldb at the same time. This is nice for comparing two runs of a program or debugging more than one binary at the same time. The new command is "target select <target-idx>" and also to see a list of the current targets you can use the new "target list" command. The flow in a debug session can be: (lldb) target create /path/to/exe/a.out (lldb) breakpoint set --name main (lldb) run ... hit breakpoint (lldb) target create /bin/ls (lldb) run /tmp Process 36001 exited with status = 0 (0x00000000) (lldb) target list Current targets: target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) * target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) target select 0 Current targets: * target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) bt * thread #1: tid = 0x2d03, 0x0000000100000b9a a.out`main + 42 at main.c:16, stop reason = breakpoint 1.1 frame #0: 0x0000000100000b9a a.out`main + 42 at main.c:16 frame #1: 0x0000000100000b64 a.out`start + 52 Above we created a target for "a.out" and ran and hit a breakpoint at "main". Then we created a new target for /bin/ls and ran it. Then we listed the targest and selected our original "a.out" program, so we showed two concurent debug sessions going on at the same time. llvm-svn: 129695
2011-04-18 16:33:37 +08:00
bool
StackFrame::GetStatus (Stream& strm,
bool show_frame_info,
Mark the selected frame of the selected thread in backtraces. <rdar://problem/15252474> llvm-svn: 192989
2013-10-19 01:38:31 +08:00
bool show_source,
const char *frame_marker)
Centralized a lot of the status information for processes, threads, and stack frame down in the lldb_private::Process, lldb_private::Thread, lldb_private::StackFrameList and the lldb_private::StackFrame classes. We had some command line commands that had duplicate versions of the process status output ("thread list" and "process status" for example). Removed the "file" command and placed it where it should have been: "target create". Made an alias for "file" to "target create" so we stay compatible with GDB commands. We can now have multple usable targets in lldb at the same time. This is nice for comparing two runs of a program or debugging more than one binary at the same time. The new command is "target select <target-idx>" and also to see a list of the current targets you can use the new "target list" command. The flow in a debug session can be: (lldb) target create /path/to/exe/a.out (lldb) breakpoint set --name main (lldb) run ... hit breakpoint (lldb) target create /bin/ls (lldb) run /tmp Process 36001 exited with status = 0 (0x00000000) (lldb) target list Current targets: target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) * target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) target select 0 Current targets: * target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) bt * thread #1: tid = 0x2d03, 0x0000000100000b9a a.out`main + 42 at main.c:16, stop reason = breakpoint 1.1 frame #0: 0x0000000100000b9a a.out`main + 42 at main.c:16 frame #1: 0x0000000100000b64 a.out`start + 52 Above we created a target for "a.out" and ran and hit a breakpoint at "main". Then we created a new target for /bin/ls and ran it. Then we listed the targest and selected our original "a.out" program, so we showed two concurent debug sessions going on at the same time. llvm-svn: 129695
2011-04-18 16:33:37 +08:00
{
<rdar://problem/11852100> The "stop-line-count-after" and "stop-line-count-before" settings are broken. This fixes them. llvm-svn: 160071
2012-07-12 04:33:48 +08:00
Centralized a lot of the status information for processes, threads, and stack frame down in the lldb_private::Process, lldb_private::Thread, lldb_private::StackFrameList and the lldb_private::StackFrame classes. We had some command line commands that had duplicate versions of the process status output ("thread list" and "process status" for example). Removed the "file" command and placed it where it should have been: "target create". Made an alias for "file" to "target create" so we stay compatible with GDB commands. We can now have multple usable targets in lldb at the same time. This is nice for comparing two runs of a program or debugging more than one binary at the same time. The new command is "target select <target-idx>" and also to see a list of the current targets you can use the new "target list" command. The flow in a debug session can be: (lldb) target create /path/to/exe/a.out (lldb) breakpoint set --name main (lldb) run ... hit breakpoint (lldb) target create /bin/ls (lldb) run /tmp Process 36001 exited with status = 0 (0x00000000) (lldb) target list Current targets: target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) * target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) target select 0 Current targets: * target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) bt * thread #1: tid = 0x2d03, 0x0000000100000b9a a.out`main + 42 at main.c:16, stop reason = breakpoint 1.1 frame #0: 0x0000000100000b9a a.out`main + 42 at main.c:16 frame #1: 0x0000000100000b64 a.out`start + 52 Above we created a target for "a.out" and ran and hit a breakpoint at "main". Then we created a new target for /bin/ls and ran it. Then we listed the targest and selected our original "a.out" program, so we showed two concurent debug sessions going on at the same time. llvm-svn: 129695
2011-04-18 16:33:37 +08:00
if (show_frame_info)
{
strm.Indent();
Mark the selected frame of the selected thread in backtraces. <rdar://problem/15252474> llvm-svn: 192989
2013-10-19 01:38:31 +08:00
DumpUsingSettingsFormat (&strm, frame_marker);
Centralized a lot of the status information for processes, threads, and stack frame down in the lldb_private::Process, lldb_private::Thread, lldb_private::StackFrameList and the lldb_private::StackFrame classes. We had some command line commands that had duplicate versions of the process status output ("thread list" and "process status" for example). Removed the "file" command and placed it where it should have been: "target create". Made an alias for "file" to "target create" so we stay compatible with GDB commands. We can now have multple usable targets in lldb at the same time. This is nice for comparing two runs of a program or debugging more than one binary at the same time. The new command is "target select <target-idx>" and also to see a list of the current targets you can use the new "target list" command. The flow in a debug session can be: (lldb) target create /path/to/exe/a.out (lldb) breakpoint set --name main (lldb) run ... hit breakpoint (lldb) target create /bin/ls (lldb) run /tmp Process 36001 exited with status = 0 (0x00000000) (lldb) target list Current targets: target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) * target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) target select 0 Current targets: * target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) bt * thread #1: tid = 0x2d03, 0x0000000100000b9a a.out`main + 42 at main.c:16, stop reason = breakpoint 1.1 frame #0: 0x0000000100000b9a a.out`main + 42 at main.c:16 frame #1: 0x0000000100000b64 a.out`start + 52 Above we created a target for "a.out" and ran and hit a breakpoint at "main". Then we created a new target for /bin/ls and ran it. Then we listed the targest and selected our original "a.out" program, so we showed two concurent debug sessions going on at the same time. llvm-svn: 129695
2011-04-18 16:33:37 +08:00
}
if (show_source)
{
The second part in thread hardening the internals of LLDB where we make the lldb_private::StackFrame objects hold onto a weak pointer to the thread object. The lldb_private::StackFrame objects the the most volatile objects we have as when we are doing single stepping, frames can often get lost or thrown away, only to be re-created as another object that still refers to the same frame. We have another bug tracking that. But we need to be able to have frames no longer be able to get the thread when they are not part of a thread anymore, and this is the first step (this fix makes that possible but doesn't implement it yet). Also changed lldb_private::ExecutionContextScope to return shared pointers to all objects in the execution context to further thread harden the internals. llvm-svn: 150871
2012-02-18 13:35:26 +08:00
ExecutionContext exe_ctx (shared_from_this());
[LLDB] Switch to assembly view if source is moved Reviewers: clayborg, jingham, jasonmolenda. Subscribers: jaydeep, bhushan, sagar, nitesh.jain,lldb-commits. Differential Revision: http://reviews.llvm.org/D12877 llvm-svn: 254588
2015-12-03 12:56:16 +08:00
bool have_source = false, have_debuginfo = false;
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 disasm_display = Debugger::eStopDisassemblyTypeNever;
The second part in thread hardening the internals of LLDB where we make the lldb_private::StackFrame objects hold onto a weak pointer to the thread object. The lldb_private::StackFrame objects the the most volatile objects we have as when we are doing single stepping, frames can often get lost or thrown away, only to be re-created as another object that still refers to the same frame. We have another bug tracking that. But we need to be able to have frames no longer be able to get the thread when they are not part of a thread anymore, and this is the first step (this fix makes that possible but doesn't implement it yet). Also changed lldb_private::ExecutionContextScope to return shared pointers to all objects in the execution context to further thread harden the internals. llvm-svn: 150871
2012-02-18 13:35:26 +08:00
Target *target = exe_ctx.GetTargetPtr();
<rdar://problem/11852100> The "stop-line-count-after" and "stop-line-count-before" settings are broken. This fixes them. llvm-svn: 160071
2012-07-12 04:33:48 +08:00
if (target)
Centralized a lot of the status information for processes, threads, and stack frame down in the lldb_private::Process, lldb_private::Thread, lldb_private::StackFrameList and the lldb_private::StackFrame classes. We had some command line commands that had duplicate versions of the process status output ("thread list" and "process status" for example). Removed the "file" command and placed it where it should have been: "target create". Made an alias for "file" to "target create" so we stay compatible with GDB commands. We can now have multple usable targets in lldb at the same time. This is nice for comparing two runs of a program or debugging more than one binary at the same time. The new command is "target select <target-idx>" and also to see a list of the current targets you can use the new "target list" command. The flow in a debug session can be: (lldb) target create /path/to/exe/a.out (lldb) breakpoint set --name main (lldb) run ... hit breakpoint (lldb) target create /bin/ls (lldb) run /tmp Process 36001 exited with status = 0 (0x00000000) (lldb) target list Current targets: target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) * target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) target select 0 Current targets: * target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) bt * thread #1: tid = 0x2d03, 0x0000000100000b9a a.out`main + 42 at main.c:16, stop reason = breakpoint 1.1 frame #0: 0x0000000100000b9a a.out`main + 42 at main.c:16 frame #1: 0x0000000100000b64 a.out`start + 52 Above we created a target for "a.out" and ran and hit a breakpoint at "main". Then we created a new target for /bin/ls and ran it. Then we listed the targest and selected our original "a.out" program, so we showed two concurent debug sessions going on at the same time. llvm-svn: 129695
2011-04-18 16:33:37 +08:00
{
<rdar://problem/11852100> The "stop-line-count-after" and "stop-line-count-before" settings are broken. This fixes them. llvm-svn: 160071
2012-07-12 04:33:48 +08:00
Debugger &debugger = target->GetDebugger();
const uint32_t source_lines_before = debugger.GetStopSourceLineCount(true);
const uint32_t source_lines_after = debugger.GetStopSourceLineCount(false);
disasm_display = debugger.GetStopDisassemblyDisplay ();
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
Allow specification of no source display on stop. See http://llvm.org/bugs/show_bug.cgi?id=20149 for details. Change by Randy Smith. llvm-svn: 212485
2014-07-08 04:47:24 +08:00
GetSymbolContext(eSymbolContextCompUnit | eSymbolContextLineEntry);
if (m_sc.comp_unit && m_sc.line_entry.IsValid())
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
{
[LLDB] Switch to assembly view if source is moved Reviewers: clayborg, jingham, jasonmolenda. Subscribers: jaydeep, bhushan, sagar, nitesh.jain,lldb-commits. Differential Revision: http://reviews.llvm.org/D12877 llvm-svn: 254588
2015-12-03 12:56:16 +08:00
have_debuginfo = true;
Allow specification of no source display on stop. See http://llvm.org/bugs/show_bug.cgi?id=20149 for details. Change by Randy Smith. llvm-svn: 212485
2014-07-08 04:47:24 +08:00
if (source_lines_before > 0 || source_lines_after > 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
{
[LLDB] Switch to assembly view if source is moved Reviewers: clayborg, jingham, jasonmolenda. Subscribers: jaydeep, bhushan, sagar, nitesh.jain,lldb-commits. Differential Revision: http://reviews.llvm.org/D12877 llvm-svn: 254588
2015-12-03 12:56:16 +08:00
size_t num_lines = target->GetSourceManager().DisplaySourceLinesWithLineNumbers (m_sc.line_entry.file,
<rdar://problem/11852100> The "stop-line-count-after" and "stop-line-count-before" settings are broken. This fixes them. llvm-svn: 160071
2012-07-12 04:33:48 +08:00
m_sc.line_entry.line,
source_lines_before,
source_lines_after,
"->",
When lldb stops in a stack frame where we have source level information (file, line number), don't print the disassembly context around $pc -- just print the filename and line number, even if we can't show the source code. Previously if the source file was not available, lldb would print the source filename & line number and assembly. <rdar://problem/13072951> llvm-svn: 180706
2013-04-29 17:59:31 +08:00
&strm);
[LLDB] Switch to assembly view if source is moved Reviewers: clayborg, jingham, jasonmolenda. Subscribers: jaydeep, bhushan, sagar, nitesh.jain,lldb-commits. Differential Revision: http://reviews.llvm.org/D12877 llvm-svn: 254588
2015-12-03 12:56:16 +08:00
if (num_lines != 0)
have_source = true;
// TODO: Give here a one time warning if source file is missing.
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
}
}
<rdar://problem/11852100> The "stop-line-count-after" and "stop-line-count-before" settings are broken. This fixes them. llvm-svn: 160071
2012-07-12 04:33:48 +08:00
switch (disasm_display)
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
case Debugger::eStopDisassemblyTypeNever:
<rdar://problem/11852100> The "stop-line-count-after" and "stop-line-count-before" settings are broken. This fixes them. llvm-svn: 160071
2012-07-12 04:33:48 +08:00
break;
[LLDB] Switch to assembly view if source is moved Reviewers: clayborg, jingham, jasonmolenda. Subscribers: jaydeep, bhushan, sagar, nitesh.jain,lldb-commits. Differential Revision: http://reviews.llvm.org/D12877 llvm-svn: 254588
2015-12-03 12:56:16 +08:00
case Debugger::eStopDisassemblyTypeNoDebugInfo:
if (have_debuginfo)
break;
Add -Wimplicit-fallthrough command line option to clang in the xcode project file to catch switch statements that have a case that falls through unintentionally. Define LLVM_FALLTHROUGH to indicate instances where a case has code and intends to fall through. This should be in llvm/Support/Compiler.h; Peter Collingbourne originally checked in there (r237766), then reverted (r237941) because he didn't have time to mark up all the 'case' statements that were intended to fall through. I put together a patch to get this back in llvm http://reviews.llvm.org/D17063 but it hasn't been approved in the past week. I added a new lldb-private-defines.h to hold the definition for now. Every place in lldb where there is a comment that the fall-through is intentional, I added LLVM_FALLTHROUGH to silence the warning. I haven't tried to identify whether the fallthrough is a bug or not in the other places. I haven't tried to add this to the cmake option build flags. This warning will only work for clang. This build cleanly (with some new warnings) on macosx with clang under xcodebuild, but if this causes problems for people on other configurations, I'll back it out. llvm-svn: 260930
2016-02-16 12:14:33 +08:00
LLVM_FALLTHROUGH;
[LLDB] Switch to assembly view if source is moved Reviewers: clayborg, jingham, jasonmolenda. Subscribers: jaydeep, bhushan, sagar, nitesh.jain,lldb-commits. Differential Revision: http://reviews.llvm.org/D12877 llvm-svn: 254588
2015-12-03 12:56:16 +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
case Debugger::eStopDisassemblyTypeNoSource:
<rdar://problem/11852100> The "stop-line-count-after" and "stop-line-count-before" settings are broken. This fixes them. llvm-svn: 160071
2012-07-12 04:33:48 +08:00
if (have_source)
break;
Add -Wimplicit-fallthrough command line option to clang in the xcode project file to catch switch statements that have a case that falls through unintentionally. Define LLVM_FALLTHROUGH to indicate instances where a case has code and intends to fall through. This should be in llvm/Support/Compiler.h; Peter Collingbourne originally checked in there (r237766), then reverted (r237941) because he didn't have time to mark up all the 'case' statements that were intended to fall through. I put together a patch to get this back in llvm http://reviews.llvm.org/D17063 but it hasn't been approved in the past week. I added a new lldb-private-defines.h to hold the definition for now. Every place in lldb where there is a comment that the fall-through is intentional, I added LLVM_FALLTHROUGH to silence the warning. I haven't tried to identify whether the fallthrough is a bug or not in the other places. I haven't tried to add this to the cmake option build flags. This warning will only work for clang. This build cleanly (with some new warnings) on macosx with clang under xcodebuild, but if this causes problems for people on other configurations, I'll back it out. llvm-svn: 260930
2016-02-16 12:14:33 +08:00
LLVM_FALLTHROUGH;
[LLDB] Switch to assembly view if source is moved Reviewers: clayborg, jingham, jasonmolenda. Subscribers: jaydeep, bhushan, sagar, nitesh.jain,lldb-commits. Differential Revision: http://reviews.llvm.org/D12877 llvm-svn: 254588
2015-12-03 12:56:16 +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
case Debugger::eStopDisassemblyTypeAlways:
<rdar://problem/11852100> The "stop-line-count-after" and "stop-line-count-before" settings are broken. This fixes them. llvm-svn: 160071
2012-07-12 04:33:48 +08:00
if (target)
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
{
<rdar://problem/11852100> The "stop-line-count-after" and "stop-line-count-before" settings are broken. This fixes them. llvm-svn: 160071
2012-07-12 04:33:48 +08:00
const uint32_t disasm_lines = debugger.GetDisassemblyLineCount();
if (disasm_lines > 0)
{
const ArchSpec &target_arch = target->GetArchitecture();
AddressRange pc_range;
pc_range.GetBaseAddress() = GetFrameCodeAddress();
pc_range.SetByteSize(disasm_lines * target_arch.GetMaximumOpcodeByteSize());
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Target; other minor fixes. llvm-svn: 261242
2016-02-19 02:52:47 +08:00
const char *plugin_name = nullptr;
const char *flavor = nullptr;
<rdar://problem/11852100> The "stop-line-count-after" and "stop-line-count-before" settings are broken. This fixes them. llvm-svn: 160071
2012-07-12 04:33:48 +08:00
Disassembler::Disassemble (target->GetDebugger(),
target_arch,
Convert from the C-based LLVM Disassembler shim to the full MC Disassembler API's. Calculate "can branch" using the MC API's rather than our hand-rolled regex'es. As extra credit, allow setting the disassembly flavor for x86 based architectures to intel or att. <rdar://problem/11319574> <rdar://problem/9329275> llvm-svn: 176392
2013-03-02 08:26:47 +08:00
plugin_name,
flavor,
<rdar://problem/11852100> The "stop-line-count-after" and "stop-line-count-before" settings are broken. This fixes them. llvm-svn: 160071
2012-07-12 04:33:48 +08:00
exe_ctx,
pc_range,
disasm_lines,
0,
Disassembler::eOptionMarkPCAddress,
strm);
}
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
}
<rdar://problem/11852100> The "stop-line-count-after" and "stop-line-count-before" settings are broken. This fixes them. llvm-svn: 160071
2012-07-12 04:33:48 +08:00
break;
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
}
Centralized a lot of the status information for processes, threads, and stack frame down in the lldb_private::Process, lldb_private::Thread, lldb_private::StackFrameList and the lldb_private::StackFrame classes. We had some command line commands that had duplicate versions of the process status output ("thread list" and "process status" for example). Removed the "file" command and placed it where it should have been: "target create". Made an alias for "file" to "target create" so we stay compatible with GDB commands. We can now have multple usable targets in lldb at the same time. This is nice for comparing two runs of a program or debugging more than one binary at the same time. The new command is "target select <target-idx>" and also to see a list of the current targets you can use the new "target list" command. The flow in a debug session can be: (lldb) target create /path/to/exe/a.out (lldb) breakpoint set --name main (lldb) run ... hit breakpoint (lldb) target create /bin/ls (lldb) run /tmp Process 36001 exited with status = 0 (0x00000000) (lldb) target list Current targets: target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) * target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) target select 0 Current targets: * target #0: /tmp/args/a.out ( arch=x86_64-apple-darwin, platform=localhost, pid=35999, state=stopped ) target #1: /bin/ls ( arch=x86_64-apple-darwin, platform=localhost, pid=36001, state=exited ) (lldb) bt * thread #1: tid = 0x2d03, 0x0000000100000b9a a.out`main + 42 at main.c:16, stop reason = breakpoint 1.1 frame #0: 0x0000000100000b9a a.out`main + 42 at main.c:16 frame #1: 0x0000000100000b64 a.out`start + 52 Above we created a target for "a.out" and ran and hit a breakpoint at "main". Then we created a new target for /bin/ls and ran it. Then we listed the targest and selected our original "a.out" program, so we showed two concurent debug sessions going on at the same time. llvm-svn: 129695
2011-04-18 16:33:37 +08:00
}
}
return true;
}