replica
/
hanchenye-llvm-project
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
hanchenye-llvm-project/lldb/source/Symbol/Block.cpp

632 lines
17 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
//===-- Block.cpp -----------------------------------------------*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
#include "lldb/Symbol/Block.h"
Fixed an issue where a lexical block or inlined function might have bad debug information generated for it. Say we have a concrete function "foo" which has inlined function "a" which calls another inlined function "b": foo 1 { 2 { a () 3 { b () 4 { } } } } Sometimes we see the compiler generate an address range in the DWARF for "foo" (block 1 above) as say [0x1000-0x1100). Then the range for "a" is something like [0x1050-0x1060) (note that it is correctly scoped within the "foo" address range). And then we get "b" which is a child of "a", yet the debug info says it has a range of [0x1060-0x1080) (not contained within "a"). We now detect this issue when making our blocks and add an extra range to "a". Also added a new "lldb" logging category named "symbol" where we can find out about symbol file errors and warnings. llvm-svn: 140822
2011-09-30 07:41:34 +08:00
#include "lldb/lldb-private-log.h"
#include "lldb/Core/Log.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
#include "lldb/Core/Module.h"
#include "lldb/Core/Section.h"
Fixed an issue where a lexical block or inlined function might have bad debug information generated for it. Say we have a concrete function "foo" which has inlined function "a" which calls another inlined function "b": foo 1 { 2 { a () 3 { b () 4 { } } } } Sometimes we see the compiler generate an address range in the DWARF for "foo" (block 1 above) as say [0x1000-0x1100). Then the range for "a" is something like [0x1050-0x1060) (note that it is correctly scoped within the "foo" address range). And then we get "b" which is a child of "a", yet the debug info says it has a range of [0x1060-0x1080) (not contained within "a"). We now detect this issue when making our blocks and add an extra range to "a". Also added a new "lldb" logging category named "symbol" where we can find out about symbol file errors and warnings. llvm-svn: 140822
2011-09-30 07:41:34 +08:00
#include "lldb/Symbol/Function.h"
This is an overhaul of the expression parser code that detects what context the current expression is meant to execute in. LLDB now properly consults the method declaration in the debug information rather than trying to hunt down the "this" or "self" pointer by name, which can be misleading. Other fixes include: - LLDB now properly detects that it is inside an inlined C++ member function. - LLDB now allows access to non-const members when in const code. - The functions in SymbolFile that locate the DeclContext containing a DIE have been renamed to reflect what they actually do. I have added new functions that find the DeclContext for the DIE itself. I have also introduced testcases for C++ and Objective-C. llvm-svn: 136999
2011-08-06 07:43:37 +08:00
#include "lldb/Symbol/SymbolFile.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
#include "lldb/Symbol/SymbolVendor.h"
#include "lldb/Symbol/VariableList.h"
using namespace lldb;
using namespace lldb_private;
Modified the host process monitor callback function Host::StartMonitoringChildProcess to spawn a thread for each process that is being monitored. Previously LLDB would spawn a single thread that would wait for any child process which isn't ok to do as a shared library (LLDB.framework on Mac OSX, or lldb.so on linux). The old single thread used to call wait4() with a pid of -1 which could cause it to reap child processes that it shouldn't have. Re-wrote the way Function blocks are handles. Previously I attempted to keep all blocks in a single memory allocation (in a std::vector). This made the code somewhat efficient, but hard to work with. I got rid of the old BlockList class, and went to a straight parent with children relationship. This new approach will allow for partial parsing of the blocks within a function. llvm-svn: 111706
2010-08-21 10:22:51 +08:00
Block::Block(lldb::user_id_t uid) :
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
UserID(uid),
Modified the host process monitor callback function Host::StartMonitoringChildProcess to spawn a thread for each process that is being monitored. Previously LLDB would spawn a single thread that would wait for any child process which isn't ok to do as a shared library (LLDB.framework on Mac OSX, or lldb.so on linux). The old single thread used to call wait4() with a pid of -1 which could cause it to reap child processes that it shouldn't have. Re-wrote the way Function blocks are handles. Previously I attempted to keep all blocks in a single memory allocation (in a std::vector). This made the code somewhat efficient, but hard to work with. I got rid of the old BlockList class, and went to a straight parent with children relationship. This new approach will allow for partial parsing of the blocks within a function. llvm-svn: 111706
2010-08-21 10:22:51 +08:00
m_parent_scope (NULL),
m_children (),
m_ranges (),
m_inlineInfoSP (),
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_variable_list_sp (),
Modified the host process monitor callback function Host::StartMonitoringChildProcess to spawn a thread for each process that is being monitored. Previously LLDB would spawn a single thread that would wait for any child process which isn't ok to do as a shared library (LLDB.framework on Mac OSX, or lldb.so on linux). The old single thread used to call wait4() with a pid of -1 which could cause it to reap child processes that it shouldn't have. Re-wrote the way Function blocks are handles. Previously I attempted to keep all blocks in a single memory allocation (in a std::vector). This made the code somewhat efficient, but hard to work with. I got rid of the old BlockList class, and went to a straight parent with children relationship. This new approach will allow for partial parsing of the blocks within a function. llvm-svn: 111706
2010-08-21 10:22:51 +08:00
m_parsed_block_info (false),
m_parsed_block_variables (false),
m_parsed_child_blocks (false)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
}
Block::~Block ()
{
}
Added function name types to allow us to set breakpoints by name more intelligently. The four name types we currently have are: eFunctionNameTypeFull = (1 << 1), // The function name. // For C this is the same as just the name of the function // For C++ this is the demangled version of the mangled name. // For ObjC this is the full function signature with the + or // - and the square brackets and the class and selector eFunctionNameTypeBase = (1 << 2), // The function name only, no namespaces or arguments and no class // methods or selectors will be searched. eFunctionNameTypeMethod = (1 << 3), // Find function by method name (C++) with no namespace or arguments eFunctionNameTypeSelector = (1 << 4) // Find function by selector name (ObjC) names this allows much more flexibility when setting breakoints: (lldb) breakpoint set --name main --basename (lldb) breakpoint set --name main --fullname (lldb) breakpoint set --name main --method (lldb) breakpoint set --name main --selector The default: (lldb) breakpoint set --name main will inspect the name "main" and look for any parens, or if the name starts with "-[" or "+[" and if any are found then a full name search will happen. Else a basename search will be the default. Fixed some command option structures so not all options are required when they shouldn't be. Cleaned up the breakpoint output summary. Made the "image lookup --address <addr>" output much more verbose so it shows all the important symbol context results. Added a GetDescription method to many of the SymbolContext objects for the more verbose output. llvm-svn: 107075
2010-06-29 05:30:43 +08:00
void
Moved the section load list up into the target so we can use the target to symbolicate things without the need for a valid process subclass. llvm-svn: 113895
2010-09-15 07:36:40 +08:00
Block::GetDescription(Stream *s, Function *function, lldb::DescriptionLevel level, Target *target) const
Added function name types to allow us to set breakpoints by name more intelligently. The four name types we currently have are: eFunctionNameTypeFull = (1 << 1), // The function name. // For C this is the same as just the name of the function // For C++ this is the demangled version of the mangled name. // For ObjC this is the full function signature with the + or // - and the square brackets and the class and selector eFunctionNameTypeBase = (1 << 2), // The function name only, no namespaces or arguments and no class // methods or selectors will be searched. eFunctionNameTypeMethod = (1 << 3), // Find function by method name (C++) with no namespace or arguments eFunctionNameTypeSelector = (1 << 4) // Find function by selector name (ObjC) names this allows much more flexibility when setting breakoints: (lldb) breakpoint set --name main --basename (lldb) breakpoint set --name main --fullname (lldb) breakpoint set --name main --method (lldb) breakpoint set --name main --selector The default: (lldb) breakpoint set --name main will inspect the name "main" and look for any parens, or if the name starts with "-[" or "+[" and if any are found then a full name search will happen. Else a basename search will be the default. Fixed some command option structures so not all options are required when they shouldn't be. Cleaned up the breakpoint output summary. Made the "image lookup --address <addr>" output much more verbose so it shows all the important symbol context results. Added a GetDescription method to many of the SymbolContext objects for the more verbose output. llvm-svn: 107075
2010-06-29 05:30:43 +08:00
{
Cleaned up the output of "image lookup --address <ADDR>" which involved cleaning up the output of many GetDescription objects that are part of a symbol context. This fixes an issue where no ranges were being printed out for functions, blocks and symbols. llvm-svn: 113571
2010-09-10 09:30:46 +08:00
*s << "id = " << ((const UserID&)*this);
Added more functionality to Range template classes in RangeMap.h and converted remaining DWARF areas that were using ranges over to this class. Also converted lldb_private::Block to use it. llvm-svn: 141460
2011-10-08 08:49:15 +08:00
size_t num_ranges = m_ranges.GetSize();
if (num_ranges > 0)
Added function name types to allow us to set breakpoints by name more intelligently. The four name types we currently have are: eFunctionNameTypeFull = (1 << 1), // The function name. // For C this is the same as just the name of the function // For C++ this is the demangled version of the mangled name. // For ObjC this is the full function signature with the + or // - and the square brackets and the class and selector eFunctionNameTypeBase = (1 << 2), // The function name only, no namespaces or arguments and no class // methods or selectors will be searched. eFunctionNameTypeMethod = (1 << 3), // Find function by method name (C++) with no namespace or arguments eFunctionNameTypeSelector = (1 << 4) // Find function by selector name (ObjC) names this allows much more flexibility when setting breakoints: (lldb) breakpoint set --name main --basename (lldb) breakpoint set --name main --fullname (lldb) breakpoint set --name main --method (lldb) breakpoint set --name main --selector The default: (lldb) breakpoint set --name main will inspect the name "main" and look for any parens, or if the name starts with "-[" or "+[" and if any are found then a full name search will happen. Else a basename search will be the default. Fixed some command option structures so not all options are required when they shouldn't be. Cleaned up the breakpoint output summary. Made the "image lookup --address <addr>" output much more verbose so it shows all the important symbol context results. Added a GetDescription method to many of the SymbolContext objects for the more verbose output. llvm-svn: 107075
2010-06-29 05:30:43 +08:00
{
addr_t base_addr = LLDB_INVALID_ADDRESS;
Moved the section load list up into the target so we can use the target to symbolicate things without the need for a valid process subclass. llvm-svn: 113895
2010-09-15 07:36:40 +08:00
if (target)
base_addr = function->GetAddressRange().GetBaseAddress().GetLoadAddress(target);
Added function name types to allow us to set breakpoints by name more intelligently. The four name types we currently have are: eFunctionNameTypeFull = (1 << 1), // The function name. // For C this is the same as just the name of the function // For C++ this is the demangled version of the mangled name. // For ObjC this is the full function signature with the + or // - and the square brackets and the class and selector eFunctionNameTypeBase = (1 << 2), // The function name only, no namespaces or arguments and no class // methods or selectors will be searched. eFunctionNameTypeMethod = (1 << 3), // Find function by method name (C++) with no namespace or arguments eFunctionNameTypeSelector = (1 << 4) // Find function by selector name (ObjC) names this allows much more flexibility when setting breakoints: (lldb) breakpoint set --name main --basename (lldb) breakpoint set --name main --fullname (lldb) breakpoint set --name main --method (lldb) breakpoint set --name main --selector The default: (lldb) breakpoint set --name main will inspect the name "main" and look for any parens, or if the name starts with "-[" or "+[" and if any are found then a full name search will happen. Else a basename search will be the default. Fixed some command option structures so not all options are required when they shouldn't be. Cleaned up the breakpoint output summary. Made the "image lookup --address <addr>" output much more verbose so it shows all the important symbol context results. Added a GetDescription method to many of the SymbolContext objects for the more verbose output. llvm-svn: 107075
2010-06-29 05:30:43 +08:00
if (base_addr == LLDB_INVALID_ADDRESS)
Modified the host process monitor callback function Host::StartMonitoringChildProcess to spawn a thread for each process that is being monitored. Previously LLDB would spawn a single thread that would wait for any child process which isn't ok to do as a shared library (LLDB.framework on Mac OSX, or lldb.so on linux). The old single thread used to call wait4() with a pid of -1 which could cause it to reap child processes that it shouldn't have. Re-wrote the way Function blocks are handles. Previously I attempted to keep all blocks in a single memory allocation (in a std::vector). This made the code somewhat efficient, but hard to work with. I got rid of the old BlockList class, and went to a straight parent with children relationship. This new approach will allow for partial parsing of the blocks within a function. llvm-svn: 111706
2010-08-21 10:22:51 +08:00
base_addr = function->GetAddressRange().GetBaseAddress().GetFileAddress();
Added function name types to allow us to set breakpoints by name more intelligently. The four name types we currently have are: eFunctionNameTypeFull = (1 << 1), // The function name. // For C this is the same as just the name of the function // For C++ this is the demangled version of the mangled name. // For ObjC this is the full function signature with the + or // - and the square brackets and the class and selector eFunctionNameTypeBase = (1 << 2), // The function name only, no namespaces or arguments and no class // methods or selectors will be searched. eFunctionNameTypeMethod = (1 << 3), // Find function by method name (C++) with no namespace or arguments eFunctionNameTypeSelector = (1 << 4) // Find function by selector name (ObjC) names this allows much more flexibility when setting breakoints: (lldb) breakpoint set --name main --basename (lldb) breakpoint set --name main --fullname (lldb) breakpoint set --name main --method (lldb) breakpoint set --name main --selector The default: (lldb) breakpoint set --name main will inspect the name "main" and look for any parens, or if the name starts with "-[" or "+[" and if any are found then a full name search will happen. Else a basename search will be the default. Fixed some command option structures so not all options are required when they shouldn't be. Cleaned up the breakpoint output summary. Made the "image lookup --address <addr>" output much more verbose so it shows all the important symbol context results. Added a GetDescription method to many of the SymbolContext objects for the more verbose output. llvm-svn: 107075
2010-06-29 05:30:43 +08:00
Cleaned up the output of "image lookup --address <ADDR>" which involved cleaning up the output of many GetDescription objects that are part of a symbol context. This fixes an issue where no ranges were being printed out for functions, blocks and symbols. llvm-svn: 113571
2010-09-10 09:30:46 +08:00
s->Printf(", range%s = ", num_ranges > 1 ? "s" : "");
Added more functionality to Range template classes in RangeMap.h and converted remaining DWARF areas that were using ranges over to this class. Also converted lldb_private::Block to use it. llvm-svn: 141460
2011-10-08 08:49:15 +08:00
for (size_t i=0; i<num_ranges; ++i)
{
const Range &range = m_ranges.GetEntryRef(i);
s->AddressRange(base_addr + range.GetRangeBase(), base_addr + range.GetRangeEnd(), 4);
}
Added function name types to allow us to set breakpoints by name more intelligently. The four name types we currently have are: eFunctionNameTypeFull = (1 << 1), // The function name. // For C this is the same as just the name of the function // For C++ this is the demangled version of the mangled name. // For ObjC this is the full function signature with the + or // - and the square brackets and the class and selector eFunctionNameTypeBase = (1 << 2), // The function name only, no namespaces or arguments and no class // methods or selectors will be searched. eFunctionNameTypeMethod = (1 << 3), // Find function by method name (C++) with no namespace or arguments eFunctionNameTypeSelector = (1 << 4) // Find function by selector name (ObjC) names this allows much more flexibility when setting breakoints: (lldb) breakpoint set --name main --basename (lldb) breakpoint set --name main --fullname (lldb) breakpoint set --name main --method (lldb) breakpoint set --name main --selector The default: (lldb) breakpoint set --name main will inspect the name "main" and look for any parens, or if the name starts with "-[" or "+[" and if any are found then a full name search will happen. Else a basename search will be the default. Fixed some command option structures so not all options are required when they shouldn't be. Cleaned up the breakpoint output summary. Made the "image lookup --address <addr>" output much more verbose so it shows all the important symbol context results. Added a GetDescription method to many of the SymbolContext objects for the more verbose output. llvm-svn: 107075
2010-06-29 05:30:43 +08:00
}
if (m_inlineInfoSP.get() != NULL)
Fixed a missing newline when dumping mixed disassembly. Added a "bool show_fullpaths" to many more objects that were previously always dumping full paths. Fixed a few places where the DWARF was not indexed when we we needed it to be when making queries. Also fixed an issue where the DWARF in .o files wasn't searching all .o files for the types. Fixed an issue with the output from "image lookup --type <TYPENAME>" where the name and byte size might not be resolved and might not display. We now call the accessors so we end up seeing all of the type info. llvm-svn: 113951
2010-09-15 13:51:24 +08:00
{
bool show_fullpaths = (level == eDescriptionLevelVerbose);
m_inlineInfoSP->Dump(s, show_fullpaths);
}
Added function name types to allow us to set breakpoints by name more intelligently. The four name types we currently have are: eFunctionNameTypeFull = (1 << 1), // The function name. // For C this is the same as just the name of the function // For C++ this is the demangled version of the mangled name. // For ObjC this is the full function signature with the + or // - and the square brackets and the class and selector eFunctionNameTypeBase = (1 << 2), // The function name only, no namespaces or arguments and no class // methods or selectors will be searched. eFunctionNameTypeMethod = (1 << 3), // Find function by method name (C++) with no namespace or arguments eFunctionNameTypeSelector = (1 << 4) // Find function by selector name (ObjC) names this allows much more flexibility when setting breakoints: (lldb) breakpoint set --name main --basename (lldb) breakpoint set --name main --fullname (lldb) breakpoint set --name main --method (lldb) breakpoint set --name main --selector The default: (lldb) breakpoint set --name main will inspect the name "main" and look for any parens, or if the name starts with "-[" or "+[" and if any are found then a full name search will happen. Else a basename search will be the default. Fixed some command option structures so not all options are required when they shouldn't be. Cleaned up the breakpoint output summary. Made the "image lookup --address <addr>" output much more verbose so it shows all the important symbol context results. Added a GetDescription method to many of the SymbolContext objects for the more verbose output. llvm-svn: 107075
2010-06-29 05:30:43 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
void
Block::Dump(Stream *s, addr_t base_addr, int32_t depth, bool show_context) const
{
if (depth < 0)
{
Modified the host process monitor callback function Host::StartMonitoringChildProcess to spawn a thread for each process that is being monitored. Previously LLDB would spawn a single thread that would wait for any child process which isn't ok to do as a shared library (LLDB.framework on Mac OSX, or lldb.so on linux). The old single thread used to call wait4() with a pid of -1 which could cause it to reap child processes that it shouldn't have. Re-wrote the way Function blocks are handles. Previously I attempted to keep all blocks in a single memory allocation (in a std::vector). This made the code somewhat efficient, but hard to work with. I got rid of the old BlockList class, and went to a straight parent with children relationship. This new approach will allow for partial parsing of the blocks within a function. llvm-svn: 111706
2010-08-21 10:22:51 +08:00
Block *parent = GetParent();
if (parent)
{
// We have a depth that is less than zero, print our parent blocks
// first
parent->Dump(s, base_addr, depth + 1, show_context);
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Update declarations for all functions/methods that accept printf-style stdarg formats to use __attribute__ format so the compiler can flag incorrect uses. Fix all incorrect uses. Most of these are innocuous, a few were resulting in crashes. llvm-svn: 140185
2011-09-21 05:44:10 +08:00
s->Printf("%p: ", this);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
s->Indent();
*s << "Block" << ((const UserID&)*this);
Added function name types to allow us to set breakpoints by name more intelligently. The four name types we currently have are: eFunctionNameTypeFull = (1 << 1), // The function name. // For C this is the same as just the name of the function // For C++ this is the demangled version of the mangled name. // For ObjC this is the full function signature with the + or // - and the square brackets and the class and selector eFunctionNameTypeBase = (1 << 2), // The function name only, no namespaces or arguments and no class // methods or selectors will be searched. eFunctionNameTypeMethod = (1 << 3), // Find function by method name (C++) with no namespace or arguments eFunctionNameTypeSelector = (1 << 4) // Find function by selector name (ObjC) names this allows much more flexibility when setting breakoints: (lldb) breakpoint set --name main --basename (lldb) breakpoint set --name main --fullname (lldb) breakpoint set --name main --method (lldb) breakpoint set --name main --selector The default: (lldb) breakpoint set --name main will inspect the name "main" and look for any parens, or if the name starts with "-[" or "+[" and if any are found then a full name search will happen. Else a basename search will be the default. Fixed some command option structures so not all options are required when they shouldn't be. Cleaned up the breakpoint output summary. Made the "image lookup --address <addr>" output much more verbose so it shows all the important symbol context results. Added a GetDescription method to many of the SymbolContext objects for the more verbose output. llvm-svn: 107075
2010-06-29 05:30:43 +08:00
const Block* parent_block = GetParent();
if (parent_block)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
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
s->Printf(", parent = {0x%8.8" PRIx64 "}", parent_block->GetID());
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
if (m_inlineInfoSP.get() != NULL)
Fixed a missing newline when dumping mixed disassembly. Added a "bool show_fullpaths" to many more objects that were previously always dumping full paths. Fixed a few places where the DWARF was not indexed when we we needed it to be when making queries. Also fixed an issue where the DWARF in .o files wasn't searching all .o files for the types. Fixed an issue with the output from "image lookup --type <TYPENAME>" where the name and byte size might not be resolved and might not display. We now call the accessors so we end up seeing all of the type info. llvm-svn: 113951
2010-09-15 13:51:24 +08:00
{
bool show_fullpaths = false;
m_inlineInfoSP->Dump(s, show_fullpaths);
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Added more functionality to Range template classes in RangeMap.h and converted remaining DWARF areas that were using ranges over to this class. Also converted lldb_private::Block to use it. llvm-svn: 141460
2011-10-08 08:49:15 +08:00
if (!m_ranges.IsEmpty())
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
*s << ", ranges =";
Added more functionality to Range template classes in RangeMap.h and converted remaining DWARF areas that were using ranges over to this class. Also converted lldb_private::Block to use it. llvm-svn: 141460
2011-10-08 08:49:15 +08:00
size_t num_ranges = m_ranges.GetSize();
for (size_t i=0; i<num_ranges; ++i)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Added more functionality to Range template classes in RangeMap.h and converted remaining DWARF areas that were using ranges over to this class. Also converted lldb_private::Block to use it. llvm-svn: 141460
2011-10-08 08:49:15 +08:00
const Range &range = m_ranges.GetEntryRef(i);
if (parent_block != NULL && parent_block->Contains(range) == false)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
*s << '!';
else
*s << ' ';
Added more functionality to Range template classes in RangeMap.h and converted remaining DWARF areas that were using ranges over to this class. Also converted lldb_private::Block to use it. llvm-svn: 141460
2011-10-08 08:49:15 +08:00
s->AddressRange(base_addr + range.GetRangeBase(), base_addr + range.GetRangeEnd(), 4);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
}
s->EOL();
if (depth > 0)
{
s->IndentMore();
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_variable_list_sp.get())
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +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
m_variable_list_sp->Dump(s, show_context);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Free up some space in lldb_private::Block by not requiring a sibling pointer. The old way of storing blocks used to use the sibling pointer, but now all blocks contain a collection of shared pointers to blocks so this isn't required anymore and a parent can be asked to find the sibling block for a child block. llvm-svn: 140808
2011-09-30 05:19:25 +08:00
collection::const_iterator pos, end = m_children.end();
for (pos = m_children.begin(); pos != end; ++pos)
(*pos)->Dump(s, base_addr, depth - 1, show_context);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
s->IndentLess();
}
}
Modified the host process monitor callback function Host::StartMonitoringChildProcess to spawn a thread for each process that is being monitored. Previously LLDB would spawn a single thread that would wait for any child process which isn't ok to do as a shared library (LLDB.framework on Mac OSX, or lldb.so on linux). The old single thread used to call wait4() with a pid of -1 which could cause it to reap child processes that it shouldn't have. Re-wrote the way Function blocks are handles. Previously I attempted to keep all blocks in a single memory allocation (in a std::vector). This made the code somewhat efficient, but hard to work with. I got rid of the old BlockList class, and went to a straight parent with children relationship. This new approach will allow for partial parsing of the blocks within a function. llvm-svn: 111706
2010-08-21 10:22:51 +08:00
Block *
Block::FindBlockByID (user_id_t block_id)
{
if (block_id == GetID())
return this;
Block *matching_block = NULL;
Free up some space in lldb_private::Block by not requiring a sibling pointer. The old way of storing blocks used to use the sibling pointer, but now all blocks contain a collection of shared pointers to blocks so this isn't required anymore and a parent can be asked to find the sibling block for a child block. llvm-svn: 140808
2011-09-30 05:19:25 +08:00
collection::const_iterator pos, end = m_children.end();
for (pos = m_children.begin(); pos != end; ++pos)
Modified the host process monitor callback function Host::StartMonitoringChildProcess to spawn a thread for each process that is being monitored. Previously LLDB would spawn a single thread that would wait for any child process which isn't ok to do as a shared library (LLDB.framework on Mac OSX, or lldb.so on linux). The old single thread used to call wait4() with a pid of -1 which could cause it to reap child processes that it shouldn't have. Re-wrote the way Function blocks are handles. Previously I attempted to keep all blocks in a single memory allocation (in a std::vector). This made the code somewhat efficient, but hard to work with. I got rid of the old BlockList class, and went to a straight parent with children relationship. This new approach will allow for partial parsing of the blocks within a function. llvm-svn: 111706
2010-08-21 10:22:51 +08:00
{
Free up some space in lldb_private::Block by not requiring a sibling pointer. The old way of storing blocks used to use the sibling pointer, but now all blocks contain a collection of shared pointers to blocks so this isn't required anymore and a parent can be asked to find the sibling block for a child block. llvm-svn: 140808
2011-09-30 05:19:25 +08:00
matching_block = (*pos)->FindBlockByID (block_id);
Modified the host process monitor callback function Host::StartMonitoringChildProcess to spawn a thread for each process that is being monitored. Previously LLDB would spawn a single thread that would wait for any child process which isn't ok to do as a shared library (LLDB.framework on Mac OSX, or lldb.so on linux). The old single thread used to call wait4() with a pid of -1 which could cause it to reap child processes that it shouldn't have. Re-wrote the way Function blocks are handles. Previously I attempted to keep all blocks in a single memory allocation (in a std::vector). This made the code somewhat efficient, but hard to work with. I got rid of the old BlockList class, and went to a straight parent with children relationship. This new approach will allow for partial parsing of the blocks within a function. llvm-svn: 111706
2010-08-21 10:22:51 +08:00
if (matching_block)
break;
}
return matching_block;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
void
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
Block::CalculateSymbolContext (SymbolContext* sc)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Modified the host process monitor callback function Host::StartMonitoringChildProcess to spawn a thread for each process that is being monitored. Previously LLDB would spawn a single thread that would wait for any child process which isn't ok to do as a shared library (LLDB.framework on Mac OSX, or lldb.so on linux). The old single thread used to call wait4() with a pid of -1 which could cause it to reap child processes that it shouldn't have. Re-wrote the way Function blocks are handles. Previously I attempted to keep all blocks in a single memory allocation (in a std::vector). This made the code somewhat efficient, but hard to work with. I got rid of the old BlockList class, and went to a straight parent with children relationship. This new approach will allow for partial parsing of the blocks within a function. llvm-svn: 111706
2010-08-21 10:22:51 +08:00
if (m_parent_scope)
m_parent_scope->CalculateSymbolContext(sc);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
sc->block = this;
}
<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
lldb::ModuleSP
We were leaking a stack frame in StackFrameList in Thread.cpp which could cause extra shared pointer references to one or more modules to be leaked. This would cause many object files to stay around the life of LLDB, so after a recompile and rexecution, we would keep adding more and more memory. After fixing the leak, we found many cases where leaked stack frames were still being used and causing crashes in the test suite. These are now all resolved. llvm-svn: 137516
2011-08-13 05:40:01 +08:00
Block::CalculateSymbolContextModule ()
{
if (m_parent_scope)
return m_parent_scope->CalculateSymbolContextModule ();
<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
return lldb::ModuleSP();
We were leaking a stack frame in StackFrameList in Thread.cpp which could cause extra shared pointer references to one or more modules to be leaked. This would cause many object files to stay around the life of LLDB, so after a recompile and rexecution, we would keep adding more and more memory. After fixing the leak, we found many cases where leaked stack frames were still being used and causing crashes in the test suite. These are now all resolved. llvm-svn: 137516
2011-08-13 05:40:01 +08:00
}
CompileUnit *
Block::CalculateSymbolContextCompileUnit ()
{
if (m_parent_scope)
return m_parent_scope->CalculateSymbolContextCompileUnit ();
return NULL;
}
Function *
Block::CalculateSymbolContextFunction ()
{
if (m_parent_scope)
return m_parent_scope->CalculateSymbolContextFunction ();
return NULL;
}
Block *
Block::CalculateSymbolContextBlock ()
{
return this;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
void
Block::DumpSymbolContext(Stream *s)
{
We were leaking a stack frame in StackFrameList in Thread.cpp which could cause extra shared pointer references to one or more modules to be leaked. This would cause many object files to stay around the life of LLDB, so after a recompile and rexecution, we would keep adding more and more memory. After fixing the leak, we found many cases where leaked stack frames were still being used and causing crashes in the test suite. These are now all resolved. llvm-svn: 137516
2011-08-13 05:40:01 +08:00
Function *function = CalculateSymbolContextFunction();
if (function)
function->DumpSymbolContext(s);
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
s->Printf(", Block{0x%8.8" PRIx64 "}", GetID());
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Add GetDescription() and __repr__ () methods to most API classes, to allow "print" from inside Python to print out the objects in a more useful manner. llvm-svn: 114321
2010-09-20 13:20:02 +08:00
void
Block::DumpAddressRanges (Stream *s, lldb::addr_t base_addr)
{
Added more functionality to Range template classes in RangeMap.h and converted remaining DWARF areas that were using ranges over to this class. Also converted lldb_private::Block to use it. llvm-svn: 141460
2011-10-08 08:49:15 +08:00
if (!m_ranges.IsEmpty())
Add GetDescription() and __repr__ () methods to most API classes, to allow "print" from inside Python to print out the objects in a more useful manner. llvm-svn: 114321
2010-09-20 13:20:02 +08:00
{
Added more functionality to Range template classes in RangeMap.h and converted remaining DWARF areas that were using ranges over to this class. Also converted lldb_private::Block to use it. llvm-svn: 141460
2011-10-08 08:49:15 +08:00
size_t num_ranges = m_ranges.GetSize();
for (size_t i=0; i<num_ranges; ++i)
{
const Range &range = m_ranges.GetEntryRef(i);
s->AddressRange(base_addr + range.GetRangeBase(), base_addr + range.GetRangeEnd(), 4);
}
Add GetDescription() and __repr__ () methods to most API classes, to allow "print" from inside Python to print out the objects in a more useful manner. llvm-svn: 114321
2010-09-20 13:20:02 +08:00
}
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
bool
Block::Contains (addr_t range_offset) const
{
Added more functionality to Range template classes in RangeMap.h and converted remaining DWARF areas that were using ranges over to this class. Also converted lldb_private::Block to use it. llvm-svn: 141460
2011-10-08 08:49:15 +08:00
return m_ranges.FindEntryThatContains(range_offset) != NULL;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
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
bool
Block::Contains (const Block *block) const
{
if (this == block)
Fixed the implementation of "bool Block::Contains (const Block *block) const" to return the correct result. Fixed "bool Variable::IsInScope (StackFrame *frame)" to return the correct result when there are no location lists. Modified the "frame variable" command such that: - if no arguments are given (dump all frame variables), then we only show variables that are currently in scope - if some arguments are given, we show an error if the variable is out of scope llvm-svn: 113830
2010-09-14 11:16:58 +08:00
return false; // This block doesn't contain itself...
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
Fixed the implementation of "bool Block::Contains (const Block *block) const" to return the correct result. Fixed "bool Variable::IsInScope (StackFrame *frame)" to return the correct result when there are no location lists. Modified the "frame variable" command such that: - if no arguments are given (dump all frame variables), then we only show variables that are currently in scope - if some arguments are given, we show an error if the variable is out of scope llvm-svn: 113830
2010-09-14 11:16:58 +08:00
// Walk the parent chain for "block" and see if any if them match this block
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
const Block *block_parent;
for (block_parent = block->GetParent();
block_parent != NULL;
block_parent = block_parent->GetParent())
{
Fixed the implementation of "bool Block::Contains (const Block *block) const" to return the correct result. Fixed "bool Variable::IsInScope (StackFrame *frame)" to return the correct result when there are no location lists. Modified the "frame variable" command such that: - if no arguments are given (dump all frame variables), then we only show variables that are currently in scope - if some arguments are given, we show an error if the variable is out of scope llvm-svn: 113830
2010-09-14 11:16:58 +08:00
if (this == block_parent)
return true; // One of the parents of "block" is this object!
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
}
return false;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
bool
Added more functionality to Range template classes in RangeMap.h and converted remaining DWARF areas that were using ranges over to this class. Also converted lldb_private::Block to use it. llvm-svn: 141460
2011-10-08 08:49:15 +08:00
Block::Contains (const Range& range) const
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Added more functionality to Range template classes in RangeMap.h and converted remaining DWARF areas that were using ranges over to this class. Also converted lldb_private::Block to use it. llvm-svn: 141460
2011-10-08 08:49:15 +08:00
return m_ranges.FindEntryThatContains (range) != NULL;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Modified the host process monitor callback function Host::StartMonitoringChildProcess to spawn a thread for each process that is being monitored. Previously LLDB would spawn a single thread that would wait for any child process which isn't ok to do as a shared library (LLDB.framework on Mac OSX, or lldb.so on linux). The old single thread used to call wait4() with a pid of -1 which could cause it to reap child processes that it shouldn't have. Re-wrote the way Function blocks are handles. Previously I attempted to keep all blocks in a single memory allocation (in a std::vector). This made the code somewhat efficient, but hard to work with. I got rid of the old BlockList class, and went to a straight parent with children relationship. This new approach will allow for partial parsing of the blocks within a function. llvm-svn: 111706
2010-08-21 10:22:51 +08:00
Block *
Block::GetParent () const
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Modified the host process monitor callback function Host::StartMonitoringChildProcess to spawn a thread for each process that is being monitored. Previously LLDB would spawn a single thread that would wait for any child process which isn't ok to do as a shared library (LLDB.framework on Mac OSX, or lldb.so on linux). The old single thread used to call wait4() with a pid of -1 which could cause it to reap child processes that it shouldn't have. Re-wrote the way Function blocks are handles. Previously I attempted to keep all blocks in a single memory allocation (in a std::vector). This made the code somewhat efficient, but hard to work with. I got rid of the old BlockList class, and went to a straight parent with children relationship. This new approach will allow for partial parsing of the blocks within a function. llvm-svn: 111706
2010-08-21 10:22:51 +08:00
if (m_parent_scope)
We were leaking a stack frame in StackFrameList in Thread.cpp which could cause extra shared pointer references to one or more modules to be leaked. This would cause many object files to stay around the life of LLDB, so after a recompile and rexecution, we would keep adding more and more memory. After fixing the leak, we found many cases where leaked stack frames were still being used and causing crashes in the test suite. These are now all resolved. llvm-svn: 137516
2011-08-13 05:40:01 +08:00
return m_parent_scope->CalculateSymbolContextBlock();
Modified the host process monitor callback function Host::StartMonitoringChildProcess to spawn a thread for each process that is being monitored. Previously LLDB would spawn a single thread that would wait for any child process which isn't ok to do as a shared library (LLDB.framework on Mac OSX, or lldb.so on linux). The old single thread used to call wait4() with a pid of -1 which could cause it to reap child processes that it shouldn't have. Re-wrote the way Function blocks are handles. Previously I attempted to keep all blocks in a single memory allocation (in a std::vector). This made the code somewhat efficient, but hard to work with. I got rid of the old BlockList class, and went to a straight parent with children relationship. This new approach will allow for partial parsing of the blocks within a function. llvm-svn: 111706
2010-08-21 10:22:51 +08:00
return NULL;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +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
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
Block::GetContainingInlinedBlock ()
{
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
if (GetInlinedFunctionInfo())
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
return this;
return GetInlinedParent ();
}
Block *
Block::GetInlinedParent ()
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
{
Block *parent_block = GetParent ();
if (parent_block)
{
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
if (parent_block->GetInlinedFunctionInfo())
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
return parent_block;
else
return parent_block->GetInlinedParent();
}
return NULL;
}
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
bool
Added more functionality to Range template classes in RangeMap.h and converted remaining DWARF areas that were using ranges over to this class. Also converted lldb_private::Block to use it. llvm-svn: 141460
2011-10-08 08:49:15 +08:00
Block::GetRangeContainingOffset (const addr_t offset, Range &range)
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 functionality to Range template classes in RangeMap.h and converted remaining DWARF areas that were using ranges over to this class. Also converted lldb_private::Block to use it. llvm-svn: 141460
2011-10-08 08:49:15 +08:00
const Range *range_ptr = m_ranges.FindEntryThatContains (offset);
if (range_ptr)
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 functionality to Range template classes in RangeMap.h and converted remaining DWARF areas that were using ranges over to this class. Also converted lldb_private::Block to use it. llvm-svn: 141460
2011-10-08 08:49:15 +08:00
range = *range_ptr;
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
return true;
}
range.Clear();
return false;
}
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
bool
Added more functionality to Range template classes in RangeMap.h and converted remaining DWARF areas that were using ranges over to this class. Also converted lldb_private::Block to use it. llvm-svn: 141460
2011-10-08 08:49:15 +08:00
Block::GetRangeContainingAddress (const Address& addr, AddressRange &range)
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
{
We were leaking a stack frame in StackFrameList in Thread.cpp which could cause extra shared pointer references to one or more modules to be leaked. This would cause many object files to stay around the life of LLDB, so after a recompile and rexecution, we would keep adding more and more memory. After fixing the leak, we found many cases where leaked stack frames were still being used and causing crashes in the test suite. These are now all resolved. llvm-svn: 137516
2011-08-13 05:40:01 +08:00
Function *function = CalculateSymbolContextFunction();
if (function)
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
{
We were leaking a stack frame in StackFrameList in Thread.cpp which could cause extra shared pointer references to one or more modules to be leaked. This would cause many object files to stay around the life of LLDB, so after a recompile and rexecution, we would keep adding more and more memory. After fixing the leak, we found many cases where leaked stack frames were still being used and causing crashes in the test suite. These are now all resolved. llvm-svn: 137516
2011-08-13 05:40:01 +08:00
const AddressRange &func_range = function->GetAddressRange();
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 (addr.GetSection() == func_range.GetBaseAddress().GetSection())
{
const addr_t addr_offset = addr.GetOffset();
const addr_t func_offset = func_range.GetBaseAddress().GetOffset();
if (addr_offset >= func_offset && addr_offset < func_offset + func_range.GetByteSize())
{
addr_t offset = addr_offset - func_offset;
Added more functionality to Range template classes in RangeMap.h and converted remaining DWARF areas that were using ranges over to this class. Also converted lldb_private::Block to use it. llvm-svn: 141460
2011-10-08 08:49:15 +08:00
const Range *range_ptr = m_ranges.FindEntryThatContains (offset);
if (range_ptr)
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
{
range.GetBaseAddress() = func_range.GetBaseAddress();
Added more functionality to Range template classes in RangeMap.h and converted remaining DWARF areas that were using ranges over to this class. Also converted lldb_private::Block to use it. llvm-svn: 141460
2011-10-08 08:49:15 +08:00
range.GetBaseAddress().SetOffset(func_offset + range_ptr->GetRangeBase());
range.SetByteSize(range_ptr->GetByteSize());
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
return true;
}
}
}
}
range.Clear();
return false;
}
Add a convenience function to get the range containing a given PC specified as load address + Target. llvm-svn: 163038
2012-09-01 07:49:32 +08:00
bool
Block::GetRangeContainingLoadAddress (lldb::addr_t load_addr, Target &target, AddressRange &range)
{
Address load_address;
load_address.SetLoadAddress(load_addr, &target);
AddressRange containing_range;
return GetRangeContainingAddress(load_address, containing_range);
}
Added more functionality to Range template classes in RangeMap.h and converted remaining DWARF areas that were using ranges over to this class. Also converted lldb_private::Block to use it. llvm-svn: 141460
2011-10-08 08:49:15 +08:00
uint32_t
Block::GetRangeIndexContainingAddress (const Address& addr)
{
Function *function = CalculateSymbolContextFunction();
if (function)
{
const AddressRange &func_range = function->GetAddressRange();
if (addr.GetSection() == func_range.GetBaseAddress().GetSection())
{
const addr_t addr_offset = addr.GetOffset();
const addr_t func_offset = func_range.GetBaseAddress().GetOffset();
if (addr_offset >= func_offset && addr_offset < func_offset + func_range.GetByteSize())
{
addr_t offset = addr_offset - func_offset;
return m_ranges.FindEntryIndexThatContains (offset);
}
}
}
return UINT32_MAX;
}
Fixed the SymbolContext::DumpStopContext() to correctly indent and dump inline contexts when the deepest most block is not inlined. Added source path remappings to the lldb_private::Target class that allow it to remap paths found in debug info so we can find source files that are elsewhere on the current system. Fixed disassembly by function name to disassemble inline functions that are inside other functions much better and to show enough context before the disassembly output so you can tell where things came from. Added the ability to get more than one address range from a SymbolContext class for the case where a block or function has discontiguous address ranges. llvm-svn: 130044
2011-04-23 10:04:55 +08:00
bool
Block::GetRangeAtIndex (uint32_t range_idx, AddressRange &range)
{
Added more functionality to Range template classes in RangeMap.h and converted remaining DWARF areas that were using ranges over to this class. Also converted lldb_private::Block to use it. llvm-svn: 141460
2011-10-08 08:49:15 +08:00
if (range_idx < m_ranges.GetSize())
Fixed the SymbolContext::DumpStopContext() to correctly indent and dump inline contexts when the deepest most block is not inlined. Added source path remappings to the lldb_private::Target class that allow it to remap paths found in debug info so we can find source files that are elsewhere on the current system. Fixed disassembly by function name to disassemble inline functions that are inside other functions much better and to show enough context before the disassembly output so you can tell where things came from. Added the ability to get more than one address range from a SymbolContext class for the case where a block or function has discontiguous address ranges. llvm-svn: 130044
2011-04-23 10:04:55 +08:00
{
We were leaking a stack frame in StackFrameList in Thread.cpp which could cause extra shared pointer references to one or more modules to be leaked. This would cause many object files to stay around the life of LLDB, so after a recompile and rexecution, we would keep adding more and more memory. After fixing the leak, we found many cases where leaked stack frames were still being used and causing crashes in the test suite. These are now all resolved. llvm-svn: 137516
2011-08-13 05:40:01 +08:00
Function *function = CalculateSymbolContextFunction();
if (function)
Fixed the SymbolContext::DumpStopContext() to correctly indent and dump inline contexts when the deepest most block is not inlined. Added source path remappings to the lldb_private::Target class that allow it to remap paths found in debug info so we can find source files that are elsewhere on the current system. Fixed disassembly by function name to disassemble inline functions that are inside other functions much better and to show enough context before the disassembly output so you can tell where things came from. Added the ability to get more than one address range from a SymbolContext class for the case where a block or function has discontiguous address ranges. llvm-svn: 130044
2011-04-23 10:04:55 +08:00
{
Added more functionality to Range template classes in RangeMap.h and converted remaining DWARF areas that were using ranges over to this class. Also converted lldb_private::Block to use it. llvm-svn: 141460
2011-10-08 08:49:15 +08:00
const Range &vm_range = m_ranges.GetEntryRef(range_idx);
We were leaking a stack frame in StackFrameList in Thread.cpp which could cause extra shared pointer references to one or more modules to be leaked. This would cause many object files to stay around the life of LLDB, so after a recompile and rexecution, we would keep adding more and more memory. After fixing the leak, we found many cases where leaked stack frames were still being used and causing crashes in the test suite. These are now all resolved. llvm-svn: 137516
2011-08-13 05:40:01 +08:00
range.GetBaseAddress() = function->GetAddressRange().GetBaseAddress();
Added more functionality to Range template classes in RangeMap.h and converted remaining DWARF areas that were using ranges over to this class. Also converted lldb_private::Block to use it. llvm-svn: 141460
2011-10-08 08:49:15 +08:00
range.GetBaseAddress().Slide(vm_range.GetRangeBase ());
range.SetByteSize (vm_range.GetByteSize());
Fixed the SymbolContext::DumpStopContext() to correctly indent and dump inline contexts when the deepest most block is not inlined. Added source path remappings to the lldb_private::Target class that allow it to remap paths found in debug info so we can find source files that are elsewhere on the current system. Fixed disassembly by function name to disassemble inline functions that are inside other functions much better and to show enough context before the disassembly output so you can tell where things came from. Added the ability to get more than one address range from a SymbolContext class for the case where a block or function has discontiguous address ranges. llvm-svn: 130044
2011-04-23 10:04:55 +08:00
return true;
}
}
return false;
}
Fixed a crasher (an assert was firing in the DWARF parser) when setting breakpoints on inlined functions by name. This involved fixing the DWARF parser to correctly back up and parse the concrete function when we find inlined functions by name, then grabbing any appropriate inlined blocks and returning symbol contexts with the block filled in. After this was fixed, the breakpoint by name resolver needed to correctly deal with symbol contexts that had the inlined block filled in in the symbol contexts. llvm-svn: 119017
2010-11-14 08:22:48 +08:00
bool
Block::GetStartAddress (Address &addr)
{
Added more functionality to Range template classes in RangeMap.h and converted remaining DWARF areas that were using ranges over to this class. Also converted lldb_private::Block to use it. llvm-svn: 141460
2011-10-08 08:49:15 +08:00
if (m_ranges.IsEmpty())
Fixed a crasher (an assert was firing in the DWARF parser) when setting breakpoints on inlined functions by name. This involved fixing the DWARF parser to correctly back up and parse the concrete function when we find inlined functions by name, then grabbing any appropriate inlined blocks and returning symbol contexts with the block filled in. After this was fixed, the breakpoint by name resolver needed to correctly deal with symbol contexts that had the inlined block filled in in the symbol contexts. llvm-svn: 119017
2010-11-14 08:22:48 +08:00
return false;
We were leaking a stack frame in StackFrameList in Thread.cpp which could cause extra shared pointer references to one or more modules to be leaked. This would cause many object files to stay around the life of LLDB, so after a recompile and rexecution, we would keep adding more and more memory. After fixing the leak, we found many cases where leaked stack frames were still being used and causing crashes in the test suite. These are now all resolved. llvm-svn: 137516
2011-08-13 05:40:01 +08:00
Function *function = CalculateSymbolContextFunction();
if (function)
Fixed a crasher (an assert was firing in the DWARF parser) when setting breakpoints on inlined functions by name. This involved fixing the DWARF parser to correctly back up and parse the concrete function when we find inlined functions by name, then grabbing any appropriate inlined blocks and returning symbol contexts with the block filled in. After this was fixed, the breakpoint by name resolver needed to correctly deal with symbol contexts that had the inlined block filled in in the symbol contexts. llvm-svn: 119017
2010-11-14 08:22:48 +08:00
{
We were leaking a stack frame in StackFrameList in Thread.cpp which could cause extra shared pointer references to one or more modules to be leaked. This would cause many object files to stay around the life of LLDB, so after a recompile and rexecution, we would keep adding more and more memory. After fixing the leak, we found many cases where leaked stack frames were still being used and causing crashes in the test suite. These are now all resolved. llvm-svn: 137516
2011-08-13 05:40:01 +08:00
addr = function->GetAddressRange().GetBaseAddress();
Added more functionality to Range template classes in RangeMap.h and converted remaining DWARF areas that were using ranges over to this class. Also converted lldb_private::Block to use it. llvm-svn: 141460
2011-10-08 08:49:15 +08:00
addr.Slide(m_ranges.GetEntryRef(0).GetRangeBase ());
Fixed a crasher (an assert was firing in the DWARF parser) when setting breakpoints on inlined functions by name. This involved fixing the DWARF parser to correctly back up and parse the concrete function when we find inlined functions by name, then grabbing any appropriate inlined blocks and returning symbol contexts with the block filled in. After this was fixed, the breakpoint by name resolver needed to correctly deal with symbol contexts that had the inlined block filled in in the symbol contexts. llvm-svn: 119017
2010-11-14 08:22:48 +08:00
return true;
}
return false;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
void
Added more functionality to Range template classes in RangeMap.h and converted remaining DWARF areas that were using ranges over to this class. Also converted lldb_private::Block to use it. llvm-svn: 141460
2011-10-08 08:49:15 +08:00
Block::FinalizeRanges ()
{
m_ranges.Sort();
m_ranges.CombineConsecutiveRanges ();
}
void
Block::AddRange (const Range& range)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Fixed an issue where a lexical block or inlined function might have bad debug information generated for it. Say we have a concrete function "foo" which has inlined function "a" which calls another inlined function "b": foo 1 { 2 { a () 3 { b () 4 { } } } } Sometimes we see the compiler generate an address range in the DWARF for "foo" (block 1 above) as say [0x1000-0x1100). Then the range for "a" is something like [0x1050-0x1060) (note that it is correctly scoped within the "foo" address range). And then we get "b" which is a child of "a", yet the debug info says it has a range of [0x1060-0x1080) (not contained within "a"). We now detect this issue when making our blocks and add an extra range to "a". Also added a new "lldb" logging category named "symbol" where we can find out about symbol file errors and warnings. llvm-svn: 140822
2011-09-30 07:41:34 +08:00
Block *parent_block = GetParent ();
Added more functionality to Range template classes in RangeMap.h and converted remaining DWARF areas that were using ranges over to this class. Also converted lldb_private::Block to use it. llvm-svn: 141460
2011-10-08 08:49:15 +08:00
if (parent_block && !parent_block->Contains(range))
Fixed an issue where a lexical block or inlined function might have bad debug information generated for it. Say we have a concrete function "foo" which has inlined function "a" which calls another inlined function "b": foo 1 { 2 { a () 3 { b () 4 { } } } } Sometimes we see the compiler generate an address range in the DWARF for "foo" (block 1 above) as say [0x1000-0x1100). Then the range for "a" is something like [0x1050-0x1060) (note that it is correctly scoped within the "foo" address range). And then we get "b" which is a child of "a", yet the debug info says it has a range of [0x1060-0x1080) (not contained within "a"). We now detect this issue when making our blocks and add an extra range to "a". Also added a new "lldb" logging category named "symbol" where we can find out about symbol file errors and warnings. llvm-svn: 140822
2011-09-30 07:41:34 +08:00
{
<rdar://problem/13521159> LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down. All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_SYMBOLS));
Fixed an issue where a lexical block or inlined function might have bad debug information generated for it. Say we have a concrete function "foo" which has inlined function "a" which calls another inlined function "b": foo 1 { 2 { a () 3 { b () 4 { } } } } Sometimes we see the compiler generate an address range in the DWARF for "foo" (block 1 above) as say [0x1000-0x1100). Then the range for "a" is something like [0x1050-0x1060) (note that it is correctly scoped within the "foo" address range). And then we get "b" which is a child of "a", yet the debug info says it has a range of [0x1060-0x1080) (not contained within "a"). We now detect this issue when making our blocks and add an extra range to "a". Also added a new "lldb" logging category named "symbol" where we can find out about symbol file errors and warnings. llvm-svn: 140822
2011-09-30 07:41:34 +08:00
if (log)
{
<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_parent_scope->CalculateSymbolContextModule());
Fixed an issue where a lexical block or inlined function might have bad debug information generated for it. Say we have a concrete function "foo" which has inlined function "a" which calls another inlined function "b": foo 1 { 2 { a () 3 { b () 4 { } } } } Sometimes we see the compiler generate an address range in the DWARF for "foo" (block 1 above) as say [0x1000-0x1100). Then the range for "a" is something like [0x1050-0x1060) (note that it is correctly scoped within the "foo" address range). And then we get "b" which is a child of "a", yet the debug info says it has a range of [0x1060-0x1080) (not contained within "a"). We now detect this issue when making our blocks and add an extra range to "a". Also added a new "lldb" logging category named "symbol" where we can find out about symbol file errors and warnings. llvm-svn: 140822
2011-09-30 07:41:34 +08:00
Function *function = m_parent_scope->CalculateSymbolContextFunction();
const addr_t function_file_addr = function->GetAddressRange().GetBaseAddress().GetFileAddress();
Added more functionality to Range template classes in RangeMap.h and converted remaining DWARF areas that were using ranges over to this class. Also converted lldb_private::Block to use it. llvm-svn: 141460
2011-10-08 08:49:15 +08:00
const addr_t block_start_addr = function_file_addr + range.GetRangeBase ();
const addr_t block_end_addr = function_file_addr + range.GetRangeEnd ();
Fixed an issue where a lexical block or inlined function might have bad debug information generated for it. Say we have a concrete function "foo" which has inlined function "a" which calls another inlined function "b": foo 1 { 2 { a () 3 { b () 4 { } } } } Sometimes we see the compiler generate an address range in the DWARF for "foo" (block 1 above) as say [0x1000-0x1100). Then the range for "a" is something like [0x1050-0x1060) (note that it is correctly scoped within the "foo" address range). And then we get "b" which is a child of "a", yet the debug info says it has a range of [0x1060-0x1080) (not contained within "a"). We now detect this issue when making our blocks and add an extra range to "a". Also added a new "lldb" logging category named "symbol" where we can find out about symbol file errors and warnings. llvm-svn: 140822
2011-09-30 07:41:34 +08:00
Type *func_type = function->GetType();
const Declaration &func_decl = func_type->GetDeclaration();
if (func_decl.GetLine())
{
Cleanup logging to use the new "std::string FileSpec::GetPath()" function. Also added a similar function for modules: std::string Module::GetSpecificationDescription () const; This returns the module as "/usr/lib/libfoo.dylib" for normal files (calls "std::string FileSpec::GetPath()" on m_file) but it also might include the object name in case the module is for a .o file in a BSD archive ("/usr/lib/libfoo.a(bar.o)"). Cleaned up necessary logging code to use it. llvm-svn: 180717
2013-04-30 01:25:54 +08:00
log->Printf ("warning: %s:%u block {0x%8.8" PRIx64 "} has range[%u] [0x%" PRIx64 " - 0x%" PRIx64 ") which is not contained in parent block {0x%8.8" PRIx64 "} in function {0x%8.8" PRIx64 "} from %s",
func_decl.GetFile().GetPath().c_str(),
Fixed an issue where a lexical block or inlined function might have bad debug information generated for it. Say we have a concrete function "foo" which has inlined function "a" which calls another inlined function "b": foo 1 { 2 { a () 3 { b () 4 { } } } } Sometimes we see the compiler generate an address range in the DWARF for "foo" (block 1 above) as say [0x1000-0x1100). Then the range for "a" is something like [0x1050-0x1060) (note that it is correctly scoped within the "foo" address range). And then we get "b" which is a child of "a", yet the debug info says it has a range of [0x1060-0x1080) (not contained within "a"). We now detect this issue when making our blocks and add an extra range to "a". Also added a new "lldb" logging category named "symbol" where we can find out about symbol file errors and warnings. llvm-svn: 140822
2011-09-30 07:41:34 +08:00
func_decl.GetLine(),
GetID(),
Added more functionality to Range template classes in RangeMap.h and converted remaining DWARF areas that were using ranges over to this class. Also converted lldb_private::Block to use it. llvm-svn: 141460
2011-10-08 08:49:15 +08:00
(uint32_t)m_ranges.GetSize(),
Fixed an issue where a lexical block or inlined function might have bad debug information generated for it. Say we have a concrete function "foo" which has inlined function "a" which calls another inlined function "b": foo 1 { 2 { a () 3 { b () 4 { } } } } Sometimes we see the compiler generate an address range in the DWARF for "foo" (block 1 above) as say [0x1000-0x1100). Then the range for "a" is something like [0x1050-0x1060) (note that it is correctly scoped within the "foo" address range). And then we get "b" which is a child of "a", yet the debug info says it has a range of [0x1060-0x1080) (not contained within "a"). We now detect this issue when making our blocks and add an extra range to "a". Also added a new "lldb" logging category named "symbol" where we can find out about symbol file errors and warnings. llvm-svn: 140822
2011-09-30 07:41:34 +08:00
block_start_addr,
block_end_addr,
parent_block->GetID(),
function->GetID(),
Cleanup logging to use the new "std::string FileSpec::GetPath()" function. Also added a similar function for modules: std::string Module::GetSpecificationDescription () const; This returns the module as "/usr/lib/libfoo.dylib" for normal files (calls "std::string FileSpec::GetPath()" on m_file) but it also might include the object name in case the module is for a .o file in a BSD archive ("/usr/lib/libfoo.a(bar.o)"). Cleaned up necessary logging code to use it. llvm-svn: 180717
2013-04-30 01:25:54 +08:00
module_sp->GetFileSpec().GetPath().c_str());
Fixed an issue where a lexical block or inlined function might have bad debug information generated for it. Say we have a concrete function "foo" which has inlined function "a" which calls another inlined function "b": foo 1 { 2 { a () 3 { b () 4 { } } } } Sometimes we see the compiler generate an address range in the DWARF for "foo" (block 1 above) as say [0x1000-0x1100). Then the range for "a" is something like [0x1050-0x1060) (note that it is correctly scoped within the "foo" address range). And then we get "b" which is a child of "a", yet the debug info says it has a range of [0x1060-0x1080) (not contained within "a"). We now detect this issue when making our blocks and add an extra range to "a". Also added a new "lldb" logging category named "symbol" where we can find out about symbol file errors and warnings. llvm-svn: 140822
2011-09-30 07:41:34 +08:00
}
else
{
Cleanup logging to use the new "std::string FileSpec::GetPath()" function. Also added a similar function for modules: std::string Module::GetSpecificationDescription () const; This returns the module as "/usr/lib/libfoo.dylib" for normal files (calls "std::string FileSpec::GetPath()" on m_file) but it also might include the object name in case the module is for a .o file in a BSD archive ("/usr/lib/libfoo.a(bar.o)"). Cleaned up necessary logging code to use it. llvm-svn: 180717
2013-04-30 01:25:54 +08:00
log->Printf ("warning: block {0x%8.8" PRIx64 "} has range[%u] [0x%" PRIx64 " - 0x%" PRIx64 ") which is not contained in parent block {0x%8.8" PRIx64 "} in function {0x%8.8" PRIx64 "} from %s",
Fixed an issue where a lexical block or inlined function might have bad debug information generated for it. Say we have a concrete function "foo" which has inlined function "a" which calls another inlined function "b": foo 1 { 2 { a () 3 { b () 4 { } } } } Sometimes we see the compiler generate an address range in the DWARF for "foo" (block 1 above) as say [0x1000-0x1100). Then the range for "a" is something like [0x1050-0x1060) (note that it is correctly scoped within the "foo" address range). And then we get "b" which is a child of "a", yet the debug info says it has a range of [0x1060-0x1080) (not contained within "a"). We now detect this issue when making our blocks and add an extra range to "a". Also added a new "lldb" logging category named "symbol" where we can find out about symbol file errors and warnings. llvm-svn: 140822
2011-09-30 07:41:34 +08:00
GetID(),
Added more functionality to Range template classes in RangeMap.h and converted remaining DWARF areas that were using ranges over to this class. Also converted lldb_private::Block to use it. llvm-svn: 141460
2011-10-08 08:49:15 +08:00
(uint32_t)m_ranges.GetSize(),
Fixed an issue where a lexical block or inlined function might have bad debug information generated for it. Say we have a concrete function "foo" which has inlined function "a" which calls another inlined function "b": foo 1 { 2 { a () 3 { b () 4 { } } } } Sometimes we see the compiler generate an address range in the DWARF for "foo" (block 1 above) as say [0x1000-0x1100). Then the range for "a" is something like [0x1050-0x1060) (note that it is correctly scoped within the "foo" address range). And then we get "b" which is a child of "a", yet the debug info says it has a range of [0x1060-0x1080) (not contained within "a"). We now detect this issue when making our blocks and add an extra range to "a". Also added a new "lldb" logging category named "symbol" where we can find out about symbol file errors and warnings. llvm-svn: 140822
2011-09-30 07:41:34 +08:00
block_start_addr,
block_end_addr,
parent_block->GetID(),
function->GetID(),
Cleanup logging to use the new "std::string FileSpec::GetPath()" function. Also added a similar function for modules: std::string Module::GetSpecificationDescription () const; This returns the module as "/usr/lib/libfoo.dylib" for normal files (calls "std::string FileSpec::GetPath()" on m_file) but it also might include the object name in case the module is for a .o file in a BSD archive ("/usr/lib/libfoo.a(bar.o)"). Cleaned up necessary logging code to use it. llvm-svn: 180717
2013-04-30 01:25:54 +08:00
module_sp->GetFileSpec().GetPath().c_str());
Fixed an issue where a lexical block or inlined function might have bad debug information generated for it. Say we have a concrete function "foo" which has inlined function "a" which calls another inlined function "b": foo 1 { 2 { a () 3 { b () 4 { } } } } Sometimes we see the compiler generate an address range in the DWARF for "foo" (block 1 above) as say [0x1000-0x1100). Then the range for "a" is something like [0x1050-0x1060) (note that it is correctly scoped within the "foo" address range). And then we get "b" which is a child of "a", yet the debug info says it has a range of [0x1060-0x1080) (not contained within "a"). We now detect this issue when making our blocks and add an extra range to "a". Also added a new "lldb" logging category named "symbol" where we can find out about symbol file errors and warnings. llvm-svn: 140822
2011-09-30 07:41:34 +08:00
}
}
Added more functionality to Range template classes in RangeMap.h and converted remaining DWARF areas that were using ranges over to this class. Also converted lldb_private::Block to use it. llvm-svn: 141460
2011-10-08 08:49:15 +08:00
parent_block->AddRange (range);
Fixed an issue where a lexical block or inlined function might have bad debug information generated for it. Say we have a concrete function "foo" which has inlined function "a" which calls another inlined function "b": foo 1 { 2 { a () 3 { b () 4 { } } } } Sometimes we see the compiler generate an address range in the DWARF for "foo" (block 1 above) as say [0x1000-0x1100). Then the range for "a" is something like [0x1050-0x1060) (note that it is correctly scoped within the "foo" address range). And then we get "b" which is a child of "a", yet the debug info says it has a range of [0x1060-0x1080) (not contained within "a"). We now detect this issue when making our blocks and add an extra range to "a". Also added a new "lldb" logging category named "symbol" where we can find out about symbol file errors and warnings. llvm-svn: 140822
2011-09-30 07:41:34 +08:00
}
Added more functionality to Range template classes in RangeMap.h and converted remaining DWARF areas that were using ranges over to this class. Also converted lldb_private::Block to use it. llvm-svn: 141460
2011-10-08 08:49:15 +08:00
m_ranges.Append(range);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
// Return the current number of bytes that this object occupies in memory
size_t
Block::MemorySize() const
{
Added more functionality to Range template classes in RangeMap.h and converted remaining DWARF areas that were using ranges over to this class. Also converted lldb_private::Block to use it. llvm-svn: 141460
2011-10-08 08:49:15 +08:00
size_t mem_size = sizeof(Block) + m_ranges.GetSize() * sizeof(Range);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
if (m_inlineInfoSP.get())
mem_size += m_inlineInfoSP->MemorySize();
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_variable_list_sp.get())
mem_size += m_variable_list_sp->MemorySize();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
return mem_size;
}
Modified the host process monitor callback function Host::StartMonitoringChildProcess to spawn a thread for each process that is being monitored. Previously LLDB would spawn a single thread that would wait for any child process which isn't ok to do as a shared library (LLDB.framework on Mac OSX, or lldb.so on linux). The old single thread used to call wait4() with a pid of -1 which could cause it to reap child processes that it shouldn't have. Re-wrote the way Function blocks are handles. Previously I attempted to keep all blocks in a single memory allocation (in a std::vector). This made the code somewhat efficient, but hard to work with. I got rid of the old BlockList class, and went to a straight parent with children relationship. This new approach will allow for partial parsing of the blocks within a function. llvm-svn: 111706
2010-08-21 10:22:51 +08:00
void
Block::AddChild(const BlockSP &child_block_sp)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Modified the host process monitor callback function Host::StartMonitoringChildProcess to spawn a thread for each process that is being monitored. Previously LLDB would spawn a single thread that would wait for any child process which isn't ok to do as a shared library (LLDB.framework on Mac OSX, or lldb.so on linux). The old single thread used to call wait4() with a pid of -1 which could cause it to reap child processes that it shouldn't have. Re-wrote the way Function blocks are handles. Previously I attempted to keep all blocks in a single memory allocation (in a std::vector). This made the code somewhat efficient, but hard to work with. I got rid of the old BlockList class, and went to a straight parent with children relationship. This new approach will allow for partial parsing of the blocks within a function. llvm-svn: 111706
2010-08-21 10:22:51 +08:00
if (child_block_sp)
{
child_block_sp->SetParentScope (this);
m_children.push_back (child_block_sp);
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
void
Block::SetInlinedFunctionInfo(const char *name, const char *mangled, const Declaration *decl_ptr, const Declaration *call_decl_ptr)
{
m_inlineInfoSP.reset(new InlineFunctionInfo(name, mangled, decl_ptr, call_decl_ptr));
}
Some Block:: methods wandered to the end of the file after the BlockList:: methods. I moved them back. llvm-svn: 111396
2010-08-19 03:29:16 +08:00
VariableListSP
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
Block::GetBlockVariableList (bool can_create)
Some Block:: methods wandered to the end of the file after the BlockList:: methods. I moved them back. llvm-svn: 111396
2010-08-19 03:29:16 +08:00
{
Modified the host process monitor callback function Host::StartMonitoringChildProcess to spawn a thread for each process that is being monitored. Previously LLDB would spawn a single thread that would wait for any child process which isn't ok to do as a shared library (LLDB.framework on Mac OSX, or lldb.so on linux). The old single thread used to call wait4() with a pid of -1 which could cause it to reap child processes that it shouldn't have. Re-wrote the way Function blocks are handles. Previously I attempted to keep all blocks in a single memory allocation (in a std::vector). This made the code somewhat efficient, but hard to work with. I got rid of the old BlockList class, and went to a straight parent with children relationship. This new approach will allow for partial parsing of the blocks within a function. llvm-svn: 111706
2010-08-21 10:22:51 +08:00
if (m_parsed_block_variables == false)
Some Block:: methods wandered to the end of the file after the BlockList:: methods. I moved them back. llvm-svn: 111396
2010-08-19 03:29:16 +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
if (m_variable_list_sp.get() == NULL && can_create)
Modified the host process monitor callback function Host::StartMonitoringChildProcess to spawn a thread for each process that is being monitored. Previously LLDB would spawn a single thread that would wait for any child process which isn't ok to do as a shared library (LLDB.framework on Mac OSX, or lldb.so on linux). The old single thread used to call wait4() with a pid of -1 which could cause it to reap child processes that it shouldn't have. Re-wrote the way Function blocks are handles. Previously I attempted to keep all blocks in a single memory allocation (in a std::vector). This made the code somewhat efficient, but hard to work with. I got rid of the old BlockList class, and went to a straight parent with children relationship. This new approach will allow for partial parsing of the blocks within a function. llvm-svn: 111706
2010-08-21 10:22:51 +08:00
{
m_parsed_block_variables = true;
SymbolContext sc;
CalculateSymbolContext(&sc);
assert(sc.module_sp);
sc.module_sp->GetSymbolVendor()->ParseVariablesForContext(sc);
}
Some Block:: methods wandered to the end of the file after the BlockList:: methods. I moved them back. llvm-svn: 111396
2010-08-19 03:29:16 +08:00
}
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
return m_variable_list_sp;
}
Some Block:: methods wandered to the end of the file after the BlockList:: methods. I moved them back. llvm-svn: 111396
2010-08-19 03:29:16 +08:00
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
uint32_t
Block::AppendBlockVariables (bool can_create,
bool get_child_block_variables,
bool stop_if_child_block_is_inlined_function,
VariableList *variable_list)
{
uint32_t num_variables_added = 0;
VariableList *block_var_list = GetBlockVariableList (can_create).get();
if (block_var_list)
Some Block:: methods wandered to the end of the file after the BlockList:: methods. I moved them back. llvm-svn: 111396
2010-08-19 03:29:16 +08:00
{
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
num_variables_added += block_var_list->GetSize();
variable_list->AddVariables (block_var_list);
}
if (get_child_block_variables)
{
Free up some space in lldb_private::Block by not requiring a sibling pointer. The old way of storing blocks used to use the sibling pointer, but now all blocks contain a collection of shared pointers to blocks so this isn't required anymore and a parent can be asked to find the sibling block for a child block. llvm-svn: 140808
2011-09-30 05:19:25 +08:00
collection::const_iterator pos, end = m_children.end();
for (pos = m_children.begin(); pos != end; ++pos)
{
Block *child_block = pos->get();
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
if (stop_if_child_block_is_inlined_function == false ||
child_block->GetInlinedFunctionInfo() == NULL)
{
num_variables_added += child_block->AppendBlockVariables (can_create,
get_child_block_variables,
stop_if_child_block_is_inlined_function,
variable_list);
Some Block:: methods wandered to the end of the file after the BlockList:: methods. I moved them back. llvm-svn: 111396
2010-08-19 03:29:16 +08:00
}
}
}
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
return num_variables_added;
Some Block:: methods wandered to the end of the file after the BlockList:: methods. I moved them back. llvm-svn: 111396
2010-08-19 03:29:16 +08:00
}
uint32_t
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
Block::AppendVariables
(
bool can_create,
bool get_parent_variables,
bool stop_if_block_is_inlined_function,
VariableList *variable_list
)
Some Block:: methods wandered to the end of the file after the BlockList:: methods. I moved them back. llvm-svn: 111396
2010-08-19 03:29:16 +08:00
{
uint32_t num_variables_added = 0;
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
VariableListSP variable_list_sp(GetBlockVariableList(can_create));
Some Block:: methods wandered to the end of the file after the BlockList:: methods. I moved them back. llvm-svn: 111396
2010-08-19 03:29:16 +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
bool is_inlined_function = GetInlinedFunctionInfo() != NULL;
Some Block:: methods wandered to the end of the file after the BlockList:: methods. I moved them back. llvm-svn: 111396
2010-08-19 03:29:16 +08:00
if (variable_list_sp.get())
{
num_variables_added = variable_list_sp->GetSize();
variable_list->AddVariables(variable_list_sp.get());
}
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
Some Block:: methods wandered to the end of the file after the BlockList:: methods. I moved them back. llvm-svn: 111396
2010-08-19 03:29:16 +08:00
if (get_parent_variables)
{
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 (stop_if_block_is_inlined_function && is_inlined_function)
return num_variables_added;
Some Block:: methods wandered to the end of the file after the BlockList:: methods. I moved them back. llvm-svn: 111396
2010-08-19 03:29:16 +08:00
Block* parent_block = GetParent();
if (parent_block)
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
num_variables_added += parent_block->AppendVariables (can_create, get_parent_variables, stop_if_block_is_inlined_function, variable_list);
Some Block:: methods wandered to the end of the file after the BlockList:: methods. I moved them back. llvm-svn: 111396
2010-08-19 03:29:16 +08:00
}
return num_variables_added;
}
This is an overhaul of the expression parser code that detects what context the current expression is meant to execute in. LLDB now properly consults the method declaration in the debug information rather than trying to hunt down the "this" or "self" pointer by name, which can be misleading. Other fixes include: - LLDB now properly detects that it is inside an inlined C++ member function. - LLDB now allows access to non-const members when in const code. - The functions in SymbolFile that locate the DeclContext containing a DIE have been renamed to reflect what they actually do. I have added new functions that find the DeclContext for the DIE itself. I have also introduced testcases for C++ and Objective-C. llvm-svn: 136999
2011-08-06 07:43:37 +08:00
clang::DeclContext *
<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
Block::GetClangDeclContext()
This is an overhaul of the expression parser code that detects what context the current expression is meant to execute in. LLDB now properly consults the method declaration in the debug information rather than trying to hunt down the "this" or "self" pointer by name, which can be misleading. Other fixes include: - LLDB now properly detects that it is inside an inlined C++ member function. - LLDB now allows access to non-const members when in const code. - The functions in SymbolFile that locate the DeclContext containing a DIE have been renamed to reflect what they actually do. I have added new functions that find the DeclContext for the DIE itself. I have also introduced testcases for C++ and Objective-C. llvm-svn: 136999
2011-08-06 07:43:37 +08:00
{
SymbolContext sc;
CalculateSymbolContext (&sc);
if (!sc.module_sp)
return NULL;
SymbolVendor *sym_vendor = sc.module_sp->GetSymbolVendor();
if (!sym_vendor)
return NULL;
SymbolFile *sym_file = sym_vendor->GetSymbolFile();
if (!sym_file)
return NULL;
return sym_file->GetClangDeclContextForTypeUID (sc, m_uid);
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
void
Modified the host process monitor callback function Host::StartMonitoringChildProcess to spawn a thread for each process that is being monitored. Previously LLDB would spawn a single thread that would wait for any child process which isn't ok to do as a shared library (LLDB.framework on Mac OSX, or lldb.so on linux). The old single thread used to call wait4() with a pid of -1 which could cause it to reap child processes that it shouldn't have. Re-wrote the way Function blocks are handles. Previously I attempted to keep all blocks in a single memory allocation (in a std::vector). This made the code somewhat efficient, but hard to work with. I got rid of the old BlockList class, and went to a straight parent with children relationship. This new approach will allow for partial parsing of the blocks within a function. llvm-svn: 111706
2010-08-21 10:22:51 +08:00
Block::SetBlockInfoHasBeenParsed (bool b, bool set_children)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Modified the host process monitor callback function Host::StartMonitoringChildProcess to spawn a thread for each process that is being monitored. Previously LLDB would spawn a single thread that would wait for any child process which isn't ok to do as a shared library (LLDB.framework on Mac OSX, or lldb.so on linux). The old single thread used to call wait4() with a pid of -1 which could cause it to reap child processes that it shouldn't have. Re-wrote the way Function blocks are handles. Previously I attempted to keep all blocks in a single memory allocation (in a std::vector). This made the code somewhat efficient, but hard to work with. I got rid of the old BlockList class, and went to a straight parent with children relationship. This new approach will allow for partial parsing of the blocks within a function. llvm-svn: 111706
2010-08-21 10:22:51 +08:00
m_parsed_block_info = b;
if (set_children)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Modified the host process monitor callback function Host::StartMonitoringChildProcess to spawn a thread for each process that is being monitored. Previously LLDB would spawn a single thread that would wait for any child process which isn't ok to do as a shared library (LLDB.framework on Mac OSX, or lldb.so on linux). The old single thread used to call wait4() with a pid of -1 which could cause it to reap child processes that it shouldn't have. Re-wrote the way Function blocks are handles. Previously I attempted to keep all blocks in a single memory allocation (in a std::vector). This made the code somewhat efficient, but hard to work with. I got rid of the old BlockList class, and went to a straight parent with children relationship. This new approach will allow for partial parsing of the blocks within a function. llvm-svn: 111706
2010-08-21 10:22:51 +08:00
m_parsed_child_blocks = true;
Free up some space in lldb_private::Block by not requiring a sibling pointer. The old way of storing blocks used to use the sibling pointer, but now all blocks contain a collection of shared pointers to blocks so this isn't required anymore and a parent can be asked to find the sibling block for a child block. llvm-svn: 140808
2011-09-30 05:19:25 +08:00
collection::const_iterator pos, end = m_children.end();
for (pos = m_children.begin(); pos != end; ++pos)
(*pos)->SetBlockInfoHasBeenParsed (b, true);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
}
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
void
Block::SetDidParseVariables (bool b, bool set_children)
{
m_parsed_block_variables = b;
if (set_children)
{
Free up some space in lldb_private::Block by not requiring a sibling pointer. The old way of storing blocks used to use the sibling pointer, but now all blocks contain a collection of shared pointers to blocks so this isn't required anymore and a parent can be asked to find the sibling block for a child block. llvm-svn: 140808
2011-09-30 05:19:25 +08:00
collection::const_iterator pos, end = m_children.end();
for (pos = m_children.begin(); pos != end; ++pos)
(*pos)->SetDidParseVariables (b, true);
}
}
Block *
Block::GetSibling() const
{
if (m_parent_scope)
{
Fixed an issue where a lexical block or inlined function might have bad debug information generated for it. Say we have a concrete function "foo" which has inlined function "a" which calls another inlined function "b": foo 1 { 2 { a () 3 { b () 4 { } } } } Sometimes we see the compiler generate an address range in the DWARF for "foo" (block 1 above) as say [0x1000-0x1100). Then the range for "a" is something like [0x1050-0x1060) (note that it is correctly scoped within the "foo" address range). And then we get "b" which is a child of "a", yet the debug info says it has a range of [0x1060-0x1080) (not contained within "a"). We now detect this issue when making our blocks and add an extra range to "a". Also added a new "lldb" logging category named "symbol" where we can find out about symbol file errors and warnings. llvm-svn: 140822
2011-09-30 07:41:34 +08:00
Block *parent_block = GetParent();
Free up some space in lldb_private::Block by not requiring a sibling pointer. The old way of storing blocks used to use the sibling pointer, but now all blocks contain a collection of shared pointers to blocks so this isn't required anymore and a parent can be asked to find the sibling block for a child block. llvm-svn: 140808
2011-09-30 05:19:25 +08:00
if (parent_block)
return parent_block->GetSiblingForChild (this);
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
}
Free up some space in lldb_private::Block by not requiring a sibling pointer. The old way of storing blocks used to use the sibling pointer, but now all blocks contain a collection of shared pointers to blocks so this isn't required anymore and a parent can be asked to find the sibling block for a child block. llvm-svn: 140808
2011-09-30 05:19:25 +08:00
return NULL;
}
// A parent of child blocks can be asked to find a sibling block given
// one of its child blocks
Block *
Block::GetSiblingForChild (const Block *child_block) const
{
if (!m_children.empty())
{
collection::const_iterator pos, end = m_children.end();
for (pos = m_children.begin(); pos != end; ++pos)
{
if (pos->get() == child_block)
{
if (++pos != end)
return pos->get();
break;
}
}
}
return NULL;
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
}