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"
|
|
|
|
|
|
|
|
|
|
namespace llvm {
|
2016-02-05 14:42:04 -08:00
|
|
|
namespace bolt {
|
2015-10-14 15:35:14 -07:00
|
|
|
|
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-03-28 17:45:22 -07:00
|
|
|
} // namespace bolt
|
|
|
|
|
} // namespace llvm
|
|
|
|
|
|
|
|
|
|
namespace {
|
|
|
|
|
|
|
|
|
|
using namespace llvm;
|
|
|
|
|
using namespace bolt;
|
|
|
|
|
|
|
|
|
|
/// Returns the binary function that contains a given address in the input
|
|
|
|
|
/// 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
|
|
|
|
|
// blocks, saving them in LexicalBlocks.
|
|
|
|
|
void findLexicalBlocks(const DWARFCompileUnit *Unit,
|
|
|
|
|
const DWARFDebugInfoEntryMinimal *DIE,
|
|
|
|
|
std::map<uint64_t, BinaryFunction> &Functions,
|
|
|
|
|
std::vector<llvm::bolt::LexicalBlock> &LexicalBlocks) {
|
|
|
|
|
if (DIE->getTag() == dwarf::DW_TAG_lexical_block) {
|
|
|
|
|
LexicalBlocks.emplace_back(Unit, DIE);
|
|
|
|
|
auto &LB = LexicalBlocks.back();
|
|
|
|
|
for (const auto &Range : DIE->getAddressRanges(Unit)) {
|
|
|
|
|
if (auto *Function = getBinaryFunctionContainingAddress(Range.first,
|
|
|
|
|
Functions)) {
|
|
|
|
|
if (Function->isSimple()) {
|
|
|
|
|
LB.addAddressRange(*Function, Range.first, Range.second);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// Recursively visit each child.
|
|
|
|
|
for (auto Child = DIE->getFirstChild(); Child; Child = Child->getSibling()) {
|
|
|
|
|
findLexicalBlocks(Unit, Child, Functions, LexicalBlocks);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-04-08 16:24: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.
|
|
|
|
|
void findSubprograms(const DWARFCompileUnit *Unit,
|
|
|
|
|
const DWARFDebugInfoEntryMinimal *DIE,
|
|
|
|
|
std::map<uint64_t, BinaryFunction> &BinaryFunctions,
|
|
|
|
|
BinaryContext::DIECompileUnitVector &Unknown) {
|
|
|
|
|
if (DIE->isSubprogramDIE()) {
|
|
|
|
|
uint64_t LowPC, HighPC;
|
|
|
|
|
if (DIE->getLowAndHighPC(Unit, LowPC, HighPC)) {
|
|
|
|
|
auto It = BinaryFunctions.find(LowPC);
|
|
|
|
|
if (It != BinaryFunctions.end()) {
|
|
|
|
|
It->second.addSubprocedureDIE(Unit, DIE);
|
|
|
|
|
} 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
|
|
|
|
|
|
|
|
|
|
namespace llvm {
|
|
|
|
|
namespace bolt {
|
|
|
|
|
|
2016-03-14 18:48:05 -07:00
|
|
|
void BinaryContext::preprocessDebugInfo() {
|
|
|
|
|
// Iterate over all DWARF compilation units and map their offset in the
|
|
|
|
|
// binary to themselves in OffsetDwarfCUMap
|
2016-02-25 16:57:07 -08:00
|
|
|
for (const auto &CU : DwCtx->compile_units()) {
|
|
|
|
|
OffsetToDwarfCU[CU->getOffset()] = CU.get();
|
|
|
|
|
}
|
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] :
|
|
|
|
|
"";
|
|
|
|
|
Ctx->getDwarfFile(Dir, FileNames[I].Name, I + 1, CUID);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
auto LineTableOffset =
|
|
|
|
|
DwCtx->getAttrFieldOffsetForUnit(CU.get(), dwarf::DW_AT_stmt_list);
|
|
|
|
|
if (LineTableOffset)
|
|
|
|
|
LineTableOffsetCUMap[CUID] = LineTableOffset;
|
|
|
|
|
}
|
2016-02-25 16:57:07 -08: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
|
|
|
void BinaryContext::preprocessFunctionDebugInfo(
|
|
|
|
|
std::map<uint64_t, BinaryFunction> &BinaryFunctions) {
|
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.
|
|
|
|
|
for (const 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
|
|
|
|
|
|
|
|
// Iterate over DIE trees finding lexical blocks.
|
|
|
|
|
for (const auto &CU : DwCtx->compile_units()) {
|
|
|
|
|
findLexicalBlocks(CU.get(), CU->getUnitDIE(false), BinaryFunctions,
|
|
|
|
|
LexicalBlocks);
|
|
|
|
|
}
|
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()) {
|
|
|
|
|
LocationLists.emplace_back(DebugLocEntry.Offset);
|
|
|
|
|
auto &LocationList = LocationLists.back();
|
|
|
|
|
for (const auto &Location : DebugLocEntry.Entries) {
|
|
|
|
|
auto *Function = getBinaryFunctionContainingAddress(Location.Begin,
|
|
|
|
|
BinaryFunctions);
|
|
|
|
|
if (Function && Function->isSimple()) {
|
|
|
|
|
LocationList.addLocation(&Location.Loc, *Function, Location.Begin,
|
|
|
|
|
Location.End);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
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-02-05 14:42:04 -08:00
|
|
|
} // namespace bolt
|
2015-10-14 15:35:14 -07:00
|
|
|
} // namespace llvm
|