llvm-project/lldb/source/Symbol/LineEntry.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

261 lines
8.4 KiB
C++
Raw Normal View History

//===-- LineEntry.cpp -----------------------------------------------------===//
//
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
//
//===----------------------------------------------------------------------===//
#include "lldb/Symbol/LineEntry.h"
#include "lldb/Symbol/CompileUnit.h"
#include "lldb/Target/Process.h"
#include "lldb/Target/Target.h"
using namespace lldb_private;
LineEntry::LineEntry()
: range(), file(), is_start_of_statement(0), is_start_of_basic_block(0),
is_prologue_end(0), is_epilogue_begin(0), is_terminal_entry(0) {}
LineEntry::LineEntry(const lldb::SectionSP &section_sp,
lldb::addr_t section_offset, lldb::addr_t byte_size,
const FileSpec &_file, uint32_t _line, uint16_t _column,
bool _is_start_of_statement, bool _is_start_of_basic_block,
bool _is_prologue_end, bool _is_epilogue_begin,
bool _is_terminal_entry)
: range(section_sp, section_offset, byte_size), file(_file),
original_file(_file), line(_line), column(_column),
is_start_of_statement(_is_start_of_statement),
is_start_of_basic_block(_is_start_of_basic_block),
is_prologue_end(_is_prologue_end), is_epilogue_begin(_is_epilogue_begin),
is_terminal_entry(_is_terminal_entry) {}
void LineEntry::Clear() {
range.Clear();
file.Clear();
original_file.Clear();
line = LLDB_INVALID_LINE_NUMBER;
column = 0;
is_start_of_statement = 0;
is_start_of_basic_block = 0;
is_prologue_end = 0;
is_epilogue_begin = 0;
is_terminal_entry = 0;
}
bool LineEntry::IsValid() const {
return range.GetBaseAddress().IsValid() && line != LLDB_INVALID_LINE_NUMBER;
}
bool LineEntry::DumpStopContext(Stream *s, bool show_fullpaths) const {
if (file) {
if (show_fullpaths)
file.Dump(s->AsRawOstream());
else
file.GetFilename().Dump(s);
if (line)
s->PutChar(':');
}
if (line) {
s->Printf("%u", line);
if (column) {
s->PutChar(':');
s->Printf("%u", column);
}
}
return file || line;
}
bool LineEntry::Dump(Stream *s, Target *target, bool show_file,
Address::DumpStyle style,
Address::DumpStyle fallback_style, bool show_range) const {
if (show_range) {
// Show address range
if (!range.Dump(s, target, style, fallback_style))
return false;
} else {
// Show address only
if (!range.GetBaseAddress().Dump(s, target, style, fallback_style))
return false;
}
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 (show_file)
*s << ", file = " << file;
if (line)
s->Printf(", line = %u", line);
if (column)
s->Printf(", column = %u", column);
if (is_start_of_statement)
*s << ", is_start_of_statement = TRUE";
if (is_start_of_basic_block)
*s << ", is_start_of_basic_block = TRUE";
if (is_prologue_end)
*s << ", is_prologue_end = TRUE";
if (is_epilogue_begin)
*s << ", is_epilogue_begin = TRUE";
if (is_terminal_entry)
*s << ", is_terminal_entry = TRUE";
return true;
}
bool LineEntry::GetDescription(Stream *s, lldb::DescriptionLevel level,
CompileUnit *cu, Target *target,
bool show_address_only) const {
if (level == lldb::eDescriptionLevelBrief ||
level == lldb::eDescriptionLevelFull) {
if (show_address_only) {
range.GetBaseAddress().Dump(s, target, Address::DumpStyleLoadAddress,
Address::DumpStyleFileAddress);
} else {
range.Dump(s, target, Address::DumpStyleLoadAddress,
Address::DumpStyleFileAddress);
}
*s << ": " << file;
if (line) {
s->Printf(":%u", line);
if (column)
s->Printf(":%u", column);
}
if (level == lldb::eDescriptionLevelFull) {
if (is_start_of_statement)
*s << ", is_start_of_statement = TRUE";
if (is_start_of_basic_block)
*s << ", is_start_of_basic_block = TRUE";
if (is_prologue_end)
*s << ", is_prologue_end = TRUE";
if (is_epilogue_begin)
*s << ", is_epilogue_begin = TRUE";
if (is_terminal_entry)
*s << ", is_terminal_entry = TRUE";
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
} else {
if (is_terminal_entry)
s->EOL();
}
} else {
return Dump(s, target, true, Address::DumpStyleLoadAddress,
Address::DumpStyleModuleWithFileAddress, true);
}
return true;
}
bool lldb_private::operator<(const LineEntry &a, const LineEntry &b) {
return LineEntry::Compare(a, b) < 0;
}
int LineEntry::Compare(const LineEntry &a, const LineEntry &b) {
int result = Address::CompareFileAddress(a.range.GetBaseAddress(),
b.range.GetBaseAddress());
if (result != 0)
return result;
const lldb::addr_t a_byte_size = a.range.GetByteSize();
const lldb::addr_t b_byte_size = b.range.GetByteSize();
if (a_byte_size < b_byte_size)
return -1;
if (a_byte_size > b_byte_size)
return +1;
// Check for an end sequence entry mismatch after we have determined that the
// address values are equal. If one of the items is an end sequence, we don't
// care about the line, file, or column info.
if (a.is_terminal_entry > b.is_terminal_entry)
return -1;
if (a.is_terminal_entry < b.is_terminal_entry)
return +1;
if (a.line < b.line)
return -1;
if (a.line > b.line)
return +1;
if (a.column < b.column)
return -1;
if (a.column > b.column)
return +1;
return FileSpec::Compare(a.file, b.file, true);
}
Include inlined functions when figuring out a contiguous address range Checking this in for Antonio Afonso: This diff changes the function LineEntry::GetSameLineContiguousAddressRange so that it also includes function calls that were inlined at the same line of code. My motivation is to decrease the step over time of lines that heavly rely on inlined functions. I have multiple examples in the code base I work that makes a step over stop 20 or mote times internally. This can easly had up to step overs that take >500ms which I was able to lower to 25ms with this new strategy. The reason the current code is not extending the address range beyond an inlined function is because when we resolve the symbol at the next address of the line entry we will get the entry line corresponding to where the original code for the inline function lives, making us barely extend the range. This then will end up on a step over having to stop multiple times everytime there's an inlined function. To check if the range is an inlined function at that line I also get the block associated with the next address and check if there is a parent block with a call site at the line we're trying to extend. To check this I created a new function in Block called GetContainingInlinedBlockWithCallSite that does exactly that. I also added a new function to Declaration for convinence of checking file/line named CompareFileAndLine. To avoid potential issues when extending an address range I added an Extend function that extends the range by the AddressRange given as an argument. This function returns true to indicate sucess when the rage was agumented, false otherwise (e.g.: the ranges are not connected). The reason I do is to make sure that we're not just blindly extending complete_line_range by whatever GetByteSize() we got. If for some reason the ranges are not connected or overlap, or even 0, this could be an issue. I also added a unit tests for this change and include the instructions on the test itself on how to generate the yaml file I use for testing. Differential Revision: https://reviews.llvm.org/D61292 llvm-svn: 360071
2019-05-07 04:01:21 +08:00
AddressRange LineEntry::GetSameLineContiguousAddressRange(
bool include_inlined_functions) const {
// Add each LineEntry's range to complete_line_range until we find a
// different file / line number.
AddressRange complete_line_range = range;
Include inlined functions when figuring out a contiguous address range Checking this in for Antonio Afonso: This diff changes the function LineEntry::GetSameLineContiguousAddressRange so that it also includes function calls that were inlined at the same line of code. My motivation is to decrease the step over time of lines that heavly rely on inlined functions. I have multiple examples in the code base I work that makes a step over stop 20 or mote times internally. This can easly had up to step overs that take >500ms which I was able to lower to 25ms with this new strategy. The reason the current code is not extending the address range beyond an inlined function is because when we resolve the symbol at the next address of the line entry we will get the entry line corresponding to where the original code for the inline function lives, making us barely extend the range. This then will end up on a step over having to stop multiple times everytime there's an inlined function. To check if the range is an inlined function at that line I also get the block associated with the next address and check if there is a parent block with a call site at the line we're trying to extend. To check this I created a new function in Block called GetContainingInlinedBlockWithCallSite that does exactly that. I also added a new function to Declaration for convinence of checking file/line named CompareFileAndLine. To avoid potential issues when extending an address range I added an Extend function that extends the range by the AddressRange given as an argument. This function returns true to indicate sucess when the rage was agumented, false otherwise (e.g.: the ranges are not connected). The reason I do is to make sure that we're not just blindly extending complete_line_range by whatever GetByteSize() we got. If for some reason the ranges are not connected or overlap, or even 0, this could be an issue. I also added a unit tests for this change and include the instructions on the test itself on how to generate the yaml file I use for testing. Differential Revision: https://reviews.llvm.org/D61292 llvm-svn: 360071
2019-05-07 04:01:21 +08:00
auto symbol_context_scope = lldb::eSymbolContextLineEntry;
Declaration start_call_site(original_file, line);
if (include_inlined_functions)
symbol_context_scope |= lldb::eSymbolContextBlock;
while (true) {
SymbolContext next_line_sc;
Address range_end(complete_line_range.GetBaseAddress());
range_end.Slide(complete_line_range.GetByteSize());
Include inlined functions when figuring out a contiguous address range Checking this in for Antonio Afonso: This diff changes the function LineEntry::GetSameLineContiguousAddressRange so that it also includes function calls that were inlined at the same line of code. My motivation is to decrease the step over time of lines that heavly rely on inlined functions. I have multiple examples in the code base I work that makes a step over stop 20 or mote times internally. This can easly had up to step overs that take >500ms which I was able to lower to 25ms with this new strategy. The reason the current code is not extending the address range beyond an inlined function is because when we resolve the symbol at the next address of the line entry we will get the entry line corresponding to where the original code for the inline function lives, making us barely extend the range. This then will end up on a step over having to stop multiple times everytime there's an inlined function. To check if the range is an inlined function at that line I also get the block associated with the next address and check if there is a parent block with a call site at the line we're trying to extend. To check this I created a new function in Block called GetContainingInlinedBlockWithCallSite that does exactly that. I also added a new function to Declaration for convinence of checking file/line named CompareFileAndLine. To avoid potential issues when extending an address range I added an Extend function that extends the range by the AddressRange given as an argument. This function returns true to indicate sucess when the rage was agumented, false otherwise (e.g.: the ranges are not connected). The reason I do is to make sure that we're not just blindly extending complete_line_range by whatever GetByteSize() we got. If for some reason the ranges are not connected or overlap, or even 0, this could be an issue. I also added a unit tests for this change and include the instructions on the test itself on how to generate the yaml file I use for testing. Differential Revision: https://reviews.llvm.org/D61292 llvm-svn: 360071
2019-05-07 04:01:21 +08:00
range_end.CalculateSymbolContext(&next_line_sc, symbol_context_scope);
Include inlined functions when figuring out a contiguous address range Checking this in for Antonio Afonso: This diff changes the function LineEntry::GetSameLineContiguousAddressRange so that it also includes function calls that were inlined at the same line of code. My motivation is to decrease the step over time of lines that heavly rely on inlined functions. I have multiple examples in the code base I work that makes a step over stop 20 or mote times internally. This can easly had up to step overs that take >500ms which I was able to lower to 25ms with this new strategy. The reason the current code is not extending the address range beyond an inlined function is because when we resolve the symbol at the next address of the line entry we will get the entry line corresponding to where the original code for the inline function lives, making us barely extend the range. This then will end up on a step over having to stop multiple times everytime there's an inlined function. To check if the range is an inlined function at that line I also get the block associated with the next address and check if there is a parent block with a call site at the line we're trying to extend. To check this I created a new function in Block called GetContainingInlinedBlockWithCallSite that does exactly that. I also added a new function to Declaration for convinence of checking file/line named CompareFileAndLine. To avoid potential issues when extending an address range I added an Extend function that extends the range by the AddressRange given as an argument. This function returns true to indicate sucess when the rage was agumented, false otherwise (e.g.: the ranges are not connected). The reason I do is to make sure that we're not just blindly extending complete_line_range by whatever GetByteSize() we got. If for some reason the ranges are not connected or overlap, or even 0, this could be an issue. I also added a unit tests for this change and include the instructions on the test itself on how to generate the yaml file I use for testing. Differential Revision: https://reviews.llvm.org/D61292 llvm-svn: 360071
2019-05-07 04:01:21 +08:00
if (!next_line_sc.line_entry.IsValid() ||
next_line_sc.line_entry.range.GetByteSize() == 0)
break;
if (original_file == next_line_sc.line_entry.original_file &&
(next_line_sc.line_entry.line == 0 ||
line == next_line_sc.line_entry.line)) {
// Include any line 0 entries - they indicate that this is compiler-
// generated code that does not correspond to user source code.
Include inlined functions when figuring out a contiguous address range Checking this in for Antonio Afonso: This diff changes the function LineEntry::GetSameLineContiguousAddressRange so that it also includes function calls that were inlined at the same line of code. My motivation is to decrease the step over time of lines that heavly rely on inlined functions. I have multiple examples in the code base I work that makes a step over stop 20 or mote times internally. This can easly had up to step overs that take >500ms which I was able to lower to 25ms with this new strategy. The reason the current code is not extending the address range beyond an inlined function is because when we resolve the symbol at the next address of the line entry we will get the entry line corresponding to where the original code for the inline function lives, making us barely extend the range. This then will end up on a step over having to stop multiple times everytime there's an inlined function. To check if the range is an inlined function at that line I also get the block associated with the next address and check if there is a parent block with a call site at the line we're trying to extend. To check this I created a new function in Block called GetContainingInlinedBlockWithCallSite that does exactly that. I also added a new function to Declaration for convinence of checking file/line named CompareFileAndLine. To avoid potential issues when extending an address range I added an Extend function that extends the range by the AddressRange given as an argument. This function returns true to indicate sucess when the rage was agumented, false otherwise (e.g.: the ranges are not connected). The reason I do is to make sure that we're not just blindly extending complete_line_range by whatever GetByteSize() we got. If for some reason the ranges are not connected or overlap, or even 0, this could be an issue. I also added a unit tests for this change and include the instructions on the test itself on how to generate the yaml file I use for testing. Differential Revision: https://reviews.llvm.org/D61292 llvm-svn: 360071
2019-05-07 04:01:21 +08:00
// next_line_sc is the same file & line as this LineEntry, so extend
// our AddressRange by its size and continue to see if there are more
// LineEntries that we can combine. However, if there was nothing to
// extend we're done.
if (!complete_line_range.Extend(next_line_sc.line_entry.range))
break;
continue;
}
if (include_inlined_functions && next_line_sc.block &&
next_line_sc.block->GetContainingInlinedBlock() != nullptr) {
// The next_line_sc might be in a different file if it's an inlined
// function. If this is the case then we still want to expand our line
// range to include them if the inlined function is at the same call site
// as this line entry. The current block could represent a nested inline
// function call so we need to need to check up the block tree to see if
// we find one.
auto inlined_parent_block =
next_line_sc.block->GetContainingInlinedBlockWithCallSite(
start_call_site);
if (!inlined_parent_block)
// We didn't find any parent inlined block with a call site at this line
// entry so this inlined function is probably at another line.
break;
// Extend our AddressRange by the size of the inlined block, but if there
// was nothing to add then we're done.
if (!complete_line_range.Extend(next_line_sc.line_entry.range))
break;
continue;
}
Include inlined functions when figuring out a contiguous address range Checking this in for Antonio Afonso: This diff changes the function LineEntry::GetSameLineContiguousAddressRange so that it also includes function calls that were inlined at the same line of code. My motivation is to decrease the step over time of lines that heavly rely on inlined functions. I have multiple examples in the code base I work that makes a step over stop 20 or mote times internally. This can easly had up to step overs that take >500ms which I was able to lower to 25ms with this new strategy. The reason the current code is not extending the address range beyond an inlined function is because when we resolve the symbol at the next address of the line entry we will get the entry line corresponding to where the original code for the inline function lives, making us barely extend the range. This then will end up on a step over having to stop multiple times everytime there's an inlined function. To check if the range is an inlined function at that line I also get the block associated with the next address and check if there is a parent block with a call site at the line we're trying to extend. To check this I created a new function in Block called GetContainingInlinedBlockWithCallSite that does exactly that. I also added a new function to Declaration for convinence of checking file/line named CompareFileAndLine. To avoid potential issues when extending an address range I added an Extend function that extends the range by the AddressRange given as an argument. This function returns true to indicate sucess when the rage was agumented, false otherwise (e.g.: the ranges are not connected). The reason I do is to make sure that we're not just blindly extending complete_line_range by whatever GetByteSize() we got. If for some reason the ranges are not connected or overlap, or even 0, this could be an issue. I also added a unit tests for this change and include the instructions on the test itself on how to generate the yaml file I use for testing. Differential Revision: https://reviews.llvm.org/D61292 llvm-svn: 360071
2019-05-07 04:01:21 +08:00
break;
}
return complete_line_range;
}
void LineEntry::ApplyFileMappings(lldb::TargetSP target_sp) {
if (target_sp) {
// Apply any file remappings to our file.
if (auto new_file_spec =
target_sp->GetSourcePathMap().FindFile(original_file))
file = *new_file_spec;
}
}