summaryrefslogtreecommitdiff
path: root/lib
diff options
context:
space:
mode:
authorDavid Blaikie <dblaikie@gmail.com>2014-04-18 21:24:12 +0000
committerDavid Blaikie <dblaikie@gmail.com>2014-04-18 21:24:12 +0000
commit037da24c10511f857cf2790905d9378184c3a355 (patch)
tree83bbd633bb3465b420113655ffc7d07b8c48a1d7 /lib
parent6c4ec69c6be8b0003b420b58df585caa0563ef70 (diff)
downloadllvm-037da24c10511f857cf2790905d9378184c3a355.tar.gz
llvm-037da24c10511f857cf2790905d9378184c3a355.tar.bz2
llvm-037da24c10511f857cf2790905d9378184c3a355.tar.xz
Update the fragments of symbols in compressed sections.
While unnamed relocations are already cached in side tables in ELFObjectWriter::RecordRelocation, symbols still need their fragments updated to refer to the newly compressed fragment (even if that fragment isn't big enough to fit the offset). Even though we only create temporary symbols in debug info sections this comes up in 32 bit builds where even temporary symbols in mergeable sections (such as debug_str) have to be emitted as named symbols. I tried a few other ways to do this but they all didn't work for various reasons: 1) Canonicalize the MCSymbolData in RecordRelocation, nulling out the Fragment (so it didn't have to be updated by CompressDebugSection). This doesn't work because some code relies on symbols having fragments to indicate that they're defined, I think. 2) Canonicalize the MCSymbolData in RecordRelocation to be "first fragment + absolute offset" so it would be cheaper to just test and update the fragment in CompressDebugSections. This doesn't work because the offset computed in RecordRelocation isn't that of the symbol's fragment, it's the passed in fragment (I haven't figured out what that fragment is - perhaps it's the location where the relocation is to be written). And if the fragment offset has to be computed only for this use we might as well just do it when we need to, in CompressDebugSection. I also added an assert to help catch this a bit more clearly, even though it is UB. The test case improvements would either assert fail and/or valgrind vail without the fix, even if they wouldn't necessarily fail the FileCheck output. git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@206653 91177308-0d34-0410-b5e6-96231b3b80d8
Diffstat (limited to 'lib')
-rw-r--r--lib/MC/ELFObjectWriter.cpp21
1 files changed, 21 insertions, 0 deletions
diff --git a/lib/MC/ELFObjectWriter.cpp b/lib/MC/ELFObjectWriter.cpp
index 3f939bbbc0..c064e24128 100644
--- a/lib/MC/ELFObjectWriter.cpp
+++ b/lib/MC/ELFObjectWriter.cpp
@@ -616,6 +616,10 @@ static const MCSymbol *getBaseSymbol(const MCAsmLayout &Layout,
void ELFObjectWriter::WriteSymbol(SymbolTableWriter &Writer, ELFSymbolData &MSD,
const MCAsmLayout &Layout) {
MCSymbolData &OrigData = *MSD.SymbolData;
+ assert(!OrigData.getFragment() ||
+ (&OrigData.getFragment()->getParent()->getSection() ==
+ &OrigData.getSymbol().getSection()) &&
+ "The symbol's section doesn't match the fragment's symbol");
const MCSymbol *Base = getBaseSymbol(Layout, OrigData.getSymbol());
// This has to be in sync with when computeSymbolTable uses SHN_ABS or
@@ -1244,6 +1248,19 @@ getCompressedFragment(MCAsmLayout &Layout,
return CompressedFragment;
}
+static void UpdateSymbols(const MCAsmLayout &Layout, const MCSectionData &SD,
+ MCAssembler::symbol_range Symbols,
+ MCFragment *NewFragment) {
+ for (MCSymbolData &Data : Symbols) {
+ MCFragment *F = Data.getFragment();
+ if (F && F->getParent() == &SD) {
+ Data.setOffset(Data.getOffset() +
+ Layout.getFragmentOffset(Data.Fragment));
+ Data.setFragment(NewFragment);
+ }
+ }
+}
+
static void CompressDebugSection(MCAssembler &Asm, MCAsmLayout &Layout,
const MCSectionELF &Section,
MCSectionData &SD) {
@@ -1257,6 +1274,10 @@ static void CompressDebugSection(MCAssembler &Asm, MCAsmLayout &Layout,
if (!CompressedFragment)
return;
+ // Update the fragment+offsets of any symbols referring to fragments in this
+ // section to refer to the new fragment.
+ UpdateSymbols(Layout, SD, Asm.symbols(), CompressedFragment.get());
+
// Invalidate the layout for the whole section since it will have new and
// different fragments now.
Layout.invalidateFragmentsFrom(&Fragments.front());