llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
//===- lib/MC/MCMachOStreamer.cpp - Mach-O Object Output ------------===//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "llvm/MC/MCStreamer.h"
|
|
|
|
|
|
|
|
#include "llvm/MC/MCAssembler.h"
|
|
|
|
#include "llvm/MC/MCContext.h"
|
2009-08-27 08:17:51 +00:00
|
|
|
#include "llvm/MC/MCCodeEmitter.h"
|
2009-08-31 08:08:38 +00:00
|
|
|
#include "llvm/MC/MCExpr.h"
|
2009-08-27 08:17:51 +00:00
|
|
|
#include "llvm/MC/MCInst.h"
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
#include "llvm/MC/MCSection.h"
|
|
|
|
#include "llvm/MC/MCSymbol.h"
|
2010-05-07 21:44:23 +00:00
|
|
|
#include "llvm/MC/MCMachOSymbolFlags.h"
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
#include "llvm/Support/ErrorHandling.h"
|
2009-08-27 08:17:51 +00:00
|
|
|
#include "llvm/Support/raw_ostream.h"
|
2010-03-23 05:09:03 +00:00
|
|
|
#include "llvm/Target/TargetAsmBackend.h"
|
|
|
|
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
using namespace llvm;
|
|
|
|
|
|
|
|
namespace {
|
|
|
|
|
|
|
|
class MCMachOStreamer : public MCStreamer {
|
2009-08-24 08:40:12 +00:00
|
|
|
|
|
|
|
private:
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
MCAssembler Assembler;
|
|
|
|
MCSectionData *CurSectionData;
|
2009-08-22 10:13:24 +00:00
|
|
|
|
2010-05-10 22:45:09 +00:00
|
|
|
/// Track the current atom for each section.
|
|
|
|
DenseMap<const MCSectionData*, MCSymbolData*> CurrentAtomMap;
|
|
|
|
|
2009-08-22 10:13:24 +00:00
|
|
|
private:
|
|
|
|
MCFragment *getCurrentFragment() const {
|
|
|
|
assert(CurSectionData && "No current section!");
|
|
|
|
|
|
|
|
if (!CurSectionData->empty())
|
|
|
|
return &CurSectionData->getFragmentList().back();
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2010-03-22 20:35:46 +00:00
|
|
|
/// Get a data fragment to write into, creating a new one if the current
|
|
|
|
/// fragment is not a data fragment.
|
|
|
|
MCDataFragment *getOrCreateDataFragment() const {
|
|
|
|
MCDataFragment *F = dyn_cast_or_null<MCDataFragment>(getCurrentFragment());
|
|
|
|
if (!F)
|
2010-05-10 22:45:09 +00:00
|
|
|
F = createDataFragment();
|
2010-03-22 20:35:46 +00:00
|
|
|
return F;
|
|
|
|
}
|
|
|
|
|
2010-05-10 22:45:09 +00:00
|
|
|
/// Create a new data fragment in the current section.
|
|
|
|
MCDataFragment *createDataFragment() const {
|
|
|
|
MCDataFragment *DF = new MCDataFragment(CurSectionData);
|
|
|
|
DF->setAtom(CurrentAtomMap.lookup(CurSectionData));
|
|
|
|
return DF;
|
|
|
|
}
|
|
|
|
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
public:
|
2010-03-11 01:34:27 +00:00
|
|
|
MCMachOStreamer(MCContext &Context, TargetAsmBackend &TAB,
|
|
|
|
raw_ostream &_OS, MCCodeEmitter *_Emitter)
|
2010-03-19 10:43:18 +00:00
|
|
|
: MCStreamer(Context), Assembler(Context, TAB, *_Emitter, _OS),
|
2009-08-27 08:17:51 +00:00
|
|
|
CurSectionData(0) {}
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
~MCMachOStreamer() {}
|
|
|
|
|
2010-03-25 22:49:09 +00:00
|
|
|
MCAssembler &getAssembler() { return Assembler; }
|
|
|
|
|
2009-08-31 08:08:38 +00:00
|
|
|
const MCExpr *AddValueSymbols(const MCExpr *Value) {
|
|
|
|
switch (Value->getKind()) {
|
2010-02-08 19:41:07 +00:00
|
|
|
case MCExpr::Target: assert(0 && "Can't handle target exprs yet!");
|
2009-08-31 08:08:38 +00:00
|
|
|
case MCExpr::Constant:
|
|
|
|
break;
|
|
|
|
|
|
|
|
case MCExpr::Binary: {
|
|
|
|
const MCBinaryExpr *BE = cast<MCBinaryExpr>(Value);
|
|
|
|
AddValueSymbols(BE->getLHS());
|
|
|
|
AddValueSymbols(BE->getRHS());
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
case MCExpr::SymbolRef:
|
2010-03-10 20:58:29 +00:00
|
|
|
Assembler.getOrCreateSymbolData(
|
|
|
|
cast<MCSymbolRefExpr>(Value)->getSymbol());
|
2009-08-31 08:08:38 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
case MCExpr::Unary:
|
|
|
|
AddValueSymbols(cast<MCUnaryExpr>(Value)->getSubExpr());
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return Value;
|
|
|
|
}
|
|
|
|
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
/// @name MCStreamer Interface
|
|
|
|
/// @{
|
|
|
|
|
|
|
|
virtual void SwitchSection(const MCSection *Section);
|
|
|
|
virtual void EmitLabel(MCSymbol *Symbol);
|
2010-01-23 06:39:22 +00:00
|
|
|
virtual void EmitAssemblerFlag(MCAssemblerFlag Flag);
|
2009-08-31 08:09:28 +00:00
|
|
|
virtual void EmitAssignment(MCSymbol *Symbol, const MCExpr *Value);
|
2010-01-23 06:39:22 +00:00
|
|
|
virtual void EmitSymbolAttribute(MCSymbol *Symbol, MCSymbolAttr Attribute);
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
virtual void EmitSymbolDesc(MCSymbol *Symbol, unsigned DescValue);
|
2010-01-23 07:47:02 +00:00
|
|
|
virtual void EmitCommonSymbol(MCSymbol *Symbol, uint64_t Size,
|
2009-08-30 06:17:16 +00:00
|
|
|
unsigned ByteAlignment);
|
2010-05-08 19:54:22 +00:00
|
|
|
virtual void BeginCOFFSymbolDef(const MCSymbol *Symbol) {
|
|
|
|
assert(0 && "macho doesn't support this directive");
|
|
|
|
}
|
|
|
|
virtual void EmitCOFFSymbolStorageClass(int StorageClass) {
|
|
|
|
assert(0 && "macho doesn't support this directive");
|
|
|
|
}
|
|
|
|
virtual void EmitCOFFSymbolType(int Type) {
|
|
|
|
assert(0 && "macho doesn't support this directive");
|
|
|
|
}
|
|
|
|
virtual void EndCOFFSymbolDef() {
|
|
|
|
assert(0 && "macho doesn't support this directive");
|
|
|
|
}
|
2010-01-25 07:52:13 +00:00
|
|
|
virtual void EmitELFSize(MCSymbol *Symbol, const MCExpr *Value) {
|
|
|
|
assert(0 && "macho doesn't support this directive");
|
|
|
|
}
|
2010-01-23 07:47:02 +00:00
|
|
|
virtual void EmitLocalCommonSymbol(MCSymbol *Symbol, uint64_t Size) {
|
|
|
|
assert(0 && "macho doesn't support this directive");
|
|
|
|
}
|
2009-08-28 05:48:22 +00:00
|
|
|
virtual void EmitZerofill(const MCSection *Section, MCSymbol *Symbol = 0,
|
2009-08-30 06:17:16 +00:00
|
|
|
unsigned Size = 0, unsigned ByteAlignment = 0);
|
2010-05-18 21:26:41 +00:00
|
|
|
virtual void EmitTBSSSymbol(const MCSection *Section, MCSymbol *Symbol,
|
|
|
|
uint64_t Size, unsigned ByteAlignment = 0);
|
2010-01-19 19:46:13 +00:00
|
|
|
virtual void EmitBytes(StringRef Data, unsigned AddrSpace);
|
|
|
|
virtual void EmitValue(const MCExpr *Value, unsigned Size,unsigned AddrSpace);
|
2010-01-25 21:28:50 +00:00
|
|
|
virtual void EmitGPRel32Value(const MCExpr *Value) {
|
|
|
|
assert(0 && "macho doesn't support this directive");
|
|
|
|
}
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
virtual void EmitValueToAlignment(unsigned ByteAlignment, int64_t Value = 0,
|
|
|
|
unsigned ValueSize = 1,
|
|
|
|
unsigned MaxBytesToEmit = 0);
|
2010-02-23 18:26:34 +00:00
|
|
|
virtual void EmitCodeAlignment(unsigned ByteAlignment,
|
|
|
|
unsigned MaxBytesToEmit = 0);
|
2009-08-31 08:09:28 +00:00
|
|
|
virtual void EmitValueToOffset(const MCExpr *Offset,
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
unsigned char Value = 0);
|
2010-01-25 18:58:59 +00:00
|
|
|
|
|
|
|
virtual void EmitFileDirective(StringRef Filename) {
|
2010-05-18 17:28:17 +00:00
|
|
|
report_fatal_error("unsupported directive: '.file'");
|
2010-01-25 18:58:59 +00:00
|
|
|
}
|
|
|
|
virtual void EmitDwarfFileDirective(unsigned FileNo, StringRef Filename) {
|
2010-05-18 17:28:17 +00:00
|
|
|
report_fatal_error("unsupported directive: '.file'");
|
2010-01-25 18:58:59 +00:00
|
|
|
}
|
|
|
|
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
virtual void EmitInstruction(const MCInst &Inst);
|
|
|
|
virtual void Finish();
|
|
|
|
|
|
|
|
/// @}
|
|
|
|
};
|
|
|
|
|
|
|
|
} // end anonymous namespace.
|
|
|
|
|
|
|
|
void MCMachOStreamer::SwitchSection(const MCSection *Section) {
|
|
|
|
assert(Section && "Cannot switch to a null section!");
|
2009-08-22 19:35:08 +00:00
|
|
|
|
|
|
|
// If already in this section, then this is a noop.
|
|
|
|
if (Section == CurSection) return;
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
|
2009-08-28 05:48:54 +00:00
|
|
|
CurSection = Section;
|
2010-03-10 20:58:29 +00:00
|
|
|
CurSectionData = &Assembler.getOrCreateSectionData(*Section);
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void MCMachOStreamer::EmitLabel(MCSymbol *Symbol) {
|
2009-08-22 07:22:36 +00:00
|
|
|
assert(Symbol->isUndefined() && "Cannot define a symbol twice!");
|
2010-05-05 19:01:00 +00:00
|
|
|
assert(!Symbol->isVariable() && "Cannot emit a variable symbol!");
|
|
|
|
assert(CurSection && "Cannot emit before setting section!");
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
|
2010-05-10 22:45:09 +00:00
|
|
|
MCSymbolData &SD = Assembler.getOrCreateSymbolData(*Symbol);
|
|
|
|
|
|
|
|
// Update the current atom map, if necessary.
|
|
|
|
bool MustCreateFragment = false;
|
|
|
|
if (Assembler.isSymbolLinkerVisible(&SD)) {
|
|
|
|
CurrentAtomMap[CurSectionData] = &SD;
|
|
|
|
|
|
|
|
// We have to create a new fragment, fragments cannot span atoms.
|
|
|
|
MustCreateFragment = true;
|
|
|
|
}
|
|
|
|
|
2010-03-22 20:35:46 +00:00
|
|
|
// FIXME: This is wasteful, we don't necessarily need to create a data
|
|
|
|
// fragment. Instead, we should mark the symbol as pointing into the data
|
|
|
|
// fragment if it exists, otherwise we should just queue the label and set its
|
|
|
|
// fragment pointer when we emit the next fragment.
|
2010-05-10 22:45:09 +00:00
|
|
|
MCDataFragment *F =
|
|
|
|
MustCreateFragment ? createDataFragment() : getOrCreateDataFragment();
|
2009-08-22 10:13:24 +00:00
|
|
|
assert(!SD.getFragment() && "Unexpected fragment on symbol data!");
|
|
|
|
SD.setFragment(F);
|
|
|
|
SD.setOffset(F->getContents().size());
|
2009-08-24 08:40:12 +00:00
|
|
|
|
2010-05-17 20:12:31 +00:00
|
|
|
// This causes the reference type flag to be cleared. Darwin 'as' was "trying"
|
|
|
|
// to clear the weak reference and weak definition bits too, but the
|
|
|
|
// implementation was buggy. For now we just try to match 'as', for
|
|
|
|
// diffability.
|
|
|
|
//
|
|
|
|
// FIXME: Cleanup this code, these bits should be emitted based on semantic
|
|
|
|
// properties, not on the order of definition, etc.
|
|
|
|
SD.setFlags(SD.getFlags() & ~SF_ReferenceTypeMask);
|
2009-08-22 10:13:24 +00:00
|
|
|
|
2009-08-22 07:22:36 +00:00
|
|
|
Symbol->setSection(*CurSection);
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
}
|
|
|
|
|
2010-01-23 06:39:22 +00:00
|
|
|
void MCMachOStreamer::EmitAssemblerFlag(MCAssemblerFlag Flag) {
|
2009-08-26 21:22:22 +00:00
|
|
|
switch (Flag) {
|
2010-01-23 06:39:22 +00:00
|
|
|
case MCAF_SubsectionsViaSymbols:
|
2009-08-26 21:22:22 +00:00
|
|
|
Assembler.setSubsectionsViaSymbols(true);
|
2009-08-28 07:08:47 +00:00
|
|
|
return;
|
2009-08-26 21:22:22 +00:00
|
|
|
}
|
2009-08-28 07:08:47 +00:00
|
|
|
|
|
|
|
assert(0 && "invalid assembler flag!");
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
}
|
|
|
|
|
2009-08-31 08:09:28 +00:00
|
|
|
void MCMachOStreamer::EmitAssignment(MCSymbol *Symbol, const MCExpr *Value) {
|
2009-10-16 01:58:23 +00:00
|
|
|
// FIXME: Lift context changes into super class.
|
2010-05-18 17:28:24 +00:00
|
|
|
Assembler.getOrCreateSymbolData(*Symbol);
|
2010-05-05 17:41:00 +00:00
|
|
|
Symbol->setVariableValue(AddValueSymbols(Value));
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void MCMachOStreamer::EmitSymbolAttribute(MCSymbol *Symbol,
|
2010-01-23 06:39:22 +00:00
|
|
|
MCSymbolAttr Attribute) {
|
2009-08-24 11:56:58 +00:00
|
|
|
// Indirect symbols are handled differently, to match how 'as' handles
|
|
|
|
// them. This makes writing matching .o files easier.
|
2010-01-23 06:39:22 +00:00
|
|
|
if (Attribute == MCSA_IndirectSymbol) {
|
2009-08-26 00:18:21 +00:00
|
|
|
// Note that we intentionally cannot use the symbol data here; this is
|
|
|
|
// important for matching the string table that 'as' generates.
|
2009-08-24 11:56:58 +00:00
|
|
|
IndirectSymbolData ISD;
|
|
|
|
ISD.Symbol = Symbol;
|
|
|
|
ISD.SectionData = CurSectionData;
|
|
|
|
Assembler.getIndirectSymbols().push_back(ISD);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2009-08-24 08:40:12 +00:00
|
|
|
// Adding a symbol attribute always introduces the symbol, note that an
|
2010-03-10 20:58:29 +00:00
|
|
|
// important side effect of calling getOrCreateSymbolData here is to register
|
|
|
|
// the symbol with the assembler.
|
|
|
|
MCSymbolData &SD = Assembler.getOrCreateSymbolData(*Symbol);
|
2009-08-24 08:40:12 +00:00
|
|
|
|
|
|
|
// The implementation of symbol attributes is designed to match 'as', but it
|
|
|
|
// leaves much to desired. It doesn't really make sense to arbitrarily add and
|
|
|
|
// remove flags, but 'as' allows this (in particular, see .desc).
|
|
|
|
//
|
|
|
|
// In the future it might be worth trying to make these operations more well
|
|
|
|
// defined.
|
2009-08-22 11:41:10 +00:00
|
|
|
switch (Attribute) {
|
2010-01-23 06:39:22 +00:00
|
|
|
case MCSA_Invalid:
|
2010-01-25 18:30:45 +00:00
|
|
|
case MCSA_ELF_TypeFunction:
|
|
|
|
case MCSA_ELF_TypeIndFunction:
|
|
|
|
case MCSA_ELF_TypeObject:
|
|
|
|
case MCSA_ELF_TypeTLS:
|
|
|
|
case MCSA_ELF_TypeCommon:
|
|
|
|
case MCSA_ELF_TypeNoType:
|
2010-01-23 06:39:22 +00:00
|
|
|
case MCSA_IndirectSymbol:
|
|
|
|
case MCSA_Hidden:
|
|
|
|
case MCSA_Internal:
|
|
|
|
case MCSA_Protected:
|
|
|
|
case MCSA_Weak:
|
|
|
|
case MCSA_Local:
|
2009-08-24 08:40:12 +00:00
|
|
|
assert(0 && "Invalid symbol attribute for Mach-O!");
|
|
|
|
break;
|
2009-08-22 11:41:10 +00:00
|
|
|
|
2010-01-23 06:39:22 +00:00
|
|
|
case MCSA_Global:
|
2009-08-28 07:08:35 +00:00
|
|
|
SD.setExternal(true);
|
2010-05-17 20:12:31 +00:00
|
|
|
// This effectively clears the undefined lazy bit, in Darwin 'as', although
|
|
|
|
// it isn't very consistent because it implements this as part of symbol
|
|
|
|
// lookup.
|
|
|
|
//
|
|
|
|
// FIXME: Cleanup this code, these bits should be emitted based on semantic
|
|
|
|
// properties, not on the order of definition, etc.
|
|
|
|
SD.setFlags(SD.getFlags() & ~SF_ReferenceTypeUndefinedLazy);
|
2009-08-22 11:41:10 +00:00
|
|
|
break;
|
2009-08-24 08:40:12 +00:00
|
|
|
|
2010-01-23 06:39:22 +00:00
|
|
|
case MCSA_LazyReference:
|
2009-08-24 08:40:12 +00:00
|
|
|
// FIXME: This requires -dynamic.
|
|
|
|
SD.setFlags(SD.getFlags() | SF_NoDeadStrip);
|
|
|
|
if (Symbol->isUndefined())
|
|
|
|
SD.setFlags(SD.getFlags() | SF_ReferenceTypeUndefinedLazy);
|
|
|
|
break;
|
|
|
|
|
|
|
|
// Since .reference sets the no dead strip bit, it is equivalent to
|
|
|
|
// .no_dead_strip in practice.
|
2010-01-23 06:39:22 +00:00
|
|
|
case MCSA_Reference:
|
|
|
|
case MCSA_NoDeadStrip:
|
2009-08-24 08:40:12 +00:00
|
|
|
SD.setFlags(SD.getFlags() | SF_NoDeadStrip);
|
|
|
|
break;
|
|
|
|
|
2010-01-23 06:39:22 +00:00
|
|
|
case MCSA_PrivateExtern:
|
2009-08-24 08:40:12 +00:00
|
|
|
SD.setExternal(true);
|
|
|
|
SD.setPrivateExtern(true);
|
|
|
|
break;
|
|
|
|
|
2010-01-23 06:39:22 +00:00
|
|
|
case MCSA_WeakReference:
|
2009-08-24 08:40:12 +00:00
|
|
|
// FIXME: This requires -dynamic.
|
|
|
|
if (Symbol->isUndefined())
|
|
|
|
SD.setFlags(SD.getFlags() | SF_WeakReference);
|
|
|
|
break;
|
|
|
|
|
2010-01-23 06:39:22 +00:00
|
|
|
case MCSA_WeakDefinition:
|
2009-08-24 08:40:12 +00:00
|
|
|
// FIXME: 'as' enforces that this is defined and global. The manual claims
|
|
|
|
// it has to be in a coalesced section, but this isn't enforced.
|
|
|
|
SD.setFlags(SD.getFlags() | SF_WeakDefinition);
|
|
|
|
break;
|
2009-08-22 11:41:10 +00:00
|
|
|
}
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void MCMachOStreamer::EmitSymbolDesc(MCSymbol *Symbol, unsigned DescValue) {
|
2009-08-24 08:40:12 +00:00
|
|
|
// Encode the 'desc' value into the lowest implementation defined bits.
|
|
|
|
assert(DescValue == (DescValue & SF_DescFlagsMask) &&
|
|
|
|
"Invalid .desc value!");
|
2010-03-10 20:58:29 +00:00
|
|
|
Assembler.getOrCreateSymbolData(*Symbol).setFlags(DescValue&SF_DescFlagsMask);
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
}
|
|
|
|
|
2010-01-23 07:47:02 +00:00
|
|
|
void MCMachOStreamer::EmitCommonSymbol(MCSymbol *Symbol, uint64_t Size,
|
2009-08-30 06:17:16 +00:00
|
|
|
unsigned ByteAlignment) {
|
2009-08-28 07:08:35 +00:00
|
|
|
// FIXME: Darwin 'as' does appear to allow redef of a .comm by itself.
|
|
|
|
assert(Symbol->isUndefined() && "Cannot define a symbol twice!");
|
|
|
|
|
2010-03-10 20:58:29 +00:00
|
|
|
MCSymbolData &SD = Assembler.getOrCreateSymbolData(*Symbol);
|
2009-08-28 07:08:35 +00:00
|
|
|
SD.setExternal(true);
|
2009-08-30 06:17:16 +00:00
|
|
|
SD.setCommon(Size, ByteAlignment);
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
}
|
|
|
|
|
2009-08-28 05:48:22 +00:00
|
|
|
void MCMachOStreamer::EmitZerofill(const MCSection *Section, MCSymbol *Symbol,
|
2009-08-30 06:17:16 +00:00
|
|
|
unsigned Size, unsigned ByteAlignment) {
|
2010-03-10 20:58:29 +00:00
|
|
|
MCSectionData &SectData = Assembler.getOrCreateSectionData(*Section);
|
2009-08-28 05:49:21 +00:00
|
|
|
|
|
|
|
// The symbol may not be present, which only creates the section.
|
|
|
|
if (!Symbol)
|
|
|
|
return;
|
|
|
|
|
|
|
|
// FIXME: Assert that this section has the zerofill type.
|
|
|
|
|
|
|
|
assert(Symbol->isUndefined() && "Cannot define a symbol twice!");
|
|
|
|
|
2010-03-10 20:58:29 +00:00
|
|
|
MCSymbolData &SD = Assembler.getOrCreateSymbolData(*Symbol);
|
2009-08-28 05:49:21 +00:00
|
|
|
|
2010-05-12 22:51:27 +00:00
|
|
|
// Emit an align fragment if necessary.
|
|
|
|
if (ByteAlignment != 1)
|
2010-05-12 22:56:23 +00:00
|
|
|
new MCAlignFragment(ByteAlignment, 0, 0, ByteAlignment, &SectData);
|
2010-05-12 22:51:27 +00:00
|
|
|
|
2010-05-12 22:51:38 +00:00
|
|
|
MCFragment *F = new MCFillFragment(0, 0, Size, &SectData);
|
2009-08-28 05:49:21 +00:00
|
|
|
SD.setFragment(F);
|
2010-05-10 22:45:09 +00:00
|
|
|
if (Assembler.isSymbolLinkerVisible(&SD))
|
|
|
|
F->setAtom(&SD);
|
2009-08-28 05:49:21 +00:00
|
|
|
|
|
|
|
Symbol->setSection(*Section);
|
|
|
|
|
|
|
|
// Update the maximum alignment on the zero fill section if necessary.
|
|
|
|
if (ByteAlignment > SectData.getAlignment())
|
|
|
|
SectData.setAlignment(ByteAlignment);
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
}
|
|
|
|
|
2010-05-21 23:03:53 +00:00
|
|
|
// This should always be called with the thread local bss section. Like the
|
|
|
|
// .zerofill directive this doesn't actually switch sections on us.
|
2010-05-18 21:26:41 +00:00
|
|
|
void MCMachOStreamer::EmitTBSSSymbol(const MCSection *Section, MCSymbol *Symbol,
|
|
|
|
uint64_t Size, unsigned ByteAlignment) {
|
|
|
|
EmitZerofill(Section, Symbol, Size, ByteAlignment);
|
|
|
|
return;
|
2010-05-14 01:50:28 +00:00
|
|
|
}
|
|
|
|
|
2010-01-19 19:46:13 +00:00
|
|
|
void MCMachOStreamer::EmitBytes(StringRef Data, unsigned AddrSpace) {
|
2010-03-22 20:35:46 +00:00
|
|
|
getOrCreateDataFragment()->getContents().append(Data.begin(), Data.end());
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
}
|
|
|
|
|
2010-01-19 19:46:13 +00:00
|
|
|
void MCMachOStreamer::EmitValue(const MCExpr *Value, unsigned Size,
|
|
|
|
unsigned AddrSpace) {
|
2010-03-22 20:35:46 +00:00
|
|
|
MCDataFragment *DF = getOrCreateDataFragment();
|
2010-02-13 09:28:22 +00:00
|
|
|
|
|
|
|
// Avoid fixups when possible.
|
|
|
|
int64_t AbsValue;
|
2010-02-22 22:08:57 +00:00
|
|
|
if (AddValueSymbols(Value)->EvaluateAsAbsolute(AbsValue)) {
|
2010-02-13 09:28:22 +00:00
|
|
|
// FIXME: Endianness assumption.
|
|
|
|
for (unsigned i = 0; i != Size; ++i)
|
|
|
|
DF->getContents().push_back(uint8_t(AbsValue >> (i * 8)));
|
|
|
|
} else {
|
2010-05-26 15:18:56 +00:00
|
|
|
DF->addFixup(MCFixup::Create(DF->getContents().size(),
|
|
|
|
AddValueSymbols(Value),
|
|
|
|
MCFixup::getKindForSize(Size)));
|
2010-02-13 09:28:22 +00:00
|
|
|
DF->getContents().resize(DF->getContents().size() + Size, 0);
|
|
|
|
}
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void MCMachOStreamer::EmitValueToAlignment(unsigned ByteAlignment,
|
|
|
|
int64_t Value, unsigned ValueSize,
|
|
|
|
unsigned MaxBytesToEmit) {
|
2009-08-21 23:07:38 +00:00
|
|
|
if (MaxBytesToEmit == 0)
|
|
|
|
MaxBytesToEmit = ByteAlignment;
|
2010-05-10 22:45:09 +00:00
|
|
|
MCFragment *F = new MCAlignFragment(ByteAlignment, Value, ValueSize,
|
2010-05-12 22:56:23 +00:00
|
|
|
MaxBytesToEmit, CurSectionData);
|
2010-05-10 22:45:09 +00:00
|
|
|
F->setAtom(CurrentAtomMap.lookup(CurSectionData));
|
2010-02-23 18:26:34 +00:00
|
|
|
|
|
|
|
// Update the maximum alignment on the current section if necessary.
|
|
|
|
if (ByteAlignment > CurSectionData->getAlignment())
|
|
|
|
CurSectionData->setAlignment(ByteAlignment);
|
|
|
|
}
|
|
|
|
|
|
|
|
void MCMachOStreamer::EmitCodeAlignment(unsigned ByteAlignment,
|
|
|
|
unsigned MaxBytesToEmit) {
|
|
|
|
if (MaxBytesToEmit == 0)
|
|
|
|
MaxBytesToEmit = ByteAlignment;
|
2010-05-12 22:56:23 +00:00
|
|
|
MCAlignFragment *F = new MCAlignFragment(ByteAlignment, 0, 1, MaxBytesToEmit,
|
|
|
|
CurSectionData);
|
|
|
|
F->setEmitNops(true);
|
2010-05-10 22:45:09 +00:00
|
|
|
F->setAtom(CurrentAtomMap.lookup(CurSectionData));
|
2009-08-21 18:29:01 +00:00
|
|
|
|
2009-08-22 10:13:24 +00:00
|
|
|
// Update the maximum alignment on the current section if necessary.
|
2009-08-21 18:29:01 +00:00
|
|
|
if (ByteAlignment > CurSectionData->getAlignment())
|
|
|
|
CurSectionData->setAlignment(ByteAlignment);
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
}
|
|
|
|
|
2009-08-31 08:09:28 +00:00
|
|
|
void MCMachOStreamer::EmitValueToOffset(const MCExpr *Offset,
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
unsigned char Value) {
|
2010-05-10 22:45:09 +00:00
|
|
|
MCFragment *F = new MCOrgFragment(*Offset, Value, CurSectionData);
|
|
|
|
F->setAtom(CurrentAtomMap.lookup(CurSectionData));
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void MCMachOStreamer::EmitInstruction(const MCInst &Inst) {
|
2009-08-27 08:17:51 +00:00
|
|
|
// Scan for values.
|
2010-05-17 21:19:59 +00:00
|
|
|
for (unsigned i = Inst.getNumOperands(); i--; )
|
2009-08-31 08:08:38 +00:00
|
|
|
if (Inst.getOperand(i).isExpr())
|
|
|
|
AddValueSymbols(Inst.getOperand(i).getExpr());
|
2009-08-27 08:17:51 +00:00
|
|
|
|
2010-02-02 21:44:01 +00:00
|
|
|
CurSectionData->setHasInstructions(true);
|
|
|
|
|
2010-03-22 23:16:48 +00:00
|
|
|
// FIXME-PERF: Common case is that we don't need to relax, encode directly
|
|
|
|
// onto the data fragments buffers.
|
|
|
|
|
2010-02-09 22:59:55 +00:00
|
|
|
SmallVector<MCFixup, 4> Fixups;
|
2009-08-27 08:17:51 +00:00
|
|
|
SmallString<256> Code;
|
|
|
|
raw_svector_ostream VecOS(Code);
|
2010-03-19 10:43:18 +00:00
|
|
|
Assembler.getEmitter().EncodeInstruction(Inst, VecOS, Fixups);
|
2010-02-13 09:29:02 +00:00
|
|
|
VecOS.flush();
|
|
|
|
|
2010-03-23 05:09:03 +00:00
|
|
|
// See if we might need to relax this instruction, if so it needs its own
|
|
|
|
// fragment.
|
|
|
|
//
|
|
|
|
// FIXME-PERF: Support target hook to do a fast path that avoids the encoder,
|
|
|
|
// when we can immediately tell that we will get something which might need
|
|
|
|
// relaxation (and compute its size).
|
|
|
|
//
|
|
|
|
// FIXME-PERF: We should also be smart about immediately relaxing instructions
|
|
|
|
// which we can already show will never possibly fit (we can also do a very
|
|
|
|
// good job of this before we do the first relaxation pass, because we have
|
|
|
|
// total knowledge about undefined symbols at that point). Even now, though,
|
|
|
|
// we can do a decent job, especially on Darwin where scattering means that we
|
|
|
|
// are going to often know that we can never fully resolve a fixup.
|
2010-05-26 17:45:29 +00:00
|
|
|
if (Assembler.getBackend().MayNeedRelaxation(Inst)) {
|
2010-03-23 05:09:03 +00:00
|
|
|
MCInstFragment *IF = new MCInstFragment(Inst, CurSectionData);
|
2010-05-10 22:45:09 +00:00
|
|
|
IF->setAtom(CurrentAtomMap.lookup(CurSectionData));
|
2010-03-23 05:09:03 +00:00
|
|
|
|
|
|
|
// Add the fixups and data.
|
|
|
|
//
|
|
|
|
// FIXME: Revisit this design decision when relaxation is done, we may be
|
|
|
|
// able to get away with not storing any extra data in the MCInst.
|
|
|
|
IF->getCode() = Code;
|
2010-05-26 17:50:16 +00:00
|
|
|
IF->getFixups() = Fixups;
|
2010-03-23 05:09:03 +00:00
|
|
|
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2010-03-23 03:13:05 +00:00
|
|
|
// Add the fixups and data.
|
|
|
|
MCDataFragment *DF = getOrCreateDataFragment();
|
2010-05-26 17:50:16 +00:00
|
|
|
for (unsigned i = 0, e = Fixups.size(); i != e; ++i) {
|
|
|
|
Fixups[i].setOffset(Fixups[i].getOffset() + DF->getContents().size());
|
|
|
|
DF->addFixup(Fixups[i]);
|
2010-02-13 09:29:02 +00:00
|
|
|
}
|
|
|
|
DF->getContents().append(Code.begin(), Code.end());
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void MCMachOStreamer::Finish() {
|
|
|
|
Assembler.Finish();
|
|
|
|
}
|
|
|
|
|
2010-03-11 01:34:27 +00:00
|
|
|
MCStreamer *llvm::createMachOStreamer(MCContext &Context, TargetAsmBackend &TAB,
|
2010-03-25 22:49:09 +00:00
|
|
|
raw_ostream &OS, MCCodeEmitter *CE,
|
|
|
|
bool RelaxAll) {
|
|
|
|
MCMachOStreamer *S = new MCMachOStreamer(Context, TAB, OS, CE);
|
|
|
|
if (RelaxAll)
|
|
|
|
S->getAssembler().setRelaxAll(true);
|
|
|
|
return S;
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
}
|