llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
//===- lib/MC/MCMachOStreamer.cpp - Mach-O Object Output ------------===//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#include "llvm/MC/MCStreamer.h"
|
|
|
|
|
|
|
|
#include "llvm/MC/MCAssembler.h"
|
|
|
|
#include "llvm/MC/MCContext.h"
|
2009-08-27 08:17:51 +00:00
|
|
|
#include "llvm/MC/MCCodeEmitter.h"
|
2009-08-31 08:08:38 +00:00
|
|
|
#include "llvm/MC/MCExpr.h"
|
2009-08-27 08:17:51 +00:00
|
|
|
#include "llvm/MC/MCInst.h"
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
#include "llvm/MC/MCSection.h"
|
|
|
|
#include "llvm/MC/MCSymbol.h"
|
2009-08-31 08:09:28 +00:00
|
|
|
#include "llvm/MC/MCValue.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"
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
using namespace llvm;
|
|
|
|
|
|
|
|
namespace {
|
|
|
|
|
|
|
|
class MCMachOStreamer : public MCStreamer {
|
2009-08-24 08:40:12 +00:00
|
|
|
/// SymbolFlags - We store the value for the 'desc' symbol field in the lowest
|
|
|
|
/// 16 bits of the implementation defined flags.
|
|
|
|
enum SymbolFlags { // See <mach-o/nlist.h>.
|
|
|
|
SF_DescFlagsMask = 0xFFFF,
|
|
|
|
|
|
|
|
// Reference type flags.
|
|
|
|
SF_ReferenceTypeMask = 0x0007,
|
|
|
|
SF_ReferenceTypeUndefinedNonLazy = 0x0000,
|
|
|
|
SF_ReferenceTypeUndefinedLazy = 0x0001,
|
|
|
|
SF_ReferenceTypeDefined = 0x0002,
|
|
|
|
SF_ReferenceTypePrivateDefined = 0x0003,
|
|
|
|
SF_ReferenceTypePrivateUndefinedNonLazy = 0x0004,
|
|
|
|
SF_ReferenceTypePrivateUndefinedLazy = 0x0005,
|
|
|
|
|
|
|
|
// Other 'desc' flags.
|
|
|
|
SF_NoDeadStrip = 0x0020,
|
|
|
|
SF_WeakReference = 0x0040,
|
|
|
|
SF_WeakDefinition = 0x0080
|
|
|
|
};
|
|
|
|
|
|
|
|
private:
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
MCAssembler Assembler;
|
|
|
|
|
2009-08-27 08:17:51 +00:00
|
|
|
MCCodeEmitter *Emitter;
|
|
|
|
|
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
|
|
|
MCSectionData *CurSectionData;
|
|
|
|
|
|
|
|
DenseMap<const MCSection*, MCSectionData*> SectionMap;
|
2009-08-22 10:13:24 +00:00
|
|
|
|
|
|
|
DenseMap<const MCSymbol*, MCSymbolData*> SymbolMap;
|
|
|
|
|
|
|
|
private:
|
|
|
|
MCFragment *getCurrentFragment() const {
|
|
|
|
assert(CurSectionData && "No current section!");
|
|
|
|
|
|
|
|
if (!CurSectionData->empty())
|
|
|
|
return &CurSectionData->getFragmentList().back();
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2009-08-28 05:48:54 +00:00
|
|
|
MCSectionData &getSectionData(const MCSection &Section) {
|
|
|
|
MCSectionData *&Entry = SectionMap[&Section];
|
|
|
|
|
|
|
|
if (!Entry)
|
|
|
|
Entry = new MCSectionData(Section, &Assembler);
|
|
|
|
|
|
|
|
return *Entry;
|
|
|
|
}
|
|
|
|
|
2009-08-31 08:08:06 +00:00
|
|
|
MCSymbolData &getSymbolData(const MCSymbol &Symbol) {
|
2009-08-22 10:13:24 +00:00
|
|
|
MCSymbolData *&Entry = SymbolMap[&Symbol];
|
|
|
|
|
|
|
|
if (!Entry)
|
|
|
|
Entry = new MCSymbolData(Symbol, 0, 0, &Assembler);
|
|
|
|
|
|
|
|
return *Entry;
|
|
|
|
}
|
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:
|
2009-08-27 08:17:51 +00:00
|
|
|
MCMachOStreamer(MCContext &Context, raw_ostream &_OS, MCCodeEmitter *_Emitter)
|
2009-08-31 08:07:55 +00:00
|
|
|
: MCStreamer(Context), Assembler(Context, _OS), Emitter(_Emitter),
|
2009-08-27 08:17:51 +00:00
|
|
|
CurSectionData(0) {}
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
~MCMachOStreamer() {}
|
|
|
|
|
2009-08-31 08:08:38 +00:00
|
|
|
const MCExpr *AddValueSymbols(const MCExpr *Value) {
|
|
|
|
switch (Value->getKind()) {
|
|
|
|
case MCExpr::Constant:
|
|
|
|
break;
|
|
|
|
|
|
|
|
case MCExpr::Binary: {
|
|
|
|
const MCBinaryExpr *BE = cast<MCBinaryExpr>(Value);
|
|
|
|
AddValueSymbols(BE->getLHS());
|
|
|
|
AddValueSymbols(BE->getRHS());
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
case MCExpr::SymbolRef:
|
|
|
|
getSymbolData(cast<MCSymbolRefExpr>(Value)->getSymbol());
|
|
|
|
break;
|
|
|
|
|
|
|
|
case MCExpr::Unary:
|
|
|
|
AddValueSymbols(cast<MCUnaryExpr>(Value)->getSubExpr());
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return Value;
|
|
|
|
}
|
|
|
|
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
/// @name MCStreamer Interface
|
|
|
|
/// @{
|
|
|
|
|
|
|
|
virtual void SwitchSection(const MCSection *Section);
|
|
|
|
|
|
|
|
virtual void EmitLabel(MCSymbol *Symbol);
|
|
|
|
|
|
|
|
virtual void EmitAssemblerFlag(AssemblerFlag Flag);
|
|
|
|
|
2009-08-31 08:09:28 +00:00
|
|
|
virtual void EmitAssignment(MCSymbol *Symbol, const MCExpr *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
|
|
|
|
|
|
|
virtual void EmitSymbolAttribute(MCSymbol *Symbol, SymbolAttr Attribute);
|
|
|
|
|
|
|
|
virtual void EmitSymbolDesc(MCSymbol *Symbol, unsigned DescValue);
|
|
|
|
|
|
|
|
virtual void EmitCommonSymbol(MCSymbol *Symbol, unsigned Size,
|
2009-08-30 06:17:16 +00:00
|
|
|
unsigned 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
|
|
|
virtual void EmitZerofill(const MCSection *Section, MCSymbol *Symbol = 0,
|
2009-08-30 06:17:16 +00:00
|
|
|
unsigned Size = 0, unsigned ByteAlignment = 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
|
|
|
|
|
|
|
virtual void EmitBytes(const StringRef &Data);
|
|
|
|
|
2009-08-31 08:09:28 +00:00
|
|
|
virtual void EmitValue(const MCExpr *Value, unsigned Size);
|
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);
|
|
|
|
|
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);
|
|
|
|
|
|
|
|
virtual void EmitInstruction(const MCInst &Inst);
|
|
|
|
|
|
|
|
virtual void Finish();
|
|
|
|
|
|
|
|
/// @}
|
|
|
|
};
|
|
|
|
|
|
|
|
} // end anonymous namespace.
|
|
|
|
|
|
|
|
void MCMachOStreamer::SwitchSection(const MCSection *Section) {
|
|
|
|
assert(Section && "Cannot switch to a null section!");
|
2009-08-22 19:35:08 +00:00
|
|
|
|
|
|
|
// If already in this section, then this is a noop.
|
|
|
|
if (Section == CurSection) return;
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
|
2009-08-28 05:48:54 +00:00
|
|
|
CurSection = Section;
|
|
|
|
CurSectionData = &getSectionData(*Section);
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void MCMachOStreamer::EmitLabel(MCSymbol *Symbol) {
|
2009-08-22 07:22:36 +00:00
|
|
|
assert(Symbol->isUndefined() && "Cannot define a symbol twice!");
|
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-26 02:48:04 +00:00
|
|
|
// FIXME: We should also use offsets into Fill fragments.
|
2009-08-22 10:13:24 +00:00
|
|
|
MCDataFragment *F = dyn_cast_or_null<MCDataFragment>(getCurrentFragment());
|
|
|
|
if (!F)
|
|
|
|
F = new MCDataFragment(CurSectionData);
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
|
2009-08-22 10:13:24 +00:00
|
|
|
MCSymbolData &SD = getSymbolData(*Symbol);
|
|
|
|
assert(!SD.getFragment() && "Unexpected fragment on symbol data!");
|
|
|
|
SD.setFragment(F);
|
|
|
|
SD.setOffset(F->getContents().size());
|
2009-08-24 08:40:12 +00:00
|
|
|
|
|
|
|
// This causes the reference type and weak reference flags to be cleared.
|
|
|
|
SD.setFlags(SD.getFlags() & ~(SF_WeakReference | SF_ReferenceTypeMask));
|
2009-08-22 10:13:24 +00:00
|
|
|
|
2009-08-22 07:22:36 +00:00
|
|
|
Symbol->setSection(*CurSection);
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void MCMachOStreamer::EmitAssemblerFlag(AssemblerFlag Flag) {
|
2009-08-26 21:22:22 +00:00
|
|
|
switch (Flag) {
|
|
|
|
case SubsectionsViaSymbols:
|
|
|
|
Assembler.setSubsectionsViaSymbols(true);
|
2009-08-28 07:08:47 +00:00
|
|
|
return;
|
2009-08-26 21:22:22 +00:00
|
|
|
}
|
2009-08-28 07:08:47 +00:00
|
|
|
|
|
|
|
assert(0 && "invalid assembler flag!");
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
}
|
|
|
|
|
2009-08-31 08:09:28 +00:00
|
|
|
void MCMachOStreamer::EmitAssignment(MCSymbol *Symbol, const MCExpr *Value) {
|
2009-08-22 07:22:36 +00:00
|
|
|
// Only absolute symbols can be redefined.
|
|
|
|
assert((Symbol->isUndefined() || Symbol->isAbsolute()) &&
|
|
|
|
"Cannot define a symbol twice!");
|
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
|
|
|
|
|
|
|
llvm_unreachable("FIXME: Not yet implemented!");
|
|
|
|
}
|
|
|
|
|
|
|
|
void MCMachOStreamer::EmitSymbolAttribute(MCSymbol *Symbol,
|
|
|
|
SymbolAttr 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.
|
|
|
|
if (Attribute == MCStreamer::IndirectSymbol) {
|
2009-08-26 00:18:21 +00:00
|
|
|
// Note that we intentionally cannot use the symbol data here; this is
|
|
|
|
// important for matching the string table that 'as' generates.
|
2009-08-24 11:56:58 +00:00
|
|
|
IndirectSymbolData ISD;
|
|
|
|
ISD.Symbol = Symbol;
|
|
|
|
ISD.SectionData = CurSectionData;
|
|
|
|
Assembler.getIndirectSymbols().push_back(ISD);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
2009-08-24 08:40:12 +00:00
|
|
|
// Adding a symbol attribute always introduces the symbol, note that an
|
|
|
|
// important side effect of calling getSymbolData here is to register the
|
|
|
|
// symbol with the assembler.
|
|
|
|
MCSymbolData &SD = getSymbolData(*Symbol);
|
|
|
|
|
|
|
|
// 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) {
|
2009-08-24 11:56:58 +00:00
|
|
|
case MCStreamer::IndirectSymbol:
|
2009-08-24 08:40:12 +00:00
|
|
|
case MCStreamer::Hidden:
|
|
|
|
case MCStreamer::Internal:
|
|
|
|
case MCStreamer::Protected:
|
|
|
|
case MCStreamer::Weak:
|
|
|
|
assert(0 && "Invalid symbol attribute for Mach-O!");
|
|
|
|
break;
|
2009-08-22 11:41:10 +00:00
|
|
|
|
|
|
|
case MCStreamer::Global:
|
2009-08-28 07:08:35 +00:00
|
|
|
SD.setExternal(true);
|
2009-08-22 11:41:10 +00:00
|
|
|
break;
|
2009-08-24 08:40:12 +00:00
|
|
|
|
|
|
|
case MCStreamer::LazyReference:
|
|
|
|
// 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.
|
|
|
|
case MCStreamer::Reference:
|
|
|
|
case MCStreamer::NoDeadStrip:
|
|
|
|
SD.setFlags(SD.getFlags() | SF_NoDeadStrip);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case MCStreamer::PrivateExtern:
|
|
|
|
SD.setExternal(true);
|
|
|
|
SD.setPrivateExtern(true);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case MCStreamer::WeakReference:
|
|
|
|
// FIXME: This requires -dynamic.
|
|
|
|
if (Symbol->isUndefined())
|
|
|
|
SD.setFlags(SD.getFlags() | SF_WeakReference);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case MCStreamer::WeakDefinition:
|
|
|
|
// FIXME: 'as' enforces that this is defined and global. The manual claims
|
|
|
|
// it has to be in a coalesced section, but this isn't enforced.
|
|
|
|
SD.setFlags(SD.getFlags() | SF_WeakDefinition);
|
|
|
|
break;
|
2009-08-22 11:41:10 +00:00
|
|
|
}
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void MCMachOStreamer::EmitSymbolDesc(MCSymbol *Symbol, unsigned DescValue) {
|
2009-08-24 08:40:12 +00:00
|
|
|
// Encode the 'desc' value into the lowest implementation defined bits.
|
|
|
|
assert(DescValue == (DescValue & SF_DescFlagsMask) &&
|
|
|
|
"Invalid .desc value!");
|
|
|
|
getSymbolData(*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
|
|
|
}
|
|
|
|
|
|
|
|
void MCMachOStreamer::EmitCommonSymbol(MCSymbol *Symbol, unsigned 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!");
|
|
|
|
|
|
|
|
MCSymbolData &SD = getSymbolData(*Symbol);
|
|
|
|
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) {
|
2009-08-28 05:49:21 +00:00
|
|
|
MCSectionData &SectData = getSectionData(*Section);
|
|
|
|
|
|
|
|
// 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!");
|
|
|
|
|
|
|
|
MCSymbolData &SD = getSymbolData(*Symbol);
|
|
|
|
|
2009-08-30 06:17:16 +00:00
|
|
|
MCFragment *F = new MCZeroFillFragment(Size, ByteAlignment, &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
|
|
|
}
|
|
|
|
|
|
|
|
void MCMachOStreamer::EmitBytes(const StringRef &Data) {
|
2009-08-22 10:13:24 +00:00
|
|
|
MCDataFragment *DF = dyn_cast_or_null<MCDataFragment>(getCurrentFragment());
|
|
|
|
if (!DF)
|
|
|
|
DF = new MCDataFragment(CurSectionData);
|
2009-08-21 18:29:01 +00:00
|
|
|
DF->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
|
|
|
}
|
|
|
|
|
2009-08-31 08:09:28 +00:00
|
|
|
void MCMachOStreamer::EmitValue(const MCExpr *Value, unsigned Size) {
|
|
|
|
MCValue RelocValue;
|
|
|
|
|
|
|
|
if (!AddValueSymbols(Value)->EvaluateAsRelocatable(getContext(), RelocValue))
|
|
|
|
return llvm_report_error("expected relocatable expression");
|
|
|
|
|
|
|
|
new MCFillFragment(RelocValue, Size, 1, CurSectionData);
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void MCMachOStreamer::EmitValueToAlignment(unsigned ByteAlignment,
|
|
|
|
int64_t Value, unsigned ValueSize,
|
|
|
|
unsigned MaxBytesToEmit) {
|
2009-08-21 23:07:38 +00:00
|
|
|
if (MaxBytesToEmit == 0)
|
|
|
|
MaxBytesToEmit = ByteAlignment;
|
2009-08-21 18:29:01 +00:00
|
|
|
new MCAlignFragment(ByteAlignment, Value, ValueSize, MaxBytesToEmit,
|
|
|
|
CurSectionData);
|
|
|
|
|
2009-08-22 10:13:24 +00:00
|
|
|
// Update the maximum alignment on the current section if necessary.
|
2009-08-21 18:29:01 +00:00
|
|
|
if (ByteAlignment > CurSectionData->getAlignment())
|
|
|
|
CurSectionData->setAlignment(ByteAlignment);
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
}
|
|
|
|
|
2009-08-31 08:09:28 +00:00
|
|
|
void MCMachOStreamer::EmitValueToOffset(const MCExpr *Offset,
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
unsigned char Value) {
|
2009-08-31 08:09:28 +00:00
|
|
|
MCValue RelocOffset;
|
|
|
|
|
|
|
|
if (!AddValueSymbols(Offset)->EvaluateAsRelocatable(getContext(),
|
|
|
|
RelocOffset))
|
|
|
|
return llvm_report_error("expected relocatable expression");
|
|
|
|
|
|
|
|
new MCOrgFragment(RelocOffset, Value, CurSectionData);
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void MCMachOStreamer::EmitInstruction(const MCInst &Inst) {
|
2009-08-27 08:17:51 +00:00
|
|
|
// Scan for values.
|
|
|
|
for (unsigned i = 0; i != Inst.getNumOperands(); ++i)
|
2009-08-31 08:08:38 +00:00
|
|
|
if (Inst.getOperand(i).isExpr())
|
|
|
|
AddValueSymbols(Inst.getOperand(i).getExpr());
|
2009-08-27 08:17:51 +00:00
|
|
|
|
|
|
|
if (!Emitter)
|
|
|
|
llvm_unreachable("no code emitter available!");
|
|
|
|
|
|
|
|
// FIXME: Relocations!
|
|
|
|
SmallString<256> Code;
|
|
|
|
raw_svector_ostream VecOS(Code);
|
|
|
|
Emitter->EncodeInstruction(Inst, VecOS);
|
|
|
|
EmitBytes(VecOS.str());
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
void MCMachOStreamer::Finish() {
|
|
|
|
Assembler.Finish();
|
|
|
|
}
|
|
|
|
|
2009-08-27 08:17:51 +00:00
|
|
|
MCStreamer *llvm::createMachOStreamer(MCContext &Context, raw_ostream &OS,
|
|
|
|
MCCodeEmitter *CE) {
|
|
|
|
return new MCMachOStreamer(Context, OS, CE);
|
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
|
|
|
}
|