DebugInfo: Reduce long-distance dependence on what will/won't emit a debug_addr section

This is a no-op/NFC at the moment & generally makes the code /somewhat/
cleaner/less reliant on assumptions about what will produce a debug_addr
section.

It's still a bit "spooky action at a distance" - the add ranges code
pre-emptively inserts addresses into the address pool it knows will
eventually be used by the range emission code (or low/high pc).

The 'ideal' would be either to actually compute the addresses needed for
range (& loc) emission earlier - which would mean decanonicalizing the
range/loc representation earlier to account for whether it was going to
use addrx encodings or not (which would be unfortunate, but could be
refactored to be relatively unobtrusive).

Alternatively, emitting the range/loc sections earlier would cause them
to request the needed addresses sooner - but then you endup having to
split finalizeModuleInfo because some things need to be handled there
before the ranges/locs are emitted, I think...
This commit is contained in:
David Blaikie 2020-05-17 12:17:31 -07:00
parent 39beeeff20
commit a055e3856f
1 changed files with 4 additions and 3 deletions

View File

@ -1271,8 +1271,7 @@ void DwarfDebug::finalizeModuleInfo() {
// We don't keep track of which addresses are used in which CU so this
// is a bit pessimistic under LTO.
if ((!AddrPool.isEmpty() || TheCU.hasRangeLists()) &&
(getDwarfVersion() >= 5 || HasSplitUnit))
if ((HasSplitUnit || getDwarfVersion() >= 5) && !AddrPool.isEmpty())
U.addAddrTableBase();
if (getDwarfVersion() >= 5) {
@ -3271,5 +3270,7 @@ const MCSymbol *DwarfDebug::getSectionLabel(const MCSection *S) {
return SectionLabels.find(S)->second;
}
void DwarfDebug::insertSectionLabel(const MCSymbol *S) {
SectionLabels.insert(std::make_pair(&S->getSection(), S));
if (SectionLabels.insert(std::make_pair(&S->getSection(), S)).second)
if (useSplitDwarf() || getDwarfVersion() >= 5)
AddrPool.getIndex(S);
}