Files
llvm/lldb/source/Core/AddressRange.cpp

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

223 lines
6.7 KiB
C++
Raw Normal View History

//===-- AddressRange.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/Core/AddressRange.h"
#include "lldb/Core/Module.h"
[trace] Dedup different source lines when dumping instructions + refactor When dumping the traced instructions in a for loop, like this one 4: for (int a = 0; a < n; a++) 5: do something; there might be multiple LineEntry objects for line 4, but with different address ranges. This was causing the dump command to dump something like this: ``` a.out`main + 11 at main.cpp:4 [1] 0x0000000000400518 movl $0x0, -0x8(%rbp) [2] 0x000000000040051f jmp 0x400529 ; <+28> at main.cpp:4 a.out`main + 28 at main.cpp:4 [3] 0x0000000000400529 cmpl $0x3, -0x8(%rbp) [4] 0x000000000040052d jle 0x400521 ; <+20> at main.cpp:5 ``` which is confusing, as main.cpp:4 appears twice consecutively. This diff fixes that issue by making the line entry comparison strictly about the line, column and file name. Before it was also comparing the address ranges, which we don't need because our output is strictly about what the user sees in the source. Besides, I've noticed that the logic that traverses instructions and calculates symbols and disassemblies had too much coupling, and made my changes harder to implement, so I decided to decouple it. Now there are two methods for iterating over the instruction of a trace. The existing one does it on raw load addresses, but the one provides a SymbolContext and an InstructionSP, and does the calculations efficiently (not as efficient as possible for now though), so the caller doesn't need to care about these details. I think I'll be using that iterator to reconstruct the call stacks. I was able to fix a test with this change. Differential Revision: https://reviews.llvm.org/D100740
2021-05-03 07:55:35 -07:00
#include "lldb/Core/Section.h"
#include "lldb/Target/Target.h"
#include "lldb/Utility/ConstString.h"
#include "lldb/Utility/FileSpec.h"
#include "lldb/Utility/Stream.h"
#include "lldb/lldb-defines.h"
#include "llvm/Support/Compiler.h"
#include <memory>
#include <cinttypes>
namespace lldb_private {
class SectionList;
}
using namespace lldb;
using namespace lldb_private;
AddressRange::AddressRange() : m_base_addr() {}
AddressRange::AddressRange(addr_t file_addr, addr_t byte_size,
const SectionList *section_list)
: m_base_addr(file_addr, section_list), m_byte_size(byte_size) {}
AddressRange::AddressRange(const lldb::SectionSP &section, addr_t offset,
addr_t byte_size)
: m_base_addr(section, offset), m_byte_size(byte_size) {}
AddressRange::AddressRange(const Address &so_addr, addr_t byte_size)
: m_base_addr(so_addr), m_byte_size(byte_size) {}
AddressRange::~AddressRange() = default;
[trace] Dedup different source lines when dumping instructions + refactor When dumping the traced instructions in a for loop, like this one 4: for (int a = 0; a < n; a++) 5: do something; there might be multiple LineEntry objects for line 4, but with different address ranges. This was causing the dump command to dump something like this: ``` a.out`main + 11 at main.cpp:4 [1] 0x0000000000400518 movl $0x0, -0x8(%rbp) [2] 0x000000000040051f jmp 0x400529 ; <+28> at main.cpp:4 a.out`main + 28 at main.cpp:4 [3] 0x0000000000400529 cmpl $0x3, -0x8(%rbp) [4] 0x000000000040052d jle 0x400521 ; <+20> at main.cpp:5 ``` which is confusing, as main.cpp:4 appears twice consecutively. This diff fixes that issue by making the line entry comparison strictly about the line, column and file name. Before it was also comparing the address ranges, which we don't need because our output is strictly about what the user sees in the source. Besides, I've noticed that the logic that traverses instructions and calculates symbols and disassemblies had too much coupling, and made my changes harder to implement, so I decided to decouple it. Now there are two methods for iterating over the instruction of a trace. The existing one does it on raw load addresses, but the one provides a SymbolContext and an InstructionSP, and does the calculations efficiently (not as efficient as possible for now though), so the caller doesn't need to care about these details. I think I'll be using that iterator to reconstruct the call stacks. I was able to fix a test with this change. Differential Revision: https://reviews.llvm.org/D100740
2021-05-03 07:55:35 -07:00
bool AddressRange::Contains(const Address &addr) const {
SectionSP range_sect_sp = GetBaseAddress().GetSection();
SectionSP addr_sect_sp = addr.GetSection();
if (range_sect_sp) {
if (!addr_sect_sp ||
range_sect_sp->GetModule() != addr_sect_sp->GetModule())
return false; // Modules do not match.
} else if (addr_sect_sp) {
return false; // Range has no module but "addr" does because addr has a
// section
}
// Either the modules match, or both have no module, so it is ok to compare
// the file addresses in this case only.
return ContainsFileAddress(addr);
}
//
// bool
// AddressRange::Contains (const Address *addr) const
//{
// if (addr)
// return Contains (*addr);
// return false;
//}
bool AddressRange::ContainsFileAddress(const Address &addr) const {
if (addr.GetSection() == m_base_addr.GetSection())
return (addr.GetOffset() - m_base_addr.GetOffset()) < GetByteSize();
addr_t file_base_addr = GetBaseAddress().GetFileAddress();
if (file_base_addr == LLDB_INVALID_ADDRESS)
return false;
addr_t file_addr = addr.GetFileAddress();
if (file_addr == LLDB_INVALID_ADDRESS)
return false;
if (file_base_addr <= file_addr)
return (file_addr - file_base_addr) < GetByteSize();
return false;
}
bool AddressRange::ContainsFileAddress(addr_t file_addr) const {
if (file_addr == LLDB_INVALID_ADDRESS)
return false;
addr_t file_base_addr = GetBaseAddress().GetFileAddress();
if (file_base_addr == LLDB_INVALID_ADDRESS)
return false;
if (file_base_addr <= file_addr)
return (file_addr - file_base_addr) < GetByteSize();
return false;
}
bool AddressRange::ContainsLoadAddress(const Address &addr,
Target *target) const {
if (addr.GetSection() == m_base_addr.GetSection())
return (addr.GetOffset() - m_base_addr.GetOffset()) < GetByteSize();
addr_t load_base_addr = GetBaseAddress().GetLoadAddress(target);
if (load_base_addr == LLDB_INVALID_ADDRESS)
return false;
addr_t load_addr = addr.GetLoadAddress(target);
if (load_addr == LLDB_INVALID_ADDRESS)
return false;
if (load_base_addr <= load_addr)
return (load_addr - load_base_addr) < GetByteSize();
return false;
}
bool AddressRange::ContainsLoadAddress(addr_t load_addr, Target *target) const {
if (load_addr == LLDB_INVALID_ADDRESS)
return false;
addr_t load_base_addr = GetBaseAddress().GetLoadAddress(target);
if (load_base_addr == LLDB_INVALID_ADDRESS)
return false;
if (load_base_addr <= load_addr)
return (load_addr - load_base_addr) < GetByteSize();
return false;
}
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-06 20:01:21 +00:00
bool AddressRange::Extend(const AddressRange &rhs_range) {
addr_t lhs_end_addr = GetBaseAddress().GetFileAddress() + GetByteSize();
addr_t rhs_base_addr = rhs_range.GetBaseAddress().GetFileAddress();
if (!ContainsFileAddress(rhs_range.GetBaseAddress()) &&
lhs_end_addr != rhs_base_addr)
// The ranges don't intersect at all on the right side of this range.
return false;
addr_t rhs_end_addr = rhs_base_addr + rhs_range.GetByteSize();
if (lhs_end_addr >= rhs_end_addr)
// The rhs range totally overlaps this one, nothing to add.
return false;
m_byte_size += rhs_end_addr - lhs_end_addr;
return true;
}
void AddressRange::Clear() {
m_base_addr.Clear();
m_byte_size = 0;
}
bool AddressRange::Dump(Stream *s, Target *target, Address::DumpStyle style,
Address::DumpStyle fallback_style) const {
addr_t vmaddr = LLDB_INVALID_ADDRESS;
int addr_size = sizeof(addr_t);
if (target)
addr_size = target->GetArchitecture().GetAddressByteSize();
bool show_module = false;
switch (style) {
default:
break;
case Address::DumpStyleSectionNameOffset:
case Address::DumpStyleSectionPointerOffset:
s->PutChar('[');
m_base_addr.Dump(s, target, style, fallback_style);
s->PutChar('-');
DumpAddress(s->AsRawOstream(), m_base_addr.GetOffset() + GetByteSize(),
addr_size);
s->PutChar(')');
return true;
break;
case Address::DumpStyleModuleWithFileAddress:
show_module = true;
LLVM_FALLTHROUGH;
case Address::DumpStyleFileAddress:
vmaddr = m_base_addr.GetFileAddress();
break;
case Address::DumpStyleLoadAddress:
vmaddr = m_base_addr.GetLoadAddress(target);
break;
}
if (vmaddr != LLDB_INVALID_ADDRESS) {
if (show_module) {
ModuleSP module_sp(GetBaseAddress().GetModule());
if (module_sp)
s->Printf("%s", module_sp->GetFileSpec().GetFilename().AsCString(
"<Unknown>"));
}
DumpAddressRange(s->AsRawOstream(), vmaddr, vmaddr + GetByteSize(),
addr_size);
return true;
} else if (fallback_style != Address::DumpStyleInvalid) {
return Dump(s, target, fallback_style, Address::DumpStyleInvalid);
}
return false;
}
void AddressRange::DumpDebug(Stream *s) const {
s->Printf("%p: AddressRange section = %p, offset = 0x%16.16" PRIx64
", byte_size = 0x%16.16" PRIx64 "\n",
static_cast<const void *>(this),
static_cast<void *>(m_base_addr.GetSection().get()),
m_base_addr.GetOffset(), GetByteSize());
}
//
// bool
// lldb::operator== (const AddressRange& lhs, const AddressRange& rhs)
//{
// if (lhs.GetBaseAddress() == rhs.GetBaseAddress())
// return lhs.GetByteSize() == rhs.GetByteSize();
// return false;
//}