Make lld actually compatible with gold in terms of filler handling.
GNU gold handles output section fillers as 32-bit values.
This patch makes LLD compatible with that behavior.
Differential revision: https://reviews.llvm.org/D23181
llvm-svn: 280018
diff --git a/lld/ELF/LinkerScript.cpp b/lld/ELF/LinkerScript.cpp
index c00791d..060844e 100644
--- a/lld/ELF/LinkerScript.cpp
+++ b/lld/ELF/LinkerScript.cpp
@@ -956,24 +956,24 @@
return Cmd;
}
+// Read "=<number>" where <number> is an octal/decimal/hexadecimal number.
+// https://sourceware.org/binutils/docs/ld/Output-Section-Fill.html
+//
+// ld.gold is not fully compatible with ld.bfd. ld.bfd handles
+// hexstrings as blobs of arbitrary sizes, while ld.gold handles them
+// as 32-bit big-endian values. We will do the same as ld.gold does
+// because it's simpler than what ld.bfd does.
std::vector<uint8_t> ScriptParser::readOutputSectionFiller() {
- StringRef Tok = peek();
- if (!Tok.startswith("="))
+ if (!peek().startswith("="))
return {};
- next();
- // Read a hexstring of arbitrary length.
- if (Tok.startswith("=0x"))
- return parseHex(Tok.substr(3));
-
- // Read a decimal or octal value as a big-endian 32 bit value.
- // Why do this? I don't know, but that's what gold does.
+ StringRef Tok = next();
uint32_t V;
if (Tok.substr(1).getAsInteger(0, V)) {
setError("invalid filler expression: " + Tok);
return {};
}
- return { uint8_t(V >> 24), uint8_t(V >> 16), uint8_t(V >> 8), uint8_t(V) };
+ return {uint8_t(V >> 24), uint8_t(V >> 16), uint8_t(V >> 8), uint8_t(V)};
}
SymbolAssignment *ScriptParser::readProvideHidden(bool Provide, bool Hidden) {