2015-10-14 15:35:14 -07:00
|
|
|
//===--- BinaryContext.cpp - Interface for machine-level context ---------===//
|
|
|
|
|
//
|
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
|
//
|
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
|
//
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
//
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
|
|
#include "BinaryContext.h"
|
Update subroutine address ranges in binary.
Summary:
[WIP] Update DWARF info for function address ranges.
This diff currently does not work for unknown reasons,
but I'm describing here what's the current state.
According to both llvm-dwarf and readelf our output seems correct,
but GDB does not interpret it as expected. All details go below in
hope I missed something.
I couldn't actually track the whole change that introduced support for
what we need in gdb yet, but I think I can get to it
(2007-12-04: Support
lexical bocks and function bodies that occupy non-contiguous address ranges). I have reasons to believe gdb at least at some
nges).
The set of introduced changes was basically this:
- After disassembly, iterate over the DIEs in .debug_info and find the
ones that correspond to each BinaryFunction.
- Refactor DebugArangesWriter to also write addresses of functions to
.debug_ranges and track the offsets of function address ranges there
- Add some infrastructure to facilitate patching the binary in
simple ways (BinaryPatcher.h)
- In RewriteInstance, after writing .debug_ranges already with
function address ranges, for each function do:
-- Find the abbreviation corresponding to the function
-- Patch .debug_abbrev to replace DW_AT_low_pc with DW_AT_ranges and
DW_AT_high_pc with DW_AT_producer (I'll explain this hack below).
Also patch the corresponding forms to DW_FORM_sec_offset and
DW_FORM_string (null-terminated in-place string).
-- Patch debug_info with the .debug_ranges offset in place of
the first 4 bytes of DW_AT_low_pc (DW_AT_ranges only occupies 4
bytes whereas low_pc occupies 8), and write an arbitrary string
in-place in the other 12 bytes that were the 4 MSB of low_pc
and the 8 bytes of high_pc before the patch. This depends on
low_pc and high_pc being put consecutively by the compiler, but
it serves to validate the idea. I tried another way of doing it
that does not rely on this but it didn't work either and I believe
the reason for either not working is the same (and still unknown,
but unrelated to them. I might be wrong though, and if I find yet
another way of doing it I may try it). The other way was to
use a form of DW_FORM_data8 for the section offset. This is
disallowed by the specification, but I doubt gdb validates this,
as it's just easier to store it as 64-bit anyway as this is even
necessary to support 64-bit DWARF (which is not what gcc generates
by default apparently).
I still need to make changes to the diff to make it production-ready,
but first I want to figure out why it doesn't work as expected.
By looking at the output of llvm-dwarfdump or readelf, all of
.debug_ranges, .debug_abbrev and .debug_info seem to have been
correctly updated. However, gdb seems to have serious problems with
what we write.
(In fact, readelf --debug-dump=Ranges shows some funny warning messages
of the form ("Warning: There is a hole [0x100 - 0x120] in .debug_ranges"),
but I played around with this and it seems it's just because no
compile unit was using these ranges. Changing .debug_info apparently
changes these warnings, so they seem to be unrelated to the section
itself. Also looking at the hex dump of the section doesn't help,
as everything seems fine. llvm-dwarfdump doesn't say anything.
So I think .debug_ranges is fine.)
The result is that gdb not only doesn't show the function name as we
wanted, but it also stops showing line number information.
Apparently it's not reading/interpreting the address ranges at all,
and so the functions now have no associated address ranges, only the
symbol value which allows one to put a breakpoint in the function,
but not to show source code.
As this left me without more ideas of what to try to feed gdb with,
I believe the most promising next trial is to try to debug gdb itself,
unless someone spots anything I missed.
I found where the interesting part of the code lies for this
case (gdb/dwarf2read.c and some other related files, but mainly that one).
It seems in some parts gdb uses DW_AT_ranges for only getting
its lowest and highest addresses and setting that as low_pc and
high_pc (see dwarf2_get_pc_bounds in gdb's code and where it's called).
I really hope this is not actually the case for
function address ranges. I'll investigate this further. Otherwise
I don't think any changes we make will make it work as initially
intended, as we'll simply need gdb to support it and in that case it
doesn't.
(cherry picked from FBD3073641)
2016-03-16 18:08:29 -07:00
|
|
|
#include "BinaryFunction.h"
|
2015-10-14 15:35:14 -07:00
|
|
|
#include "llvm/ADT/Twine.h"
|
2016-03-28 17:45:22 -07:00
|
|
|
#include "llvm/DebugInfo/DWARF/DWARFUnit.h"
|
2015-10-14 15:35:14 -07:00
|
|
|
#include "llvm/MC/MCContext.h"
|
|
|
|
|
#include "llvm/MC/MCSymbol.h"
|
2016-07-23 08:01:53 -07:00
|
|
|
#include "llvm/Support/CommandLine.h"
|
2015-10-14 15:35:14 -07:00
|
|
|
|
2016-12-21 17:13:56 -08:00
|
|
|
|
|
|
|
|
using namespace llvm;
|
|
|
|
|
using namespace bolt;
|
2015-10-14 15:35:14 -07:00
|
|
|
|
2016-07-23 08:01:53 -07:00
|
|
|
namespace opts {
|
|
|
|
|
|
2016-12-21 17:13:56 -08:00
|
|
|
extern cl::opt<bool> Relocs;
|
|
|
|
|
|
2016-07-23 08:01:53 -07:00
|
|
|
static cl::opt<bool>
|
|
|
|
|
PrintDebugInfo("print-debug-info",
|
|
|
|
|
cl::desc("print debug info when printing functions"),
|
|
|
|
|
cl::Hidden);
|
|
|
|
|
|
|
|
|
|
} // namespace opts
|
|
|
|
|
|
2016-03-28 17:45:22 -07:00
|
|
|
BinaryContext::~BinaryContext() { }
|
|
|
|
|
|
2015-10-14 15:35:14 -07:00
|
|
|
MCSymbol *BinaryContext::getOrCreateGlobalSymbol(uint64_t Address,
|
|
|
|
|
Twine Prefix) {
|
|
|
|
|
MCSymbol *Symbol{nullptr};
|
|
|
|
|
std::string Name;
|
|
|
|
|
auto NI = GlobalAddresses.find(Address);
|
|
|
|
|
if (NI != GlobalAddresses.end()) {
|
|
|
|
|
// Even though there could be multiple names registered at the address,
|
|
|
|
|
// we only use the first one.
|
|
|
|
|
Name = NI->second;
|
|
|
|
|
} else {
|
|
|
|
|
Name = (Prefix + "0x" + Twine::utohexstr(Address)).str();
|
|
|
|
|
assert(GlobalSymbols.find(Name) == GlobalSymbols.end() &&
|
|
|
|
|
"created name is not unique");
|
|
|
|
|
GlobalAddresses.emplace(std::make_pair(Address, Name));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
Symbol = Ctx->lookupSymbol(Name);
|
|
|
|
|
if (Symbol)
|
|
|
|
|
return Symbol;
|
|
|
|
|
|
|
|
|
|
Symbol = Ctx->getOrCreateSymbol(Name);
|
|
|
|
|
GlobalSymbols[Name] = Address;
|
|
|
|
|
|
|
|
|
|
return Symbol;
|
|
|
|
|
}
|
|
|
|
|
|
2016-09-29 11:19:06 -07:00
|
|
|
MCSymbol *BinaryContext::getGlobalSymbolAtAddress(uint64_t Address) const {
|
|
|
|
|
auto NI = GlobalAddresses.find(Address);
|
|
|
|
|
if (NI == GlobalAddresses.end())
|
|
|
|
|
return nullptr;
|
|
|
|
|
|
|
|
|
|
auto *Symbol = Ctx->lookupSymbol(NI->second);
|
|
|
|
|
assert(Symbol && "symbol cannot be NULL at this point");
|
|
|
|
|
|
|
|
|
|
return Symbol;
|
|
|
|
|
}
|
|
|
|
|
|
2016-12-21 17:13:56 -08:00
|
|
|
void BinaryContext::foldFunction(BinaryFunction &ChildBF,
|
|
|
|
|
BinaryFunction &ParentBF,
|
|
|
|
|
std::map<uint64_t, BinaryFunction> &BFs) {
|
|
|
|
|
|
|
|
|
|
// Copy name list.
|
|
|
|
|
ParentBF.addNewNames(ChildBF.getNames());
|
|
|
|
|
|
|
|
|
|
// Update internal bookkeeping info.
|
|
|
|
|
for (auto &Name : ChildBF.getNames()) {
|
|
|
|
|
// Calls to functions are handled via symbols, and we keep the lookup table
|
|
|
|
|
// that we need to update.
|
|
|
|
|
auto *Symbol = Ctx->lookupSymbol(Name);
|
|
|
|
|
assert(Symbol && "symbol cannot be NULL at this point");
|
|
|
|
|
SymbolToFunctionMap[Symbol] = &ParentBF;
|
|
|
|
|
|
|
|
|
|
// NB: there's no need to update GlobalAddresses and GlobalSymbols.
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Merge execution counts of ChildBF into those of ParentBF.
|
|
|
|
|
ChildBF.mergeProfileDataInto(ParentBF);
|
|
|
|
|
|
|
|
|
|
if (opts::Relocs) {
|
|
|
|
|
// Remove ChildBF from the global set of functions in relocs mode.
|
|
|
|
|
auto FI = BFs.find(ChildBF.getAddress());
|
|
|
|
|
assert(FI != BFs.end() && "function not found");
|
|
|
|
|
assert(&ChildBF == &FI->second && "function mismatch");
|
|
|
|
|
FI = BFs.erase(FI);
|
|
|
|
|
} else {
|
|
|
|
|
// In non-relocation mode we keep the function, but rename it.
|
|
|
|
|
std::string NewName = "__ICF_" + ChildBF.Names.back();
|
|
|
|
|
ChildBF.Names.clear();
|
|
|
|
|
ChildBF.Names.push_back(NewName);
|
|
|
|
|
ChildBF.OutputSymbol = Ctx->getOrCreateSymbol(NewName);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-07-23 08:01:53 -07:00
|
|
|
void BinaryContext::printGlobalSymbols(raw_ostream& OS) const {
|
|
|
|
|
for (auto &entry : GlobalSymbols) {
|
|
|
|
|
OS << "(" << entry.first << " -> " << entry.second << ")\n";
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-03-28 17:45:22 -07:00
|
|
|
namespace {
|
|
|
|
|
|
2016-08-22 14:24:09 -07:00
|
|
|
/// Returns a binary function that contains a given address in the input
|
2016-03-28 17:45:22 -07:00
|
|
|
/// binary, or nullptr if none does.
|
|
|
|
|
BinaryFunction *getBinaryFunctionContainingAddress(
|
|
|
|
|
uint64_t Address,
|
|
|
|
|
std::map<uint64_t, BinaryFunction> &BinaryFunctions) {
|
|
|
|
|
auto It = BinaryFunctions.upper_bound(Address);
|
|
|
|
|
if (It != BinaryFunctions.begin()) {
|
|
|
|
|
--It;
|
|
|
|
|
if (It->first + It->second.getSize() > Address) {
|
|
|
|
|
return &It->second;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return nullptr;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Traverses the DIE tree in a recursive depth-first search and finds lexical
|
2016-04-12 11:41:03 -07:00
|
|
|
// blocks and instances of inlined subroutines, saving them in
|
|
|
|
|
// AddressRangesObjects.
|
|
|
|
|
void findAddressRangesObjects(
|
|
|
|
|
const DWARFCompileUnit *Unit,
|
|
|
|
|
const DWARFDebugInfoEntryMinimal *DIE,
|
|
|
|
|
std::map<uint64_t, BinaryFunction> &Functions,
|
|
|
|
|
std::vector<llvm::bolt::AddressRangesDWARFObject> &AddressRangesObjects) {
|
|
|
|
|
auto Tag = DIE->getTag();
|
|
|
|
|
if (Tag == dwarf::DW_TAG_lexical_block ||
|
|
|
|
|
Tag == dwarf::DW_TAG_inlined_subroutine ||
|
|
|
|
|
Tag == dwarf::DW_TAG_try_block ||
|
|
|
|
|
Tag == dwarf::DW_TAG_catch_block) {
|
2016-05-23 19:36:38 -07:00
|
|
|
auto const &Ranges = DIE->getAddressRanges(Unit);
|
|
|
|
|
if (!Ranges.empty()) {
|
|
|
|
|
// We have to process all ranges, even for functions that we are not
|
|
|
|
|
// updating. The primary reason is that abbrev entries are shared
|
|
|
|
|
// and if we convert one DIE, it may affect the rest. Thus
|
|
|
|
|
// the conservative approach that does not involve expanding
|
|
|
|
|
// .debug_abbrev, is to switch all DIEs to use .debug_ranges, even if
|
|
|
|
|
// they use a single [a,b) range. The secondary reason is that it allows
|
|
|
|
|
// us to get rid of the original portion of .debug_ranges to save
|
|
|
|
|
// space in the binary.
|
|
|
|
|
auto Function = getBinaryFunctionContainingAddress(Ranges.front().first,
|
|
|
|
|
Functions);
|
|
|
|
|
AddressRangesObjects.emplace_back(Unit, DIE);
|
|
|
|
|
auto &Object = AddressRangesObjects.back();
|
|
|
|
|
for (const auto &Range : Ranges) {
|
|
|
|
|
if (Function && Function->isSimple()) {
|
2016-04-12 11:41:03 -07:00
|
|
|
Object.addAddressRange(*Function, Range.first, Range.second);
|
2016-05-23 19:36:38 -07:00
|
|
|
} else {
|
|
|
|
|
Object.addAbsoluteRange(Range.first, Range.second);
|
2016-03-28 17:45:22 -07:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Recursively visit each child.
|
|
|
|
|
for (auto Child = DIE->getFirstChild(); Child; Child = Child->getSibling()) {
|
2016-04-12 11:41:03 -07:00
|
|
|
findAddressRangesObjects(Unit, Child, Functions, AddressRangesObjects);
|
2016-03-28 17:45:22 -07:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-05-23 19:36:38 -07:00
|
|
|
/// Recursively finds DWARF DW_TAG_subprogram DIEs and match them with
|
|
|
|
|
/// BinaryFunctions. Record DIEs for unknown subprograms (mostly functions that
|
|
|
|
|
/// are never called and removed from the binary) in Unknown.
|
2016-05-27 20:19:19 -07:00
|
|
|
void findSubprograms(DWARFCompileUnit *Unit,
|
2016-04-08 16:24:38 -07:00
|
|
|
const DWARFDebugInfoEntryMinimal *DIE,
|
|
|
|
|
std::map<uint64_t, BinaryFunction> &BinaryFunctions,
|
|
|
|
|
BinaryContext::DIECompileUnitVector &Unknown) {
|
|
|
|
|
if (DIE->isSubprogramDIE()) {
|
2016-05-23 19:36:38 -07:00
|
|
|
// TODO: handle DW_AT_ranges.
|
2016-04-08 16:24:38 -07:00
|
|
|
uint64_t LowPC, HighPC;
|
|
|
|
|
if (DIE->getLowAndHighPC(Unit, LowPC, HighPC)) {
|
|
|
|
|
auto It = BinaryFunctions.find(LowPC);
|
|
|
|
|
if (It != BinaryFunctions.end()) {
|
2016-05-27 20:19:19 -07:00
|
|
|
It->second.addSubprogramDIE(Unit, DIE);
|
2016-04-08 16:24:38 -07:00
|
|
|
} else {
|
|
|
|
|
Unknown.emplace_back(DIE, Unit);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
for (auto ChildDIE = DIE->getFirstChild();
|
|
|
|
|
ChildDIE != nullptr && !ChildDIE->isNULL();
|
|
|
|
|
ChildDIE = ChildDIE->getSibling()) {
|
|
|
|
|
findSubprograms(Unit, ChildDIE, BinaryFunctions, Unknown);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-03-28 17:45:22 -07:00
|
|
|
} // namespace
|
|
|
|
|
|
2016-09-02 11:58:53 -07:00
|
|
|
unsigned BinaryContext::addDebugFilenameToUnit(const uint32_t DestCUID,
|
|
|
|
|
const uint32_t SrcCUID,
|
|
|
|
|
unsigned FileIndex) {
|
|
|
|
|
auto SrcUnit = DwCtx->getCompileUnitForOffset(SrcCUID);
|
|
|
|
|
auto LineTable = DwCtx->getLineTableForUnit(SrcUnit);
|
|
|
|
|
const auto &FileNames = LineTable->Prologue.FileNames;
|
|
|
|
|
// Dir indexes start at 1, as DWARF file numbers, and a dir index 0
|
|
|
|
|
// means empty dir.
|
|
|
|
|
assert(FileIndex > 0 && FileIndex <= FileNames.size() &&
|
|
|
|
|
"FileIndex out of range for the compilation unit.");
|
|
|
|
|
const char *Dir = FileNames[FileIndex - 1].DirIdx ?
|
|
|
|
|
LineTable->Prologue.IncludeDirectories[FileNames[FileIndex - 1].DirIdx - 1] :
|
|
|
|
|
"";
|
|
|
|
|
return Ctx->getDwarfFile(Dir, FileNames[FileIndex - 1].Name, 0, DestCUID);
|
|
|
|
|
}
|
|
|
|
|
|
2016-05-27 20:19:19 -07:00
|
|
|
void BinaryContext::preprocessDebugInfo(
|
|
|
|
|
std::map<uint64_t, BinaryFunction> &BinaryFunctions) {
|
2016-03-14 18:48:05 -07:00
|
|
|
// Populate MCContext with DWARF files.
|
|
|
|
|
for (const auto &CU : DwCtx->compile_units()) {
|
|
|
|
|
const auto CUID = CU->getOffset();
|
|
|
|
|
auto LineTable = DwCtx->getLineTableForUnit(CU.get());
|
|
|
|
|
const auto &FileNames = LineTable->Prologue.FileNames;
|
|
|
|
|
for (size_t I = 0, Size = FileNames.size(); I != Size; ++I) {
|
|
|
|
|
// Dir indexes start at 1, as DWARF file numbers, and a dir index 0
|
|
|
|
|
// means empty dir.
|
|
|
|
|
const char *Dir = FileNames[I].DirIdx ?
|
|
|
|
|
LineTable->Prologue.IncludeDirectories[FileNames[I].DirIdx - 1] :
|
|
|
|
|
"";
|
2016-09-02 11:58:53 -07:00
|
|
|
Ctx->getDwarfFile(Dir, FileNames[I].Name, 0, CUID);
|
2016-03-14 18:48:05 -07:00
|
|
|
}
|
|
|
|
|
}
|
2016-02-25 16:57:07 -08:00
|
|
|
|
2016-04-08 16:24:38 -07:00
|
|
|
// For each CU, iterate over its children DIEs and match subprogram DIEs to
|
Update subroutine address ranges in binary.
Summary:
[WIP] Update DWARF info for function address ranges.
This diff currently does not work for unknown reasons,
but I'm describing here what's the current state.
According to both llvm-dwarf and readelf our output seems correct,
but GDB does not interpret it as expected. All details go below in
hope I missed something.
I couldn't actually track the whole change that introduced support for
what we need in gdb yet, but I think I can get to it
(2007-12-04: Support
lexical bocks and function bodies that occupy non-contiguous address ranges). I have reasons to believe gdb at least at some
nges).
The set of introduced changes was basically this:
- After disassembly, iterate over the DIEs in .debug_info and find the
ones that correspond to each BinaryFunction.
- Refactor DebugArangesWriter to also write addresses of functions to
.debug_ranges and track the offsets of function address ranges there
- Add some infrastructure to facilitate patching the binary in
simple ways (BinaryPatcher.h)
- In RewriteInstance, after writing .debug_ranges already with
function address ranges, for each function do:
-- Find the abbreviation corresponding to the function
-- Patch .debug_abbrev to replace DW_AT_low_pc with DW_AT_ranges and
DW_AT_high_pc with DW_AT_producer (I'll explain this hack below).
Also patch the corresponding forms to DW_FORM_sec_offset and
DW_FORM_string (null-terminated in-place string).
-- Patch debug_info with the .debug_ranges offset in place of
the first 4 bytes of DW_AT_low_pc (DW_AT_ranges only occupies 4
bytes whereas low_pc occupies 8), and write an arbitrary string
in-place in the other 12 bytes that were the 4 MSB of low_pc
and the 8 bytes of high_pc before the patch. This depends on
low_pc and high_pc being put consecutively by the compiler, but
it serves to validate the idea. I tried another way of doing it
that does not rely on this but it didn't work either and I believe
the reason for either not working is the same (and still unknown,
but unrelated to them. I might be wrong though, and if I find yet
another way of doing it I may try it). The other way was to
use a form of DW_FORM_data8 for the section offset. This is
disallowed by the specification, but I doubt gdb validates this,
as it's just easier to store it as 64-bit anyway as this is even
necessary to support 64-bit DWARF (which is not what gcc generates
by default apparently).
I still need to make changes to the diff to make it production-ready,
but first I want to figure out why it doesn't work as expected.
By looking at the output of llvm-dwarfdump or readelf, all of
.debug_ranges, .debug_abbrev and .debug_info seem to have been
correctly updated. However, gdb seems to have serious problems with
what we write.
(In fact, readelf --debug-dump=Ranges shows some funny warning messages
of the form ("Warning: There is a hole [0x100 - 0x120] in .debug_ranges"),
but I played around with this and it seems it's just because no
compile unit was using these ranges. Changing .debug_info apparently
changes these warnings, so they seem to be unrelated to the section
itself. Also looking at the hex dump of the section doesn't help,
as everything seems fine. llvm-dwarfdump doesn't say anything.
So I think .debug_ranges is fine.)
The result is that gdb not only doesn't show the function name as we
wanted, but it also stops showing line number information.
Apparently it's not reading/interpreting the address ranges at all,
and so the functions now have no associated address ranges, only the
symbol value which allows one to put a breakpoint in the function,
but not to show source code.
As this left me without more ideas of what to try to feed gdb with,
I believe the most promising next trial is to try to debug gdb itself,
unless someone spots anything I missed.
I found where the interesting part of the code lies for this
case (gdb/dwarf2read.c and some other related files, but mainly that one).
It seems in some parts gdb uses DW_AT_ranges for only getting
its lowest and highest addresses and setting that as low_pc and
high_pc (see dwarf2_get_pc_bounds in gdb's code and where it's called).
I really hope this is not actually the case for
function address ranges. I'll investigate this further. Otherwise
I don't think any changes we make will make it work as initially
intended, as we'll simply need gdb to support it and in that case it
doesn't.
(cherry picked from FBD3073641)
2016-03-16 18:08:29 -07:00
|
|
|
// BinaryFunctions.
|
2016-05-27 20:19:19 -07:00
|
|
|
for (auto &CU : DwCtx->compile_units()) {
|
2016-04-08 16:24:38 -07:00
|
|
|
findSubprograms(CU.get(), CU->getUnitDIE(false), BinaryFunctions,
|
|
|
|
|
UnknownFunctions);
|
Update subroutine address ranges in binary.
Summary:
[WIP] Update DWARF info for function address ranges.
This diff currently does not work for unknown reasons,
but I'm describing here what's the current state.
According to both llvm-dwarf and readelf our output seems correct,
but GDB does not interpret it as expected. All details go below in
hope I missed something.
I couldn't actually track the whole change that introduced support for
what we need in gdb yet, but I think I can get to it
(2007-12-04: Support
lexical bocks and function bodies that occupy non-contiguous address ranges). I have reasons to believe gdb at least at some
nges).
The set of introduced changes was basically this:
- After disassembly, iterate over the DIEs in .debug_info and find the
ones that correspond to each BinaryFunction.
- Refactor DebugArangesWriter to also write addresses of functions to
.debug_ranges and track the offsets of function address ranges there
- Add some infrastructure to facilitate patching the binary in
simple ways (BinaryPatcher.h)
- In RewriteInstance, after writing .debug_ranges already with
function address ranges, for each function do:
-- Find the abbreviation corresponding to the function
-- Patch .debug_abbrev to replace DW_AT_low_pc with DW_AT_ranges and
DW_AT_high_pc with DW_AT_producer (I'll explain this hack below).
Also patch the corresponding forms to DW_FORM_sec_offset and
DW_FORM_string (null-terminated in-place string).
-- Patch debug_info with the .debug_ranges offset in place of
the first 4 bytes of DW_AT_low_pc (DW_AT_ranges only occupies 4
bytes whereas low_pc occupies 8), and write an arbitrary string
in-place in the other 12 bytes that were the 4 MSB of low_pc
and the 8 bytes of high_pc before the patch. This depends on
low_pc and high_pc being put consecutively by the compiler, but
it serves to validate the idea. I tried another way of doing it
that does not rely on this but it didn't work either and I believe
the reason for either not working is the same (and still unknown,
but unrelated to them. I might be wrong though, and if I find yet
another way of doing it I may try it). The other way was to
use a form of DW_FORM_data8 for the section offset. This is
disallowed by the specification, but I doubt gdb validates this,
as it's just easier to store it as 64-bit anyway as this is even
necessary to support 64-bit DWARF (which is not what gcc generates
by default apparently).
I still need to make changes to the diff to make it production-ready,
but first I want to figure out why it doesn't work as expected.
By looking at the output of llvm-dwarfdump or readelf, all of
.debug_ranges, .debug_abbrev and .debug_info seem to have been
correctly updated. However, gdb seems to have serious problems with
what we write.
(In fact, readelf --debug-dump=Ranges shows some funny warning messages
of the form ("Warning: There is a hole [0x100 - 0x120] in .debug_ranges"),
but I played around with this and it seems it's just because no
compile unit was using these ranges. Changing .debug_info apparently
changes these warnings, so they seem to be unrelated to the section
itself. Also looking at the hex dump of the section doesn't help,
as everything seems fine. llvm-dwarfdump doesn't say anything.
So I think .debug_ranges is fine.)
The result is that gdb not only doesn't show the function name as we
wanted, but it also stops showing line number information.
Apparently it's not reading/interpreting the address ranges at all,
and so the functions now have no associated address ranges, only the
symbol value which allows one to put a breakpoint in the function,
but not to show source code.
As this left me without more ideas of what to try to feed gdb with,
I believe the most promising next trial is to try to debug gdb itself,
unless someone spots anything I missed.
I found where the interesting part of the code lies for this
case (gdb/dwarf2read.c and some other related files, but mainly that one).
It seems in some parts gdb uses DW_AT_ranges for only getting
its lowest and highest addresses and setting that as low_pc and
high_pc (see dwarf2_get_pc_bounds in gdb's code and where it's called).
I really hope this is not actually the case for
function address ranges. I'll investigate this further. Otherwise
I don't think any changes we make will make it work as initially
intended, as we'll simply need gdb to support it and in that case it
doesn't.
(cherry picked from FBD3073641)
2016-03-16 18:08:29 -07:00
|
|
|
}
|
2016-03-28 17:45:22 -07:00
|
|
|
|
2016-05-27 20:19:19 -07:00
|
|
|
// Some functions may not have a corresponding subprogram DIE
|
|
|
|
|
// yet they will be included in some CU and will have line number information.
|
|
|
|
|
// Hence we need to associate them with the CU and include in CU ranges.
|
|
|
|
|
for (auto &AddrFunctionPair : BinaryFunctions) {
|
|
|
|
|
auto FunctionAddress = AddrFunctionPair.first;
|
|
|
|
|
auto &Function = AddrFunctionPair.second;
|
|
|
|
|
if (!Function.getSubprogramDIEs().empty())
|
|
|
|
|
continue;
|
|
|
|
|
if (auto DebugAranges = DwCtx->getDebugAranges()) {
|
|
|
|
|
auto CUOffset = DebugAranges->findAddress(FunctionAddress);
|
|
|
|
|
if (CUOffset != -1U) {
|
|
|
|
|
Function.addSubprogramDIE(DwCtx->getCompileUnitForOffset(CUOffset),
|
|
|
|
|
nullptr);
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
#ifdef DWARF_LOOKUP_ALL_RANGES
|
|
|
|
|
// Last resort - iterate over all compile units. This should not happen
|
|
|
|
|
// very often. If it does, we need to create a separate lookup table
|
|
|
|
|
// similar to .debug_aranges internally. This slows down processing
|
|
|
|
|
// considerably.
|
|
|
|
|
for (const auto &CU : DwCtx->compile_units()) {
|
|
|
|
|
const auto *CUDie = CU->getUnitDIE();
|
|
|
|
|
for (const auto &Range : CUDie->getAddressRanges(CU.get())) {
|
|
|
|
|
if (FunctionAddress >= Range.first &&
|
|
|
|
|
FunctionAddress < Range.second) {
|
|
|
|
|
Function.addSubprogramDIE(CU.get(), nullptr);
|
|
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
#endif
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void BinaryContext::preprocessFunctionDebugInfo(
|
|
|
|
|
std::map<uint64_t, BinaryFunction> &BinaryFunctions) {
|
2016-04-12 11:41:03 -07:00
|
|
|
// Iterate over DIE trees finding objects that contain address ranges.
|
2016-03-28 17:45:22 -07:00
|
|
|
for (const auto &CU : DwCtx->compile_units()) {
|
2016-04-12 11:41:03 -07:00
|
|
|
findAddressRangesObjects(CU.get(), CU->getUnitDIE(false), BinaryFunctions,
|
|
|
|
|
AddressRangesObjects);
|
2016-03-28 17:45:22 -07:00
|
|
|
}
|
2016-04-01 11:37:28 -07:00
|
|
|
|
|
|
|
|
// Iterate over location lists and save them in LocationLists.
|
|
|
|
|
auto DebugLoc = DwCtx->getDebugLoc();
|
|
|
|
|
for (const auto &DebugLocEntry : DebugLoc->getLocationLists()) {
|
2016-05-27 20:19:19 -07:00
|
|
|
if (DebugLocEntry.Entries.empty())
|
|
|
|
|
continue;
|
|
|
|
|
auto StartAddress = DebugLocEntry.Entries.front().Begin;
|
|
|
|
|
auto *Function = getBinaryFunctionContainingAddress(StartAddress,
|
|
|
|
|
BinaryFunctions);
|
|
|
|
|
if (!Function || !Function->isSimple())
|
|
|
|
|
continue;
|
2016-04-01 11:37:28 -07:00
|
|
|
LocationLists.emplace_back(DebugLocEntry.Offset);
|
|
|
|
|
auto &LocationList = LocationLists.back();
|
|
|
|
|
for (const auto &Location : DebugLocEntry.Entries) {
|
2016-05-27 20:19:19 -07:00
|
|
|
LocationList.addLocation(&Location.Loc, *Function, Location.Begin,
|
|
|
|
|
Location.End);
|
2016-04-01 11:37:28 -07:00
|
|
|
}
|
|
|
|
|
}
|
Update subroutine address ranges in binary.
Summary:
[WIP] Update DWARF info for function address ranges.
This diff currently does not work for unknown reasons,
but I'm describing here what's the current state.
According to both llvm-dwarf and readelf our output seems correct,
but GDB does not interpret it as expected. All details go below in
hope I missed something.
I couldn't actually track the whole change that introduced support for
what we need in gdb yet, but I think I can get to it
(2007-12-04: Support
lexical bocks and function bodies that occupy non-contiguous address ranges). I have reasons to believe gdb at least at some
nges).
The set of introduced changes was basically this:
- After disassembly, iterate over the DIEs in .debug_info and find the
ones that correspond to each BinaryFunction.
- Refactor DebugArangesWriter to also write addresses of functions to
.debug_ranges and track the offsets of function address ranges there
- Add some infrastructure to facilitate patching the binary in
simple ways (BinaryPatcher.h)
- In RewriteInstance, after writing .debug_ranges already with
function address ranges, for each function do:
-- Find the abbreviation corresponding to the function
-- Patch .debug_abbrev to replace DW_AT_low_pc with DW_AT_ranges and
DW_AT_high_pc with DW_AT_producer (I'll explain this hack below).
Also patch the corresponding forms to DW_FORM_sec_offset and
DW_FORM_string (null-terminated in-place string).
-- Patch debug_info with the .debug_ranges offset in place of
the first 4 bytes of DW_AT_low_pc (DW_AT_ranges only occupies 4
bytes whereas low_pc occupies 8), and write an arbitrary string
in-place in the other 12 bytes that were the 4 MSB of low_pc
and the 8 bytes of high_pc before the patch. This depends on
low_pc and high_pc being put consecutively by the compiler, but
it serves to validate the idea. I tried another way of doing it
that does not rely on this but it didn't work either and I believe
the reason for either not working is the same (and still unknown,
but unrelated to them. I might be wrong though, and if I find yet
another way of doing it I may try it). The other way was to
use a form of DW_FORM_data8 for the section offset. This is
disallowed by the specification, but I doubt gdb validates this,
as it's just easier to store it as 64-bit anyway as this is even
necessary to support 64-bit DWARF (which is not what gcc generates
by default apparently).
I still need to make changes to the diff to make it production-ready,
but first I want to figure out why it doesn't work as expected.
By looking at the output of llvm-dwarfdump or readelf, all of
.debug_ranges, .debug_abbrev and .debug_info seem to have been
correctly updated. However, gdb seems to have serious problems with
what we write.
(In fact, readelf --debug-dump=Ranges shows some funny warning messages
of the form ("Warning: There is a hole [0x100 - 0x120] in .debug_ranges"),
but I played around with this and it seems it's just because no
compile unit was using these ranges. Changing .debug_info apparently
changes these warnings, so they seem to be unrelated to the section
itself. Also looking at the hex dump of the section doesn't help,
as everything seems fine. llvm-dwarfdump doesn't say anything.
So I think .debug_ranges is fine.)
The result is that gdb not only doesn't show the function name as we
wanted, but it also stops showing line number information.
Apparently it's not reading/interpreting the address ranges at all,
and so the functions now have no associated address ranges, only the
symbol value which allows one to put a breakpoint in the function,
but not to show source code.
As this left me without more ideas of what to try to feed gdb with,
I believe the most promising next trial is to try to debug gdb itself,
unless someone spots anything I missed.
I found where the interesting part of the code lies for this
case (gdb/dwarf2read.c and some other related files, but mainly that one).
It seems in some parts gdb uses DW_AT_ranges for only getting
its lowest and highest addresses and setting that as low_pc and
high_pc (see dwarf2_get_pc_bounds in gdb's code and where it's called).
I really hope this is not actually the case for
function address ranges. I'll investigate this further. Otherwise
I don't think any changes we make will make it work as initially
intended, as we'll simply need gdb to support it and in that case it
doesn't.
(cherry picked from FBD3073641)
2016-03-16 18:08:29 -07:00
|
|
|
}
|
|
|
|
|
|
2016-07-23 08:01:53 -07:00
|
|
|
void BinaryContext::printCFI(raw_ostream &OS, uint32_t Operation) {
|
|
|
|
|
switch(Operation) {
|
|
|
|
|
case MCCFIInstruction::OpSameValue: OS << "OpSameValue"; break;
|
|
|
|
|
case MCCFIInstruction::OpRememberState: OS << "OpRememberState"; break;
|
|
|
|
|
case MCCFIInstruction::OpRestoreState: OS << "OpRestoreState"; break;
|
|
|
|
|
case MCCFIInstruction::OpOffset: OS << "OpOffset"; break;
|
|
|
|
|
case MCCFIInstruction::OpDefCfaRegister: OS << "OpDefCfaRegister"; break;
|
|
|
|
|
case MCCFIInstruction::OpDefCfaOffset: OS << "OpDefCfaOffset"; break;
|
|
|
|
|
case MCCFIInstruction::OpDefCfa: OS << "OpDefCfa"; break;
|
|
|
|
|
case MCCFIInstruction::OpRelOffset: OS << "OpRelOffset"; break;
|
|
|
|
|
case MCCFIInstruction::OpAdjustCfaOffset: OS << "OfAdjustCfaOffset"; break;
|
|
|
|
|
case MCCFIInstruction::OpEscape: OS << "OpEscape"; break;
|
|
|
|
|
case MCCFIInstruction::OpRestore: OS << "OpRestore"; break;
|
|
|
|
|
case MCCFIInstruction::OpUndefined: OS << "OpUndefined"; break;
|
|
|
|
|
case MCCFIInstruction::OpRegister: OS << "OpRegister"; break;
|
|
|
|
|
case MCCFIInstruction::OpWindowSave: OS << "OpWindowSave"; break;
|
|
|
|
|
case MCCFIInstruction::OpGnuArgsSize: OS << "OpGnuArgsSize"; break;
|
|
|
|
|
default: OS << "Op#" << Operation; break;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void BinaryContext::printInstruction(raw_ostream &OS,
|
|
|
|
|
const MCInst &Instruction,
|
|
|
|
|
uint64_t Offset,
|
|
|
|
|
const BinaryFunction* Function,
|
|
|
|
|
bool printMCInst) const {
|
|
|
|
|
if (MIA->isEHLabel(Instruction)) {
|
2016-09-08 14:52:26 -07:00
|
|
|
OS << " EH_LABEL: " << *MIA->getTargetSymbol(Instruction) << '\n';
|
2016-07-23 08:01:53 -07:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
OS << format(" %08" PRIx64 ": ", Offset);
|
2016-08-22 14:24:09 -07:00
|
|
|
if (MIA->isCFI(Instruction)) {
|
2016-07-23 08:01:53 -07:00
|
|
|
uint32_t Offset = Instruction.getOperand(0).getImm();
|
|
|
|
|
OS << "\t!CFI\t$" << Offset << "\t; ";
|
2016-08-22 14:24:09 -07:00
|
|
|
if (Function)
|
|
|
|
|
printCFI(OS, Function->getCFIFor(Instruction)->getOperation());
|
2016-07-23 08:01:53 -07:00
|
|
|
OS << "\n";
|
|
|
|
|
return;
|
|
|
|
|
}
|
2016-07-28 18:49:48 -07:00
|
|
|
InstPrinter->printInst(&Instruction, OS, "", *STI);
|
2016-07-23 08:01:53 -07:00
|
|
|
if (MIA->isCall(Instruction)) {
|
|
|
|
|
if (MIA->isTailCall(Instruction))
|
|
|
|
|
OS << " # TAILCALL ";
|
|
|
|
|
if (MIA->isInvoke(Instruction)) {
|
|
|
|
|
const MCSymbol *LP;
|
|
|
|
|
uint64_t Action;
|
|
|
|
|
std::tie(LP, Action) = MIA->getEHInfo(Instruction);
|
|
|
|
|
OS << " # handler: ";
|
|
|
|
|
if (LP)
|
|
|
|
|
OS << *LP;
|
|
|
|
|
else
|
|
|
|
|
OS << '0';
|
|
|
|
|
OS << "; action: " << Action;
|
|
|
|
|
auto GnuArgsSize = MIA->getGnuArgsSize(Instruction);
|
|
|
|
|
if (GnuArgsSize >= 0)
|
|
|
|
|
OS << "; GNU_args_size = " << GnuArgsSize;
|
|
|
|
|
}
|
|
|
|
|
}
|
2016-09-14 16:45:40 -07:00
|
|
|
if (MIA->isIndirectBranch(Instruction)) {
|
2016-09-16 15:54:32 -07:00
|
|
|
if (auto JTAddress = MIA->getJumpTable(Instruction)) {
|
|
|
|
|
OS << " # JUMPTABLE @0x" << Twine::utohexstr(JTAddress);
|
2016-09-14 16:45:40 -07:00
|
|
|
}
|
|
|
|
|
}
|
2016-07-23 08:01:53 -07:00
|
|
|
|
|
|
|
|
const DWARFDebugLine::LineTable *LineTable =
|
|
|
|
|
Function && opts::PrintDebugInfo ? Function->getDWARFUnitLineTable().second
|
|
|
|
|
: nullptr;
|
|
|
|
|
|
|
|
|
|
if (LineTable) {
|
|
|
|
|
auto RowRef = DebugLineTableRowRef::fromSMLoc(Instruction.getLoc());
|
|
|
|
|
|
|
|
|
|
if (RowRef != DebugLineTableRowRef::NULL_ROW) {
|
|
|
|
|
const auto &Row = LineTable->Rows[RowRef.RowIndex - 1];
|
|
|
|
|
OS << " # debug line "
|
|
|
|
|
<< LineTable->Prologue.FileNames[Row.File - 1].Name
|
|
|
|
|
<< ":" << Row.Line;
|
|
|
|
|
|
|
|
|
|
if (Row.Column) {
|
|
|
|
|
OS << ":" << Row.Column;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
OS << "\n";
|
|
|
|
|
|
|
|
|
|
if (printMCInst) {
|
|
|
|
|
Instruction.dump_pretty(OS, InstPrinter.get());
|
|
|
|
|
OS << "\n";
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-07-21 12:45:35 -07:00
|
|
|
ErrorOr<SectionRef> BinaryContext::getSectionForAddress(uint64_t Address) const{
|
|
|
|
|
auto SI = AllocatableSections.upper_bound(Address);
|
|
|
|
|
if (SI != AllocatableSections.begin()) {
|
|
|
|
|
--SI;
|
|
|
|
|
if (SI->first + SI->second.getSize() > Address)
|
|
|
|
|
return SI->second;
|
|
|
|
|
}
|
|
|
|
|
return std::make_error_code(std::errc::bad_address);
|
|
|
|
|
}
|
|
|
|
|
|
2016-09-27 19:09:38 -07:00
|
|
|
void BinaryContext::addSectionRelocation(SectionRef Section, uint64_t Address,
|
|
|
|
|
MCSymbol *Symbol, uint64_t Type,
|
|
|
|
|
uint64_t Addend) {
|
|
|
|
|
auto RI = SectionRelocations.find(Section);
|
|
|
|
|
if (RI == SectionRelocations.end()) {
|
|
|
|
|
auto Result =
|
|
|
|
|
SectionRelocations.emplace(Section, std::vector<Relocation>());
|
|
|
|
|
RI = Result.first;
|
|
|
|
|
}
|
|
|
|
|
RI->second.emplace_back(Relocation{Address, Symbol, Type, Addend});
|
|
|
|
|
}
|