2013-09-04 22:35:41 +00:00
|
|
|
//===-- MCMachOStreamer.cpp - MachO Streamer ------------------------------===//
|
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
|
|
|
//
|
|
|
|
// 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"
|
2012-12-03 16:50:05 +00:00
|
|
|
#include "llvm/MC/MCAsmBackend.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/MCAssembler.h"
|
2009-08-27 08:17:51 +00:00
|
|
|
#include "llvm/MC/MCCodeEmitter.h"
|
2012-12-03 16:50:05 +00:00
|
|
|
#include "llvm/MC/MCContext.h"
|
|
|
|
#include "llvm/MC/MCDwarf.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"
|
2012-12-03 16:50:05 +00:00
|
|
|
#include "llvm/MC/MCMachOSymbolFlags.h"
|
2014-01-23 22:49:25 +00:00
|
|
|
#include "llvm/MC/MCObjectFileInfo.h"
|
2010-06-16 20:04:22 +00:00
|
|
|
#include "llvm/MC/MCObjectStreamer.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"
|
2010-08-09 22:52:14 +00:00
|
|
|
#include "llvm/MC/MCSectionMachO.h"
|
2012-12-03 16:50:05 +00:00
|
|
|
#include "llvm/MC/MCSymbol.h"
|
2010-09-30 16:52:03 +00:00
|
|
|
#include "llvm/Support/Dwarf.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
|
|
|
|
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 {
|
|
|
|
|
2010-06-16 20:04:22 +00:00
|
|
|
class MCMachOStreamer : public MCObjectStreamer {
|
2009-08-22 10:13:24 +00:00
|
|
|
private:
|
2014-01-28 23:12:49 +00:00
|
|
|
virtual void EmitInstToData(const MCInst &Inst, const MCSubtargetInfo &STI);
|
2010-05-26 20:37:00 +00:00
|
|
|
|
2012-05-18 19:12:01 +00:00
|
|
|
void EmitDataRegion(DataRegionData::KindTy Kind);
|
|
|
|
void EmitDataRegionEnd();
|
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:
|
2013-01-31 23:29:57 +00:00
|
|
|
MCMachOStreamer(MCContext &Context, MCAsmBackend &MAB, raw_ostream &OS,
|
|
|
|
MCCodeEmitter *Emitter)
|
2014-01-26 06:06:37 +00:00
|
|
|
: MCObjectStreamer(Context, MAB, OS, Emitter) {}
|
2010-03-25 22:49:09 +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
|
|
|
/// @name MCStreamer Interface
|
|
|
|
/// @{
|
|
|
|
|
|
|
|
virtual void EmitLabel(MCSymbol *Symbol);
|
2012-12-16 04:00:45 +00:00
|
|
|
virtual void EmitDebugLabel(MCSymbol *Symbol);
|
2011-04-28 12:50:37 +00:00
|
|
|
virtual void EmitEHSymAttributes(const MCSymbol *Symbol,
|
|
|
|
MCSymbol *EHSymbol);
|
2010-01-23 06:39:22 +00:00
|
|
|
virtual void EmitAssemblerFlag(MCAssemblerFlag Flag);
|
2013-01-18 01:26:07 +00:00
|
|
|
virtual void EmitLinkerOptions(ArrayRef<std::string> Options);
|
2012-05-18 19:12:01 +00:00
|
|
|
virtual void EmitDataRegion(MCDataRegionType Kind);
|
2010-11-05 22:08:08 +00:00
|
|
|
virtual void EmitThumbFunc(MCSymbol *Func);
|
2013-08-09 01:52:03 +00:00
|
|
|
virtual bool 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) {
|
2012-02-07 05:05:23 +00:00
|
|
|
llvm_unreachable("macho doesn't support this directive");
|
2010-05-08 19:54:22 +00:00
|
|
|
}
|
|
|
|
virtual void EmitCOFFSymbolStorageClass(int StorageClass) {
|
2012-02-07 05:05:23 +00:00
|
|
|
llvm_unreachable("macho doesn't support this directive");
|
2010-05-08 19:54:22 +00:00
|
|
|
}
|
|
|
|
virtual void EmitCOFFSymbolType(int Type) {
|
2012-02-07 05:05:23 +00:00
|
|
|
llvm_unreachable("macho doesn't support this directive");
|
2010-05-08 19:54:22 +00:00
|
|
|
}
|
|
|
|
virtual void EndCOFFSymbolDef() {
|
2012-02-07 05:05:23 +00:00
|
|
|
llvm_unreachable("macho doesn't support this directive");
|
2010-05-08 19:54:22 +00:00
|
|
|
}
|
2010-01-25 07:52:13 +00:00
|
|
|
virtual void EmitELFSize(MCSymbol *Symbol, const MCExpr *Value) {
|
2012-02-07 05:05:23 +00:00
|
|
|
llvm_unreachable("macho doesn't support this directive");
|
2010-01-25 07:52:13 +00:00
|
|
|
}
|
2011-09-01 23:04:27 +00:00
|
|
|
virtual void EmitLocalCommonSymbol(MCSymbol *Symbol, uint64_t Size,
|
2012-09-07 17:25:13 +00:00
|
|
|
unsigned ByteAlignment);
|
2009-08-28 05:48:22 +00:00
|
|
|
virtual void EmitZerofill(const MCSection *Section, MCSymbol *Symbol = 0,
|
2012-06-22 20:14:46 +00:00
|
|
|
uint64_t 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-05-26 20:37:00 +00:00
|
|
|
|
2010-01-25 18:58:59 +00:00
|
|
|
virtual void EmitFileDirective(StringRef Filename) {
|
2010-07-19 20:44:20 +00:00
|
|
|
// FIXME: Just ignore the .file; it isn't important enough to fail the
|
|
|
|
// entire assembly.
|
|
|
|
|
2013-10-16 01:05:45 +00:00
|
|
|
// report_fatal_error("unsupported directive: '.file'");
|
|
|
|
}
|
|
|
|
|
|
|
|
virtual void EmitIdent(StringRef IdentString) {
|
|
|
|
llvm_unreachable("macho doesn't support this directive");
|
2010-01-25 18:58:59 +00:00
|
|
|
}
|
2010-05-26 20:37:00 +00:00
|
|
|
|
2012-01-07 03:13:18 +00:00
|
|
|
virtual void FinishImpl();
|
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
|
|
|
};
|
|
|
|
|
|
|
|
} // end anonymous namespace.
|
|
|
|
|
2011-04-28 12:50:37 +00:00
|
|
|
void MCMachOStreamer::EmitEHSymAttributes(const MCSymbol *Symbol,
|
|
|
|
MCSymbol *EHSymbol) {
|
|
|
|
MCSymbolData &SD =
|
|
|
|
getAssembler().getOrCreateSymbolData(*Symbol);
|
|
|
|
if (SD.isExternal())
|
|
|
|
EmitSymbolAttribute(EHSymbol, MCSA_Global);
|
|
|
|
if (SD.getFlags() & SF_WeakDefinition)
|
|
|
|
EmitSymbolAttribute(EHSymbol, MCSA_WeakDefinition);
|
2011-04-30 16:22:46 +00:00
|
|
|
if (SD.isPrivateExtern())
|
|
|
|
EmitSymbolAttribute(EHSymbol, MCSA_PrivateExtern);
|
2011-04-28 12:50:37 +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::EmitLabel(MCSymbol *Symbol) {
|
2010-11-28 16:22:59 +00:00
|
|
|
assert(Symbol->isUndefined() && "Cannot define a symbol twice!");
|
|
|
|
|
2010-11-28 17:18:55 +00:00
|
|
|
// isSymbolLinkerVisible uses the section.
|
2013-09-19 23:21:01 +00:00
|
|
|
AssignSection(Symbol, getCurrentSection().first);
|
2010-06-16 20:04:32 +00:00
|
|
|
// We have to create a new fragment if this is an atom defining symbol,
|
|
|
|
// fragments cannot span atoms.
|
2010-11-28 17:18:55 +00:00
|
|
|
if (getAssembler().isSymbolLinkerVisible(*Symbol))
|
2013-04-17 21:18:16 +00:00
|
|
|
insert(new MCDataFragment());
|
2010-05-10 22:45:09 +00:00
|
|
|
|
2010-11-28 17:18:55 +00:00
|
|
|
MCObjectStreamer::EmitLabel(Symbol);
|
2009-08-24 08:40:12 +00:00
|
|
|
|
2010-11-28 17:18:55 +00:00
|
|
|
MCSymbolData &SD = getAssembler().getSymbolData(*Symbol);
|
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);
|
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
|
|
|
}
|
|
|
|
|
2012-12-16 04:00:45 +00:00
|
|
|
void MCMachOStreamer::EmitDebugLabel(MCSymbol *Symbol) {
|
|
|
|
EmitLabel(Symbol);
|
|
|
|
}
|
2012-05-18 19:12:01 +00:00
|
|
|
void MCMachOStreamer::EmitDataRegion(DataRegionData::KindTy Kind) {
|
2012-10-01 22:20:54 +00:00
|
|
|
if (!getAssembler().getBackend().hasDataInCodeSupport())
|
|
|
|
return;
|
2012-05-18 19:12:01 +00:00
|
|
|
// Create a temporary label to mark the start of the data region.
|
|
|
|
MCSymbol *Start = getContext().CreateTempSymbol();
|
|
|
|
EmitLabel(Start);
|
|
|
|
// Record the region for the object writer to use.
|
|
|
|
DataRegionData Data = { Kind, Start, NULL };
|
|
|
|
std::vector<DataRegionData> &Regions = getAssembler().getDataRegions();
|
|
|
|
Regions.push_back(Data);
|
|
|
|
}
|
|
|
|
|
|
|
|
void MCMachOStreamer::EmitDataRegionEnd() {
|
2012-10-01 22:20:54 +00:00
|
|
|
if (!getAssembler().getBackend().hasDataInCodeSupport())
|
|
|
|
return;
|
2012-05-18 19:12:01 +00:00
|
|
|
std::vector<DataRegionData> &Regions = getAssembler().getDataRegions();
|
|
|
|
assert(Regions.size() && "Mismatched .end_data_region!");
|
|
|
|
DataRegionData &Data = Regions.back();
|
|
|
|
assert(Data.End == NULL && "Mismatched .end_data_region!");
|
|
|
|
// Create a temporary label to mark the end of the data region.
|
|
|
|
Data.End = getContext().CreateTempSymbol();
|
|
|
|
EmitLabel(Data.End);
|
|
|
|
}
|
|
|
|
|
2010-01-23 06:39:22 +00:00
|
|
|
void MCMachOStreamer::EmitAssemblerFlag(MCAssemblerFlag Flag) {
|
2010-12-08 01:16:55 +00:00
|
|
|
// Let the target do whatever target specific stuff it needs to do.
|
2012-01-18 18:52:16 +00:00
|
|
|
getAssembler().getBackend().handleAssemblerFlag(Flag);
|
2010-12-08 01:16:55 +00:00
|
|
|
// Do any generic stuff we need to do.
|
2009-08-26 21:22:22 +00:00
|
|
|
switch (Flag) {
|
2010-11-05 22:08:08 +00:00
|
|
|
case MCAF_SyntaxUnified: return; // no-op here.
|
2011-07-27 00:38:12 +00:00
|
|
|
case MCAF_Code16: return; // Change parsing mode; no-op here.
|
|
|
|
case MCAF_Code32: return; // Change parsing mode; no-op here.
|
|
|
|
case MCAF_Code64: return; // Change parsing mode; no-op here.
|
2010-01-23 06:39:22 +00:00
|
|
|
case MCAF_SubsectionsViaSymbols:
|
2010-06-16 20:04:22 +00:00
|
|
|
getAssembler().setSubsectionsViaSymbols(true);
|
2009-08-28 07:08:47 +00:00
|
|
|
return;
|
2009-08-26 21:22:22 +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
|
|
|
}
|
|
|
|
|
2013-01-18 01:26:07 +00:00
|
|
|
void MCMachOStreamer::EmitLinkerOptions(ArrayRef<std::string> Options) {
|
|
|
|
getAssembler().getLinkerOptions().push_back(Options);
|
|
|
|
}
|
|
|
|
|
2012-05-18 19:12:01 +00:00
|
|
|
void MCMachOStreamer::EmitDataRegion(MCDataRegionType Kind) {
|
|
|
|
switch (Kind) {
|
|
|
|
case MCDR_DataRegion:
|
|
|
|
EmitDataRegion(DataRegionData::Data);
|
|
|
|
return;
|
|
|
|
case MCDR_DataRegionJT8:
|
|
|
|
EmitDataRegion(DataRegionData::JumpTable8);
|
|
|
|
return;
|
|
|
|
case MCDR_DataRegionJT16:
|
|
|
|
EmitDataRegion(DataRegionData::JumpTable16);
|
|
|
|
return;
|
|
|
|
case MCDR_DataRegionJT32:
|
|
|
|
EmitDataRegion(DataRegionData::JumpTable32);
|
|
|
|
return;
|
|
|
|
case MCDR_DataRegionEnd:
|
|
|
|
EmitDataRegionEnd();
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2010-12-29 14:14:06 +00:00
|
|
|
void MCMachOStreamer::EmitThumbFunc(MCSymbol *Symbol) {
|
2010-12-14 18:46:57 +00:00
|
|
|
// Remember that the function is a thumb function. Fixup and relocation
|
|
|
|
// values will need adjusted.
|
2010-12-29 14:14:06 +00:00
|
|
|
getAssembler().setIsThumbFunc(Symbol);
|
|
|
|
|
|
|
|
// Mark the thumb bit on the symbol.
|
|
|
|
MCSymbolData &SD = getAssembler().getOrCreateSymbolData(*Symbol);
|
|
|
|
SD.setFlags(SD.getFlags() | SF_ThumbFunc);
|
2010-11-05 22:08:08 +00:00
|
|
|
}
|
|
|
|
|
2013-08-09 01:52:03 +00:00
|
|
|
bool 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;
|
2010-06-16 20:04:25 +00:00
|
|
|
ISD.SectionData = getCurrentSectionData();
|
2010-06-16 20:04:22 +00:00
|
|
|
getAssembler().getIndirectSymbols().push_back(ISD);
|
2013-08-09 01:52:03 +00:00
|
|
|
return true;
|
2009-08-24 11:56:58 +00:00
|
|
|
}
|
|
|
|
|
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.
|
2010-06-16 20:04:22 +00:00
|
|
|
MCSymbolData &SD = getAssembler().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-11-13 04:51:02 +00:00
|
|
|
case MCSA_ELF_TypeGnuUniqueObject:
|
2010-01-23 06:39:22 +00:00
|
|
|
case MCSA_Hidden:
|
2011-07-25 21:21:08 +00:00
|
|
|
case MCSA_IndirectSymbol:
|
2010-01-23 06:39:22 +00:00
|
|
|
case MCSA_Internal:
|
|
|
|
case MCSA_Protected:
|
|
|
|
case MCSA_Weak:
|
|
|
|
case MCSA_Local:
|
2013-08-09 01:52:03 +00:00
|
|
|
return false;
|
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-11-19 18:39:33 +00:00
|
|
|
case MCSA_SymbolResolver:
|
|
|
|
SD.setFlags(SD.getFlags() | SF_SymbolResolver);
|
|
|
|
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;
|
2010-07-08 17:22:42 +00:00
|
|
|
|
|
|
|
case MCSA_WeakDefAutoPrivate:
|
|
|
|
SD.setFlags(SD.getFlags() | SF_WeakDefinition | SF_WeakReference);
|
|
|
|
break;
|
2009-08-22 11:41:10 +00:00
|
|
|
}
|
2013-08-09 01:52:03 +00:00
|
|
|
|
|
|
|
return true;
|
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.
|
2010-05-26 20:37:00 +00:00
|
|
|
assert(DescValue == (DescValue & SF_DescFlagsMask) &&
|
2009-08-24 08:40:12 +00:00
|
|
|
"Invalid .desc value!");
|
2010-06-16 20:04:22 +00:00
|
|
|
getAssembler().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!");
|
|
|
|
|
2013-09-19 23:21:01 +00:00
|
|
|
AssignSection(Symbol, NULL);
|
|
|
|
|
2010-06-16 20:04:22 +00:00
|
|
|
MCSymbolData &SD = getAssembler().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
|
|
|
}
|
|
|
|
|
2012-09-07 17:25:13 +00:00
|
|
|
void MCMachOStreamer::EmitLocalCommonSymbol(MCSymbol *Symbol, uint64_t Size,
|
|
|
|
unsigned ByteAlignment) {
|
|
|
|
// '.lcomm' is equivalent to '.zerofill'.
|
2014-01-23 22:49:25 +00:00
|
|
|
return EmitZerofill(getContext().getObjectFileInfo()->getDataBSSSection(),
|
2012-09-07 17:25:13 +00:00
|
|
|
Symbol, Size, ByteAlignment);
|
|
|
|
}
|
|
|
|
|
2009-08-28 05:48:22 +00:00
|
|
|
void MCMachOStreamer::EmitZerofill(const MCSection *Section, MCSymbol *Symbol,
|
2012-06-22 20:14:46 +00:00
|
|
|
uint64_t Size, unsigned ByteAlignment) {
|
2010-06-16 20:04:22 +00:00
|
|
|
MCSectionData &SectData = getAssembler().getOrCreateSectionData(*Section);
|
2009-08-28 05:49:21 +00:00
|
|
|
|
|
|
|
// The symbol may not be present, which only creates the section.
|
|
|
|
if (!Symbol)
|
|
|
|
return;
|
|
|
|
|
2013-08-07 21:13:01 +00:00
|
|
|
// On darwin all virtual sections have zerofill type.
|
|
|
|
assert(Section->isVirtualSection() && "Section does not have zerofill type!");
|
2009-08-28 05:49:21 +00:00
|
|
|
|
|
|
|
assert(Symbol->isUndefined() && "Cannot define a symbol twice!");
|
|
|
|
|
2010-06-16 20:04:22 +00:00
|
|
|
MCSymbolData &SD = getAssembler().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);
|
|
|
|
|
2013-09-19 23:21:01 +00:00
|
|
|
AssignSection(Symbol, Section);
|
2009-08-28 05:49:21 +00:00
|
|
|
|
|
|
|
// 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
|
|
|
}
|
|
|
|
|
2014-01-28 23:12:49 +00:00
|
|
|
void MCMachOStreamer::EmitInstToData(const MCInst &Inst,
|
|
|
|
const MCSubtargetInfo &STI) {
|
2010-05-26 20:37:00 +00:00
|
|
|
MCDataFragment *DF = getOrCreateDataFragment();
|
2010-03-22 23:16:48 +00:00
|
|
|
|
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);
|
2014-01-28 23:13:07 +00:00
|
|
|
getAssembler().getEmitter().EncodeInstruction(Inst, VecOS, Fixups, STI);
|
2010-02-13 09:29:02 +00:00
|
|
|
VecOS.flush();
|
|
|
|
|
2010-05-26 20:37:00 +00:00
|
|
|
// Add the fixups and data.
|
|
|
|
for (unsigned i = 0, e = Fixups.size(); i != e; ++i) {
|
|
|
|
Fixups[i].setOffset(Fixups[i].getOffset() + DF->getContents().size());
|
2012-12-07 19:13:57 +00:00
|
|
|
DF->getFixups().push_back(Fixups[i]);
|
2010-05-26 20:37:00 +00:00
|
|
|
}
|
|
|
|
DF->getContents().append(Code.begin(), Code.end());
|
|
|
|
}
|
|
|
|
|
2012-01-07 03:13:18 +00:00
|
|
|
void MCMachOStreamer::FinishImpl() {
|
2013-09-09 19:48:37 +00:00
|
|
|
EmitFrames(&getAssembler().getBackend(), true);
|
2011-05-01 15:44:13 +00:00
|
|
|
|
2010-06-16 20:04:32 +00:00
|
|
|
// We have to set the fragment atom associations so we can relax properly for
|
|
|
|
// Mach-O.
|
|
|
|
|
|
|
|
// First, scan the symbol table to build a lookup table from fragments to
|
|
|
|
// defining symbols.
|
|
|
|
DenseMap<const MCFragment*, MCSymbolData*> DefiningSymbolMap;
|
|
|
|
for (MCAssembler::symbol_iterator it = getAssembler().symbol_begin(),
|
|
|
|
ie = getAssembler().symbol_end(); it != ie; ++it) {
|
|
|
|
if (getAssembler().isSymbolLinkerVisible(it->getSymbol()) &&
|
|
|
|
it->getFragment()) {
|
|
|
|
// An atom defining symbol should never be internal to a fragment.
|
|
|
|
assert(it->getOffset() == 0 && "Invalid offset in atom defining symbol!");
|
|
|
|
DefiningSymbolMap[it->getFragment()] = it;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Set the fragment atom associations by tracking the last seen atom defining
|
|
|
|
// symbol.
|
|
|
|
for (MCAssembler::iterator it = getAssembler().begin(),
|
|
|
|
ie = getAssembler().end(); it != ie; ++it) {
|
|
|
|
MCSymbolData *CurrentAtom = 0;
|
|
|
|
for (MCSectionData::iterator it2 = it->begin(),
|
|
|
|
ie2 = it->end(); it2 != ie2; ++it2) {
|
|
|
|
if (MCSymbolData *SD = DefiningSymbolMap.lookup(it2))
|
|
|
|
CurrentAtom = SD;
|
|
|
|
it2->setAtom(CurrentAtom);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2012-01-07 03:13:18 +00:00
|
|
|
this->MCObjectStreamer::FinishImpl();
|
2010-06-16 20:04:32 +00:00
|
|
|
}
|
|
|
|
|
2011-07-25 23:24:55 +00:00
|
|
|
MCStreamer *llvm::createMachOStreamer(MCContext &Context, MCAsmBackend &MAB,
|
2010-03-25 22:49:09 +00:00
|
|
|
raw_ostream &OS, MCCodeEmitter *CE,
|
|
|
|
bool RelaxAll) {
|
2011-07-25 23:24:55 +00:00
|
|
|
MCMachOStreamer *S = new MCMachOStreamer(Context, MAB, OS, CE);
|
2010-03-25 22:49:09 +00:00
|
|
|
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
|
|
|
}
|