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"
|
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);
|
2010-08-09 22:52:14 +00:00
|
|
|
// FIXME: These will likely moved to a better place.
|
|
|
|
const MCExpr * MakeStartMinusEndExpr(MCSymbol *Start, MCSymbol *End,
|
|
|
|
int IntVal);
|
|
|
|
void EmitDwarfFileTable(void);
|
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
|
|
|
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-06-16 20:04:25 +00:00
|
|
|
: MCObjectStreamer(Context, TAB, OS, Emitter) {}
|
2010-03-25 22:49:09 +00:00
|
|
|
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
/// @name MCStreamer Interface
|
|
|
|
/// @{
|
|
|
|
|
|
|
|
virtual void EmitLabel(MCSymbol *Symbol);
|
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.
|
|
|
|
|
|
|
|
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;
|
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) {
|
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-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-08-09 22:52:14 +00:00
|
|
|
//
|
|
|
|
// This helper routine returns an expression of End - Start + IntVal for use
|
|
|
|
// by EmitDwarfFileTable() below.
|
|
|
|
//
|
|
|
|
const MCExpr * MCMachOStreamer::MakeStartMinusEndExpr(MCSymbol *Start,
|
|
|
|
MCSymbol *End,
|
|
|
|
int IntVal) {
|
|
|
|
MCSymbolRefExpr::VariantKind Variant = MCSymbolRefExpr::VK_None;
|
|
|
|
const MCExpr *Res =
|
|
|
|
MCSymbolRefExpr::Create(End, Variant, getContext());
|
|
|
|
const MCExpr *RHS =
|
|
|
|
MCSymbolRefExpr::Create(Start, Variant, getContext());
|
|
|
|
const MCExpr *Res1 =
|
|
|
|
MCBinaryExpr::Create(MCBinaryExpr::Sub, Res, RHS,getContext());
|
|
|
|
const MCExpr *Res2 =
|
|
|
|
MCConstantExpr::Create(IntVal, getContext());
|
|
|
|
const MCExpr *Res3 =
|
|
|
|
MCBinaryExpr::Create(MCBinaryExpr::Sub, Res1, Res2, getContext());
|
|
|
|
return Res3;
|
|
|
|
}
|
|
|
|
|
|
|
|
//
|
|
|
|
// This emits the Dwarf file (and eventually the line) table.
|
|
|
|
//
|
|
|
|
void MCMachOStreamer::EmitDwarfFileTable(void) {
|
|
|
|
// For now make sure we don't put out the Dwarf file table if no .file
|
|
|
|
// directives were seen.
|
|
|
|
const std::vector<MCDwarfFile *> &MCDwarfFiles =
|
|
|
|
getContext().getMCDwarfFiles();
|
|
|
|
if (MCDwarfFiles.size() == 0)
|
|
|
|
return;
|
|
|
|
|
|
|
|
// This is the Mach-O section, for ELF it is the .debug_line section.
|
|
|
|
SwitchSection(getContext().getMachOSection("__DWARF", "__debug_line",
|
|
|
|
MCSectionMachO::S_ATTR_DEBUG,
|
|
|
|
0, SectionKind::getDataRelLocal()));
|
|
|
|
|
|
|
|
// Create a symbol at the beginning of this section.
|
|
|
|
MCSymbol *LineStartSym = getContext().CreateTempSymbol();
|
|
|
|
// Set the value of the symbol, as we are at the start of the section.
|
|
|
|
EmitLabel(LineStartSym);
|
|
|
|
|
|
|
|
// Create a symbol for the end of the section (to be set when we get there).
|
|
|
|
MCSymbol *LineEndSym = getContext().CreateTempSymbol();
|
|
|
|
|
|
|
|
// The first 4 bytes is the total length of the information for this
|
|
|
|
// compilation unit (not including these 4 bytes for the length).
|
|
|
|
EmitValue(MakeStartMinusEndExpr(LineStartSym, LineEndSym, 4), 4, 0);
|
|
|
|
|
|
|
|
// Next 2 bytes is the Version, which is Dwarf 2.
|
|
|
|
EmitIntValue(2, 2);
|
|
|
|
|
|
|
|
// Create a symbol for the end of the prologue (to be set when we get there).
|
|
|
|
MCSymbol *ProEndSym = getContext().CreateTempSymbol(); // Lprologue_end
|
|
|
|
|
|
|
|
// Length of the prologue, is the next 4 bytes. Which is the start of the
|
|
|
|
// section to the end of the prologue. Not including the 4 bytes for the
|
|
|
|
// total length, the 2 bytes for the version, and these 4 bytes for the
|
|
|
|
// length of the prologue.
|
|
|
|
EmitValue(MakeStartMinusEndExpr(LineStartSym, ProEndSym, (4 + 2 + 4)), 4, 0);
|
|
|
|
|
|
|
|
// Parameters of the state machine, are next.
|
|
|
|
// Define the architecture-dependent minimum instruction length (in
|
|
|
|
// bytes). This value should be rather too small than too big. */
|
|
|
|
// DWARF2_LINE_MIN_INSN_LENGTH
|
|
|
|
EmitIntValue(1, 1);
|
|
|
|
// Flag that indicates the initial value of the is_stmt_start flag.
|
|
|
|
// DWARF2_LINE_DEFAULT_IS_STMT
|
|
|
|
EmitIntValue(1, 1);
|
|
|
|
// Minimum line offset in a special line info. opcode. This value
|
|
|
|
// was chosen to give a reasonable range of values. */
|
|
|
|
// DWARF2_LINE_BASE
|
|
|
|
EmitIntValue(-5, 1);
|
|
|
|
// Range of line offsets in a special line info. opcode.
|
|
|
|
// DWARF2_LINE_RANGE
|
|
|
|
EmitIntValue(14, 1);
|
|
|
|
// First special line opcode - leave room for the standard opcodes.
|
|
|
|
// DWARF2_LINE_OPCODE_BASE
|
|
|
|
EmitIntValue(13, 1);
|
|
|
|
|
|
|
|
// Standard opcode lengths
|
|
|
|
EmitIntValue(0, 1); // length of DW_LNS_copy
|
|
|
|
EmitIntValue(1, 1); // length of DW_LNS_advance_pc
|
|
|
|
EmitIntValue(1, 1); // length of DW_LNS_advance_line
|
|
|
|
EmitIntValue(1, 1); // length of DW_LNS_set_file
|
|
|
|
EmitIntValue(1, 1); // length of DW_LNS_set_column
|
|
|
|
EmitIntValue(0, 1); // length of DW_LNS_negate_stmt
|
|
|
|
EmitIntValue(0, 1); // length of DW_LNS_set_basic_block
|
|
|
|
EmitIntValue(0, 1); // length of DW_LNS_const_add_pc
|
|
|
|
EmitIntValue(1, 1); // length of DW_LNS_fixed_advance_pc
|
|
|
|
EmitIntValue(0, 1); // length of DW_LNS_set_prologue_end
|
|
|
|
EmitIntValue(0, 1); // length of DW_LNS_set_epilogue_begin
|
|
|
|
EmitIntValue(1, 1); // DW_LNS_set_isa
|
|
|
|
|
|
|
|
// Put out the directory and file tables.
|
|
|
|
|
|
|
|
// First the directory table.
|
|
|
|
const std::vector<StringRef> &MCDwarfDirs =
|
|
|
|
getContext().getMCDwarfDirs();
|
|
|
|
for (unsigned i = 0; i < MCDwarfDirs.size(); i++) {
|
|
|
|
EmitBytes(MCDwarfDirs[i], 0); // the DirectoryName
|
|
|
|
EmitBytes(StringRef("\0", 1), 0); // the null termination of the string
|
|
|
|
}
|
|
|
|
EmitIntValue(0, 1); // Terminate the directory list
|
|
|
|
|
|
|
|
// Second the file table.
|
|
|
|
for (unsigned i = 1; i < MCDwarfFiles.size(); i++) {
|
|
|
|
EmitBytes(MCDwarfFiles[i]->getName(), 0); // FileName
|
|
|
|
EmitBytes(StringRef("\0", 1), 0); // the null termination of the string
|
|
|
|
// FIXME the Directory number should be a .uleb128 not a .byte
|
|
|
|
EmitIntValue(MCDwarfFiles[i]->getDirIndex(), 1);
|
|
|
|
EmitIntValue(0, 1); // last modification timestamp (always 0)
|
|
|
|
EmitIntValue(0, 1); // filesize (always 0)
|
|
|
|
}
|
|
|
|
EmitIntValue(0, 1); // Terminate the file list
|
|
|
|
|
|
|
|
// This is the end of the prologue, so set the value of the symbol at the
|
|
|
|
// end of the prologue (that was used in a previous expression).
|
|
|
|
EmitLabel(ProEndSym);
|
|
|
|
|
|
|
|
// TODO: This is the point where the line tables would be emitted.
|
|
|
|
|
|
|
|
// If there are no line tables emited then we emit:
|
|
|
|
// The following DW_LNE_set_address sequence to set the address to zero
|
|
|
|
// TODO test for 32-bit or 64-bit output
|
|
|
|
// This is the sequence for 32-bit code
|
|
|
|
EmitIntValue(0, 1);
|
|
|
|
EmitIntValue(5, 1);
|
|
|
|
EmitIntValue(2, 1);
|
|
|
|
EmitIntValue(0, 1);
|
|
|
|
EmitIntValue(0, 1);
|
|
|
|
EmitIntValue(0, 1);
|
|
|
|
EmitIntValue(0, 1);
|
|
|
|
|
|
|
|
// Lastly emit the DW_LNE_end_sequence which consists of 3 bytes '00 01 01'
|
|
|
|
// (00 is the code for extended opcodes, followed by a ULEB128 length of the
|
|
|
|
// extended opcode (01), and the DW_LNE_end_sequence (01).
|
|
|
|
EmitIntValue(0, 1); // DW_LNS_extended_op
|
|
|
|
EmitIntValue(1, 1); // ULEB128 length of the extended opcode
|
|
|
|
EmitIntValue(1, 1); // DW_LNE_end_sequence
|
|
|
|
|
|
|
|
// This is the end of the section, so set the value of the symbol at the end
|
|
|
|
// of this section (that was used in a previous expression).
|
|
|
|
EmitLabel(LineEndSym);
|
|
|
|
}
|
|
|
|
|
2010-06-16 20:04:32 +00:00
|
|
|
void MCMachOStreamer::Finish() {
|
2010-08-09 22:52:14 +00:00
|
|
|
// Dump out the dwarf file and directory tables (soon to include line table)
|
|
|
|
EmitDwarfFileTable();
|
|
|
|
|
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
|
|
|
}
|