llvm-project/llvm/lib/Target/Mips/MCTargetDesc/MipsELFObjectWriter.cpp

670 lines
24 KiB
C++
Raw Normal View History

//===-- MipsELFObjectWriter.cpp - Mips ELF Writer -------------------------===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
#include "MCTargetDesc/MipsFixupKinds.h"
#include "MCTargetDesc/MipsMCTargetDesc.h"
#include "llvm/ADT/STLExtras.h"
#include "llvm/BinaryFormat/ELF.h"
#include "llvm/MC/MCELFObjectWriter.h"
#include "llvm/MC/MCFixup.h"
#include "llvm/MC/MCSymbolELF.h"
#include "llvm/Support/Casting.h"
#include "llvm/Support/Compiler.h"
[mips] Correct the ordering of HI/LO pairs in the relocation table. Summary: There seems to have been a misunderstanding as to the meaning of 'offset' in the rules laid down by our ABI. The previous code believed that 'offset' meant the offset within the section that the relocation is applied to. However, it should have meant the offset from the symbol used in the relocation expression. This patch adds two fields to ELFRelocationEntry and uses them to correct the order of relocations for MIPS. These fields contain: * The original symbol before shouldRelocateWithSymbol() is considered. This ensures that R_MIPS_GOT16 is able to correctly distinguish between local and external symbols, allowing us to tell whether %got() requires a matching %lo() or not (local symbols require one, external symbols don't). It also prevents confusing cases where the fuzzy matching rules cause things like %hi(foo)/%lo(foo+3) and %hi(bar)/%lo(bar+1) to swap their %lo()'s. * The original offset before shouldRelocateWithSymbol() is considered. The existing Addend field is always zero when the object uses in place addends (because it's already moved it to the encoding) but MIPS needs to use the original offset to ensure that the linker correctly calculates the carry-in bit for %hi() and %got(). IAS ensures that unmatchable %hi()/%got() relocations are placed at the end of the table to ensure that the linker rejects the table (we're unable to report such errors directly). The alternatives to this risk accidental matching against inappropriate relocations which may silently compute incorrect values due to an incorrect carry bit between the %lo() and %hi()/%got(). Reviewers: sdardis Subscribers: dsanders, sdardis, rafael, llvm-commits Differential Revision: http://reviews.llvm.org/D19718 llvm-svn: 268733
2016-05-06 21:49:25 +08:00
#include "llvm/Support/Debug.h"
#include "llvm/Support/ErrorHandling.h"
#include "llvm/Support/MathExtras.h"
#include "llvm/Support/raw_ostream.h"
#include <algorithm>
#include <cassert>
#include <cstdint>
#include <iterator>
#include <list>
#include <utility>
[mips] Correct the ordering of HI/LO pairs in the relocation table. Summary: There seems to have been a misunderstanding as to the meaning of 'offset' in the rules laid down by our ABI. The previous code believed that 'offset' meant the offset within the section that the relocation is applied to. However, it should have meant the offset from the symbol used in the relocation expression. This patch adds two fields to ELFRelocationEntry and uses them to correct the order of relocations for MIPS. These fields contain: * The original symbol before shouldRelocateWithSymbol() is considered. This ensures that R_MIPS_GOT16 is able to correctly distinguish between local and external symbols, allowing us to tell whether %got() requires a matching %lo() or not (local symbols require one, external symbols don't). It also prevents confusing cases where the fuzzy matching rules cause things like %hi(foo)/%lo(foo+3) and %hi(bar)/%lo(bar+1) to swap their %lo()'s. * The original offset before shouldRelocateWithSymbol() is considered. The existing Addend field is always zero when the object uses in place addends (because it's already moved it to the encoding) but MIPS needs to use the original offset to ensure that the linker correctly calculates the carry-in bit for %hi() and %got(). IAS ensures that unmatchable %hi()/%got() relocations are placed at the end of the table to ensure that the linker rejects the table (we're unable to report such errors directly). The alternatives to this risk accidental matching against inappropriate relocations which may silently compute incorrect values due to an incorrect carry bit between the %lo() and %hi()/%got(). Reviewers: sdardis Subscribers: dsanders, sdardis, rafael, llvm-commits Differential Revision: http://reviews.llvm.org/D19718 llvm-svn: 268733
2016-05-06 21:49:25 +08:00
#define DEBUG_TYPE "mips-elf-object-writer"
using namespace llvm;
namespace {
[mips] Correct the ordering of HI/LO pairs in the relocation table. Summary: There seems to have been a misunderstanding as to the meaning of 'offset' in the rules laid down by our ABI. The previous code believed that 'offset' meant the offset within the section that the relocation is applied to. However, it should have meant the offset from the symbol used in the relocation expression. This patch adds two fields to ELFRelocationEntry and uses them to correct the order of relocations for MIPS. These fields contain: * The original symbol before shouldRelocateWithSymbol() is considered. This ensures that R_MIPS_GOT16 is able to correctly distinguish between local and external symbols, allowing us to tell whether %got() requires a matching %lo() or not (local symbols require one, external symbols don't). It also prevents confusing cases where the fuzzy matching rules cause things like %hi(foo)/%lo(foo+3) and %hi(bar)/%lo(bar+1) to swap their %lo()'s. * The original offset before shouldRelocateWithSymbol() is considered. The existing Addend field is always zero when the object uses in place addends (because it's already moved it to the encoding) but MIPS needs to use the original offset to ensure that the linker correctly calculates the carry-in bit for %hi() and %got(). IAS ensures that unmatchable %hi()/%got() relocations are placed at the end of the table to ensure that the linker rejects the table (we're unable to report such errors directly). The alternatives to this risk accidental matching against inappropriate relocations which may silently compute incorrect values due to an incorrect carry bit between the %lo() and %hi()/%got(). Reviewers: sdardis Subscribers: dsanders, sdardis, rafael, llvm-commits Differential Revision: http://reviews.llvm.org/D19718 llvm-svn: 268733
2016-05-06 21:49:25 +08:00
/// Holds additional information needed by the relocation ordering algorithm.
struct MipsRelocationEntry {
[mips] Correct the ordering of HI/LO pairs in the relocation table. Summary: There seems to have been a misunderstanding as to the meaning of 'offset' in the rules laid down by our ABI. The previous code believed that 'offset' meant the offset within the section that the relocation is applied to. However, it should have meant the offset from the symbol used in the relocation expression. This patch adds two fields to ELFRelocationEntry and uses them to correct the order of relocations for MIPS. These fields contain: * The original symbol before shouldRelocateWithSymbol() is considered. This ensures that R_MIPS_GOT16 is able to correctly distinguish between local and external symbols, allowing us to tell whether %got() requires a matching %lo() or not (local symbols require one, external symbols don't). It also prevents confusing cases where the fuzzy matching rules cause things like %hi(foo)/%lo(foo+3) and %hi(bar)/%lo(bar+1) to swap their %lo()'s. * The original offset before shouldRelocateWithSymbol() is considered. The existing Addend field is always zero when the object uses in place addends (because it's already moved it to the encoding) but MIPS needs to use the original offset to ensure that the linker correctly calculates the carry-in bit for %hi() and %got(). IAS ensures that unmatchable %hi()/%got() relocations are placed at the end of the table to ensure that the linker rejects the table (we're unable to report such errors directly). The alternatives to this risk accidental matching against inappropriate relocations which may silently compute incorrect values due to an incorrect carry bit between the %lo() and %hi()/%got(). Reviewers: sdardis Subscribers: dsanders, sdardis, rafael, llvm-commits Differential Revision: http://reviews.llvm.org/D19718 llvm-svn: 268733
2016-05-06 21:49:25 +08:00
const ELFRelocationEntry R; ///< The relocation.
bool Matched = false; ///< Is this relocation part of a match.
[mips] Correct the ordering of HI/LO pairs in the relocation table. Summary: There seems to have been a misunderstanding as to the meaning of 'offset' in the rules laid down by our ABI. The previous code believed that 'offset' meant the offset within the section that the relocation is applied to. However, it should have meant the offset from the symbol used in the relocation expression. This patch adds two fields to ELFRelocationEntry and uses them to correct the order of relocations for MIPS. These fields contain: * The original symbol before shouldRelocateWithSymbol() is considered. This ensures that R_MIPS_GOT16 is able to correctly distinguish between local and external symbols, allowing us to tell whether %got() requires a matching %lo() or not (local symbols require one, external symbols don't). It also prevents confusing cases where the fuzzy matching rules cause things like %hi(foo)/%lo(foo+3) and %hi(bar)/%lo(bar+1) to swap their %lo()'s. * The original offset before shouldRelocateWithSymbol() is considered. The existing Addend field is always zero when the object uses in place addends (because it's already moved it to the encoding) but MIPS needs to use the original offset to ensure that the linker correctly calculates the carry-in bit for %hi() and %got(). IAS ensures that unmatchable %hi()/%got() relocations are placed at the end of the table to ensure that the linker rejects the table (we're unable to report such errors directly). The alternatives to this risk accidental matching against inappropriate relocations which may silently compute incorrect values due to an incorrect carry bit between the %lo() and %hi()/%got(). Reviewers: sdardis Subscribers: dsanders, sdardis, rafael, llvm-commits Differential Revision: http://reviews.llvm.org/D19718 llvm-svn: 268733
2016-05-06 21:49:25 +08:00
MipsRelocationEntry(const ELFRelocationEntry &R) : R(R) {}
[mips] Correct the ordering of HI/LO pairs in the relocation table. Summary: There seems to have been a misunderstanding as to the meaning of 'offset' in the rules laid down by our ABI. The previous code believed that 'offset' meant the offset within the section that the relocation is applied to. However, it should have meant the offset from the symbol used in the relocation expression. This patch adds two fields to ELFRelocationEntry and uses them to correct the order of relocations for MIPS. These fields contain: * The original symbol before shouldRelocateWithSymbol() is considered. This ensures that R_MIPS_GOT16 is able to correctly distinguish between local and external symbols, allowing us to tell whether %got() requires a matching %lo() or not (local symbols require one, external symbols don't). It also prevents confusing cases where the fuzzy matching rules cause things like %hi(foo)/%lo(foo+3) and %hi(bar)/%lo(bar+1) to swap their %lo()'s. * The original offset before shouldRelocateWithSymbol() is considered. The existing Addend field is always zero when the object uses in place addends (because it's already moved it to the encoding) but MIPS needs to use the original offset to ensure that the linker correctly calculates the carry-in bit for %hi() and %got(). IAS ensures that unmatchable %hi()/%got() relocations are placed at the end of the table to ensure that the linker rejects the table (we're unable to report such errors directly). The alternatives to this risk accidental matching against inappropriate relocations which may silently compute incorrect values due to an incorrect carry bit between the %lo() and %hi()/%got(). Reviewers: sdardis Subscribers: dsanders, sdardis, rafael, llvm-commits Differential Revision: http://reviews.llvm.org/D19718 llvm-svn: 268733
2016-05-06 21:49:25 +08:00
void print(raw_ostream &Out) const {
R.print(Out);
Out << ", Matched=" << Matched;
}
};
#ifndef NDEBUG
[mips] Correct the ordering of HI/LO pairs in the relocation table. Summary: There seems to have been a misunderstanding as to the meaning of 'offset' in the rules laid down by our ABI. The previous code believed that 'offset' meant the offset within the section that the relocation is applied to. However, it should have meant the offset from the symbol used in the relocation expression. This patch adds two fields to ELFRelocationEntry and uses them to correct the order of relocations for MIPS. These fields contain: * The original symbol before shouldRelocateWithSymbol() is considered. This ensures that R_MIPS_GOT16 is able to correctly distinguish between local and external symbols, allowing us to tell whether %got() requires a matching %lo() or not (local symbols require one, external symbols don't). It also prevents confusing cases where the fuzzy matching rules cause things like %hi(foo)/%lo(foo+3) and %hi(bar)/%lo(bar+1) to swap their %lo()'s. * The original offset before shouldRelocateWithSymbol() is considered. The existing Addend field is always zero when the object uses in place addends (because it's already moved it to the encoding) but MIPS needs to use the original offset to ensure that the linker correctly calculates the carry-in bit for %hi() and %got(). IAS ensures that unmatchable %hi()/%got() relocations are placed at the end of the table to ensure that the linker rejects the table (we're unable to report such errors directly). The alternatives to this risk accidental matching against inappropriate relocations which may silently compute incorrect values due to an incorrect carry bit between the %lo() and %hi()/%got(). Reviewers: sdardis Subscribers: dsanders, sdardis, rafael, llvm-commits Differential Revision: http://reviews.llvm.org/D19718 llvm-svn: 268733
2016-05-06 21:49:25 +08:00
raw_ostream &operator<<(raw_ostream &OS, const MipsRelocationEntry &RHS) {
RHS.print(OS);
return OS;
}
#endif
[mips] Correct the ordering of HI/LO pairs in the relocation table. Summary: There seems to have been a misunderstanding as to the meaning of 'offset' in the rules laid down by our ABI. The previous code believed that 'offset' meant the offset within the section that the relocation is applied to. However, it should have meant the offset from the symbol used in the relocation expression. This patch adds two fields to ELFRelocationEntry and uses them to correct the order of relocations for MIPS. These fields contain: * The original symbol before shouldRelocateWithSymbol() is considered. This ensures that R_MIPS_GOT16 is able to correctly distinguish between local and external symbols, allowing us to tell whether %got() requires a matching %lo() or not (local symbols require one, external symbols don't). It also prevents confusing cases where the fuzzy matching rules cause things like %hi(foo)/%lo(foo+3) and %hi(bar)/%lo(bar+1) to swap their %lo()'s. * The original offset before shouldRelocateWithSymbol() is considered. The existing Addend field is always zero when the object uses in place addends (because it's already moved it to the encoding) but MIPS needs to use the original offset to ensure that the linker correctly calculates the carry-in bit for %hi() and %got(). IAS ensures that unmatchable %hi()/%got() relocations are placed at the end of the table to ensure that the linker rejects the table (we're unable to report such errors directly). The alternatives to this risk accidental matching against inappropriate relocations which may silently compute incorrect values due to an incorrect carry bit between the %lo() and %hi()/%got(). Reviewers: sdardis Subscribers: dsanders, sdardis, rafael, llvm-commits Differential Revision: http://reviews.llvm.org/D19718 llvm-svn: 268733
2016-05-06 21:49:25 +08:00
class MipsELFObjectWriter : public MCELFObjectTargetWriter {
public:
MipsELFObjectWriter(uint8_t OSABI, bool HasRelocationAddend, bool IsN64,
[mips] Correct the ordering of HI/LO pairs in the relocation table. Summary: There seems to have been a misunderstanding as to the meaning of 'offset' in the rules laid down by our ABI. The previous code believed that 'offset' meant the offset within the section that the relocation is applied to. However, it should have meant the offset from the symbol used in the relocation expression. This patch adds two fields to ELFRelocationEntry and uses them to correct the order of relocations for MIPS. These fields contain: * The original symbol before shouldRelocateWithSymbol() is considered. This ensures that R_MIPS_GOT16 is able to correctly distinguish between local and external symbols, allowing us to tell whether %got() requires a matching %lo() or not (local symbols require one, external symbols don't). It also prevents confusing cases where the fuzzy matching rules cause things like %hi(foo)/%lo(foo+3) and %hi(bar)/%lo(bar+1) to swap their %lo()'s. * The original offset before shouldRelocateWithSymbol() is considered. The existing Addend field is always zero when the object uses in place addends (because it's already moved it to the encoding) but MIPS needs to use the original offset to ensure that the linker correctly calculates the carry-in bit for %hi() and %got(). IAS ensures that unmatchable %hi()/%got() relocations are placed at the end of the table to ensure that the linker rejects the table (we're unable to report such errors directly). The alternatives to this risk accidental matching against inappropriate relocations which may silently compute incorrect values due to an incorrect carry bit between the %lo() and %hi()/%got(). Reviewers: sdardis Subscribers: dsanders, sdardis, rafael, llvm-commits Differential Revision: http://reviews.llvm.org/D19718 llvm-svn: 268733
2016-05-06 21:49:25 +08:00
bool IsLittleEndian);
~MipsELFObjectWriter() override = default;
[mips] Correct the ordering of HI/LO pairs in the relocation table. Summary: There seems to have been a misunderstanding as to the meaning of 'offset' in the rules laid down by our ABI. The previous code believed that 'offset' meant the offset within the section that the relocation is applied to. However, it should have meant the offset from the symbol used in the relocation expression. This patch adds two fields to ELFRelocationEntry and uses them to correct the order of relocations for MIPS. These fields contain: * The original symbol before shouldRelocateWithSymbol() is considered. This ensures that R_MIPS_GOT16 is able to correctly distinguish between local and external symbols, allowing us to tell whether %got() requires a matching %lo() or not (local symbols require one, external symbols don't). It also prevents confusing cases where the fuzzy matching rules cause things like %hi(foo)/%lo(foo+3) and %hi(bar)/%lo(bar+1) to swap their %lo()'s. * The original offset before shouldRelocateWithSymbol() is considered. The existing Addend field is always zero when the object uses in place addends (because it's already moved it to the encoding) but MIPS needs to use the original offset to ensure that the linker correctly calculates the carry-in bit for %hi() and %got(). IAS ensures that unmatchable %hi()/%got() relocations are placed at the end of the table to ensure that the linker rejects the table (we're unable to report such errors directly). The alternatives to this risk accidental matching against inappropriate relocations which may silently compute incorrect values due to an incorrect carry bit between the %lo() and %hi()/%got(). Reviewers: sdardis Subscribers: dsanders, sdardis, rafael, llvm-commits Differential Revision: http://reviews.llvm.org/D19718 llvm-svn: 268733
2016-05-06 21:49:25 +08:00
unsigned getRelocType(MCContext &Ctx, const MCValue &Target,
const MCFixup &Fixup, bool IsPCRel) const override;
bool needsRelocateWithSymbol(const MCSymbol &Sym,
unsigned Type) const override;
void sortRelocs(const MCAssembler &Asm,
std::vector<ELFRelocationEntry> &Relocs) override;
};
/// The possible results of the Predicate function used by find_best.
enum FindBestPredicateResult {
FindBest_NoMatch = 0, ///< The current element is not a match.
FindBest_Match, ///< The current element is a match but better ones are
/// possible.
FindBest_PerfectMatch, ///< The current element is an unbeatable match.
[mips] Correct the ordering of HI/LO pairs in the relocation table. Summary: There seems to have been a misunderstanding as to the meaning of 'offset' in the rules laid down by our ABI. The previous code believed that 'offset' meant the offset within the section that the relocation is applied to. However, it should have meant the offset from the symbol used in the relocation expression. This patch adds two fields to ELFRelocationEntry and uses them to correct the order of relocations for MIPS. These fields contain: * The original symbol before shouldRelocateWithSymbol() is considered. This ensures that R_MIPS_GOT16 is able to correctly distinguish between local and external symbols, allowing us to tell whether %got() requires a matching %lo() or not (local symbols require one, external symbols don't). It also prevents confusing cases where the fuzzy matching rules cause things like %hi(foo)/%lo(foo+3) and %hi(bar)/%lo(bar+1) to swap their %lo()'s. * The original offset before shouldRelocateWithSymbol() is considered. The existing Addend field is always zero when the object uses in place addends (because it's already moved it to the encoding) but MIPS needs to use the original offset to ensure that the linker correctly calculates the carry-in bit for %hi() and %got(). IAS ensures that unmatchable %hi()/%got() relocations are placed at the end of the table to ensure that the linker rejects the table (we're unable to report such errors directly). The alternatives to this risk accidental matching against inappropriate relocations which may silently compute incorrect values due to an incorrect carry bit between the %lo() and %hi()/%got(). Reviewers: sdardis Subscribers: dsanders, sdardis, rafael, llvm-commits Differential Revision: http://reviews.llvm.org/D19718 llvm-svn: 268733
2016-05-06 21:49:25 +08:00
};
} // end anonymous namespace
[mips] Correct the ordering of HI/LO pairs in the relocation table. Summary: There seems to have been a misunderstanding as to the meaning of 'offset' in the rules laid down by our ABI. The previous code believed that 'offset' meant the offset within the section that the relocation is applied to. However, it should have meant the offset from the symbol used in the relocation expression. This patch adds two fields to ELFRelocationEntry and uses them to correct the order of relocations for MIPS. These fields contain: * The original symbol before shouldRelocateWithSymbol() is considered. This ensures that R_MIPS_GOT16 is able to correctly distinguish between local and external symbols, allowing us to tell whether %got() requires a matching %lo() or not (local symbols require one, external symbols don't). It also prevents confusing cases where the fuzzy matching rules cause things like %hi(foo)/%lo(foo+3) and %hi(bar)/%lo(bar+1) to swap their %lo()'s. * The original offset before shouldRelocateWithSymbol() is considered. The existing Addend field is always zero when the object uses in place addends (because it's already moved it to the encoding) but MIPS needs to use the original offset to ensure that the linker correctly calculates the carry-in bit for %hi() and %got(). IAS ensures that unmatchable %hi()/%got() relocations are placed at the end of the table to ensure that the linker rejects the table (we're unable to report such errors directly). The alternatives to this risk accidental matching against inappropriate relocations which may silently compute incorrect values due to an incorrect carry bit between the %lo() and %hi()/%got(). Reviewers: sdardis Subscribers: dsanders, sdardis, rafael, llvm-commits Differential Revision: http://reviews.llvm.org/D19718 llvm-svn: 268733
2016-05-06 21:49:25 +08:00
/// Copy elements in the range [First, Last) to d1 when the predicate is true or
/// d2 when the predicate is false. This is essentially both std::copy_if and
/// std::remove_copy_if combined into a single pass.
template <class InputIt, class OutputIt1, class OutputIt2, class UnaryPredicate>
static std::pair<OutputIt1, OutputIt2> copy_if_else(InputIt First, InputIt Last,
OutputIt1 d1, OutputIt2 d2,
UnaryPredicate Predicate) {
[mips] Correct the ordering of HI/LO pairs in the relocation table. Summary: There seems to have been a misunderstanding as to the meaning of 'offset' in the rules laid down by our ABI. The previous code believed that 'offset' meant the offset within the section that the relocation is applied to. However, it should have meant the offset from the symbol used in the relocation expression. This patch adds two fields to ELFRelocationEntry and uses them to correct the order of relocations for MIPS. These fields contain: * The original symbol before shouldRelocateWithSymbol() is considered. This ensures that R_MIPS_GOT16 is able to correctly distinguish between local and external symbols, allowing us to tell whether %got() requires a matching %lo() or not (local symbols require one, external symbols don't). It also prevents confusing cases where the fuzzy matching rules cause things like %hi(foo)/%lo(foo+3) and %hi(bar)/%lo(bar+1) to swap their %lo()'s. * The original offset before shouldRelocateWithSymbol() is considered. The existing Addend field is always zero when the object uses in place addends (because it's already moved it to the encoding) but MIPS needs to use the original offset to ensure that the linker correctly calculates the carry-in bit for %hi() and %got(). IAS ensures that unmatchable %hi()/%got() relocations are placed at the end of the table to ensure that the linker rejects the table (we're unable to report such errors directly). The alternatives to this risk accidental matching against inappropriate relocations which may silently compute incorrect values due to an incorrect carry bit between the %lo() and %hi()/%got(). Reviewers: sdardis Subscribers: dsanders, sdardis, rafael, llvm-commits Differential Revision: http://reviews.llvm.org/D19718 llvm-svn: 268733
2016-05-06 21:49:25 +08:00
for (InputIt I = First; I != Last; ++I) {
if (Predicate(*I)) {
*d1 = *I;
d1++;
} else {
*d2 = *I;
d2++;
}
}
return std::make_pair(d1, d2);
}
[mips] Correct the ordering of HI/LO pairs in the relocation table. Summary: There seems to have been a misunderstanding as to the meaning of 'offset' in the rules laid down by our ABI. The previous code believed that 'offset' meant the offset within the section that the relocation is applied to. However, it should have meant the offset from the symbol used in the relocation expression. This patch adds two fields to ELFRelocationEntry and uses them to correct the order of relocations for MIPS. These fields contain: * The original symbol before shouldRelocateWithSymbol() is considered. This ensures that R_MIPS_GOT16 is able to correctly distinguish between local and external symbols, allowing us to tell whether %got() requires a matching %lo() or not (local symbols require one, external symbols don't). It also prevents confusing cases where the fuzzy matching rules cause things like %hi(foo)/%lo(foo+3) and %hi(bar)/%lo(bar+1) to swap their %lo()'s. * The original offset before shouldRelocateWithSymbol() is considered. The existing Addend field is always zero when the object uses in place addends (because it's already moved it to the encoding) but MIPS needs to use the original offset to ensure that the linker correctly calculates the carry-in bit for %hi() and %got(). IAS ensures that unmatchable %hi()/%got() relocations are placed at the end of the table to ensure that the linker rejects the table (we're unable to report such errors directly). The alternatives to this risk accidental matching against inappropriate relocations which may silently compute incorrect values due to an incorrect carry bit between the %lo() and %hi()/%got(). Reviewers: sdardis Subscribers: dsanders, sdardis, rafael, llvm-commits Differential Revision: http://reviews.llvm.org/D19718 llvm-svn: 268733
2016-05-06 21:49:25 +08:00
/// Find the best match in the range [First, Last).
///
/// An element matches when Predicate(X) returns FindBest_Match or
/// FindBest_PerfectMatch. A value of FindBest_PerfectMatch also terminates
/// the search. BetterThan(A, B) is a comparator that returns true when A is a
/// better match than B. The return value is the position of the best match.
///
/// This is similar to std::find_if but finds the best of multiple possible
/// matches.
template <class InputIt, class UnaryPredicate, class Comparator>
static InputIt find_best(InputIt First, InputIt Last, UnaryPredicate Predicate,
Comparator BetterThan) {
[mips] Correct the ordering of HI/LO pairs in the relocation table. Summary: There seems to have been a misunderstanding as to the meaning of 'offset' in the rules laid down by our ABI. The previous code believed that 'offset' meant the offset within the section that the relocation is applied to. However, it should have meant the offset from the symbol used in the relocation expression. This patch adds two fields to ELFRelocationEntry and uses them to correct the order of relocations for MIPS. These fields contain: * The original symbol before shouldRelocateWithSymbol() is considered. This ensures that R_MIPS_GOT16 is able to correctly distinguish between local and external symbols, allowing us to tell whether %got() requires a matching %lo() or not (local symbols require one, external symbols don't). It also prevents confusing cases where the fuzzy matching rules cause things like %hi(foo)/%lo(foo+3) and %hi(bar)/%lo(bar+1) to swap their %lo()'s. * The original offset before shouldRelocateWithSymbol() is considered. The existing Addend field is always zero when the object uses in place addends (because it's already moved it to the encoding) but MIPS needs to use the original offset to ensure that the linker correctly calculates the carry-in bit for %hi() and %got(). IAS ensures that unmatchable %hi()/%got() relocations are placed at the end of the table to ensure that the linker rejects the table (we're unable to report such errors directly). The alternatives to this risk accidental matching against inappropriate relocations which may silently compute incorrect values due to an incorrect carry bit between the %lo() and %hi()/%got(). Reviewers: sdardis Subscribers: dsanders, sdardis, rafael, llvm-commits Differential Revision: http://reviews.llvm.org/D19718 llvm-svn: 268733
2016-05-06 21:49:25 +08:00
InputIt Best = Last;
for (InputIt I = First; I != Last; ++I) {
unsigned Matched = Predicate(*I);
if (Matched != FindBest_NoMatch) {
DEBUG(dbgs() << std::distance(First, I) << " is a match (";
I->print(dbgs()); dbgs() << ")\n");
if (Best == Last || BetterThan(*I, *Best)) {
DEBUG(dbgs() << ".. and it beats the last one\n");
Best = I;
}
}
if (Matched == FindBest_PerfectMatch) {
DEBUG(dbgs() << ".. and it is unbeatable\n");
break;
}
}
return Best;
}
/// Determine the low relocation that matches the given relocation.
/// If the relocation does not need a low relocation then the return value
/// is ELF::R_MIPS_NONE.
///
/// The relocations that need a matching low part are
/// R_(MIPS|MICROMIPS|MIPS16)_HI16 for all symbols and
/// R_(MIPS|MICROMIPS|MIPS16)_GOT16 for local symbols only.
static unsigned getMatchingLoType(const ELFRelocationEntry &Reloc) {
unsigned Type = Reloc.Type;
if (Type == ELF::R_MIPS_HI16)
return ELF::R_MIPS_LO16;
if (Type == ELF::R_MICROMIPS_HI16)
return ELF::R_MICROMIPS_LO16;
if (Type == ELF::R_MIPS16_HI16)
return ELF::R_MIPS16_LO16;
if (Reloc.OriginalSymbol->getBinding() != ELF::STB_LOCAL)
return ELF::R_MIPS_NONE;
if (Type == ELF::R_MIPS_GOT16)
return ELF::R_MIPS_LO16;
if (Type == ELF::R_MICROMIPS_GOT16)
return ELF::R_MICROMIPS_LO16;
if (Type == ELF::R_MIPS16_GOT16)
return ELF::R_MIPS16_LO16;
return ELF::R_MIPS_NONE;
}
/// Determine whether a relocation (X) matches the one given in R.
///
/// A relocation matches if:
/// - It's type matches that of a corresponding low part. This is provided in
/// MatchingType for efficiency.
/// - It's based on the same symbol.
/// - It's offset of greater or equal to that of the one given in R.
/// It should be noted that this rule assumes the programmer does not use
/// offsets that exceed the alignment of the symbol. The carry-bit will be
/// incorrect if this is not true.
///
/// A matching relocation is unbeatable if:
/// - It is not already involved in a match.
/// - It's offset is exactly that of the one given in R.
static FindBestPredicateResult isMatchingReloc(const MipsRelocationEntry &X,
const ELFRelocationEntry &R,
unsigned MatchingType) {
[mips] Correct the ordering of HI/LO pairs in the relocation table. Summary: There seems to have been a misunderstanding as to the meaning of 'offset' in the rules laid down by our ABI. The previous code believed that 'offset' meant the offset within the section that the relocation is applied to. However, it should have meant the offset from the symbol used in the relocation expression. This patch adds two fields to ELFRelocationEntry and uses them to correct the order of relocations for MIPS. These fields contain: * The original symbol before shouldRelocateWithSymbol() is considered. This ensures that R_MIPS_GOT16 is able to correctly distinguish between local and external symbols, allowing us to tell whether %got() requires a matching %lo() or not (local symbols require one, external symbols don't). It also prevents confusing cases where the fuzzy matching rules cause things like %hi(foo)/%lo(foo+3) and %hi(bar)/%lo(bar+1) to swap their %lo()'s. * The original offset before shouldRelocateWithSymbol() is considered. The existing Addend field is always zero when the object uses in place addends (because it's already moved it to the encoding) but MIPS needs to use the original offset to ensure that the linker correctly calculates the carry-in bit for %hi() and %got(). IAS ensures that unmatchable %hi()/%got() relocations are placed at the end of the table to ensure that the linker rejects the table (we're unable to report such errors directly). The alternatives to this risk accidental matching against inappropriate relocations which may silently compute incorrect values due to an incorrect carry bit between the %lo() and %hi()/%got(). Reviewers: sdardis Subscribers: dsanders, sdardis, rafael, llvm-commits Differential Revision: http://reviews.llvm.org/D19718 llvm-svn: 268733
2016-05-06 21:49:25 +08:00
if (X.R.Type == MatchingType && X.R.OriginalSymbol == R.OriginalSymbol) {
if (!X.Matched &&
X.R.OriginalAddend == R.OriginalAddend)
return FindBest_PerfectMatch;
else if (X.R.OriginalAddend >= R.OriginalAddend)
return FindBest_Match;
}
return FindBest_NoMatch;
}
/// Determine whether Candidate or PreviousBest is the better match.
/// The return value is true if Candidate is the better match.
///
/// A matching relocation is a better match if:
/// - It has a smaller addend.
/// - It is not already involved in a match.
static bool compareMatchingRelocs(const MipsRelocationEntry &Candidate,
const MipsRelocationEntry &PreviousBest) {
if (Candidate.R.OriginalAddend != PreviousBest.R.OriginalAddend)
return Candidate.R.OriginalAddend < PreviousBest.R.OriginalAddend;
return PreviousBest.Matched && !Candidate.Matched;
}
#ifndef NDEBUG
/// Print all the relocations.
template <class Container>
static void dumpRelocs(const char *Prefix, const Container &Relocs) {
for (const auto &R : Relocs)
dbgs() << Prefix << R << "\n";
}
#endif
MipsELFObjectWriter::MipsELFObjectWriter(uint8_t OSABI,
bool HasRelocationAddend, bool IsN64,
bool IsLittleEndian)
: MCELFObjectTargetWriter(IsN64, OSABI, ELF::EM_MIPS, HasRelocationAddend,
IsN64) {}
unsigned MipsELFObjectWriter::getRelocType(MCContext &Ctx,
const MCValue &Target,
const MCFixup &Fixup,
bool IsPCRel) const {
// Determine the type of the relocation.
unsigned Kind = (unsigned)Fixup.getKind();
switch (Kind) {
case Mips::fixup_Mips_NONE:
return ELF::R_MIPS_NONE;
case Mips::fixup_Mips_16:
case FK_Data_2:
return IsPCRel ? ELF::R_MIPS_PC16 : ELF::R_MIPS_16;
case Mips::fixup_Mips_32:
case FK_Data_4:
return IsPCRel ? ELF::R_MIPS_PC32 : ELF::R_MIPS_32;
}
if (IsPCRel) {
switch (Kind) {
case Mips::fixup_Mips_Branch_PCRel:
case Mips::fixup_Mips_PC16:
return ELF::R_MIPS_PC16;
case Mips::fixup_MICROMIPS_PC7_S1:
return ELF::R_MICROMIPS_PC7_S1;
case Mips::fixup_MICROMIPS_PC10_S1:
return ELF::R_MICROMIPS_PC10_S1;
case Mips::fixup_MICROMIPS_PC16_S1:
return ELF::R_MICROMIPS_PC16_S1;
case Mips::fixup_MICROMIPS_PC26_S1:
return ELF::R_MICROMIPS_PC26_S1;
case Mips::fixup_MICROMIPS_PC19_S2:
return ELF::R_MICROMIPS_PC19_S2;
case Mips::fixup_MICROMIPS_PC18_S3:
return ELF::R_MICROMIPS_PC18_S3;
case Mips::fixup_MICROMIPS_PC21_S1:
return ELF::R_MICROMIPS_PC21_S1;
case Mips::fixup_MIPS_PC19_S2:
return ELF::R_MIPS_PC19_S2;
case Mips::fixup_MIPS_PC18_S3:
return ELF::R_MIPS_PC18_S3;
case Mips::fixup_MIPS_PC21_S2:
return ELF::R_MIPS_PC21_S2;
case Mips::fixup_MIPS_PC26_S2:
return ELF::R_MIPS_PC26_S2;
case Mips::fixup_MIPS_PCHI16:
return ELF::R_MIPS_PCHI16;
case Mips::fixup_MIPS_PCLO16:
return ELF::R_MIPS_PCLO16;
}
llvm_unreachable("invalid PC-relative fixup kind!");
}
switch (Kind) {
case Mips::fixup_Mips_64:
case FK_Data_8:
2015-06-01 22:58:29 +08:00
return ELF::R_MIPS_64;
case FK_DTPRel_4:
return ELF::R_MIPS_TLS_DTPREL32;
case FK_DTPRel_8:
return ELF::R_MIPS_TLS_DTPREL64;
case FK_TPRel_4:
return ELF::R_MIPS_TLS_TPREL32;
case FK_TPRel_8:
return ELF::R_MIPS_TLS_TPREL64;
case FK_GPRel_4:
if (isN64()) {
2015-06-01 22:58:29 +08:00
unsigned Type = (unsigned)ELF::R_MIPS_NONE;
Type = setRType((unsigned)ELF::R_MIPS_GPREL32, Type);
Type = setRType2((unsigned)ELF::R_MIPS_64, Type);
Type = setRType3((unsigned)ELF::R_MIPS_NONE, Type);
2015-06-01 22:58:29 +08:00
return Type;
}
2015-06-01 22:58:29 +08:00
return ELF::R_MIPS_GPREL32;
case Mips::fixup_Mips_GPREL16:
2015-06-01 22:58:29 +08:00
return ELF::R_MIPS_GPREL16;
case Mips::fixup_Mips_26:
2015-06-01 22:58:29 +08:00
return ELF::R_MIPS_26;
case Mips::fixup_Mips_CALL16:
2015-06-01 22:58:29 +08:00
return ELF::R_MIPS_CALL16;
[mips] Use MipsMCExpr instead of MCSymbolRefExpr for all relocations. Summary: This is much closer to the way MIPS relocation expressions work (%hi(foo + 2) rather than %hi(foo) + 2) and removes the need for the various bodges in MipsAsmParser::evaluateRelocExpr(). Removing those bodges ensures that the constant stored in MCValue is the full 32 or 64-bit (depending on ABI) offset from the symbol. This will be used to correct the %hi/%lo matching needed to sort the relocation table correctly. As part of this: * Gave MCExpr::print() the ability to omit parenthesis when emitting a symbol reference inside a MipsMCExpr operator like %hi(X). Without this we print things like %lo(($L1)). * %hi(%neg(%gprel(X))) is now three MipsMCExpr's instead of one. Most of the related special cases have been removed or moved to MipsMCExpr. We can remove the rest as we gain support for the less common relocations when they are not part of this specific combination. * Renamed MipsMCExpr::VariantKind and the enum prefix ('VK_') to avoid confusion with MCSymbolRefExpr::VariantKind and its prefix (also 'VK_'). * fixup_Mips_GOT_Local and fixup_Mips_GOT_Global were found to be identical and merged into fixup_Mips_GOT. * MO_GOT16 and MO_GOT turned out to be identical and have been merged into MO_GOT. * VK_Mips_GOT and VK_Mips_GOT16 turned out to be the same thing so they have been merged into MEK_GOT Reviewers: sdardis Subscribers: dsanders, sdardis, llvm-commits Differential Revision: http://reviews.llvm.org/D19716 llvm-svn: 268379
2016-05-03 21:35:44 +08:00
case Mips::fixup_Mips_GOT:
2015-06-01 22:58:29 +08:00
return ELF::R_MIPS_GOT16;
case Mips::fixup_Mips_HI16:
2015-06-01 22:58:29 +08:00
return ELF::R_MIPS_HI16;
case Mips::fixup_Mips_LO16:
2015-06-01 22:58:29 +08:00
return ELF::R_MIPS_LO16;
case Mips::fixup_Mips_TLSGD:
2015-06-01 22:58:29 +08:00
return ELF::R_MIPS_TLS_GD;
case Mips::fixup_Mips_GOTTPREL:
2015-06-01 22:58:29 +08:00
return ELF::R_MIPS_TLS_GOTTPREL;
case Mips::fixup_Mips_TPREL_HI:
2015-06-01 22:58:29 +08:00
return ELF::R_MIPS_TLS_TPREL_HI16;
case Mips::fixup_Mips_TPREL_LO:
2015-06-01 22:58:29 +08:00
return ELF::R_MIPS_TLS_TPREL_LO16;
case Mips::fixup_Mips_TLSLDM:
2015-06-01 22:58:29 +08:00
return ELF::R_MIPS_TLS_LDM;
case Mips::fixup_Mips_DTPREL_HI:
2015-06-01 22:58:29 +08:00
return ELF::R_MIPS_TLS_DTPREL_HI16;
case Mips::fixup_Mips_DTPREL_LO:
2015-06-01 22:58:29 +08:00
return ELF::R_MIPS_TLS_DTPREL_LO16;
case Mips::fixup_Mips_GOT_PAGE:
2015-06-01 22:58:29 +08:00
return ELF::R_MIPS_GOT_PAGE;
case Mips::fixup_Mips_GOT_OFST:
2015-06-01 22:58:29 +08:00
return ELF::R_MIPS_GOT_OFST;
case Mips::fixup_Mips_GOT_DISP:
2015-06-01 22:58:29 +08:00
return ELF::R_MIPS_GOT_DISP;
case Mips::fixup_Mips_GPOFF_HI: {
unsigned Type = (unsigned)ELF::R_MIPS_NONE;
Type = setRType((unsigned)ELF::R_MIPS_GPREL16, Type);
Type = setRType2((unsigned)ELF::R_MIPS_SUB, Type);
Type = setRType3((unsigned)ELF::R_MIPS_HI16, Type);
2015-06-01 22:58:29 +08:00
return Type;
}
case Mips::fixup_Mips_GPOFF_LO: {
unsigned Type = (unsigned)ELF::R_MIPS_NONE;
Type = setRType((unsigned)ELF::R_MIPS_GPREL16, Type);
Type = setRType2((unsigned)ELF::R_MIPS_SUB, Type);
Type = setRType3((unsigned)ELF::R_MIPS_LO16, Type);
2015-06-01 22:58:29 +08:00
return Type;
}
case Mips::fixup_Mips_HIGHER:
2015-06-01 22:58:29 +08:00
return ELF::R_MIPS_HIGHER;
case Mips::fixup_Mips_HIGHEST:
2015-06-01 22:58:29 +08:00
return ELF::R_MIPS_HIGHEST;
case Mips::fixup_Mips_SUB:
return ELF::R_MIPS_SUB;
case Mips::fixup_Mips_GOT_HI16:
2015-06-01 22:58:29 +08:00
return ELF::R_MIPS_GOT_HI16;
case Mips::fixup_Mips_GOT_LO16:
2015-06-01 22:58:29 +08:00
return ELF::R_MIPS_GOT_LO16;
case Mips::fixup_Mips_CALL_HI16:
2015-06-01 22:58:29 +08:00
return ELF::R_MIPS_CALL_HI16;
case Mips::fixup_Mips_CALL_LO16:
2015-06-01 22:58:29 +08:00
return ELF::R_MIPS_CALL_LO16;
case Mips::fixup_MICROMIPS_26_S1:
2015-06-01 22:58:29 +08:00
return ELF::R_MICROMIPS_26_S1;
case Mips::fixup_MICROMIPS_HI16:
2015-06-01 22:58:29 +08:00
return ELF::R_MICROMIPS_HI16;
case Mips::fixup_MICROMIPS_LO16:
2015-06-01 22:58:29 +08:00
return ELF::R_MICROMIPS_LO16;
case Mips::fixup_MICROMIPS_GOT16:
2015-06-01 22:58:29 +08:00
return ELF::R_MICROMIPS_GOT16;
case Mips::fixup_MICROMIPS_CALL16:
2015-06-01 22:58:29 +08:00
return ELF::R_MICROMIPS_CALL16;
case Mips::fixup_MICROMIPS_GOT_DISP:
2015-06-01 22:58:29 +08:00
return ELF::R_MICROMIPS_GOT_DISP;
case Mips::fixup_MICROMIPS_GOT_PAGE:
2015-06-01 22:58:29 +08:00
return ELF::R_MICROMIPS_GOT_PAGE;
case Mips::fixup_MICROMIPS_GOT_OFST:
2015-06-01 22:58:29 +08:00
return ELF::R_MICROMIPS_GOT_OFST;
case Mips::fixup_MICROMIPS_TLS_GD:
2015-06-01 22:58:29 +08:00
return ELF::R_MICROMIPS_TLS_GD;
case Mips::fixup_MICROMIPS_TLS_LDM:
2015-06-01 22:58:29 +08:00
return ELF::R_MICROMIPS_TLS_LDM;
case Mips::fixup_MICROMIPS_TLS_DTPREL_HI16:
2015-06-01 22:58:29 +08:00
return ELF::R_MICROMIPS_TLS_DTPREL_HI16;
case Mips::fixup_MICROMIPS_TLS_DTPREL_LO16:
2015-06-01 22:58:29 +08:00
return ELF::R_MICROMIPS_TLS_DTPREL_LO16;
case Mips::fixup_MICROMIPS_GOTTPREL:
return ELF::R_MICROMIPS_TLS_GOTTPREL;
case Mips::fixup_MICROMIPS_TLS_TPREL_HI16:
2015-06-01 22:58:29 +08:00
return ELF::R_MICROMIPS_TLS_TPREL_HI16;
case Mips::fixup_MICROMIPS_TLS_TPREL_LO16:
2015-06-01 22:58:29 +08:00
return ELF::R_MICROMIPS_TLS_TPREL_LO16;
case Mips::fixup_MICROMIPS_SUB:
return ELF::R_MICROMIPS_SUB;
}
2015-06-01 22:58:29 +08:00
llvm_unreachable("invalid fixup kind!");
}
[mips] Correct the ordering of HI/LO pairs in the relocation table. Summary: There seems to have been a misunderstanding as to the meaning of 'offset' in the rules laid down by our ABI. The previous code believed that 'offset' meant the offset within the section that the relocation is applied to. However, it should have meant the offset from the symbol used in the relocation expression. This patch adds two fields to ELFRelocationEntry and uses them to correct the order of relocations for MIPS. These fields contain: * The original symbol before shouldRelocateWithSymbol() is considered. This ensures that R_MIPS_GOT16 is able to correctly distinguish between local and external symbols, allowing us to tell whether %got() requires a matching %lo() or not (local symbols require one, external symbols don't). It also prevents confusing cases where the fuzzy matching rules cause things like %hi(foo)/%lo(foo+3) and %hi(bar)/%lo(bar+1) to swap their %lo()'s. * The original offset before shouldRelocateWithSymbol() is considered. The existing Addend field is always zero when the object uses in place addends (because it's already moved it to the encoding) but MIPS needs to use the original offset to ensure that the linker correctly calculates the carry-in bit for %hi() and %got(). IAS ensures that unmatchable %hi()/%got() relocations are placed at the end of the table to ensure that the linker rejects the table (we're unable to report such errors directly). The alternatives to this risk accidental matching against inappropriate relocations which may silently compute incorrect values due to an incorrect carry bit between the %lo() and %hi()/%got(). Reviewers: sdardis Subscribers: dsanders, sdardis, rafael, llvm-commits Differential Revision: http://reviews.llvm.org/D19718 llvm-svn: 268733
2016-05-06 21:49:25 +08:00
/// Sort relocation table entries by offset except where another order is
/// required by the MIPS ABI.
///
/// MIPS has a few relocations that have an AHL component in the expression used
/// to evaluate them. This AHL component is an addend with the same number of
/// bits as a symbol value but not all of our ABI's are able to supply a
/// sufficiently sized addend in a single relocation.
///
/// The O32 ABI for example, uses REL relocations which store the addend in the
/// section data. All the relocations with AHL components affect 16-bit fields
/// so the addend for a single relocation is limited to 16-bit. This ABI
/// resolves the limitation by linking relocations (e.g. R_MIPS_HI16 and
/// R_MIPS_LO16) and distributing the addend between the linked relocations. The
/// ABI mandates that such relocations must be next to each other in a
/// particular order (e.g. R_MIPS_HI16 must be immediately followed by a
/// matching R_MIPS_LO16) but the rule is less strict in practice.
///
/// The de facto standard is lenient in the following ways:
/// - 'Immediately following' does not refer to the next relocation entry but
/// the next matching relocation.
/// - There may be multiple high parts relocations for one low part relocation.
/// - There may be multiple low part relocations for one high part relocation.
/// - The AHL addend in each part does not have to be exactly equal as long as
/// the difference does not affect the carry bit from bit 15 into 16. This is
/// to allow, for example, the use of %lo(foo) and %lo(foo+4) when loading
/// both halves of a long long.
///
/// See getMatchingLoType() for a description of which high part relocations
/// match which low part relocations. One particular thing to note is that
/// R_MIPS_GOT16 and similar only have AHL addends if they refer to local
/// symbols.
///
/// It should also be noted that this function is not affected by whether
/// the symbol was kept or rewritten into a section-relative equivalent. We
/// always match using the expressions from the source.
void MipsELFObjectWriter::sortRelocs(const MCAssembler &Asm,
std::vector<ELFRelocationEntry> &Relocs) {
// We do not need to sort the relocation table for RELA relocations which
// N32/N64 uses as the relocation addend contains the value we require,
// rather than it being split across a pair of relocations.
if (hasRelocationAddend())
return;
if (Relocs.size() < 2)
return;
[mips] Correct the ordering of HI/LO pairs in the relocation table. Summary: There seems to have been a misunderstanding as to the meaning of 'offset' in the rules laid down by our ABI. The previous code believed that 'offset' meant the offset within the section that the relocation is applied to. However, it should have meant the offset from the symbol used in the relocation expression. This patch adds two fields to ELFRelocationEntry and uses them to correct the order of relocations for MIPS. These fields contain: * The original symbol before shouldRelocateWithSymbol() is considered. This ensures that R_MIPS_GOT16 is able to correctly distinguish between local and external symbols, allowing us to tell whether %got() requires a matching %lo() or not (local symbols require one, external symbols don't). It also prevents confusing cases where the fuzzy matching rules cause things like %hi(foo)/%lo(foo+3) and %hi(bar)/%lo(bar+1) to swap their %lo()'s. * The original offset before shouldRelocateWithSymbol() is considered. The existing Addend field is always zero when the object uses in place addends (because it's already moved it to the encoding) but MIPS needs to use the original offset to ensure that the linker correctly calculates the carry-in bit for %hi() and %got(). IAS ensures that unmatchable %hi()/%got() relocations are placed at the end of the table to ensure that the linker rejects the table (we're unable to report such errors directly). The alternatives to this risk accidental matching against inappropriate relocations which may silently compute incorrect values due to an incorrect carry bit between the %lo() and %hi()/%got(). Reviewers: sdardis Subscribers: dsanders, sdardis, rafael, llvm-commits Differential Revision: http://reviews.llvm.org/D19718 llvm-svn: 268733
2016-05-06 21:49:25 +08:00
// Sort relocations by the address they are applied to.
std::sort(Relocs.begin(), Relocs.end(),
[](const ELFRelocationEntry &A, const ELFRelocationEntry &B) {
return A.Offset < B.Offset;
});
std::list<MipsRelocationEntry> Sorted;
std::list<ELFRelocationEntry> Remainder;
DEBUG(dumpRelocs("R: ", Relocs));
// Separate the movable relocations (AHL relocations using the high bits) from
// the immobile relocations (everything else). This does not preserve high/low
// matches that already existed in the input.
copy_if_else(Relocs.begin(), Relocs.end(), std::back_inserter(Remainder),
std::back_inserter(Sorted), [](const ELFRelocationEntry &Reloc) {
return getMatchingLoType(Reloc) != ELF::R_MIPS_NONE;
});
for (auto &R : Remainder) {
DEBUG(dbgs() << "Matching: " << R << "\n");
unsigned MatchingType = getMatchingLoType(R);
assert(MatchingType != ELF::R_MIPS_NONE &&
"Wrong list for reloc that doesn't need a match");
// Find the best matching relocation for the current high part.
// See isMatchingReloc for a description of a matching relocation and
// compareMatchingRelocs for a description of what 'best' means.
auto InsertionPoint =
find_best(Sorted.begin(), Sorted.end(),
[&R, &MatchingType](const MipsRelocationEntry &X) {
return isMatchingReloc(X, R, MatchingType);
},
compareMatchingRelocs);
// If we matched then insert the high part in front of the match and mark
// both relocations as being involved in a match. We only mark the high
// part for cosmetic reasons in the debug output.
//
// If we failed to find a match then the high part is orphaned. This is not
// permitted since the relocation cannot be evaluated without knowing the
// carry-in. We can sometimes handle this using a matching low part that is
// already used in a match but we already cover that case in
// isMatchingReloc and compareMatchingRelocs. For the remaining cases we
// should insert the high part at the end of the list. This will cause the
// linker to fail but the alternative is to cause the linker to bind the
// high part to a semi-matching low part and silently calculate the wrong
// value. Unfortunately we have no means to warn the user that we did this
// so leave it up to the linker to complain about it.
if (InsertionPoint != Sorted.end())
InsertionPoint->Matched = true;
Sorted.insert(InsertionPoint, R)->Matched = true;
}
[mips] Correct the ordering of HI/LO pairs in the relocation table. Summary: There seems to have been a misunderstanding as to the meaning of 'offset' in the rules laid down by our ABI. The previous code believed that 'offset' meant the offset within the section that the relocation is applied to. However, it should have meant the offset from the symbol used in the relocation expression. This patch adds two fields to ELFRelocationEntry and uses them to correct the order of relocations for MIPS. These fields contain: * The original symbol before shouldRelocateWithSymbol() is considered. This ensures that R_MIPS_GOT16 is able to correctly distinguish between local and external symbols, allowing us to tell whether %got() requires a matching %lo() or not (local symbols require one, external symbols don't). It also prevents confusing cases where the fuzzy matching rules cause things like %hi(foo)/%lo(foo+3) and %hi(bar)/%lo(bar+1) to swap their %lo()'s. * The original offset before shouldRelocateWithSymbol() is considered. The existing Addend field is always zero when the object uses in place addends (because it's already moved it to the encoding) but MIPS needs to use the original offset to ensure that the linker correctly calculates the carry-in bit for %hi() and %got(). IAS ensures that unmatchable %hi()/%got() relocations are placed at the end of the table to ensure that the linker rejects the table (we're unable to report such errors directly). The alternatives to this risk accidental matching against inappropriate relocations which may silently compute incorrect values due to an incorrect carry bit between the %lo() and %hi()/%got(). Reviewers: sdardis Subscribers: dsanders, sdardis, rafael, llvm-commits Differential Revision: http://reviews.llvm.org/D19718 llvm-svn: 268733
2016-05-06 21:49:25 +08:00
DEBUG(dumpRelocs("S: ", Sorted));
assert(Relocs.size() == Sorted.size() && "Some relocs were not consumed");
[mips] Correct the ordering of HI/LO pairs in the relocation table. Summary: There seems to have been a misunderstanding as to the meaning of 'offset' in the rules laid down by our ABI. The previous code believed that 'offset' meant the offset within the section that the relocation is applied to. However, it should have meant the offset from the symbol used in the relocation expression. This patch adds two fields to ELFRelocationEntry and uses them to correct the order of relocations for MIPS. These fields contain: * The original symbol before shouldRelocateWithSymbol() is considered. This ensures that R_MIPS_GOT16 is able to correctly distinguish between local and external symbols, allowing us to tell whether %got() requires a matching %lo() or not (local symbols require one, external symbols don't). It also prevents confusing cases where the fuzzy matching rules cause things like %hi(foo)/%lo(foo+3) and %hi(bar)/%lo(bar+1) to swap their %lo()'s. * The original offset before shouldRelocateWithSymbol() is considered. The existing Addend field is always zero when the object uses in place addends (because it's already moved it to the encoding) but MIPS needs to use the original offset to ensure that the linker correctly calculates the carry-in bit for %hi() and %got(). IAS ensures that unmatchable %hi()/%got() relocations are placed at the end of the table to ensure that the linker rejects the table (we're unable to report such errors directly). The alternatives to this risk accidental matching against inappropriate relocations which may silently compute incorrect values due to an incorrect carry bit between the %lo() and %hi()/%got(). Reviewers: sdardis Subscribers: dsanders, sdardis, rafael, llvm-commits Differential Revision: http://reviews.llvm.org/D19718 llvm-svn: 268733
2016-05-06 21:49:25 +08:00
// Overwrite the original vector with the sorted elements. The caller expects
// them in reverse order.
unsigned CopyTo = 0;
for (const auto &R : reverse(Sorted))
Relocs[CopyTo++] = R.R;
}
bool MipsELFObjectWriter::needsRelocateWithSymbol(const MCSymbol &Sym,
unsigned Type) const {
// If it's a compound relocation for N64 then we need the relocation if any
// sub-relocation needs it.
if (!isUInt<8>(Type))
return needsRelocateWithSymbol(Sym, Type & 0xff) ||
needsRelocateWithSymbol(Sym, (Type >> 8) & 0xff) ||
needsRelocateWithSymbol(Sym, (Type >> 16) & 0xff);
switch (Type) {
default:
errs() << Type << "\n";
llvm_unreachable("Unexpected relocation");
return true;
// This relocation doesn't affect the section data.
case ELF::R_MIPS_NONE:
return false;
// On REL ABI's (e.g. O32), these relocations form pairs. The pairing is done
// by the static linker by matching the symbol and offset.
// We only see one relocation at a time but it's still safe to relocate with
// the section so long as both relocations make the same decision.
//
// Some older linkers may require the symbol for particular cases. Such cases
// are not supported yet but can be added as required.
case ELF::R_MIPS_GOT16:
case ELF::R_MIPS16_GOT16:
case ELF::R_MICROMIPS_GOT16:
case ELF::R_MIPS_HIGHER:
case ELF::R_MIPS_HIGHEST:
case ELF::R_MIPS_HI16:
case ELF::R_MIPS16_HI16:
case ELF::R_MICROMIPS_HI16:
case ELF::R_MIPS_LO16:
case ELF::R_MIPS16_LO16:
case ELF::R_MICROMIPS_LO16:
// FIXME: It should be safe to return false for the STO_MIPS_MICROMIPS but
// we neglect to handle the adjustment to the LSB of the addend that
// it causes in applyFixup() and similar.
if (cast<MCSymbolELF>(Sym).getOther() & ELF::STO_MIPS_MICROMIPS)
return true;
return false;
case ELF::R_MIPS_GOT_PAGE:
case ELF::R_MICROMIPS_GOT_PAGE:
case ELF::R_MIPS_GOT_OFST:
case ELF::R_MICROMIPS_GOT_OFST:
case ELF::R_MIPS_16:
case ELF::R_MIPS_32:
case ELF::R_MIPS_GPREL32:
if (cast<MCSymbolELF>(Sym).getOther() & ELF::STO_MIPS_MICROMIPS)
return true;
LLVM_FALLTHROUGH;
case ELF::R_MIPS_26:
case ELF::R_MIPS_64:
case ELF::R_MIPS_GPREL16:
case ELF::R_MIPS_PC16:
case ELF::R_MIPS_SUB:
return false;
// FIXME: Many of these relocations should probably return false but this
// hasn't been confirmed to be safe yet.
case ELF::R_MIPS_REL32:
case ELF::R_MIPS_LITERAL:
case ELF::R_MIPS_CALL16:
case ELF::R_MIPS_SHIFT5:
case ELF::R_MIPS_SHIFT6:
case ELF::R_MIPS_GOT_DISP:
case ELF::R_MIPS_GOT_HI16:
case ELF::R_MIPS_GOT_LO16:
case ELF::R_MIPS_INSERT_A:
case ELF::R_MIPS_INSERT_B:
case ELF::R_MIPS_DELETE:
case ELF::R_MIPS_CALL_HI16:
case ELF::R_MIPS_CALL_LO16:
case ELF::R_MIPS_SCN_DISP:
case ELF::R_MIPS_REL16:
case ELF::R_MIPS_ADD_IMMEDIATE:
case ELF::R_MIPS_PJUMP:
case ELF::R_MIPS_RELGOT:
case ELF::R_MIPS_JALR:
case ELF::R_MIPS_TLS_DTPMOD32:
case ELF::R_MIPS_TLS_DTPREL32:
case ELF::R_MIPS_TLS_DTPMOD64:
case ELF::R_MIPS_TLS_DTPREL64:
case ELF::R_MIPS_TLS_GD:
case ELF::R_MIPS_TLS_LDM:
case ELF::R_MIPS_TLS_DTPREL_HI16:
case ELF::R_MIPS_TLS_DTPREL_LO16:
case ELF::R_MIPS_TLS_GOTTPREL:
case ELF::R_MIPS_TLS_TPREL32:
case ELF::R_MIPS_TLS_TPREL64:
case ELF::R_MIPS_TLS_TPREL_HI16:
case ELF::R_MIPS_TLS_TPREL_LO16:
case ELF::R_MIPS_GLOB_DAT:
case ELF::R_MIPS_PC21_S2:
case ELF::R_MIPS_PC26_S2:
case ELF::R_MIPS_PC18_S3:
case ELF::R_MIPS_PC19_S2:
case ELF::R_MIPS_PCHI16:
case ELF::R_MIPS_PCLO16:
case ELF::R_MIPS_COPY:
case ELF::R_MIPS_JUMP_SLOT:
case ELF::R_MIPS_NUM:
case ELF::R_MIPS_PC32:
case ELF::R_MIPS_EH:
case ELF::R_MICROMIPS_26_S1:
case ELF::R_MICROMIPS_GPREL16:
case ELF::R_MICROMIPS_LITERAL:
case ELF::R_MICROMIPS_PC7_S1:
case ELF::R_MICROMIPS_PC10_S1:
case ELF::R_MICROMIPS_PC16_S1:
case ELF::R_MICROMIPS_CALL16:
case ELF::R_MICROMIPS_GOT_DISP:
case ELF::R_MICROMIPS_GOT_HI16:
case ELF::R_MICROMIPS_GOT_LO16:
case ELF::R_MICROMIPS_SUB:
case ELF::R_MICROMIPS_HIGHER:
case ELF::R_MICROMIPS_HIGHEST:
case ELF::R_MICROMIPS_CALL_HI16:
case ELF::R_MICROMIPS_CALL_LO16:
case ELF::R_MICROMIPS_SCN_DISP:
case ELF::R_MICROMIPS_JALR:
case ELF::R_MICROMIPS_HI0_LO16:
case ELF::R_MICROMIPS_TLS_GD:
case ELF::R_MICROMIPS_TLS_LDM:
case ELF::R_MICROMIPS_TLS_DTPREL_HI16:
case ELF::R_MICROMIPS_TLS_DTPREL_LO16:
case ELF::R_MICROMIPS_TLS_GOTTPREL:
case ELF::R_MICROMIPS_TLS_TPREL_HI16:
case ELF::R_MICROMIPS_TLS_TPREL_LO16:
case ELF::R_MICROMIPS_GPREL7_S2:
case ELF::R_MICROMIPS_PC23_S2:
case ELF::R_MICROMIPS_PC21_S1:
case ELF::R_MICROMIPS_PC26_S1:
case ELF::R_MICROMIPS_PC18_S3:
case ELF::R_MICROMIPS_PC19_S2:
return true;
// FIXME: Many of these should probably return false but MIPS16 isn't
// supported by the integrated assembler.
case ELF::R_MIPS16_26:
case ELF::R_MIPS16_GPREL:
case ELF::R_MIPS16_CALL16:
case ELF::R_MIPS16_TLS_GD:
case ELF::R_MIPS16_TLS_LDM:
case ELF::R_MIPS16_TLS_DTPREL_HI16:
case ELF::R_MIPS16_TLS_DTPREL_LO16:
case ELF::R_MIPS16_TLS_GOTTPREL:
case ELF::R_MIPS16_TLS_TPREL_HI16:
case ELF::R_MIPS16_TLS_TPREL_LO16:
llvm_unreachable("Unsupported MIPS16 relocation");
return true;
}
}
MCObjectWriter *llvm::createMipsELFObjectWriter(raw_pwrite_stream &OS,
const Triple &TT) {
uint8_t OSABI = MCELFObjectTargetWriter::getOSABI(TT.getOS());
// FIXME: We need to check an actual ABI. mips64/mips64el do not
// always imply the N64 ABI and RELA relocation's format.
bool IsN64 = TT.isArch64Bit();
bool HasRelocationAddend = IsN64;
auto *MOTW = new MipsELFObjectWriter(OSABI, HasRelocationAddend, IsN64,
TT.isLittleEndian());
return createELFObjectWriter(MOTW, OS, TT.isLittleEndian());
}