2010-06-16 20:04:22 +00:00
|
|
|
//===- lib/MC/MCObjectStreamer.cpp - Object File MCStreamer Interface -----===//
|
|
|
|
//
|
2019-01-19 08:50:56 +00:00
|
|
|
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
|
|
|
|
// See https://llvm.org/LICENSE.txt for license information.
|
|
|
|
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
|
2010-06-16 20:04:22 +00:00
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "llvm/MC/MCObjectStreamer.h"
|
2013-04-17 21:18:16 +00:00
|
|
|
#include "llvm/ADT/STLExtras.h"
|
2012-03-26 06:58:25 +00:00
|
|
|
#include "llvm/MC/MCAsmBackend.h"
|
2021-03-04 20:47:41 -05:00
|
|
|
#include "llvm/MC/MCAsmInfo.h"
|
2010-06-16 20:04:22 +00:00
|
|
|
#include "llvm/MC/MCAssembler.h"
|
2010-07-29 17:48:06 +00:00
|
|
|
#include "llvm/MC/MCCodeEmitter.h"
|
2016-08-26 17:58:37 +00:00
|
|
|
#include "llvm/MC/MCCodeView.h"
|
2010-12-10 07:39:47 +00:00
|
|
|
#include "llvm/MC/MCContext.h"
|
2010-11-01 16:27:31 +00:00
|
|
|
#include "llvm/MC/MCDwarf.h"
|
2010-07-19 06:13:10 +00:00
|
|
|
#include "llvm/MC/MCExpr.h"
|
2021-03-04 20:47:41 -05:00
|
|
|
#include "llvm/MC/MCObjectFileInfo.h"
|
2012-03-26 06:58:25 +00:00
|
|
|
#include "llvm/MC/MCObjectWriter.h"
|
2013-06-27 14:35:03 +00:00
|
|
|
#include "llvm/MC/MCSection.h"
|
2014-01-07 11:48:04 +00:00
|
|
|
#include "llvm/MC/MCSymbol.h"
|
2020-07-14 13:44:00 -07:00
|
|
|
#include "llvm/MC/MCValue.h"
|
2012-03-26 06:58:25 +00:00
|
|
|
#include "llvm/Support/ErrorHandling.h"
|
2016-05-28 05:57:48 +00:00
|
|
|
#include "llvm/Support/SourceMgr.h"
|
2010-06-16 20:04:22 +00:00
|
|
|
using namespace llvm;
|
|
|
|
|
2017-10-11 01:57:21 +00:00
|
|
|
MCObjectStreamer::MCObjectStreamer(MCContext &Context,
|
|
|
|
std::unique_ptr<MCAsmBackend> TAB,
|
2018-05-18 18:26:45 +00:00
|
|
|
std::unique_ptr<MCObjectWriter> OW,
|
2017-10-11 23:34:47 +00:00
|
|
|
std::unique_ptr<MCCodeEmitter> Emitter)
|
2018-04-27 15:45:27 +00:00
|
|
|
: MCStreamer(Context),
|
2019-08-15 15:54:37 +00:00
|
|
|
Assembler(std::make_unique<MCAssembler>(
|
2018-05-18 18:26:45 +00:00
|
|
|
Context, std::move(TAB), std::move(Emitter), std::move(OW))),
|
2020-01-08 09:58:42 -08:00
|
|
|
EmitEHFrame(true), EmitDebugFrame(false) {
|
|
|
|
if (Assembler->getBackendPtr())
|
|
|
|
setAllowAutoPadding(Assembler->getBackend().allowAutoPadding());
|
|
|
|
}
|
2010-06-16 20:04:22 +00:00
|
|
|
|
2017-10-11 23:34:47 +00:00
|
|
|
MCObjectStreamer::~MCObjectStreamer() {}
|
2010-06-16 20:04:25 +00:00
|
|
|
|
[MC] Change AsmParser to leverage Assembler during evaluation
Teach AsmParser to check with Assembler for when evaluating constant
expressions. This improves the handing of preprocessor expressions
that must be resolved at parse time. This idiom can be found as
assembling-time assertion checks in source-level assemblers. Note that
this relies on the MCStreamer to keep sufficient tabs on Section /
Fragment information which the MCAsmStreamer does not. As a result the
textual output may fail where the equivalent object generation would
pass. This can most easily be resolved by folding the MCAsmStreamer
and MCObjectStreamer together which is planned for in a separate
patch.
Currently, this feature is only enabled for assembly input, keeping IR
compilation consistent between assembly and object generation.
Reviewers: echristo, rnk, probinson, espindola, peter.smith
Reviewed By: peter.smith
Subscribers: eraman, peter.smith, arichardson, jyknight, hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D45164
llvm-svn: 331218
2018-04-30 19:22:40 +00:00
|
|
|
// AssemblerPtr is used for evaluation of expressions and causes
|
|
|
|
// difference between asm and object outputs. Return nullptr to in
|
|
|
|
// inline asm mode to limit divergence to assembly inputs.
|
|
|
|
MCAssembler *MCObjectStreamer::getAssemblerPtr() {
|
|
|
|
if (getUseAssemblerInfoForParsing())
|
|
|
|
return Assembler.get();
|
|
|
|
return nullptr;
|
|
|
|
}
|
|
|
|
|
[ MC ] Match labels to existing fragments even when switching sections.
(This commit restores the original branch (4272372c571) and applies an
additional change dropped from the original in a bad merge. This change
should address the previous bot failures. Both changes reviewed by pete.)
Summary:
This commit builds upon Derek Schuff's 2014 commit for attaching labels to
existing fragments ( Diff Revision: http://reviews.llvm.org/D5915 )
When temporary labels appear ahead of a fragment, MCObjectStreamer will
track the temporary label symbol in a "Pending Labels" list. Labels are
associated with fragments when a real fragment arrives; otherwise, an empty
data fragment will be created if the streamer's section changes or if the
stream finishes.
This commit moves the "Pending Labels" list into each MCStream, so that
this label-fragment matching process is resilient to section changes. If
the streamer emits a label in a new section, switches to another section to
do other work, then switches back to the first section and emits a
fragment, that initial label will be associated with this new fragment.
Labels will only receive empty data fragments in the case where no other
fragment exists for that section.
The downstream effects of this can be seen in Mach-O relocations. The
previous approach could produce local section relocations and external
symbol relocations for the same data in an object file, and this mix of
relocation types resulted in problems in the ld64 Mach-O linker. This
commit ensures relocations triggered by temporary labels are consistent.
Reviewers: pete, ab, dschuff
Reviewed By: pete, dschuff
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71368
2019-12-11 10:42:37 -08:00
|
|
|
void MCObjectStreamer::addPendingLabel(MCSymbol* S) {
|
|
|
|
MCSection *CurSection = getCurrentSectionOnly();
|
|
|
|
if (CurSection) {
|
|
|
|
// Register labels that have not yet been assigned to a Section.
|
|
|
|
if (!PendingLabels.empty()) {
|
|
|
|
for (MCSymbol* Sym : PendingLabels)
|
|
|
|
CurSection->addPendingLabel(Sym);
|
|
|
|
PendingLabels.clear();
|
|
|
|
}
|
|
|
|
|
|
|
|
// Add this label to the current Section / Subsection.
|
|
|
|
CurSection->addPendingLabel(S, CurSubsectionIdx);
|
|
|
|
|
|
|
|
// Add this Section to the list of PendingLabelSections.
|
2020-04-26 10:39:30 -04:00
|
|
|
PendingLabelSections.insert(CurSection);
|
|
|
|
} else
|
[ MC ] Match labels to existing fragments even when switching sections.
(This commit restores the original branch (4272372c571) and applies an
additional change dropped from the original in a bad merge. This change
should address the previous bot failures. Both changes reviewed by pete.)
Summary:
This commit builds upon Derek Schuff's 2014 commit for attaching labels to
existing fragments ( Diff Revision: http://reviews.llvm.org/D5915 )
When temporary labels appear ahead of a fragment, MCObjectStreamer will
track the temporary label symbol in a "Pending Labels" list. Labels are
associated with fragments when a real fragment arrives; otherwise, an empty
data fragment will be created if the streamer's section changes or if the
stream finishes.
This commit moves the "Pending Labels" list into each MCStream, so that
this label-fragment matching process is resilient to section changes. If
the streamer emits a label in a new section, switches to another section to
do other work, then switches back to the first section and emits a
fragment, that initial label will be associated with this new fragment.
Labels will only receive empty data fragments in the case where no other
fragment exists for that section.
The downstream effects of this can be seen in Mach-O relocations. The
previous approach could produce local section relocations and external
symbol relocations for the same data in an object file, and this mix of
relocation types resulted in problems in the ld64 Mach-O linker. This
commit ensures relocations triggered by temporary labels are consistent.
Reviewers: pete, ab, dschuff
Reviewed By: pete, dschuff
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71368
2019-12-11 10:42:37 -08:00
|
|
|
// There is no Section / Subsection for this label yet.
|
|
|
|
PendingLabels.push_back(S);
|
|
|
|
}
|
|
|
|
|
2015-04-12 23:42:25 +00:00
|
|
|
void MCObjectStreamer::flushPendingLabels(MCFragment *F, uint64_t FOffset) {
|
[ MC ] Match labels to existing fragments even when switching sections.
(This commit restores the original branch (4272372c571) and applies an
additional change dropped from the original in a bad merge. This change
should address the previous bot failures. Both changes reviewed by pete.)
Summary:
This commit builds upon Derek Schuff's 2014 commit for attaching labels to
existing fragments ( Diff Revision: http://reviews.llvm.org/D5915 )
When temporary labels appear ahead of a fragment, MCObjectStreamer will
track the temporary label symbol in a "Pending Labels" list. Labels are
associated with fragments when a real fragment arrives; otherwise, an empty
data fragment will be created if the streamer's section changes or if the
stream finishes.
This commit moves the "Pending Labels" list into each MCStream, so that
this label-fragment matching process is resilient to section changes. If
the streamer emits a label in a new section, switches to another section to
do other work, then switches back to the first section and emits a
fragment, that initial label will be associated with this new fragment.
Labels will only receive empty data fragments in the case where no other
fragment exists for that section.
The downstream effects of this can be seen in Mach-O relocations. The
previous approach could produce local section relocations and external
symbol relocations for the same data in an object file, and this mix of
relocation types resulted in problems in the ld64 Mach-O linker. This
commit ensures relocations triggered by temporary labels are consistent.
Reviewers: pete, ab, dschuff
Reviewed By: pete, dschuff
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71368
2019-12-11 10:42:37 -08:00
|
|
|
MCSection *CurSection = getCurrentSectionOnly();
|
|
|
|
if (!CurSection) {
|
|
|
|
assert(PendingLabels.empty());
|
2015-10-03 00:57:12 +00:00
|
|
|
return;
|
[ MC ] Match labels to existing fragments even when switching sections.
Summary:
This commit builds upon Derek Schuff's 2014 commit for attaching labels to
existing fragments ( Diff Revision: http://reviews.llvm.org/D5915 )
When temporary labels appear ahead of a fragment, MCObjectStreamer will
track the temporary label symbol in a "Pending Labels" list. Labels are
associated with fragments when a real fragment arrives; otherwise, an empty
data fragment will be created if the streamer's section changes or if the
stream finishes.
This commit moves the "Pending Labels" list into each MCStream, so that
this label-fragment matching process is resilient to section changes. If
the streamer emits a label in a new section, switches to another section to
do other work, then switches back to the first section and emits a
fragment, that initial label will be associated with this new fragment.
Labels will only receive empty data fragments in the case where no other
fragment exists for that section.
The downstream effects of this can be seen in Mach-O relocations. The
previous approach could produce local section relocations and external
symbol relocations for the same data in an object file, and this mix of
relocation types resulted in problems in the ld64 Mach-O linker. This
commit ensures relocations triggered by temporary labels are consistent.
Reviewers: pete, ab, dschuff
Reviewed By: pete, dschuff
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71368
2019-12-11 10:42:37 -08:00
|
|
|
}
|
[ MC ] Match labels to existing fragments even when switching sections.
(This commit restores the original branch (4272372c571) and applies an
additional change dropped from the original in a bad merge. This change
should address the previous bot failures. Both changes reviewed by pete.)
Summary:
This commit builds upon Derek Schuff's 2014 commit for attaching labels to
existing fragments ( Diff Revision: http://reviews.llvm.org/D5915 )
When temporary labels appear ahead of a fragment, MCObjectStreamer will
track the temporary label symbol in a "Pending Labels" list. Labels are
associated with fragments when a real fragment arrives; otherwise, an empty
data fragment will be created if the streamer's section changes or if the
stream finishes.
This commit moves the "Pending Labels" list into each MCStream, so that
this label-fragment matching process is resilient to section changes. If
the streamer emits a label in a new section, switches to another section to
do other work, then switches back to the first section and emits a
fragment, that initial label will be associated with this new fragment.
Labels will only receive empty data fragments in the case where no other
fragment exists for that section.
The downstream effects of this can be seen in Mach-O relocations. The
previous approach could produce local section relocations and external
symbol relocations for the same data in an object file, and this mix of
relocation types resulted in problems in the ld64 Mach-O linker. This
commit ensures relocations triggered by temporary labels are consistent.
Reviewers: pete, ab, dschuff
Reviewed By: pete, dschuff
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71368
2019-12-11 10:42:37 -08:00
|
|
|
// Register labels that have not yet been assigned to a Section.
|
|
|
|
if (!PendingLabels.empty()) {
|
|
|
|
for (MCSymbol* Sym : PendingLabels)
|
|
|
|
CurSection->addPendingLabel(Sym, CurSubsectionIdx);
|
|
|
|
PendingLabels.clear();
|
2019-12-17 15:03:10 -08:00
|
|
|
}
|
[ MC ] Match labels to existing fragments even when switching sections.
(This commit restores the original branch (4272372c571) and applies an
additional change dropped from the original in a bad merge. This change
should address the previous bot failures. Both changes reviewed by pete.)
Summary:
This commit builds upon Derek Schuff's 2014 commit for attaching labels to
existing fragments ( Diff Revision: http://reviews.llvm.org/D5915 )
When temporary labels appear ahead of a fragment, MCObjectStreamer will
track the temporary label symbol in a "Pending Labels" list. Labels are
associated with fragments when a real fragment arrives; otherwise, an empty
data fragment will be created if the streamer's section changes or if the
stream finishes.
This commit moves the "Pending Labels" list into each MCStream, so that
this label-fragment matching process is resilient to section changes. If
the streamer emits a label in a new section, switches to another section to
do other work, then switches back to the first section and emits a
fragment, that initial label will be associated with this new fragment.
Labels will only receive empty data fragments in the case where no other
fragment exists for that section.
The downstream effects of this can be seen in Mach-O relocations. The
previous approach could produce local section relocations and external
symbol relocations for the same data in an object file, and this mix of
relocation types resulted in problems in the ld64 Mach-O linker. This
commit ensures relocations triggered by temporary labels are consistent.
Reviewers: pete, ab, dschuff
Reviewed By: pete, dschuff
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71368
2019-12-11 10:42:37 -08:00
|
|
|
|
|
|
|
// Associate a fragment with this label, either the supplied fragment
|
|
|
|
// or an empty data fragment.
|
|
|
|
if (F)
|
|
|
|
CurSection->flushPendingLabels(F, FOffset, CurSubsectionIdx);
|
|
|
|
else
|
|
|
|
CurSection->flushPendingLabels(nullptr, 0, CurSubsectionIdx);
|
|
|
|
}
|
|
|
|
|
|
|
|
void MCObjectStreamer::flushPendingLabels() {
|
|
|
|
// Register labels that have not yet been assigned to a Section.
|
|
|
|
if (!PendingLabels.empty()) {
|
|
|
|
MCSection *CurSection = getCurrentSectionOnly();
|
|
|
|
assert(CurSection);
|
|
|
|
for (MCSymbol* Sym : PendingLabels)
|
|
|
|
CurSection->addPendingLabel(Sym, CurSubsectionIdx);
|
|
|
|
PendingLabels.clear();
|
|
|
|
}
|
|
|
|
|
|
|
|
// Assign an empty data fragment to all remaining pending labels.
|
|
|
|
for (MCSection* Section : PendingLabelSections)
|
|
|
|
Section->flushPendingLabels();
|
2014-10-22 22:38:06 +00:00
|
|
|
}
|
|
|
|
|
2018-11-21 16:28:39 +00:00
|
|
|
// When fixup's offset is a forward declared label, e.g.:
|
|
|
|
//
|
|
|
|
// .reloc 1f, R_MIPS_JALR, foo
|
|
|
|
// 1: nop
|
|
|
|
//
|
|
|
|
// postpone adding it to Fixups vector until the label is defined and its offset
|
|
|
|
// is known.
|
|
|
|
void MCObjectStreamer::resolvePendingFixups() {
|
|
|
|
for (PendingMCFixup &PendingFixup : PendingFixups) {
|
|
|
|
if (!PendingFixup.Sym || PendingFixup.Sym->isUndefined ()) {
|
|
|
|
getContext().reportError(PendingFixup.Fixup.getLoc(),
|
|
|
|
"unresolved relocation offset");
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
flushPendingLabels(PendingFixup.DF, PendingFixup.DF->getContents().size());
|
|
|
|
PendingFixup.Fixup.setOffset(PendingFixup.Sym->getOffset());
|
|
|
|
PendingFixup.DF->getFixups().push_back(PendingFixup.Fixup);
|
|
|
|
}
|
|
|
|
PendingFixups.clear();
|
|
|
|
}
|
|
|
|
|
2018-02-09 17:00:25 +00:00
|
|
|
// As a compile-time optimization, avoid allocating and evaluating an MCExpr
|
|
|
|
// tree for (Hi - Lo) when Hi and Lo are offsets into the same fragment.
|
2021-05-26 15:41:11 +00:00
|
|
|
static Optional<uint64_t> absoluteSymbolDiff(const MCSymbol *Hi,
|
|
|
|
const MCSymbol *Lo) {
|
2018-03-15 21:24:04 +00:00
|
|
|
assert(Hi && Lo);
|
2018-02-09 17:00:25 +00:00
|
|
|
if (!Hi->getFragment() || Hi->getFragment() != Lo->getFragment() ||
|
|
|
|
Hi->isVariable() || Lo->isVariable())
|
|
|
|
return None;
|
|
|
|
|
|
|
|
return Hi->getOffset() - Lo->getOffset();
|
|
|
|
}
|
|
|
|
|
2015-06-11 18:58:08 +00:00
|
|
|
void MCObjectStreamer::emitAbsoluteSymbolDiff(const MCSymbol *Hi,
|
2015-05-21 02:41:23 +00:00
|
|
|
const MCSymbol *Lo,
|
|
|
|
unsigned Size) {
|
2021-05-26 15:41:11 +00:00
|
|
|
if (!getAssembler().getContext().getTargetTriple().isRISCV())
|
|
|
|
if (Optional<uint64_t> Diff = absoluteSymbolDiff(Hi, Lo))
|
|
|
|
return emitIntValue(*Diff, Size);
|
2018-02-09 17:00:25 +00:00
|
|
|
MCStreamer::emitAbsoluteSymbolDiff(Hi, Lo, Size);
|
|
|
|
}
|
2015-05-21 02:41:23 +00:00
|
|
|
|
2018-02-09 17:00:25 +00:00
|
|
|
void MCObjectStreamer::emitAbsoluteSymbolDiffAsULEB128(const MCSymbol *Hi,
|
|
|
|
const MCSymbol *Lo) {
|
2021-05-26 15:41:11 +00:00
|
|
|
if (!getAssembler().getContext().getTargetTriple().isRISCV())
|
|
|
|
if (Optional<uint64_t> Diff = absoluteSymbolDiff(Hi, Lo))
|
|
|
|
return emitULEB128IntValue(*Diff);
|
2018-02-09 17:00:25 +00:00
|
|
|
MCStreamer::emitAbsoluteSymbolDiffAsULEB128(Hi, Lo);
|
2015-05-21 02:41:23 +00:00
|
|
|
}
|
|
|
|
|
2012-12-12 22:59:46 +00:00
|
|
|
void MCObjectStreamer::reset() {
|
2012-12-14 18:52:11 +00:00
|
|
|
if (Assembler)
|
|
|
|
Assembler->reset();
|
2015-05-27 15:14:11 +00:00
|
|
|
CurInsertionPoint = MCSection::iterator();
|
2014-05-12 14:02:44 +00:00
|
|
|
EmitEHFrame = true;
|
|
|
|
EmitDebugFrame = false;
|
2014-10-22 22:38:06 +00:00
|
|
|
PendingLabels.clear();
|
[ MC ] Match labels to existing fragments even when switching sections.
(This commit restores the original branch (4272372c571) and applies an
additional change dropped from the original in a bad merge. This change
should address the previous bot failures. Both changes reviewed by pete.)
Summary:
This commit builds upon Derek Schuff's 2014 commit for attaching labels to
existing fragments ( Diff Revision: http://reviews.llvm.org/D5915 )
When temporary labels appear ahead of a fragment, MCObjectStreamer will
track the temporary label symbol in a "Pending Labels" list. Labels are
associated with fragments when a real fragment arrives; otherwise, an empty
data fragment will be created if the streamer's section changes or if the
stream finishes.
This commit moves the "Pending Labels" list into each MCStream, so that
this label-fragment matching process is resilient to section changes. If
the streamer emits a label in a new section, switches to another section to
do other work, then switches back to the first section and emits a
fragment, that initial label will be associated with this new fragment.
Labels will only receive empty data fragments in the case where no other
fragment exists for that section.
The downstream effects of this can be seen in Mach-O relocations. The
previous approach could produce local section relocations and external
symbol relocations for the same data in an object file, and this mix of
relocation types resulted in problems in the ld64 Mach-O linker. This
commit ensures relocations triggered by temporary labels are consistent.
Reviewers: pete, ab, dschuff
Reviewed By: pete, dschuff
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71368
2019-12-11 10:42:37 -08:00
|
|
|
PendingLabelSections.clear();
|
2012-12-12 22:59:46 +00:00
|
|
|
MCStreamer::reset();
|
|
|
|
}
|
|
|
|
|
2020-04-20 19:28:13 -07:00
|
|
|
void MCObjectStreamer::emitFrames(MCAsmBackend *MAB) {
|
2014-05-12 14:02:44 +00:00
|
|
|
if (!getNumFrameInfos())
|
|
|
|
return;
|
|
|
|
|
|
|
|
if (EmitEHFrame)
|
|
|
|
MCDwarfFrameEmitter::Emit(*this, MAB, true);
|
|
|
|
|
|
|
|
if (EmitDebugFrame)
|
|
|
|
MCDwarfFrameEmitter::Emit(*this, MAB, false);
|
|
|
|
}
|
|
|
|
|
2010-07-19 06:13:10 +00:00
|
|
|
MCFragment *MCObjectStreamer::getCurrentFragment() const {
|
2015-05-27 21:04:14 +00:00
|
|
|
assert(getCurrentSectionOnly() && "No current section!");
|
2010-07-19 06:13:10 +00:00
|
|
|
|
2015-05-27 21:04:14 +00:00
|
|
|
if (CurInsertionPoint != getCurrentSectionOnly()->getFragmentList().begin())
|
2015-10-10 00:13:11 +00:00
|
|
|
return &*std::prev(CurInsertionPoint);
|
2010-07-19 06:13:10 +00:00
|
|
|
|
2014-04-13 04:57:38 +00:00
|
|
|
return nullptr;
|
2010-07-19 06:13:10 +00:00
|
|
|
}
|
|
|
|
|
2020-05-09 12:47:44 +08:00
|
|
|
static bool canReuseDataFragment(const MCDataFragment &F,
|
2018-06-06 09:40:06 +00:00
|
|
|
const MCAssembler &Assembler,
|
|
|
|
const MCSubtargetInfo *STI) {
|
|
|
|
if (!F.hasInstructions())
|
|
|
|
return true;
|
2013-02-15 22:50:52 +00:00
|
|
|
// When bundling is enabled, we don't want to add data to a fragment that
|
2020-04-20 02:53:00 -07:00
|
|
|
// already has instructions (see MCELFStreamer::emitInstToData for details)
|
2018-06-06 09:40:06 +00:00
|
|
|
if (Assembler.isBundlingEnabled())
|
|
|
|
return Assembler.getRelaxAll();
|
|
|
|
// If the subtarget is changed mid fragment we start a new fragment to record
|
|
|
|
// the new STI.
|
|
|
|
return !STI || F.getSubtargetInfo() == STI;
|
|
|
|
}
|
|
|
|
|
|
|
|
MCDataFragment *
|
|
|
|
MCObjectStreamer::getOrCreateDataFragment(const MCSubtargetInfo *STI) {
|
|
|
|
MCDataFragment *F = dyn_cast_or_null<MCDataFragment>(getCurrentFragment());
|
2020-05-09 12:47:44 +08:00
|
|
|
if (!F || !canReuseDataFragment(*F, *Assembler, STI)) {
|
2014-04-10 21:53:47 +00:00
|
|
|
F = new MCDataFragment();
|
2013-04-17 21:18:16 +00:00
|
|
|
insert(F);
|
|
|
|
}
|
2010-07-19 06:13:10 +00:00
|
|
|
return F;
|
|
|
|
}
|
|
|
|
|
2014-06-25 15:29:54 +00:00
|
|
|
void MCObjectStreamer::visitUsedSymbol(const MCSymbol &Sym) {
|
2015-05-29 20:21:02 +00:00
|
|
|
Assembler->registerSymbol(Sym);
|
2014-06-25 15:29:54 +00:00
|
|
|
}
|
|
|
|
|
2020-02-13 21:58:16 -08:00
|
|
|
void MCObjectStreamer::emitCFISections(bool EH, bool Debug) {
|
|
|
|
MCStreamer::emitCFISections(EH, Debug);
|
2014-05-12 14:02:44 +00:00
|
|
|
EmitEHFrame = EH;
|
|
|
|
EmitDebugFrame = Debug;
|
|
|
|
}
|
|
|
|
|
2020-02-14 19:21:58 -08:00
|
|
|
void MCObjectStreamer::emitValueImpl(const MCExpr *Value, unsigned Size,
|
2015-09-20 23:35:59 +00:00
|
|
|
SMLoc Loc) {
|
2020-02-14 19:21:58 -08:00
|
|
|
MCStreamer::emitValueImpl(Value, Size, Loc);
|
2010-11-28 23:08:47 +00:00
|
|
|
MCDataFragment *DF = getOrCreateDataFragment();
|
2015-06-27 01:54:17 +00:00
|
|
|
flushPendingLabels(DF, DF->getContents().size());
|
2010-11-28 23:08:47 +00:00
|
|
|
|
2021-03-04 20:47:41 -05:00
|
|
|
MCDwarfLineEntry::make(this, getCurrentSectionOnly());
|
2013-05-25 21:56:53 +00:00
|
|
|
|
2010-11-28 23:08:47 +00:00
|
|
|
// Avoid fixups when possible.
|
|
|
|
int64_t AbsValue;
|
[MC] Change AsmParser to leverage Assembler during evaluation
Teach AsmParser to check with Assembler for when evaluating constant
expressions. This improves the handing of preprocessor expressions
that must be resolved at parse time. This idiom can be found as
assembling-time assertion checks in source-level assemblers. Note that
this relies on the MCStreamer to keep sufficient tabs on Section /
Fragment information which the MCAsmStreamer does not. As a result the
textual output may fail where the equivalent object generation would
pass. This can most easily be resolved by folding the MCAsmStreamer
and MCObjectStreamer together which is planned for in a separate
patch.
Currently, this feature is only enabled for assembly input, keeping IR
compilation consistent between assembly and object generation.
Reviewers: echristo, rnk, probinson, espindola, peter.smith
Reviewed By: peter.smith
Subscribers: eraman, peter.smith, arichardson, jyknight, hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D45164
llvm-svn: 331218
2018-04-30 19:22:40 +00:00
|
|
|
if (Value->evaluateAsAbsolute(AbsValue, getAssemblerPtr())) {
|
2017-05-15 08:43:27 +00:00
|
|
|
if (!isUIntN(8 * Size, AbsValue) && !isIntN(8 * Size, AbsValue)) {
|
|
|
|
getContext().reportError(
|
|
|
|
Loc, "value evaluated as " + Twine(AbsValue) + " is out of range.");
|
|
|
|
return;
|
|
|
|
}
|
2020-02-14 22:40:47 -08:00
|
|
|
emitIntValue(AbsValue, Size);
|
2010-12-03 02:54:21 +00:00
|
|
|
return;
|
2010-11-28 23:08:47 +00:00
|
|
|
}
|
2012-12-07 19:13:57 +00:00
|
|
|
DF->getFixups().push_back(
|
2015-05-15 19:13:05 +00:00
|
|
|
MCFixup::create(DF->getContents().size(), Value,
|
2014-04-22 17:27:29 +00:00
|
|
|
MCFixup::getKindForSize(Size, false), Loc));
|
2010-12-03 02:54:21 +00:00
|
|
|
DF->getContents().resize(DF->getContents().size() + Size, 0);
|
2010-11-28 23:08:47 +00:00
|
|
|
}
|
|
|
|
|
2020-02-13 21:58:16 -08:00
|
|
|
MCSymbol *MCObjectStreamer::emitCFILabel() {
|
2020-12-21 14:04:13 -08:00
|
|
|
MCSymbol *Label = getContext().createTempSymbol("cfi");
|
2020-02-14 19:21:58 -08:00
|
|
|
emitLabel(Label);
|
[MC] Suppress .Lcfi labels when emitting textual assembly
Summary:
This suppresses the generation of .Lcfi labels in our textual assembler.
It was annoying that this generated cascading .Lcfi labels:
llc foo.ll -o - | llvm-mc | llvm-mc
After three trips through MCAsmStreamer, we'd have three labels in the
output when none are necessary. We should only bother creating the
labels and frame data when making a real object file.
This supercedes D38605, which moved the entire .seh_ implementation into
MCObjectStreamer.
This has the advantage that we do more checking when emitting textual
assembly, as a minor efficiency cost. Outputting textual assembly is not
performance critical, so this shouldn't matter.
Reviewers: majnemer, MatzeB
Subscribers: qcolombet, nemanjai, javed.absar, eraman, hiraditya, JDevlieghere, llvm-commits
Differential Revision: https://reviews.llvm.org/D38638
llvm-svn: 315259
2017-10-10 00:57:36 +00:00
|
|
|
return Label;
|
|
|
|
}
|
|
|
|
|
2020-02-13 21:58:16 -08:00
|
|
|
void MCObjectStreamer::emitCFIStartProcImpl(MCDwarfFrameInfo &Frame) {
|
2014-11-03 12:19:03 +00:00
|
|
|
// We need to create a local symbol to avoid relocations.
|
2015-05-18 18:43:14 +00:00
|
|
|
Frame.Begin = getContext().createTempSymbol();
|
2020-02-14 19:21:58 -08:00
|
|
|
emitLabel(Frame.Begin);
|
2012-01-07 22:42:19 +00:00
|
|
|
}
|
|
|
|
|
2020-02-13 21:58:16 -08:00
|
|
|
void MCObjectStreamer::emitCFIEndProcImpl(MCDwarfFrameInfo &Frame) {
|
2015-05-18 18:43:14 +00:00
|
|
|
Frame.End = getContext().createTempSymbol();
|
2020-02-14 19:21:58 -08:00
|
|
|
emitLabel(Frame.End);
|
2012-01-09 00:17:29 +00:00
|
|
|
}
|
|
|
|
|
2020-02-14 19:21:58 -08:00
|
|
|
void MCObjectStreamer::emitLabel(MCSymbol *Symbol, SMLoc Loc) {
|
|
|
|
MCStreamer::emitLabel(Symbol, Loc);
|
2010-11-28 17:18:55 +00:00
|
|
|
|
2015-05-29 20:21:02 +00:00
|
|
|
getAssembler().registerSymbol(*Symbol);
|
2014-10-22 22:38:06 +00:00
|
|
|
|
|
|
|
// If there is a current fragment, mark the symbol as pointing into it.
|
|
|
|
// Otherwise queue the label and set its fragment pointer when we emit the
|
|
|
|
// next fragment.
|
2015-04-12 23:42:25 +00:00
|
|
|
auto *F = dyn_cast_or_null<MCDataFragment>(getCurrentFragment());
|
|
|
|
if (F && !(getAssembler().isBundlingEnabled() &&
|
|
|
|
getAssembler().getRelaxAll())) {
|
2015-05-29 21:45:01 +00:00
|
|
|
Symbol->setFragment(F);
|
2015-05-29 17:48:04 +00:00
|
|
|
Symbol->setOffset(F->getContents().size());
|
2014-10-22 22:38:06 +00:00
|
|
|
} else {
|
2019-11-10 16:12:29 -05:00
|
|
|
// Assign all pending labels to offset 0 within the dummy "pending"
|
|
|
|
// fragment. (They will all be reassigned to a real fragment in
|
|
|
|
// flushPendingLabels())
|
|
|
|
Symbol->setOffset(0);
|
[ MC ] Match labels to existing fragments even when switching sections.
(This commit restores the original branch (4272372c571) and applies an
additional change dropped from the original in a bad merge. This change
should address the previous bot failures. Both changes reviewed by pete.)
Summary:
This commit builds upon Derek Schuff's 2014 commit for attaching labels to
existing fragments ( Diff Revision: http://reviews.llvm.org/D5915 )
When temporary labels appear ahead of a fragment, MCObjectStreamer will
track the temporary label symbol in a "Pending Labels" list. Labels are
associated with fragments when a real fragment arrives; otherwise, an empty
data fragment will be created if the streamer's section changes or if the
stream finishes.
This commit moves the "Pending Labels" list into each MCStream, so that
this label-fragment matching process is resilient to section changes. If
the streamer emits a label in a new section, switches to another section to
do other work, then switches back to the first section and emits a
fragment, that initial label will be associated with this new fragment.
Labels will only receive empty data fragments in the case where no other
fragment exists for that section.
The downstream effects of this can be seen in Mach-O relocations. The
previous approach could produce local section relocations and external
symbol relocations for the same data in an object file, and this mix of
relocation types resulted in problems in the ld64 Mach-O linker. This
commit ensures relocations triggered by temporary labels are consistent.
Reviewers: pete, ab, dschuff
Reviewed By: pete, dschuff
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71368
2019-12-11 10:42:37 -08:00
|
|
|
addPendingLabel(Symbol);
|
2014-10-22 22:38:06 +00:00
|
|
|
}
|
2010-11-28 17:18:55 +00:00
|
|
|
}
|
|
|
|
|
2019-11-10 16:12:29 -05:00
|
|
|
// Emit a label at a previously emitted fragment/offset position. This must be
|
|
|
|
// within the currently-active section.
|
2020-02-13 13:26:21 -08:00
|
|
|
void MCObjectStreamer::emitLabelAtPos(MCSymbol *Symbol, SMLoc Loc,
|
2019-11-10 16:12:29 -05:00
|
|
|
MCFragment *F, uint64_t Offset) {
|
|
|
|
assert(F->getParent() == getCurrentSectionOnly());
|
|
|
|
|
2020-02-14 19:21:58 -08:00
|
|
|
MCStreamer::emitLabel(Symbol, Loc);
|
2017-04-03 21:50:04 +00:00
|
|
|
getAssembler().registerSymbol(*Symbol);
|
|
|
|
auto *DF = dyn_cast_or_null<MCDataFragment>(F);
|
2019-11-10 16:12:29 -05:00
|
|
|
Symbol->setOffset(Offset);
|
|
|
|
if (DF) {
|
2017-04-03 21:50:04 +00:00
|
|
|
Symbol->setFragment(F);
|
2019-11-10 16:12:29 -05:00
|
|
|
} else {
|
|
|
|
assert(isa<MCDummyFragment>(F) &&
|
|
|
|
"F must either be an MCDataFragment or the pending MCDummyFragment");
|
|
|
|
assert(Offset == 0);
|
[ MC ] Match labels to existing fragments even when switching sections.
(This commit restores the original branch (4272372c571) and applies an
additional change dropped from the original in a bad merge. This change
should address the previous bot failures. Both changes reviewed by pete.)
Summary:
This commit builds upon Derek Schuff's 2014 commit for attaching labels to
existing fragments ( Diff Revision: http://reviews.llvm.org/D5915 )
When temporary labels appear ahead of a fragment, MCObjectStreamer will
track the temporary label symbol in a "Pending Labels" list. Labels are
associated with fragments when a real fragment arrives; otherwise, an empty
data fragment will be created if the streamer's section changes or if the
stream finishes.
This commit moves the "Pending Labels" list into each MCStream, so that
this label-fragment matching process is resilient to section changes. If
the streamer emits a label in a new section, switches to another section to
do other work, then switches back to the first section and emits a
fragment, that initial label will be associated with this new fragment.
Labels will only receive empty data fragments in the case where no other
fragment exists for that section.
The downstream effects of this can be seen in Mach-O relocations. The
previous approach could produce local section relocations and external
symbol relocations for the same data in an object file, and this mix of
relocation types resulted in problems in the ld64 Mach-O linker. This
commit ensures relocations triggered by temporary labels are consistent.
Reviewers: pete, ab, dschuff
Reviewed By: pete, dschuff
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71368
2019-12-11 10:42:37 -08:00
|
|
|
addPendingLabel(Symbol);
|
2019-11-10 16:12:29 -05:00
|
|
|
}
|
2017-04-03 21:50:04 +00:00
|
|
|
}
|
|
|
|
|
2020-02-13 13:26:21 -08:00
|
|
|
void MCObjectStreamer::emitULEB128Value(const MCExpr *Value) {
|
2010-12-03 01:19:49 +00:00
|
|
|
int64_t IntValue;
|
[MC] Change AsmParser to leverage Assembler during evaluation
Teach AsmParser to check with Assembler for when evaluating constant
expressions. This improves the handing of preprocessor expressions
that must be resolved at parse time. This idiom can be found as
assembling-time assertion checks in source-level assemblers. Note that
this relies on the MCStreamer to keep sufficient tabs on Section /
Fragment information which the MCAsmStreamer does not. As a result the
textual output may fail where the equivalent object generation would
pass. This can most easily be resolved by folding the MCAsmStreamer
and MCObjectStreamer together which is planned for in a separate
patch.
Currently, this feature is only enabled for assembly input, keeping IR
compilation consistent between assembly and object generation.
Reviewers: echristo, rnk, probinson, espindola, peter.smith
Reviewed By: peter.smith
Subscribers: eraman, peter.smith, arichardson, jyknight, hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D45164
llvm-svn: 331218
2018-04-30 19:22:40 +00:00
|
|
|
if (Value->evaluateAsAbsolute(IntValue, getAssemblerPtr())) {
|
2020-02-13 13:26:21 -08:00
|
|
|
emitULEB128IntValue(IntValue);
|
2010-12-03 01:19:49 +00:00
|
|
|
return;
|
|
|
|
}
|
2013-04-17 21:18:16 +00:00
|
|
|
insert(new MCLEBFragment(*Value, false));
|
2010-11-02 17:22:24 +00:00
|
|
|
}
|
|
|
|
|
2020-02-13 13:26:21 -08:00
|
|
|
void MCObjectStreamer::emitSLEB128Value(const MCExpr *Value) {
|
2010-12-03 01:19:49 +00:00
|
|
|
int64_t IntValue;
|
[MC] Change AsmParser to leverage Assembler during evaluation
Teach AsmParser to check with Assembler for when evaluating constant
expressions. This improves the handing of preprocessor expressions
that must be resolved at parse time. This idiom can be found as
assembling-time assertion checks in source-level assemblers. Note that
this relies on the MCStreamer to keep sufficient tabs on Section /
Fragment information which the MCAsmStreamer does not. As a result the
textual output may fail where the equivalent object generation would
pass. This can most easily be resolved by folding the MCAsmStreamer
and MCObjectStreamer together which is planned for in a separate
patch.
Currently, this feature is only enabled for assembly input, keeping IR
compilation consistent between assembly and object generation.
Reviewers: echristo, rnk, probinson, espindola, peter.smith
Reviewed By: peter.smith
Subscribers: eraman, peter.smith, arichardson, jyknight, hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D45164
llvm-svn: 331218
2018-04-30 19:22:40 +00:00
|
|
|
if (Value->evaluateAsAbsolute(IntValue, getAssemblerPtr())) {
|
2020-02-13 13:26:21 -08:00
|
|
|
emitSLEB128IntValue(IntValue);
|
2010-12-03 01:19:49 +00:00
|
|
|
return;
|
|
|
|
}
|
2013-04-17 21:18:16 +00:00
|
|
|
insert(new MCLEBFragment(*Value, true));
|
2010-11-02 17:22:24 +00:00
|
|
|
}
|
|
|
|
|
2020-02-14 18:16:24 -08:00
|
|
|
void MCObjectStreamer::emitWeakReference(MCSymbol *Alias,
|
2010-11-01 14:28:48 +00:00
|
|
|
const MCSymbol *Symbol) {
|
|
|
|
report_fatal_error("This file format doesn't support weak aliases.");
|
|
|
|
}
|
|
|
|
|
2020-04-20 19:28:13 -07:00
|
|
|
void MCObjectStreamer::changeSection(MCSection *Section,
|
2013-04-17 21:18:16 +00:00
|
|
|
const MCExpr *Subsection) {
|
2015-03-20 20:00:01 +00:00
|
|
|
changeSectionImpl(Section, Subsection);
|
|
|
|
}
|
|
|
|
|
2015-05-21 19:20:38 +00:00
|
|
|
bool MCObjectStreamer::changeSectionImpl(MCSection *Section,
|
2015-03-20 20:00:01 +00:00
|
|
|
const MCExpr *Subsection) {
|
2010-06-16 20:04:25 +00:00
|
|
|
assert(Section && "Cannot switch to a null section!");
|
2017-03-16 00:52:18 +00:00
|
|
|
getContext().clearDwarfLocSeen();
|
2010-06-16 20:04:25 +00:00
|
|
|
|
2015-05-26 15:07:25 +00:00
|
|
|
bool Created = getAssembler().registerSection(*Section);
|
2013-04-17 21:18:16 +00:00
|
|
|
|
|
|
|
int64_t IntSubsection = 0;
|
|
|
|
if (Subsection &&
|
[MC] Change AsmParser to leverage Assembler during evaluation
Teach AsmParser to check with Assembler for when evaluating constant
expressions. This improves the handing of preprocessor expressions
that must be resolved at parse time. This idiom can be found as
assembling-time assertion checks in source-level assemblers. Note that
this relies on the MCStreamer to keep sufficient tabs on Section /
Fragment information which the MCAsmStreamer does not. As a result the
textual output may fail where the equivalent object generation would
pass. This can most easily be resolved by folding the MCAsmStreamer
and MCObjectStreamer together which is planned for in a separate
patch.
Currently, this feature is only enabled for assembly input, keeping IR
compilation consistent between assembly and object generation.
Reviewers: echristo, rnk, probinson, espindola, peter.smith
Reviewed By: peter.smith
Subscribers: eraman, peter.smith, arichardson, jyknight, hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D45164
llvm-svn: 331218
2018-04-30 19:22:40 +00:00
|
|
|
!Subsection->evaluateAsAbsolute(IntSubsection, getAssemblerPtr()))
|
2013-04-17 21:18:16 +00:00
|
|
|
report_fatal_error("Cannot evaluate subsection number");
|
|
|
|
if (IntSubsection < 0 || IntSubsection > 8192)
|
|
|
|
report_fatal_error("Subsection number out of range");
|
[ MC ] Match labels to existing fragments even when switching sections.
(This commit restores the original branch (4272372c571) and applies an
additional change dropped from the original in a bad merge. This change
should address the previous bot failures. Both changes reviewed by pete.)
Summary:
This commit builds upon Derek Schuff's 2014 commit for attaching labels to
existing fragments ( Diff Revision: http://reviews.llvm.org/D5915 )
When temporary labels appear ahead of a fragment, MCObjectStreamer will
track the temporary label symbol in a "Pending Labels" list. Labels are
associated with fragments when a real fragment arrives; otherwise, an empty
data fragment will be created if the streamer's section changes or if the
stream finishes.
This commit moves the "Pending Labels" list into each MCStream, so that
this label-fragment matching process is resilient to section changes. If
the streamer emits a label in a new section, switches to another section to
do other work, then switches back to the first section and emits a
fragment, that initial label will be associated with this new fragment.
Labels will only receive empty data fragments in the case where no other
fragment exists for that section.
The downstream effects of this can be seen in Mach-O relocations. The
previous approach could produce local section relocations and external
symbol relocations for the same data in an object file, and this mix of
relocation types resulted in problems in the ld64 Mach-O linker. This
commit ensures relocations triggered by temporary labels are consistent.
Reviewers: pete, ab, dschuff
Reviewed By: pete, dschuff
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71368
2019-12-11 10:42:37 -08:00
|
|
|
CurSubsectionIdx = unsigned(IntSubsection);
|
2013-04-17 21:18:16 +00:00
|
|
|
CurInsertionPoint =
|
[ MC ] Match labels to existing fragments even when switching sections.
(This commit restores the original branch (4272372c571) and applies an
additional change dropped from the original in a bad merge. This change
should address the previous bot failures. Both changes reviewed by pete.)
Summary:
This commit builds upon Derek Schuff's 2014 commit for attaching labels to
existing fragments ( Diff Revision: http://reviews.llvm.org/D5915 )
When temporary labels appear ahead of a fragment, MCObjectStreamer will
track the temporary label symbol in a "Pending Labels" list. Labels are
associated with fragments when a real fragment arrives; otherwise, an empty
data fragment will be created if the streamer's section changes or if the
stream finishes.
This commit moves the "Pending Labels" list into each MCStream, so that
this label-fragment matching process is resilient to section changes. If
the streamer emits a label in a new section, switches to another section to
do other work, then switches back to the first section and emits a
fragment, that initial label will be associated with this new fragment.
Labels will only receive empty data fragments in the case where no other
fragment exists for that section.
The downstream effects of this can be seen in Mach-O relocations. The
previous approach could produce local section relocations and external
symbol relocations for the same data in an object file, and this mix of
relocation types resulted in problems in the ld64 Mach-O linker. This
commit ensures relocations triggered by temporary labels are consistent.
Reviewers: pete, ab, dschuff
Reviewed By: pete, dschuff
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71368
2019-12-11 10:42:37 -08:00
|
|
|
Section->getSubsectionInsertionPoint(CurSubsectionIdx);
|
2015-03-20 20:00:01 +00:00
|
|
|
return Created;
|
2010-06-16 20:04:25 +00:00
|
|
|
}
|
|
|
|
|
2020-02-14 18:16:24 -08:00
|
|
|
void MCObjectStreamer::emitAssignment(MCSymbol *Symbol, const MCExpr *Value) {
|
2015-05-29 20:21:02 +00:00
|
|
|
getAssembler().registerSymbol(*Symbol);
|
2020-02-14 18:16:24 -08:00
|
|
|
MCStreamer::emitAssignment(Symbol, Value);
|
2012-12-07 17:42:41 +00:00
|
|
|
}
|
|
|
|
|
2015-05-25 18:34:26 +00:00
|
|
|
bool MCObjectStreamer::mayHaveInstructions(MCSection &Sec) const {
|
|
|
|
return Sec.hasInstructions();
|
|
|
|
}
|
|
|
|
|
2020-02-13 21:58:16 -08:00
|
|
|
void MCObjectStreamer::emitInstruction(const MCInst &Inst,
|
2019-02-04 12:51:26 +00:00
|
|
|
const MCSubtargetInfo &STI) {
|
2020-04-14 11:05:21 -07:00
|
|
|
const MCSection &Sec = *getCurrentSectionOnly();
|
|
|
|
if (Sec.isVirtualSection()) {
|
|
|
|
getContext().reportError(Inst.getLoc(), Twine(Sec.getVirtualSectionKind()) +
|
|
|
|
" section '" + Sec.getName() +
|
|
|
|
"' cannot have instructions");
|
|
|
|
return;
|
|
|
|
}
|
2021-08-09 11:40:22 +01:00
|
|
|
getAssembler().getBackend().emitInstructionBegin(*this, Inst, STI);
|
2020-02-13 21:58:16 -08:00
|
|
|
emitInstructionImpl(Inst, STI);
|
2020-03-16 16:52:31 +08:00
|
|
|
getAssembler().getBackend().emitInstructionEnd(*this, Inst);
|
Align branches within 32-Byte boundary (NOP padding)
WARNING: If you're looking at this patch because you're looking for a full
performace mitigation of the Intel JCC Erratum, this is not it!
This is a preliminary patch on the patch towards mitigating the performance
regressions caused by Intel's microcode update for Jump Conditional Code
Erratum. For context, see:
https://www.intel.com/content/www/us/en/support/articles/000055650.html
The patch adds the required assembler infrastructure and command line options
needed to exercise the logic for INTERNAL TESTING. These are NOT public flags,
and should not be used for anything other than LLVM's own testing/debugging
purposes. They are likely to change both in spelling and meaning.
WARNING: This patch is knowingly incorrect in some cornercases. We need, and
do not yet provide, a mechanism to selective enable/disable the padding.
Conversation on this will continue in parellel with work on extending this
infrastructure to support prefix padding.
The goal here is to have the assembler align specific instructions such that
they neither cross or end at a 32 byte boundary. The impacted instructions are:
a. Conditional jump.
b. Fused conditional jump.
c. Unconditional jump.
d. Indirect jump.
e. Ret.
f. Call.
The new options for llvm-mc are:
-x86-align-branch-boundary=NUM aligns branches within NUM byte boundary.
-x86-align-branch=TYPE[+TYPE...] specifies types of branches to align.
A new MCFragment type, MCBoundaryAlignFragment, is added, which may emit
NOP to align the fused/unfused branch.
alignBranchesBegin inserts MCBoundaryAlignFragment before instructions,
alignBranchesEnd marks the end of the branch to be aligned,
relaxBoundaryAlign grows or shrinks sizes of NOP to align the target branch.
Nop padding is disabled when the instruction may be rewritten by the linker,
such as TLS Call.
Process Note: I am landing a patch by skan as it has been LGTMed, and
continuing to iterate on the review is simply slowing us down at this point.
We can and will continue to iterate in tree.
Patch By: skan
Differential Revision: https://reviews.llvm.org/D70157
2019-12-20 10:51:05 -08:00
|
|
|
}
|
|
|
|
|
2020-02-13 21:58:16 -08:00
|
|
|
void MCObjectStreamer::emitInstructionImpl(const MCInst &Inst,
|
Align branches within 32-Byte boundary (NOP padding)
WARNING: If you're looking at this patch because you're looking for a full
performace mitigation of the Intel JCC Erratum, this is not it!
This is a preliminary patch on the patch towards mitigating the performance
regressions caused by Intel's microcode update for Jump Conditional Code
Erratum. For context, see:
https://www.intel.com/content/www/us/en/support/articles/000055650.html
The patch adds the required assembler infrastructure and command line options
needed to exercise the logic for INTERNAL TESTING. These are NOT public flags,
and should not be used for anything other than LLVM's own testing/debugging
purposes. They are likely to change both in spelling and meaning.
WARNING: This patch is knowingly incorrect in some cornercases. We need, and
do not yet provide, a mechanism to selective enable/disable the padding.
Conversation on this will continue in parellel with work on extending this
infrastructure to support prefix padding.
The goal here is to have the assembler align specific instructions such that
they neither cross or end at a 32 byte boundary. The impacted instructions are:
a. Conditional jump.
b. Fused conditional jump.
c. Unconditional jump.
d. Indirect jump.
e. Ret.
f. Call.
The new options for llvm-mc are:
-x86-align-branch-boundary=NUM aligns branches within NUM byte boundary.
-x86-align-branch=TYPE[+TYPE...] specifies types of branches to align.
A new MCFragment type, MCBoundaryAlignFragment, is added, which may emit
NOP to align the fused/unfused branch.
alignBranchesBegin inserts MCBoundaryAlignFragment before instructions,
alignBranchesEnd marks the end of the branch to be aligned,
relaxBoundaryAlign grows or shrinks sizes of NOP to align the target branch.
Nop padding is disabled when the instruction may be rewritten by the linker,
such as TLS Call.
Process Note: I am landing a patch by skan as it has been LGTMed, and
continuing to iterate on the review is simply slowing us down at this point.
We can and will continue to iterate in tree.
Patch By: skan
Differential Revision: https://reviews.llvm.org/D70157
2019-12-20 10:51:05 -08:00
|
|
|
const MCSubtargetInfo &STI) {
|
2020-02-13 21:58:16 -08:00
|
|
|
MCStreamer::emitInstruction(Inst, STI);
|
2010-11-01 16:27:31 +00:00
|
|
|
|
2015-05-27 21:04:14 +00:00
|
|
|
MCSection *Sec = getCurrentSectionOnly();
|
2015-05-26 14:48:11 +00:00
|
|
|
Sec->setHasInstructions(true);
|
2010-11-01 16:27:31 +00:00
|
|
|
|
|
|
|
// Now that a machine instruction has been assembled into this section, make
|
|
|
|
// a line entry for any .loc directive that has been seen.
|
2021-03-04 20:47:41 -05:00
|
|
|
MCDwarfLineEntry::make(this, getCurrentSectionOnly());
|
2010-11-01 16:27:31 +00:00
|
|
|
|
|
|
|
// If this instruction doesn't need relaxation, just emit it as data.
|
2012-12-20 19:05:53 +00:00
|
|
|
MCAssembler &Assembler = getAssembler();
|
[X86][MC] Support enhanced relaxation for branch align
Summary:
Since D75300 has been landed, I want to support enhanced relaxation when we need to align branches and allow prefix padding. "Enhanced Relaxtion" means we allow an instruction that could not be traditionally relaxed to be emitted into RelaxableFragment so that we increase its length by adding prefixes for optimization.
The motivation is straightforward, RelaxFragment is mostly for relative jumps and we can not increase the length of jumps when we need to align them, so if we need to achieve D75300's purpose (reducing the bytes of nops) when need to align jumps, we have to make more instructions "relaxable".
Reviewers: reames, MaskRay, craig.topper, LuoYuanke, jyknight
Reviewed By: reames
Subscribers: hiraditya, llvm-commits, annita.zhang
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D76286
2020-04-07 12:27:45 +08:00
|
|
|
MCAsmBackend &Backend = Assembler.getBackend();
|
|
|
|
if (!(Backend.mayNeedRelaxation(Inst, STI) ||
|
|
|
|
Backend.allowEnhancedRelaxation())) {
|
2020-04-20 02:53:00 -07:00
|
|
|
emitInstToData(Inst, STI);
|
2010-11-01 16:27:31 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2012-12-20 19:05:53 +00:00
|
|
|
// Otherwise, relax and emit it as data if either:
|
|
|
|
// - The RelaxAll flag was passed
|
|
|
|
// - Bundling is enabled and this instruction is inside a bundle-locked
|
|
|
|
// group. We want to emit all such instructions into the same data
|
|
|
|
// fragment.
|
|
|
|
if (Assembler.getRelaxAll() ||
|
2015-05-26 14:48:11 +00:00
|
|
|
(Assembler.isBundlingEnabled() && Sec->isBundleLocked())) {
|
2020-04-10 18:37:24 +08:00
|
|
|
MCInst Relaxed = Inst;
|
2020-05-09 12:47:44 +08:00
|
|
|
while (Backend.mayNeedRelaxation(Relaxed, STI))
|
|
|
|
Backend.relaxInstruction(Relaxed, STI);
|
2020-04-20 02:53:00 -07:00
|
|
|
emitInstToData(Relaxed, STI);
|
2010-11-01 16:27:31 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Otherwise emit to a separate fragment.
|
2020-04-20 19:28:13 -07:00
|
|
|
emitInstToFragment(Inst, STI);
|
2010-11-01 16:27:31 +00:00
|
|
|
}
|
|
|
|
|
2020-04-20 19:28:13 -07:00
|
|
|
void MCObjectStreamer::emitInstToFragment(const MCInst &Inst,
|
2014-01-28 23:12:49 +00:00
|
|
|
const MCSubtargetInfo &STI) {
|
2015-04-12 23:42:25 +00:00
|
|
|
if (getAssembler().getRelaxAll() && getAssembler().isBundlingEnabled())
|
|
|
|
llvm_unreachable("All instructions should have already been relaxed");
|
|
|
|
|
2012-12-20 19:05:53 +00:00
|
|
|
// Always create a new, separate fragment here, because its size can change
|
|
|
|
// during relaxation.
|
2014-01-28 23:12:53 +00:00
|
|
|
MCRelaxableFragment *IF = new MCRelaxableFragment(Inst, STI);
|
2013-04-17 21:18:16 +00:00
|
|
|
insert(IF);
|
2010-12-02 05:44:06 +00:00
|
|
|
|
2011-04-18 20:54:46 +00:00
|
|
|
SmallString<128> Code;
|
|
|
|
raw_svector_ostream VecOS(Code);
|
2015-05-15 19:13:16 +00:00
|
|
|
getAssembler().getEmitter().encodeInstruction(Inst, VecOS, IF->getFixups(),
|
2014-01-28 23:13:07 +00:00
|
|
|
STI);
|
2012-12-07 19:13:57 +00:00
|
|
|
IF->getContents().append(Code.begin(), Code.end());
|
2010-12-02 05:44:06 +00:00
|
|
|
}
|
|
|
|
|
2013-02-15 23:12:33 +00:00
|
|
|
#ifndef NDEBUG
|
2013-07-16 01:17:10 +00:00
|
|
|
static const char *const BundlingNotImplementedMsg =
|
2012-12-20 19:05:53 +00:00
|
|
|
"Aligned bundling is not implemented for this object format";
|
2013-02-15 23:12:33 +00:00
|
|
|
#endif
|
2012-12-20 19:05:53 +00:00
|
|
|
|
2020-02-15 08:52:56 -08:00
|
|
|
void MCObjectStreamer::emitBundleAlignMode(unsigned AlignPow2) {
|
2012-12-20 19:05:53 +00:00
|
|
|
llvm_unreachable(BundlingNotImplementedMsg);
|
|
|
|
}
|
|
|
|
|
2020-02-15 08:52:56 -08:00
|
|
|
void MCObjectStreamer::emitBundleLock(bool AlignToEnd) {
|
2012-12-20 19:05:53 +00:00
|
|
|
llvm_unreachable(BundlingNotImplementedMsg);
|
|
|
|
}
|
|
|
|
|
2020-02-15 08:52:56 -08:00
|
|
|
void MCObjectStreamer::emitBundleUnlock() {
|
2012-12-20 19:05:53 +00:00
|
|
|
llvm_unreachable(BundlingNotImplementedMsg);
|
|
|
|
}
|
|
|
|
|
2020-02-13 13:26:21 -08:00
|
|
|
void MCObjectStreamer::emitDwarfLocDirective(unsigned FileNo, unsigned Line,
|
2013-06-19 21:27:27 +00:00
|
|
|
unsigned Column, unsigned Flags,
|
|
|
|
unsigned Isa,
|
|
|
|
unsigned Discriminator,
|
|
|
|
StringRef FileName) {
|
|
|
|
// In case we see two .loc directives in a row, make sure the
|
|
|
|
// first one gets a line entry.
|
2021-03-04 20:47:41 -05:00
|
|
|
MCDwarfLineEntry::make(this, getCurrentSectionOnly());
|
2013-06-19 21:27:27 +00:00
|
|
|
|
2020-02-13 13:26:21 -08:00
|
|
|
this->MCStreamer::emitDwarfLocDirective(FileNo, Line, Column, Flags, Isa,
|
|
|
|
Discriminator, FileName);
|
2013-06-19 21:27:27 +00:00
|
|
|
}
|
|
|
|
|
2014-08-15 14:31:47 +00:00
|
|
|
static const MCExpr *buildSymbolDiff(MCObjectStreamer &OS, const MCSymbol *A,
|
|
|
|
const MCSymbol *B) {
|
|
|
|
MCContext &Context = OS.getContext();
|
|
|
|
MCSymbolRefExpr::VariantKind Variant = MCSymbolRefExpr::VK_None;
|
2015-05-30 01:25:56 +00:00
|
|
|
const MCExpr *ARef = MCSymbolRefExpr::create(A, Variant, Context);
|
|
|
|
const MCExpr *BRef = MCSymbolRefExpr::create(B, Variant, Context);
|
2014-08-15 14:31:47 +00:00
|
|
|
const MCExpr *AddrDelta =
|
2015-05-30 01:25:56 +00:00
|
|
|
MCBinaryExpr::create(MCBinaryExpr::Sub, ARef, BRef, Context);
|
2014-08-15 14:31:47 +00:00
|
|
|
return AddrDelta;
|
|
|
|
}
|
|
|
|
|
2015-08-07 15:14:08 +00:00
|
|
|
static void emitDwarfSetLineAddr(MCObjectStreamer &OS,
|
|
|
|
MCDwarfLineTableParams Params,
|
|
|
|
int64_t LineDelta, const MCSymbol *Label,
|
|
|
|
int PointerSize) {
|
2014-08-15 14:43:02 +00:00
|
|
|
// emit the sequence to set the address
|
2020-02-14 22:40:47 -08:00
|
|
|
OS.emitIntValue(dwarf::DW_LNS_extended_op, 1);
|
2020-02-13 13:26:21 -08:00
|
|
|
OS.emitULEB128IntValue(PointerSize + 1);
|
2020-02-14 22:40:47 -08:00
|
|
|
OS.emitIntValue(dwarf::DW_LNE_set_address, 1);
|
2020-02-14 19:21:58 -08:00
|
|
|
OS.emitSymbolValue(Label, PointerSize);
|
2014-08-15 14:43:02 +00:00
|
|
|
|
|
|
|
// emit the sequence for the LineDelta (from 1) and a zero address delta.
|
2015-08-07 15:14:08 +00:00
|
|
|
MCDwarfLineAddr::Emit(&OS, Params, LineDelta, 0);
|
2014-08-15 14:43:02 +00:00
|
|
|
}
|
|
|
|
|
2020-02-13 13:26:21 -08:00
|
|
|
void MCObjectStreamer::emitDwarfAdvanceLineAddr(int64_t LineDelta,
|
2010-12-03 00:55:40 +00:00
|
|
|
const MCSymbol *LastLabel,
|
2011-07-14 05:43:07 +00:00
|
|
|
const MCSymbol *Label,
|
|
|
|
unsigned PointerSize) {
|
2010-12-03 00:55:40 +00:00
|
|
|
if (!LastLabel) {
|
2015-08-07 15:14:08 +00:00
|
|
|
emitDwarfSetLineAddr(*this, Assembler->getDWARFLinetableParams(), LineDelta,
|
|
|
|
Label, PointerSize);
|
2010-12-03 00:55:40 +00:00
|
|
|
return;
|
|
|
|
}
|
2014-08-15 14:31:47 +00:00
|
|
|
const MCExpr *AddrDelta = buildSymbolDiff(*this, Label, LastLabel);
|
2010-12-03 00:55:40 +00:00
|
|
|
int64_t Res;
|
[MC] Change AsmParser to leverage Assembler during evaluation
Teach AsmParser to check with Assembler for when evaluating constant
expressions. This improves the handing of preprocessor expressions
that must be resolved at parse time. This idiom can be found as
assembling-time assertion checks in source-level assemblers. Note that
this relies on the MCStreamer to keep sufficient tabs on Section /
Fragment information which the MCAsmStreamer does not. As a result the
textual output may fail where the equivalent object generation would
pass. This can most easily be resolved by folding the MCAsmStreamer
and MCObjectStreamer together which is planned for in a separate
patch.
Currently, this feature is only enabled for assembly input, keeping IR
compilation consistent between assembly and object generation.
Reviewers: echristo, rnk, probinson, espindola, peter.smith
Reviewed By: peter.smith
Subscribers: eraman, peter.smith, arichardson, jyknight, hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D45164
llvm-svn: 331218
2018-04-30 19:22:40 +00:00
|
|
|
if (AddrDelta->evaluateAsAbsolute(Res, getAssemblerPtr())) {
|
2015-08-07 15:14:08 +00:00
|
|
|
MCDwarfLineAddr::Emit(this, Assembler->getDWARFLinetableParams(), LineDelta,
|
|
|
|
Res);
|
2010-12-03 00:55:40 +00:00
|
|
|
return;
|
|
|
|
}
|
2013-04-17 21:18:16 +00:00
|
|
|
insert(new MCDwarfLineAddrFragment(LineDelta, *AddrDelta));
|
2010-12-03 00:55:40 +00:00
|
|
|
}
|
|
|
|
|
2021-03-04 20:47:41 -05:00
|
|
|
void MCObjectStreamer::emitDwarfLineEndEntry(MCSection *Section,
|
|
|
|
MCSymbol *LastLabel) {
|
|
|
|
// Emit a DW_LNE_end_sequence for the end of the section.
|
|
|
|
// Use the section end label to compute the address delta and use INT64_MAX
|
|
|
|
// as the line delta which is the signal that this is actually a
|
|
|
|
// DW_LNE_end_sequence.
|
|
|
|
MCSymbol *SectionEnd = endSection(Section);
|
|
|
|
|
|
|
|
// Switch back the dwarf line section, in case endSection had to switch the
|
|
|
|
// section.
|
|
|
|
MCContext &Ctx = getContext();
|
|
|
|
SwitchSection(Ctx.getObjectFileInfo()->getDwarfLineSection());
|
|
|
|
|
|
|
|
const MCAsmInfo *AsmInfo = Ctx.getAsmInfo();
|
|
|
|
emitDwarfAdvanceLineAddr(INT64_MAX, LastLabel, SectionEnd,
|
|
|
|
AsmInfo->getCodePointerSize());
|
|
|
|
}
|
|
|
|
|
2020-02-13 13:26:21 -08:00
|
|
|
void MCObjectStreamer::emitDwarfAdvanceFrameAddr(const MCSymbol *LastLabel,
|
2010-12-28 05:39:27 +00:00
|
|
|
const MCSymbol *Label) {
|
2014-08-15 14:31:47 +00:00
|
|
|
const MCExpr *AddrDelta = buildSymbolDiff(*this, Label, LastLabel);
|
2010-12-28 05:39:27 +00:00
|
|
|
int64_t Res;
|
[MC] Change AsmParser to leverage Assembler during evaluation
Teach AsmParser to check with Assembler for when evaluating constant
expressions. This improves the handing of preprocessor expressions
that must be resolved at parse time. This idiom can be found as
assembling-time assertion checks in source-level assemblers. Note that
this relies on the MCStreamer to keep sufficient tabs on Section /
Fragment information which the MCAsmStreamer does not. As a result the
textual output may fail where the equivalent object generation would
pass. This can most easily be resolved by folding the MCAsmStreamer
and MCObjectStreamer together which is planned for in a separate
patch.
Currently, this feature is only enabled for assembly input, keeping IR
compilation consistent between assembly and object generation.
Reviewers: echristo, rnk, probinson, espindola, peter.smith
Reviewed By: peter.smith
Subscribers: eraman, peter.smith, arichardson, jyknight, hiraditya, llvm-commits
Differential Revision: https://reviews.llvm.org/D45164
llvm-svn: 331218
2018-04-30 19:22:40 +00:00
|
|
|
if (AddrDelta->evaluateAsAbsolute(Res, getAssemblerPtr())) {
|
2010-12-28 05:39:27 +00:00
|
|
|
MCDwarfFrameEmitter::EmitAdvanceLoc(*this, Res);
|
|
|
|
return;
|
|
|
|
}
|
2013-04-17 21:18:16 +00:00
|
|
|
insert(new MCDwarfCallFrameFragment(*AddrDelta));
|
2010-12-28 05:39:27 +00:00
|
|
|
}
|
|
|
|
|
2020-04-20 19:28:13 -07:00
|
|
|
void MCObjectStreamer::emitCVLocDirective(unsigned FunctionId, unsigned FileNo,
|
2016-01-29 00:49:42 +00:00
|
|
|
unsigned Line, unsigned Column,
|
|
|
|
bool PrologueEnd, bool IsStmt,
|
2016-09-07 16:15:31 +00:00
|
|
|
StringRef FileName, SMLoc Loc) {
|
2018-08-28 23:25:59 +00:00
|
|
|
// Validate the directive.
|
|
|
|
if (!checkCVLocSection(FunctionId, FileNo, Loc))
|
|
|
|
return;
|
|
|
|
|
|
|
|
// Emit a label at the current position and record it in the CodeViewContext.
|
|
|
|
MCSymbol *LineSym = getContext().createTempSymbol();
|
2020-02-14 19:21:58 -08:00
|
|
|
emitLabel(LineSym);
|
2018-08-28 23:25:59 +00:00
|
|
|
getContext().getCVContext().recordCVLoc(getContext(), LineSym, FunctionId,
|
|
|
|
FileNo, Line, Column, PrologueEnd,
|
|
|
|
IsStmt);
|
2016-01-29 00:49:42 +00:00
|
|
|
}
|
|
|
|
|
2020-04-20 19:28:13 -07:00
|
|
|
void MCObjectStreamer::emitCVLinetableDirective(unsigned FunctionId,
|
2016-01-29 00:49:42 +00:00
|
|
|
const MCSymbol *Begin,
|
|
|
|
const MCSymbol *End) {
|
|
|
|
getContext().getCVContext().emitLineTableForFunction(*this, FunctionId, Begin,
|
|
|
|
End);
|
2020-04-20 19:28:13 -07:00
|
|
|
this->MCStreamer::emitCVLinetableDirective(FunctionId, Begin, End);
|
2016-01-29 00:49:42 +00:00
|
|
|
}
|
|
|
|
|
2020-04-20 19:28:13 -07:00
|
|
|
void MCObjectStreamer::emitCVInlineLinetableDirective(
|
2016-01-29 19:24:12 +00:00
|
|
|
unsigned PrimaryFunctionId, unsigned SourceFileId, unsigned SourceLineNum,
|
2016-09-07 16:15:31 +00:00
|
|
|
const MCSymbol *FnStartSym, const MCSymbol *FnEndSym) {
|
2016-01-29 19:24:12 +00:00
|
|
|
getContext().getCVContext().emitInlineLineTableForFunction(
|
2016-02-02 17:41:18 +00:00
|
|
|
*this, PrimaryFunctionId, SourceFileId, SourceLineNum, FnStartSym,
|
2016-09-07 16:15:31 +00:00
|
|
|
FnEndSym);
|
2020-04-20 19:28:13 -07:00
|
|
|
this->MCStreamer::emitCVInlineLinetableDirective(
|
2016-09-07 16:15:31 +00:00
|
|
|
PrimaryFunctionId, SourceFileId, SourceLineNum, FnStartSym, FnEndSym);
|
2016-01-29 19:24:12 +00:00
|
|
|
}
|
|
|
|
|
2020-04-20 19:28:13 -07:00
|
|
|
void MCObjectStreamer::emitCVDefRangeDirective(
|
2016-02-05 01:55:49 +00:00
|
|
|
ArrayRef<std::pair<const MCSymbol *, const MCSymbol *>> Ranges,
|
|
|
|
StringRef FixedSizePortion) {
|
2018-12-17 21:49:35 +00:00
|
|
|
MCFragment *Frag =
|
|
|
|
getContext().getCVContext().emitDefRange(*this, Ranges, FixedSizePortion);
|
|
|
|
// Attach labels that were pending before we created the defrange fragment to
|
|
|
|
// the beginning of the new fragment.
|
|
|
|
flushPendingLabels(Frag, 0);
|
2020-04-20 19:28:13 -07:00
|
|
|
this->MCStreamer::emitCVDefRangeDirective(Ranges, FixedSizePortion);
|
2016-02-05 01:55:49 +00:00
|
|
|
}
|
|
|
|
|
2020-04-20 19:28:13 -07:00
|
|
|
void MCObjectStreamer::emitCVStringTableDirective() {
|
2016-01-29 00:49:42 +00:00
|
|
|
getContext().getCVContext().emitStringTable(*this);
|
|
|
|
}
|
2020-04-20 19:28:13 -07:00
|
|
|
void MCObjectStreamer::emitCVFileChecksumsDirective() {
|
2016-01-29 00:49:42 +00:00
|
|
|
getContext().getCVContext().emitFileChecksums(*this);
|
|
|
|
}
|
|
|
|
|
2020-04-20 19:28:13 -07:00
|
|
|
void MCObjectStreamer::emitCVFileChecksumOffsetDirective(unsigned FileNo) {
|
2017-09-19 18:14:45 +00:00
|
|
|
getContext().getCVContext().emitFileChecksumOffset(*this, FileNo);
|
|
|
|
}
|
2016-01-29 00:49:42 +00:00
|
|
|
|
2020-02-14 18:16:24 -08:00
|
|
|
void MCObjectStreamer::emitBytes(StringRef Data) {
|
2021-03-04 20:47:41 -05:00
|
|
|
MCDwarfLineEntry::make(this, getCurrentSectionOnly());
|
2015-06-27 01:54:17 +00:00
|
|
|
MCDataFragment *DF = getOrCreateDataFragment();
|
|
|
|
flushPendingLabels(DF, DF->getContents().size());
|
|
|
|
DF->getContents().append(Data.begin(), Data.end());
|
2012-10-04 13:12:43 +00:00
|
|
|
}
|
|
|
|
|
2020-02-14 19:21:58 -08:00
|
|
|
void MCObjectStreamer::emitValueToAlignment(unsigned ByteAlignment,
|
2012-10-04 13:12:43 +00:00
|
|
|
int64_t Value,
|
|
|
|
unsigned ValueSize,
|
|
|
|
unsigned MaxBytesToEmit) {
|
|
|
|
if (MaxBytesToEmit == 0)
|
|
|
|
MaxBytesToEmit = ByteAlignment;
|
2013-04-17 21:18:16 +00:00
|
|
|
insert(new MCAlignFragment(ByteAlignment, Value, ValueSize, MaxBytesToEmit));
|
2012-10-04 13:12:43 +00:00
|
|
|
|
|
|
|
// Update the maximum alignment on the current section if necessary.
|
2016-10-14 05:47:37 +00:00
|
|
|
MCSection *CurSec = getCurrentSectionOnly();
|
2015-05-21 21:02:35 +00:00
|
|
|
if (ByteAlignment > CurSec->getAlignment())
|
2019-09-27 12:54:21 +00:00
|
|
|
CurSec->setAlignment(Align(ByteAlignment));
|
2012-10-04 13:12:43 +00:00
|
|
|
}
|
|
|
|
|
2020-02-14 19:21:58 -08:00
|
|
|
void MCObjectStreamer::emitCodeAlignment(unsigned ByteAlignment,
|
2021-08-06 17:42:12 +01:00
|
|
|
const MCSubtargetInfo *STI,
|
2012-10-04 13:12:43 +00:00
|
|
|
unsigned MaxBytesToEmit) {
|
2020-02-14 19:21:58 -08:00
|
|
|
emitValueToAlignment(ByteAlignment, 0, 1, MaxBytesToEmit);
|
2021-08-06 17:42:12 +01:00
|
|
|
cast<MCAlignFragment>(getCurrentFragment())->setEmitNops(true, STI);
|
2012-10-04 13:12:43 +00:00
|
|
|
}
|
|
|
|
|
2015-11-04 23:59:18 +00:00
|
|
|
void MCObjectStreamer::emitValueToOffset(const MCExpr *Offset,
|
2016-12-14 10:43:58 +00:00
|
|
|
unsigned char Value,
|
|
|
|
SMLoc Loc) {
|
|
|
|
insert(new MCOrgFragment(*Offset, Value, Loc));
|
2010-12-02 05:59:38 +00:00
|
|
|
}
|
|
|
|
|
2016-08-22 16:18:42 +00:00
|
|
|
// Associate DTPRel32 fixup with data and resize data area
|
2020-02-14 19:21:58 -08:00
|
|
|
void MCObjectStreamer::emitDTPRel32Value(const MCExpr *Value) {
|
2016-08-22 16:18:42 +00:00
|
|
|
MCDataFragment *DF = getOrCreateDataFragment();
|
|
|
|
flushPendingLabels(DF, DF->getContents().size());
|
|
|
|
|
|
|
|
DF->getFixups().push_back(MCFixup::create(DF->getContents().size(),
|
|
|
|
Value, FK_DTPRel_4));
|
|
|
|
DF->getContents().resize(DF->getContents().size() + 4, 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Associate DTPRel64 fixup with data and resize data area
|
2020-02-14 19:21:58 -08:00
|
|
|
void MCObjectStreamer::emitDTPRel64Value(const MCExpr *Value) {
|
2016-08-22 16:18:42 +00:00
|
|
|
MCDataFragment *DF = getOrCreateDataFragment();
|
|
|
|
flushPendingLabels(DF, DF->getContents().size());
|
|
|
|
|
|
|
|
DF->getFixups().push_back(MCFixup::create(DF->getContents().size(),
|
|
|
|
Value, FK_DTPRel_8));
|
|
|
|
DF->getContents().resize(DF->getContents().size() + 8, 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Associate TPRel32 fixup with data and resize data area
|
2020-02-14 19:21:58 -08:00
|
|
|
void MCObjectStreamer::emitTPRel32Value(const MCExpr *Value) {
|
2016-08-22 16:18:42 +00:00
|
|
|
MCDataFragment *DF = getOrCreateDataFragment();
|
|
|
|
flushPendingLabels(DF, DF->getContents().size());
|
|
|
|
|
|
|
|
DF->getFixups().push_back(MCFixup::create(DF->getContents().size(),
|
|
|
|
Value, FK_TPRel_4));
|
|
|
|
DF->getContents().resize(DF->getContents().size() + 4, 0);
|
|
|
|
}
|
|
|
|
|
|
|
|
// Associate TPRel64 fixup with data and resize data area
|
2020-02-14 19:21:58 -08:00
|
|
|
void MCObjectStreamer::emitTPRel64Value(const MCExpr *Value) {
|
2016-08-22 16:18:42 +00:00
|
|
|
MCDataFragment *DF = getOrCreateDataFragment();
|
|
|
|
flushPendingLabels(DF, DF->getContents().size());
|
|
|
|
|
|
|
|
DF->getFixups().push_back(MCFixup::create(DF->getContents().size(),
|
|
|
|
Value, FK_TPRel_8));
|
|
|
|
DF->getContents().resize(DF->getContents().size() + 8, 0);
|
|
|
|
}
|
|
|
|
|
2011-11-23 22:18:04 +00:00
|
|
|
// Associate GPRel32 fixup with data and resize data area
|
2020-02-14 19:21:58 -08:00
|
|
|
void MCObjectStreamer::emitGPRel32Value(const MCExpr *Value) {
|
2011-11-23 22:18:04 +00:00
|
|
|
MCDataFragment *DF = getOrCreateDataFragment();
|
2015-06-27 01:54:17 +00:00
|
|
|
flushPendingLabels(DF, DF->getContents().size());
|
2011-11-23 22:18:04 +00:00
|
|
|
|
2017-04-03 21:50:04 +00:00
|
|
|
DF->getFixups().push_back(
|
|
|
|
MCFixup::create(DF->getContents().size(), Value, FK_GPRel_4));
|
2011-11-23 22:18:04 +00:00
|
|
|
DF->getContents().resize(DF->getContents().size() + 4, 0);
|
|
|
|
}
|
|
|
|
|
2016-08-22 16:18:42 +00:00
|
|
|
// Associate GPRel64 fixup with data and resize data area
|
2020-02-14 19:21:58 -08:00
|
|
|
void MCObjectStreamer::emitGPRel64Value(const MCExpr *Value) {
|
2012-08-22 00:49:30 +00:00
|
|
|
MCDataFragment *DF = getOrCreateDataFragment();
|
2015-06-27 01:54:17 +00:00
|
|
|
flushPendingLabels(DF, DF->getContents().size());
|
2012-08-22 00:49:30 +00:00
|
|
|
|
2017-04-03 21:50:04 +00:00
|
|
|
DF->getFixups().push_back(
|
|
|
|
MCFixup::create(DF->getContents().size(), Value, FK_GPRel_4));
|
2012-08-22 00:49:30 +00:00
|
|
|
DF->getContents().resize(DF->getContents().size() + 8, 0);
|
|
|
|
}
|
|
|
|
|
[PowerPC] Extend .reloc directive on PowerPC
When the compiler generates a GOT indirect load it must generate two loads. One
that loads the address of the element from the GOT and a second to load the
actual element based on the address just loaded from the GOT. However, the
linker can optimize these two loads into one load if it knows that it is safe
to do so. The compiler can tell the linker that the optimization is safe
by using the R_PPC64_PCREL_OPT relocation.
This patch extends the .reloc directive to allow the following setup
pld 3, vec@got@pcrel(0), 1
.Lpcrel1=.-8
... More instructions possible here ...
.reloc .Lpcrel1,R_PPC64_PCREL_OPT,.-.Lpcrel1
lwa 3, 4(3)
Reviewers: nemanjai, lei, hfinkel, sfertile, efriedma, tstellar, grosbach, MaskRay
Reviewed By: nemanjai, MaskRay
Differential Revision: https://reviews.llvm.org/D79625
2020-07-21 12:54:48 -05:00
|
|
|
static Optional<std::pair<bool, std::string>>
|
|
|
|
getOffsetAndDataFragment(const MCSymbol &Symbol, uint32_t &RelocOffset,
|
|
|
|
MCDataFragment *&DF) {
|
|
|
|
if (Symbol.isVariable()) {
|
|
|
|
const MCExpr *SymbolExpr = Symbol.getVariableValue();
|
|
|
|
MCValue OffsetVal;
|
|
|
|
if(!SymbolExpr->evaluateAsRelocatable(OffsetVal, nullptr, nullptr))
|
|
|
|
return std::make_pair(false,
|
|
|
|
std::string("symbol in .reloc offset is not "
|
|
|
|
"relocatable"));
|
|
|
|
if (OffsetVal.isAbsolute()) {
|
|
|
|
RelocOffset = OffsetVal.getConstant();
|
|
|
|
MCFragment *Fragment = Symbol.getFragment();
|
|
|
|
// FIXME Support symbols with no DF. For example:
|
|
|
|
// .reloc .data, ENUM_VALUE, <some expr>
|
|
|
|
if (!Fragment || Fragment->getKind() != MCFragment::FT_Data)
|
|
|
|
return std::make_pair(false,
|
|
|
|
std::string("symbol in offset has no data "
|
|
|
|
"fragment"));
|
|
|
|
DF = cast<MCDataFragment>(Fragment);
|
|
|
|
return None;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (OffsetVal.getSymB())
|
|
|
|
return std::make_pair(false,
|
|
|
|
std::string(".reloc symbol offset is not "
|
|
|
|
"representable"));
|
|
|
|
|
|
|
|
const MCSymbolRefExpr &SRE = cast<MCSymbolRefExpr>(*OffsetVal.getSymA());
|
|
|
|
if (!SRE.getSymbol().isDefined())
|
|
|
|
return std::make_pair(false,
|
|
|
|
std::string("symbol used in the .reloc offset is "
|
|
|
|
"not defined"));
|
|
|
|
|
|
|
|
if (SRE.getSymbol().isVariable())
|
|
|
|
return std::make_pair(false,
|
|
|
|
std::string("symbol used in the .reloc offset is "
|
|
|
|
"variable"));
|
|
|
|
|
|
|
|
MCFragment *Fragment = SRE.getSymbol().getFragment();
|
|
|
|
// FIXME Support symbols with no DF. For example:
|
|
|
|
// .reloc .data, ENUM_VALUE, <some expr>
|
|
|
|
if (!Fragment || Fragment->getKind() != MCFragment::FT_Data)
|
|
|
|
return std::make_pair(false,
|
|
|
|
std::string("symbol in offset has no data "
|
|
|
|
"fragment"));
|
|
|
|
RelocOffset = SRE.getSymbol().getOffset() + OffsetVal.getConstant();
|
|
|
|
DF = cast<MCDataFragment>(Fragment);
|
|
|
|
} else {
|
|
|
|
RelocOffset = Symbol.getOffset();
|
|
|
|
MCFragment *Fragment = Symbol.getFragment();
|
|
|
|
// FIXME Support symbols with no DF. For example:
|
|
|
|
// .reloc .data, ENUM_VALUE, <some expr>
|
|
|
|
if (!Fragment || Fragment->getKind() != MCFragment::FT_Data)
|
|
|
|
return std::make_pair(false,
|
|
|
|
std::string("symbol in offset has no data "
|
|
|
|
"fragment"));
|
|
|
|
DF = cast<MCDataFragment>(Fragment);
|
|
|
|
}
|
|
|
|
return None;
|
|
|
|
}
|
|
|
|
|
2020-07-14 13:44:00 -07:00
|
|
|
Optional<std::pair<bool, std::string>>
|
|
|
|
MCObjectStreamer::emitRelocDirective(const MCExpr &Offset, StringRef Name,
|
|
|
|
const MCExpr *Expr, SMLoc Loc,
|
|
|
|
const MCSubtargetInfo &STI) {
|
2016-01-19 23:05:27 +00:00
|
|
|
Optional<MCFixupKind> MaybeKind = Assembler->getBackend().getFixupKind(Name);
|
|
|
|
if (!MaybeKind.hasValue())
|
2020-07-14 13:44:00 -07:00
|
|
|
return std::make_pair(true, std::string("unknown relocation name"));
|
2015-11-12 13:33:00 +00:00
|
|
|
|
2016-01-19 23:05:27 +00:00
|
|
|
MCFixupKind Kind = *MaybeKind;
|
|
|
|
|
2015-11-12 13:33:00 +00:00
|
|
|
if (Expr == nullptr)
|
|
|
|
Expr =
|
|
|
|
MCSymbolRefExpr::create(getContext().createTempSymbol(), getContext());
|
2018-11-21 16:28:39 +00:00
|
|
|
|
|
|
|
MCDataFragment *DF = getOrCreateDataFragment(&STI);
|
|
|
|
flushPendingLabels(DF, DF->getContents().size());
|
|
|
|
|
2020-07-14 13:44:00 -07:00
|
|
|
MCValue OffsetVal;
|
|
|
|
if (!Offset.evaluateAsRelocatable(OffsetVal, nullptr, nullptr))
|
|
|
|
return std::make_pair(false,
|
|
|
|
std::string(".reloc offset is not relocatable"));
|
|
|
|
if (OffsetVal.isAbsolute()) {
|
|
|
|
if (OffsetVal.getConstant() < 0)
|
|
|
|
return std::make_pair(false, std::string(".reloc offset is negative"));
|
|
|
|
DF->getFixups().push_back(
|
|
|
|
MCFixup::create(OffsetVal.getConstant(), Expr, Kind, Loc));
|
|
|
|
return None;
|
2018-11-21 16:28:39 +00:00
|
|
|
}
|
2020-07-14 13:44:00 -07:00
|
|
|
if (OffsetVal.getSymB())
|
|
|
|
return std::make_pair(false,
|
|
|
|
std::string(".reloc offset is not representable"));
|
2018-11-21 16:28:39 +00:00
|
|
|
|
2020-07-14 13:44:00 -07:00
|
|
|
const MCSymbolRefExpr &SRE = cast<MCSymbolRefExpr>(*OffsetVal.getSymA());
|
[PowerPC] Extend .reloc directive on PowerPC
When the compiler generates a GOT indirect load it must generate two loads. One
that loads the address of the element from the GOT and a second to load the
actual element based on the address just loaded from the GOT. However, the
linker can optimize these two loads into one load if it knows that it is safe
to do so. The compiler can tell the linker that the optimization is safe
by using the R_PPC64_PCREL_OPT relocation.
This patch extends the .reloc directive to allow the following setup
pld 3, vec@got@pcrel(0), 1
.Lpcrel1=.-8
... More instructions possible here ...
.reloc .Lpcrel1,R_PPC64_PCREL_OPT,.-.Lpcrel1
lwa 3, 4(3)
Reviewers: nemanjai, lei, hfinkel, sfertile, efriedma, tstellar, grosbach, MaskRay
Reviewed By: nemanjai, MaskRay
Differential Revision: https://reviews.llvm.org/D79625
2020-07-21 12:54:48 -05:00
|
|
|
const MCSymbol &Symbol = SRE.getSymbol();
|
|
|
|
if (Symbol.isDefined()) {
|
|
|
|
uint32_t SymbolOffset = 0;
|
|
|
|
Optional<std::pair<bool, std::string>> Error;
|
|
|
|
Error = getOffsetAndDataFragment(Symbol, SymbolOffset, DF);
|
|
|
|
|
|
|
|
if (Error != None)
|
|
|
|
return Error;
|
|
|
|
|
2020-07-14 13:44:00 -07:00
|
|
|
DF->getFixups().push_back(
|
[PowerPC] Extend .reloc directive on PowerPC
When the compiler generates a GOT indirect load it must generate two loads. One
that loads the address of the element from the GOT and a second to load the
actual element based on the address just loaded from the GOT. However, the
linker can optimize these two loads into one load if it knows that it is safe
to do so. The compiler can tell the linker that the optimization is safe
by using the R_PPC64_PCREL_OPT relocation.
This patch extends the .reloc directive to allow the following setup
pld 3, vec@got@pcrel(0), 1
.Lpcrel1=.-8
... More instructions possible here ...
.reloc .Lpcrel1,R_PPC64_PCREL_OPT,.-.Lpcrel1
lwa 3, 4(3)
Reviewers: nemanjai, lei, hfinkel, sfertile, efriedma, tstellar, grosbach, MaskRay
Reviewed By: nemanjai, MaskRay
Differential Revision: https://reviews.llvm.org/D79625
2020-07-21 12:54:48 -05:00
|
|
|
MCFixup::create(SymbolOffset + OffsetVal.getConstant(),
|
2020-07-14 13:44:00 -07:00
|
|
|
Expr, Kind, Loc));
|
|
|
|
return None;
|
2018-11-21 16:28:39 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
PendingFixups.emplace_back(&SRE.getSymbol(), DF,
|
2020-07-14 13:44:00 -07:00
|
|
|
MCFixup::create(-1, Expr, Kind, Loc));
|
|
|
|
return None;
|
2015-11-12 13:33:00 +00:00
|
|
|
}
|
|
|
|
|
2016-05-28 05:57:48 +00:00
|
|
|
void MCObjectStreamer::emitFill(const MCExpr &NumBytes, uint64_t FillValue,
|
|
|
|
SMLoc Loc) {
|
|
|
|
MCDataFragment *DF = getOrCreateDataFragment();
|
|
|
|
flushPendingLabels(DF, DF->getContents().size());
|
|
|
|
|
2018-01-09 19:29:33 +00:00
|
|
|
assert(getCurrentSectionOnly() && "need a section");
|
2018-05-18 17:45:48 +00:00
|
|
|
insert(new MCFillFragment(FillValue, 1, NumBytes, Loc));
|
2016-05-28 05:57:48 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void MCObjectStreamer::emitFill(const MCExpr &NumValues, int64_t Size,
|
|
|
|
int64_t Expr, SMLoc Loc) {
|
|
|
|
int64_t IntNumValues;
|
2018-05-18 17:45:48 +00:00
|
|
|
// Do additional checking now if we can resolve the value.
|
|
|
|
if (NumValues.evaluateAsAbsolute(IntNumValues, getAssemblerPtr())) {
|
|
|
|
if (IntNumValues < 0) {
|
|
|
|
getContext().getSourceManager()->PrintMessage(
|
|
|
|
Loc, SourceMgr::DK_Warning,
|
|
|
|
"'.fill' directive with negative repeat count has no effect");
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
// Emit now if we can for better errors.
|
|
|
|
int64_t NonZeroSize = Size > 4 ? 4 : Size;
|
|
|
|
Expr &= ~0ULL >> (64 - NonZeroSize * 8);
|
|
|
|
for (uint64_t i = 0, e = IntNumValues; i != e; ++i) {
|
2020-02-14 22:40:47 -08:00
|
|
|
emitIntValue(Expr, NonZeroSize);
|
2018-05-18 17:45:48 +00:00
|
|
|
if (NonZeroSize < Size)
|
2020-02-14 22:40:47 -08:00
|
|
|
emitIntValue(0, Size - NonZeroSize);
|
2018-05-18 17:45:48 +00:00
|
|
|
}
|
2016-05-28 05:57:48 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2018-05-18 17:45:48 +00:00
|
|
|
// Otherwise emit as fragment.
|
|
|
|
MCDataFragment *DF = getOrCreateDataFragment();
|
|
|
|
flushPendingLabels(DF, DF->getContents().size());
|
2016-05-28 05:57:48 +00:00
|
|
|
|
2018-05-18 17:45:48 +00:00
|
|
|
assert(getCurrentSectionOnly() && "need a section");
|
|
|
|
insert(new MCFillFragment(Expr, Size, NumValues, Loc));
|
2016-05-28 05:57:48 +00:00
|
|
|
}
|
|
|
|
|
2020-07-30 18:33:33 -07:00
|
|
|
void MCObjectStreamer::emitNops(int64_t NumBytes, int64_t ControlledNopLength,
|
2021-08-09 11:40:22 +01:00
|
|
|
SMLoc Loc, const MCSubtargetInfo &STI) {
|
2020-07-30 18:33:33 -07:00
|
|
|
// Emit an NOP fragment.
|
|
|
|
MCDataFragment *DF = getOrCreateDataFragment();
|
|
|
|
flushPendingLabels(DF, DF->getContents().size());
|
|
|
|
|
|
|
|
assert(getCurrentSectionOnly() && "need a section");
|
2021-08-09 11:40:22 +01:00
|
|
|
|
|
|
|
insert(new MCNopsFragment(NumBytes, ControlledNopLength, Loc, STI));
|
2020-07-30 18:33:33 -07:00
|
|
|
}
|
|
|
|
|
2020-02-15 08:52:56 -08:00
|
|
|
void MCObjectStreamer::emitFileDirective(StringRef Filename) {
|
2017-03-03 21:22:06 +00:00
|
|
|
getAssembler().addFileName(Filename);
|
|
|
|
}
|
|
|
|
|
2021-07-12 03:37:06 +00:00
|
|
|
void MCObjectStreamer::emitFileDirective(StringRef Filename,
|
|
|
|
StringRef CompilerVerion,
|
|
|
|
StringRef TimeStamp,
|
|
|
|
StringRef Description) {
|
|
|
|
getAssembler().addFileName(Filename);
|
|
|
|
// TODO: add additional info to integrated assembler.
|
|
|
|
}
|
|
|
|
|
2020-02-15 08:52:56 -08:00
|
|
|
void MCObjectStreamer::emitAddrsig() {
|
2018-07-17 22:17:18 +00:00
|
|
|
getAssembler().getWriter().emitAddrsigSection();
|
|
|
|
}
|
|
|
|
|
2020-02-15 08:52:56 -08:00
|
|
|
void MCObjectStreamer::emitAddrsigSym(const MCSymbol *Sym) {
|
2018-07-17 22:17:18 +00:00
|
|
|
getAssembler().registerSymbol(*Sym);
|
|
|
|
getAssembler().getWriter().addAddrsigSymbol(Sym);
|
|
|
|
}
|
|
|
|
|
2020-04-20 19:28:13 -07:00
|
|
|
void MCObjectStreamer::finishImpl() {
|
2018-07-11 12:30:35 +00:00
|
|
|
getContext().RemapDebugPaths();
|
2018-07-10 14:41:54 +00:00
|
|
|
|
2011-12-09 18:09:40 +00:00
|
|
|
// If we are generating dwarf for assembly source files dump out the sections.
|
|
|
|
if (getContext().getGenDwarfForAssembly())
|
2014-04-01 07:35:52 +00:00
|
|
|
MCGenDwarfInfo::Emit(this);
|
|
|
|
|
|
|
|
// Dump out the dwarf file & directory tables and line tables.
|
2021-03-04 20:47:41 -05:00
|
|
|
MCDwarfLineTable::emit(this, getAssembler().getDWARFLinetableParams());
|
2011-12-09 18:09:40 +00:00
|
|
|
|
[CSSPGO] Pseudo probe encoding and emission.
This change implements pseudo probe encoding and emission for CSSPGO. Please see RFC here for more context: https://groups.google.com/g/llvm-dev/c/1p1rdYbL93s
Pseudo probes are in the form of intrinsic calls on IR/MIR but they do not turn into any machine instructions. Instead they are emitted into the binary as a piece of data in standalone sections. The probe-specific sections are not needed to be loaded into memory at execution time, thus they do not incur a runtime overhead.
**ELF object emission**
The binary data to emit are organized as two ELF sections, i.e, the `.pseudo_probe_desc` section and the `.pseudo_probe` section. The `.pseudo_probe_desc` section stores a function descriptor for each function and the `.pseudo_probe` section stores the actual probes, each fo which corresponds to an IR basic block or an IR function callsite. A function descriptor is stored as a module-level metadata during the compilation and is serialized into the object file during object emission.
Both the probe descriptors and pseudo probes can be emitted into a separate ELF section per function to leverage the linker for deduplication. A `.pseudo_probe` section shares the same COMDAT group with the function code so that when the function is dead, the probes are dead and disposed too. On the contrary, a `.pseudo_probe_desc` section has its own COMDAT group. This is because even if a function is dead, its probes may be inlined into other functions and its descriptor is still needed by the profile generation tool.
The format of `.pseudo_probe_desc` section looks like:
```
.section .pseudo_probe_desc,"",@progbits
.quad 6309742469962978389 // Func GUID
.quad 4294967295 // Func Hash
.byte 9 // Length of func name
.ascii "_Z5funcAi" // Func name
.quad 7102633082150537521
.quad 138828622701
.byte 12
.ascii "_Z8funcLeafi"
.quad 446061515086924981
.quad 4294967295
.byte 9
.ascii "_Z5funcBi"
.quad -2016976694713209516
.quad 72617220756
.byte 7
.ascii "_Z3fibi"
```
For each `.pseudoprobe` section, the encoded binary data consists of a single function record corresponding to an outlined function (i.e, a function with a code entry in the `.text` section). A function record has the following format :
```
FUNCTION BODY (one for each outlined function present in the text section)
GUID (uint64)
GUID of the function
NPROBES (ULEB128)
Number of probes originating from this function.
NUM_INLINED_FUNCTIONS (ULEB128)
Number of callees inlined into this function, aka number of
first-level inlinees
PROBE RECORDS
A list of NPROBES entries. Each entry contains:
INDEX (ULEB128)
TYPE (uint4)
0 - block probe, 1 - indirect call, 2 - direct call
ATTRIBUTE (uint3)
reserved
ADDRESS_TYPE (uint1)
0 - code address, 1 - address delta
CODE_ADDRESS (uint64 or ULEB128)
code address or address delta, depending on ADDRESS_TYPE
INLINED FUNCTION RECORDS
A list of NUM_INLINED_FUNCTIONS entries describing each of the inlined
callees. Each record contains:
INLINE SITE
GUID of the inlinee (uint64)
ID of the callsite probe (ULEB128)
FUNCTION BODY
A FUNCTION BODY entry describing the inlined function.
```
To support building a context-sensitive profile, probes from inlinees are grouped by their inline contexts. An inline context is logically a call path through which a callee function lands in a caller function. The probe emitter builds an inline tree based on the debug metadata for each outlined function in the form of a trie tree. A tree root is the outlined function. Each tree edge stands for a callsite where inlining happens. Pseudo probes originating from an inlinee function are stored in a tree node and the tree path starting from the root all the way down to the tree node is the inline context of the probes. The emission happens on the whole tree top-down recursively. Probes of a tree node will be emitted altogether with their direct parent edge. Since a pseudo probe corresponds to a real code address, for size savings, the address is encoded as a delta from the previous probe except for the first probe. Variant-sized integer encoding, aka LEB128, is used for address delta and probe index.
**Assembling**
Pseudo probes can be printed as assembly directives alternatively. This allows for good assembly code readability and also provides a view of how optimizations and pseudo probes affect each other, especially helpful for diff time assembly analysis.
A pseudo probe directive has the following operands in order: function GUID, probe index, probe type, probe attributes and inline context. The directive is generated by the compiler and can be parsed by the assembler to form an encoded `.pseudoprobe` section in the object file.
A example assembly looks like:
```
foo2: # @foo2
# %bb.0: # %bb0
pushq %rax
testl %edi, %edi
.pseudoprobe 837061429793323041 1 0 0
je .LBB1_1
# %bb.2: # %bb2
.pseudoprobe 837061429793323041 6 2 0
callq foo
.pseudoprobe 837061429793323041 3 0 0
.pseudoprobe 837061429793323041 4 0 0
popq %rax
retq
.LBB1_1: # %bb1
.pseudoprobe 837061429793323041 5 1 0
callq *%rsi
.pseudoprobe 837061429793323041 2 0 0
.pseudoprobe 837061429793323041 4 0 0
popq %rax
retq
# -- End function
.section .pseudo_probe_desc,"",@progbits
.quad 6699318081062747564
.quad 72617220756
.byte 3
.ascii "foo"
.quad 837061429793323041
.quad 281547593931412
.byte 4
.ascii "foo2"
```
With inlining turned on, the assembly may look different around %bb2 with an inlined probe:
```
# %bb.2: # %bb2
.pseudoprobe 837061429793323041 3 0
.pseudoprobe 6699318081062747564 1 0 @ 837061429793323041:6
.pseudoprobe 837061429793323041 4 0
popq %rax
retq
```
**Disassembling**
We have a disassembling tool (llvm-profgen) that can display disassembly alongside with pseudo probes. So far it only supports ELF executable file.
An example disassembly looks like:
```
00000000002011a0 <foo2>:
2011a0: 50 push rax
2011a1: 85 ff test edi,edi
[Probe]: FUNC: foo2 Index: 1 Type: Block
2011a3: 74 02 je 2011a7 <foo2+0x7>
[Probe]: FUNC: foo2 Index: 3 Type: Block
[Probe]: FUNC: foo2 Index: 4 Type: Block
[Probe]: FUNC: foo Index: 1 Type: Block Inlined: @ foo2:6
2011a5: 58 pop rax
2011a6: c3 ret
[Probe]: FUNC: foo2 Index: 2 Type: Block
2011a7: bf 01 00 00 00 mov edi,0x1
[Probe]: FUNC: foo2 Index: 5 Type: IndirectCall
2011ac: ff d6 call rsi
[Probe]: FUNC: foo2 Index: 4 Type: Block
2011ae: 58 pop rax
2011af: c3 ret
```
Reviewed By: wmi
Differential Revision: https://reviews.llvm.org/D91878
2020-12-08 15:37:32 -08:00
|
|
|
// Emit pseudo probes for the current module.
|
|
|
|
MCPseudoProbeTable::emit(this);
|
|
|
|
|
[ MC ] Match labels to existing fragments even when switching sections.
(This commit restores the original branch (4272372c571) and applies an
additional change dropped from the original in a bad merge. This change
should address the previous bot failures. Both changes reviewed by pete.)
Summary:
This commit builds upon Derek Schuff's 2014 commit for attaching labels to
existing fragments ( Diff Revision: http://reviews.llvm.org/D5915 )
When temporary labels appear ahead of a fragment, MCObjectStreamer will
track the temporary label symbol in a "Pending Labels" list. Labels are
associated with fragments when a real fragment arrives; otherwise, an empty
data fragment will be created if the streamer's section changes or if the
stream finishes.
This commit moves the "Pending Labels" list into each MCStream, so that
this label-fragment matching process is resilient to section changes. If
the streamer emits a label in a new section, switches to another section to
do other work, then switches back to the first section and emits a
fragment, that initial label will be associated with this new fragment.
Labels will only receive empty data fragments in the case where no other
fragment exists for that section.
The downstream effects of this can be seen in Mach-O relocations. The
previous approach could produce local section relocations and external
symbol relocations for the same data in an object file, and this mix of
relocation types resulted in problems in the ld64 Mach-O linker. This
commit ensures relocations triggered by temporary labels are consistent.
Reviewers: pete, ab, dschuff
Reviewed By: pete, dschuff
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71368
2019-12-11 10:42:37 -08:00
|
|
|
// Update any remaining pending labels with empty data fragments.
|
2018-07-10 15:32:17 +00:00
|
|
|
flushPendingLabels();
|
[ MC ] Match labels to existing fragments even when switching sections.
(This commit restores the original branch (4272372c571) and applies an
additional change dropped from the original in a bad merge. This change
should address the previous bot failures. Both changes reviewed by pete.)
Summary:
This commit builds upon Derek Schuff's 2014 commit for attaching labels to
existing fragments ( Diff Revision: http://reviews.llvm.org/D5915 )
When temporary labels appear ahead of a fragment, MCObjectStreamer will
track the temporary label symbol in a "Pending Labels" list. Labels are
associated with fragments when a real fragment arrives; otherwise, an empty
data fragment will be created if the streamer's section changes or if the
stream finishes.
This commit moves the "Pending Labels" list into each MCStream, so that
this label-fragment matching process is resilient to section changes. If
the streamer emits a label in a new section, switches to another section to
do other work, then switches back to the first section and emits a
fragment, that initial label will be associated with this new fragment.
Labels will only receive empty data fragments in the case where no other
fragment exists for that section.
The downstream effects of this can be seen in Mach-O relocations. The
previous approach could produce local section relocations and external
symbol relocations for the same data in an object file, and this mix of
relocation types resulted in problems in the ld64 Mach-O linker. This
commit ensures relocations triggered by temporary labels are consistent.
Reviewers: pete, ab, dschuff
Reviewed By: pete, dschuff
Subscribers: hiraditya, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D71368
2019-12-11 10:42:37 -08:00
|
|
|
|
2018-11-21 16:28:39 +00:00
|
|
|
resolvePendingFixups();
|
2010-06-16 20:04:25 +00:00
|
|
|
getAssembler().Finish();
|
|
|
|
}
|