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"
|
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"
|
|
|
|
#include "llvm/MC/MCSymbol.h"
|
2010-05-07 21:44:23 +00:00
|
|
|
#include "llvm/MC/MCMachOSymbolFlags.h"
|
2010-08-09 22:52:14 +00:00
|
|
|
#include "llvm/MC/MCSectionMachO.h"
|
|
|
|
#include "llvm/MC/MCDwarf.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
|
|
|
#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 {
|
|
|
|
|
2010-06-16 20:04:22 +00:00
|
|
|
class MCMachOStreamer : public MCObjectStreamer {
|
2009-08-22 10:13:24 +00:00
|
|
|
private:
|
2010-05-26 20:37:00 +00:00
|
|
|
void EmitInstToFragment(const MCInst &Inst);
|
|
|
|
void EmitInstToData(const MCInst &Inst);
|
|
|
|
|
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,
|
2010-06-16 20:04:22 +00:00
|
|
|
raw_ostream &OS, MCCodeEmitter *Emitter)
|
2010-09-22 22:27:05 +00:00
|
|
|
: MCObjectStreamer(Context, TAB, OS, Emitter, true) {}
|
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
|
|
|
|
/// @{
|
|
|
|
|
2010-09-15 21:48:40 +00:00
|
|
|
virtual void InitSections();
|
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 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-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.
|
|
|
|
|
|
|
|
//report_fatal_error("unsupported directive: '.file'");
|
2010-01-25 18:58:59 +00:00
|
|
|
}
|
|
|
|
virtual void EmitDwarfFileDirective(unsigned FileNo, 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.
|
|
|
|
|
|
|
|
//report_fatal_error("unsupported directive: '.file'");
|
2010-01-25 18:58:59 +00:00
|
|
|
}
|
2010-05-26 20:37:00 +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);
|
|
|
|
|
2010-06-16 20:04:32 +00:00
|
|
|
virtual void Finish();
|
|
|
|
|
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.
|
|
|
|
|
2010-09-15 21:48:40 +00:00
|
|
|
void MCMachOStreamer::InitSections() {
|
|
|
|
SwitchSection(getContext().getMachOSection("__TEXT", "__text",
|
|
|
|
MCSectionMachO::S_ATTR_PURE_INSTRUCTIONS,
|
|
|
|
0, SectionKind::getText()));
|
|
|
|
|
|
|
|
}
|
|
|
|
|
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-07-19 06:13:10 +00:00
|
|
|
// TODO: This is almost exactly the same as WinCOFFStreamer. Consider merging
|
|
|
|
// into MCObjectStreamer.
|
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-06-16 20:04:32 +00:00
|
|
|
Symbol->setSection(*CurSection);
|
2010-05-10 22:45:09 +00:00
|
|
|
|
2010-06-16 20:04:32 +00:00
|
|
|
MCSymbolData &SD = getAssembler().getOrCreateSymbolData(*Symbol);
|
2010-05-10 22:45:09 +00:00
|
|
|
|
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.
|
|
|
|
if (getAssembler().isSymbolLinkerVisible(SD.getSymbol()))
|
|
|
|
new MCDataFragment(getCurrentSectionData());
|
2010-05-10 22:45:09 +00:00
|
|
|
|
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-06-16 20:04:32 +00:00
|
|
|
MCDataFragment *F = 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);
|
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:
|
2010-06-16 20:04:22 +00:00
|
|
|
getAssembler().setSubsectionsViaSymbols(true);
|
2009-08-28 07:08:47 +00:00
|
|
|
return;
|
2010-09-30 10:59:51 +00:00
|
|
|
default:
|
|
|
|
llvm_unreachable("invalid assembler flag!");
|
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
|
|
|
}
|
|
|
|
|
2009-08-31 08:09:28 +00:00
|
|
|
void MCMachOStreamer::EmitAssignment(MCSymbol *Symbol, const MCExpr *Value) {
|
2010-07-19 06:13:10 +00:00
|
|
|
// TODO: This is exactly the same as WinCOFFStreamer. Consider merging into
|
|
|
|
// MCObjectStreamer.
|
2009-10-16 01:58:23 +00:00
|
|
|
// FIXME: Lift context changes into super class.
|
2010-06-16 20:04:22 +00:00
|
|
|
getAssembler().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;
|
2010-06-16 20:04:25 +00:00
|
|
|
ISD.SectionData = getCurrentSectionData();
|
2010-06-16 20:04:22 +00:00
|
|
|
getAssembler().getIndirectSymbols().push_back(ISD);
|
2009-08-24 11:56:58 +00:00
|
|
|
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.
|
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-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;
|
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
|
|
|
}
|
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!");
|
|
|
|
|
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
|
|
|
}
|
|
|
|
|
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-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;
|
|
|
|
|
|
|
|
// FIXME: Assert that this section has the zerofill type.
|
|
|
|
|
|
|
|
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);
|
|
|
|
|
|
|
|
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-07-19 06:13:10 +00:00
|
|
|
// TODO: This is exactly the same as WinCOFFStreamer. Consider merging into
|
|
|
|
// MCObjectStreamer.
|
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-07-19 06:13:10 +00:00
|
|
|
// TODO: This is exactly the same as WinCOFFStreamer. Consider merging into
|
|
|
|
// MCObjectStreamer.
|
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) {
|
2010-07-19 06:13:10 +00:00
|
|
|
// TODO: This is exactly the same as WinCOFFStreamer. Consider merging into
|
|
|
|
// MCObjectStreamer.
|
2009-08-21 23:07:38 +00:00
|
|
|
if (MaxBytesToEmit == 0)
|
|
|
|
MaxBytesToEmit = ByteAlignment;
|
2010-06-16 20:04:32 +00:00
|
|
|
new MCAlignFragment(ByteAlignment, Value, ValueSize, MaxBytesToEmit,
|
|
|
|
getCurrentSectionData());
|
2010-02-23 18:26:34 +00:00
|
|
|
|
|
|
|
// Update the maximum alignment on the current section if necessary.
|
2010-06-16 20:04:25 +00:00
|
|
|
if (ByteAlignment > getCurrentSectionData()->getAlignment())
|
|
|
|
getCurrentSectionData()->setAlignment(ByteAlignment);
|
2010-02-23 18:26:34 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void MCMachOStreamer::EmitCodeAlignment(unsigned ByteAlignment,
|
|
|
|
unsigned MaxBytesToEmit) {
|
2010-07-19 06:13:10 +00:00
|
|
|
// TODO: This is exactly the same as WinCOFFStreamer. Consider merging into
|
|
|
|
// MCObjectStreamer.
|
2010-02-23 18:26:34 +00:00
|
|
|
if (MaxBytesToEmit == 0)
|
|
|
|
MaxBytesToEmit = ByteAlignment;
|
2010-05-12 22:56:23 +00:00
|
|
|
MCAlignFragment *F = new MCAlignFragment(ByteAlignment, 0, 1, MaxBytesToEmit,
|
2010-06-16 20:04:25 +00:00
|
|
|
getCurrentSectionData());
|
2010-05-12 22:56:23 +00:00
|
|
|
F->setEmitNops(true);
|
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.
|
2010-06-16 20:04:25 +00:00
|
|
|
if (ByteAlignment > getCurrentSectionData()->getAlignment())
|
|
|
|
getCurrentSectionData()->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-06-16 20:04:32 +00:00
|
|
|
new MCOrgFragment(*Offset, Value, getCurrentSectionData());
|
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-26 20:37:00 +00:00
|
|
|
void MCMachOStreamer::EmitInstToFragment(const MCInst &Inst) {
|
2010-06-16 20:04:25 +00:00
|
|
|
MCInstFragment *IF = new MCInstFragment(Inst, getCurrentSectionData());
|
2009-08-27 08:17:51 +00:00
|
|
|
|
2010-05-26 20:37:00 +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.
|
|
|
|
SmallVector<MCFixup, 4> Fixups;
|
|
|
|
SmallString<256> Code;
|
|
|
|
raw_svector_ostream VecOS(Code);
|
2010-06-16 20:04:22 +00:00
|
|
|
getAssembler().getEmitter().EncodeInstruction(Inst, VecOS, Fixups);
|
2010-05-26 20:37:00 +00:00
|
|
|
VecOS.flush();
|
|
|
|
|
|
|
|
IF->getCode() = Code;
|
|
|
|
IF->getFixups() = Fixups;
|
|
|
|
}
|
2010-02-02 21:44:01 +00:00
|
|
|
|
2010-05-26 20:37:00 +00:00
|
|
|
void MCMachOStreamer::EmitInstToData(const MCInst &Inst) {
|
|
|
|
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);
|
2010-06-16 20:04:22 +00:00
|
|
|
getAssembler().getEmitter().EncodeInstruction(Inst, VecOS, Fixups);
|
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());
|
|
|
|
DF->addFixup(Fixups[i]);
|
|
|
|
}
|
|
|
|
DF->getContents().append(Code.begin(), Code.end());
|
|
|
|
}
|
|
|
|
|
|
|
|
void MCMachOStreamer::EmitInstruction(const MCInst &Inst) {
|
|
|
|
// Scan for values.
|
|
|
|
for (unsigned i = Inst.getNumOperands(); i--; )
|
|
|
|
if (Inst.getOperand(i).isExpr())
|
|
|
|
AddValueSymbols(Inst.getOperand(i).getExpr());
|
|
|
|
|
2010-06-16 20:04:25 +00:00
|
|
|
getCurrentSectionData()->setHasInstructions(true);
|
2010-05-26 20:37:00 +00:00
|
|
|
|
2010-08-31 22:55:11 +00:00
|
|
|
// Now that a machine instruction has been assembled into this section, make
|
|
|
|
// a line entry for any .loc directive that has been seen.
|
2010-09-30 16:52:03 +00:00
|
|
|
MCLineEntry::Make(this, getCurrentSection());
|
2010-08-31 22:55:11 +00:00
|
|
|
|
2010-05-26 20:37:03 +00:00
|
|
|
// If this instruction doesn't need relaxation, just emit it as data.
|
2010-06-16 20:04:22 +00:00
|
|
|
if (!getAssembler().getBackend().MayNeedRelaxation(Inst)) {
|
2010-05-26 20:37:00 +00:00
|
|
|
EmitInstToData(Inst);
|
2010-05-26 20:37:03 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Otherwise, if we are relaxing everything, relax the instruction as much as
|
|
|
|
// possible and emit it as data.
|
2010-06-16 20:04:22 +00:00
|
|
|
if (getAssembler().getRelaxAll()) {
|
2010-05-26 20:37:03 +00:00
|
|
|
MCInst Relaxed;
|
2010-06-16 20:04:22 +00:00
|
|
|
getAssembler().getBackend().RelaxInstruction(Inst, Relaxed);
|
|
|
|
while (getAssembler().getBackend().MayNeedRelaxation(Relaxed))
|
|
|
|
getAssembler().getBackend().RelaxInstruction(Relaxed, Relaxed);
|
2010-05-26 20:37:03 +00:00
|
|
|
EmitInstToData(Relaxed);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
// Otherwise emit to a separate fragment.
|
|
|
|
EmitInstToFragment(Inst);
|
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-09-30 16:52:03 +00:00
|
|
|
void MCMachOStreamer::Finish() {
|
|
|
|
// Dump out the dwarf file & directory tables and line tables.
|
2010-10-02 00:13:41 +00:00
|
|
|
if (getContext().hasDwarfFiles()) {
|
2010-09-30 16:52:03 +00:00
|
|
|
const MCSection *DwarfLineSection = getContext().getMachOSection("__DWARF",
|
|
|
|
"__debug_line",
|
2010-08-09 22:52:14 +00:00
|
|
|
MCSectionMachO::S_ATTR_DEBUG,
|
2010-09-30 16:52:03 +00:00
|
|
|
0, SectionKind::getDataRelLocal());
|
|
|
|
MCDwarfFileTable::Emit(this, DwarfLineSection);
|
2010-08-09 22:52:14 +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);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
this->MCObjectStreamer::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
|
|
|
}
|