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.h - Object File Generation -------------------*- C++ -*-===//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#ifndef LLVM_MC_MCASSEMBLER_H
|
|
|
|
#define LLVM_MC_MCASSEMBLER_H
|
|
|
|
|
2010-03-10 20:58:29 +00:00
|
|
|
#include "llvm/ADT/DenseMap.h"
|
2009-08-21 18:29:01 +00:00
|
|
|
#include "llvm/ADT/SmallString.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/ADT/ilist.h"
|
|
|
|
#include "llvm/ADT/ilist_node.h"
|
2009-08-21 18:29:01 +00:00
|
|
|
#include "llvm/Support/Casting.h"
|
2010-02-13 09:28:54 +00:00
|
|
|
#include "llvm/MC/MCFixup.h"
|
2010-03-22 23:16:48 +00:00
|
|
|
#include "llvm/MC/MCInst.h"
|
2009-10-26 01:35:46 +00:00
|
|
|
#include "llvm/System/DataTypes.h"
|
2009-08-24 11:56:58 +00:00
|
|
|
#include <vector> // FIXME: Shouldn't be needed.
|
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
|
|
|
|
|
|
|
namespace llvm {
|
|
|
|
class raw_ostream;
|
2010-03-12 21:00:49 +00:00
|
|
|
class MCAsmLayout;
|
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
|
|
|
class MCAssembler;
|
2009-08-31 08:07:55 +00:00
|
|
|
class MCContext;
|
2010-03-19 10:43:18 +00:00
|
|
|
class MCCodeEmitter;
|
2009-10-16 01:58:03 +00:00
|
|
|
class MCExpr;
|
2010-02-11 21:29:29 +00:00
|
|
|
class MCFragment;
|
2010-03-19 09:28:59 +00:00
|
|
|
class MCObjectWriter;
|
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
|
|
|
class MCSection;
|
|
|
|
class MCSectionData;
|
2009-10-16 01:58:03 +00:00
|
|
|
class MCSymbol;
|
2010-03-12 21:00:49 +00:00
|
|
|
class MCValue;
|
2010-03-11 01:34:27 +00:00
|
|
|
class TargetAsmBackend;
|
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-02-11 21:29:29 +00:00
|
|
|
/// MCAsmFixup - Represent a fixed size region of bytes inside some fragment
|
|
|
|
/// which needs to be rewritten. This region will either be rewritten by the
|
|
|
|
/// assembler or cause a relocation entry to be generated.
|
2010-03-22 23:16:48 +00:00
|
|
|
//
|
|
|
|
// FIXME: This should probably just be merged with MCFixup.
|
2010-03-19 15:31:09 +00:00
|
|
|
class MCAsmFixup {
|
2010-03-19 15:36:58 +00:00
|
|
|
public:
|
2010-02-11 21:29:29 +00:00
|
|
|
/// Offset - The offset inside the fragment which needs to be rewritten.
|
|
|
|
uint64_t Offset;
|
|
|
|
|
|
|
|
/// Value - The expression to eventually write into the fragment.
|
|
|
|
const MCExpr *Value;
|
|
|
|
|
2010-02-13 09:28:54 +00:00
|
|
|
/// Kind - The fixup kind.
|
|
|
|
MCFixupKind Kind;
|
2010-02-11 21:29:29 +00:00
|
|
|
|
|
|
|
public:
|
2010-02-13 09:28:54 +00:00
|
|
|
MCAsmFixup(uint64_t _Offset, const MCExpr &_Value, MCFixupKind _Kind)
|
2010-03-19 07:09:47 +00:00
|
|
|
: Offset(_Offset), Value(&_Value), Kind(_Kind) {}
|
2010-02-11 21:29:29 +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
|
|
|
class MCFragment : public ilist_node<MCFragment> {
|
2010-03-25 01:03:24 +00:00
|
|
|
friend class MCAsmLayout;
|
|
|
|
|
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
|
|
|
MCFragment(const MCFragment&); // DO NOT IMPLEMENT
|
|
|
|
void operator=(const MCFragment&); // DO NOT IMPLEMENT
|
|
|
|
|
|
|
|
public:
|
2009-08-21 18:29:01 +00:00
|
|
|
enum FragmentType {
|
|
|
|
FT_Align,
|
2010-03-22 23:16:48 +00:00
|
|
|
FT_Data,
|
2009-08-21 18:29:01 +00:00
|
|
|
FT_Fill,
|
2010-03-22 23:16:48 +00:00
|
|
|
FT_Inst,
|
2009-08-28 05:49:21 +00:00
|
|
|
FT_Org,
|
|
|
|
FT_ZeroFill
|
2009-08-21 18:29:01 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
private:
|
|
|
|
FragmentType Kind;
|
|
|
|
|
2009-08-26 02:48:04 +00:00
|
|
|
/// Parent - The data for the section this fragment is in.
|
|
|
|
MCSectionData *Parent;
|
|
|
|
|
2009-08-21 18:29:01 +00:00
|
|
|
/// @name Assembler Backend Data
|
|
|
|
/// @{
|
|
|
|
//
|
|
|
|
// FIXME: This could all be kept private to the assembler implementation.
|
|
|
|
|
2009-08-22 08:27:54 +00:00
|
|
|
/// Offset - The offset of this fragment in its section. This is ~0 until
|
2009-08-21 18:29:01 +00:00
|
|
|
/// initialized.
|
2009-08-22 08:27:54 +00:00
|
|
|
uint64_t Offset;
|
|
|
|
|
2010-03-25 02:00:02 +00:00
|
|
|
/// EffectiveSize - The compute size of this section. This is ~0 until
|
|
|
|
/// initialized.
|
|
|
|
uint64_t EffectiveSize;
|
2009-08-21 18:29:01 +00:00
|
|
|
|
2010-03-25 07:10:11 +00:00
|
|
|
/// Ordinal - The global index of this fragment. This is the index across all
|
|
|
|
/// sections, not just the parent section.
|
|
|
|
unsigned Ordinal;
|
|
|
|
|
2009-08-21 18:29:01 +00:00
|
|
|
/// @}
|
|
|
|
|
|
|
|
protected:
|
2009-08-26 02:48:04 +00:00
|
|
|
MCFragment(FragmentType _Kind, MCSectionData *_Parent = 0);
|
2009-08-21 18:29:01 +00:00
|
|
|
|
|
|
|
public:
|
|
|
|
// Only for sentinel.
|
|
|
|
MCFragment();
|
|
|
|
virtual ~MCFragment();
|
|
|
|
|
|
|
|
FragmentType getKind() const { return Kind; }
|
|
|
|
|
2009-08-26 02:48:04 +00:00
|
|
|
MCSectionData *getParent() const { return Parent; }
|
|
|
|
void setParent(MCSectionData *Value) { Parent = Value; }
|
|
|
|
|
2010-03-25 07:10:11 +00:00
|
|
|
unsigned getOrdinal() const { return Ordinal; }
|
|
|
|
void setOrdinal(unsigned Value) { Ordinal = Value; }
|
|
|
|
|
2009-08-21 18:29:01 +00:00
|
|
|
static bool classof(const MCFragment *O) { return true; }
|
2010-02-13 09:28:03 +00:00
|
|
|
|
|
|
|
virtual void dump();
|
2009-08-21 18:29:01 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
class MCDataFragment : public MCFragment {
|
|
|
|
SmallString<32> Contents;
|
|
|
|
|
2010-02-13 09:28:43 +00:00
|
|
|
/// Fixups - The list of fixups in this fragment.
|
|
|
|
std::vector<MCAsmFixup> Fixups;
|
|
|
|
|
|
|
|
public:
|
|
|
|
typedef std::vector<MCAsmFixup>::const_iterator const_fixup_iterator;
|
|
|
|
typedef std::vector<MCAsmFixup>::iterator fixup_iterator;
|
|
|
|
|
2009-08-21 18:29:01 +00:00
|
|
|
public:
|
|
|
|
MCDataFragment(MCSectionData *SD = 0) : MCFragment(FT_Data, SD) {}
|
|
|
|
|
|
|
|
/// @name Accessors
|
|
|
|
/// @{
|
|
|
|
|
|
|
|
SmallString<32> &getContents() { return Contents; }
|
|
|
|
const SmallString<32> &getContents() const { return Contents; }
|
|
|
|
|
|
|
|
/// @}
|
2010-02-13 09:28:43 +00:00
|
|
|
/// @name Fixup Access
|
|
|
|
/// @{
|
|
|
|
|
2010-03-12 21:00:38 +00:00
|
|
|
void addFixup(MCAsmFixup Fixup) {
|
|
|
|
// Enforce invariant that fixups are in offset order.
|
2010-03-13 07:40:34 +00:00
|
|
|
assert((Fixups.empty() || Fixup.Offset > Fixups.back().Offset) &&
|
2010-03-12 21:00:38 +00:00
|
|
|
"Fixups must be added in order!");
|
|
|
|
Fixups.push_back(Fixup);
|
|
|
|
}
|
|
|
|
|
2010-02-13 09:28:43 +00:00
|
|
|
std::vector<MCAsmFixup> &getFixups() { return Fixups; }
|
|
|
|
const std::vector<MCAsmFixup> &getFixups() const { return Fixups; }
|
|
|
|
|
|
|
|
fixup_iterator fixup_begin() { return Fixups.begin(); }
|
|
|
|
const_fixup_iterator fixup_begin() const { return Fixups.begin(); }
|
|
|
|
|
|
|
|
fixup_iterator fixup_end() {return Fixups.end();}
|
|
|
|
const_fixup_iterator fixup_end() const {return Fixups.end();}
|
|
|
|
|
|
|
|
size_t fixup_size() const { return Fixups.size(); }
|
|
|
|
|
|
|
|
/// @}
|
|
|
|
|
2010-02-13 09:28:03 +00:00
|
|
|
static bool classof(const MCFragment *F) {
|
|
|
|
return F->getKind() == MCFragment::FT_Data;
|
2009-08-21 18:29:01 +00:00
|
|
|
}
|
|
|
|
static bool classof(const MCDataFragment *) { return true; }
|
2010-02-13 09:28:03 +00:00
|
|
|
|
|
|
|
virtual void dump();
|
2009-08-21 18:29:01 +00:00
|
|
|
};
|
|
|
|
|
2010-03-23 01:39:05 +00:00
|
|
|
// FIXME: This current incarnation of MCInstFragment doesn't make much sense, as
|
|
|
|
// it is almost entirely a duplicate of MCDataFragment. If we decide to stick
|
|
|
|
// with this approach (as opposed to making MCInstFragment a very light weight
|
|
|
|
// object with just the MCInst and a code size, then we should just change
|
|
|
|
// MCDataFragment to have an optional MCInst at its end.
|
2010-03-22 23:16:48 +00:00
|
|
|
class MCInstFragment : public MCFragment {
|
|
|
|
/// Inst - The instruction this is a fragment for.
|
|
|
|
MCInst Inst;
|
|
|
|
|
|
|
|
/// InstSize - The size of the currently encoded instruction.
|
2010-03-23 01:39:05 +00:00
|
|
|
SmallString<8> Code;
|
|
|
|
|
|
|
|
/// Fixups - The list of fixups in this fragment.
|
|
|
|
SmallVector<MCAsmFixup, 1> Fixups;
|
2010-03-22 23:16:48 +00:00
|
|
|
|
|
|
|
public:
|
2010-03-23 01:39:05 +00:00
|
|
|
typedef SmallVectorImpl<MCAsmFixup>::const_iterator const_fixup_iterator;
|
|
|
|
typedef SmallVectorImpl<MCAsmFixup>::iterator fixup_iterator;
|
|
|
|
|
|
|
|
public:
|
|
|
|
MCInstFragment(MCInst _Inst, MCSectionData *SD = 0)
|
|
|
|
: MCFragment(FT_Inst, SD), Inst(_Inst) {
|
|
|
|
}
|
2010-03-22 23:16:48 +00:00
|
|
|
|
|
|
|
/// @name Accessors
|
|
|
|
/// @{
|
|
|
|
|
2010-03-23 01:39:05 +00:00
|
|
|
SmallVectorImpl<char> &getCode() { return Code; }
|
|
|
|
const SmallVectorImpl<char> &getCode() const { return Code; }
|
2010-03-22 23:16:48 +00:00
|
|
|
|
2010-03-23 01:39:05 +00:00
|
|
|
unsigned getInstSize() const { return Code.size(); }
|
|
|
|
|
|
|
|
MCInst &getInst() { return Inst; }
|
2010-03-22 23:16:48 +00:00
|
|
|
const MCInst &getInst() const { return Inst; }
|
|
|
|
|
2010-03-23 01:39:05 +00:00
|
|
|
void setInst(MCInst Value) { Inst = Value; }
|
|
|
|
|
|
|
|
/// @}
|
|
|
|
/// @name Fixup Access
|
|
|
|
/// @{
|
|
|
|
|
|
|
|
SmallVectorImpl<MCAsmFixup> &getFixups() { return Fixups; }
|
|
|
|
const SmallVectorImpl<MCAsmFixup> &getFixups() const { return Fixups; }
|
|
|
|
|
|
|
|
fixup_iterator fixup_begin() { return Fixups.begin(); }
|
|
|
|
const_fixup_iterator fixup_begin() const { return Fixups.begin(); }
|
|
|
|
|
|
|
|
fixup_iterator fixup_end() {return Fixups.end();}
|
|
|
|
const_fixup_iterator fixup_end() const {return Fixups.end();}
|
|
|
|
|
|
|
|
size_t fixup_size() const { return Fixups.size(); }
|
2010-03-22 23:16:48 +00:00
|
|
|
|
|
|
|
/// @}
|
|
|
|
|
|
|
|
static bool classof(const MCFragment *F) {
|
|
|
|
return F->getKind() == MCFragment::FT_Inst;
|
|
|
|
}
|
|
|
|
static bool classof(const MCInstFragment *) { return true; }
|
|
|
|
|
|
|
|
virtual void dump();
|
|
|
|
};
|
|
|
|
|
2009-08-21 18:29:01 +00:00
|
|
|
class MCAlignFragment : public MCFragment {
|
|
|
|
/// Alignment - The alignment to ensure, in bytes.
|
|
|
|
unsigned Alignment;
|
|
|
|
|
|
|
|
/// Value - Value to use for filling padding bytes.
|
|
|
|
int64_t Value;
|
|
|
|
|
|
|
|
/// ValueSize - The size of the integer (in bytes) of \arg Value.
|
|
|
|
unsigned ValueSize;
|
|
|
|
|
|
|
|
/// MaxBytesToEmit - The maximum number of bytes to emit; if the alignment
|
|
|
|
/// cannot be satisfied in this width then this fragment is ignored.
|
|
|
|
unsigned MaxBytesToEmit;
|
|
|
|
|
2010-03-12 21:00:45 +00:00
|
|
|
/// EmitNops - true when aligning code and optimal nops to be used for
|
|
|
|
/// filling.
|
2010-02-23 18:26:34 +00:00
|
|
|
bool EmitNops;
|
|
|
|
|
2009-08-21 18:29:01 +00:00
|
|
|
public:
|
|
|
|
MCAlignFragment(unsigned _Alignment, int64_t _Value, unsigned _ValueSize,
|
2010-02-23 18:26:34 +00:00
|
|
|
unsigned _MaxBytesToEmit, bool _EmitNops,
|
|
|
|
MCSectionData *SD = 0)
|
2009-08-21 18:29:01 +00:00
|
|
|
: MCFragment(FT_Align, SD), Alignment(_Alignment),
|
|
|
|
Value(_Value),ValueSize(_ValueSize),
|
2010-02-23 18:26:34 +00:00
|
|
|
MaxBytesToEmit(_MaxBytesToEmit), EmitNops(_EmitNops) {}
|
2009-08-21 18:29:01 +00:00
|
|
|
|
|
|
|
/// @name Accessors
|
|
|
|
/// @{
|
|
|
|
|
|
|
|
unsigned getAlignment() const { return Alignment; }
|
2010-02-13 09:28:03 +00:00
|
|
|
|
2009-08-21 18:29:01 +00:00
|
|
|
int64_t getValue() const { return Value; }
|
|
|
|
|
|
|
|
unsigned getValueSize() const { return ValueSize; }
|
|
|
|
|
|
|
|
unsigned getMaxBytesToEmit() const { return MaxBytesToEmit; }
|
|
|
|
|
2010-02-23 18:26:34 +00:00
|
|
|
unsigned getEmitNops() const { return EmitNops; }
|
|
|
|
|
2009-08-21 18:29:01 +00:00
|
|
|
/// @}
|
|
|
|
|
2010-02-13 09:28:03 +00:00
|
|
|
static bool classof(const MCFragment *F) {
|
|
|
|
return F->getKind() == MCFragment::FT_Align;
|
2009-08-21 18:29:01 +00:00
|
|
|
}
|
|
|
|
static bool classof(const MCAlignFragment *) { return true; }
|
2010-02-13 09:28:03 +00:00
|
|
|
|
|
|
|
virtual void dump();
|
2009-08-21 18:29:01 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
class MCFillFragment : public MCFragment {
|
|
|
|
/// Value - Value to use for filling bytes.
|
2010-02-13 09:28:32 +00:00
|
|
|
int64_t Value;
|
2009-08-21 18:29:01 +00:00
|
|
|
|
|
|
|
/// ValueSize - The size (in bytes) of \arg Value to use when filling.
|
|
|
|
unsigned ValueSize;
|
|
|
|
|
|
|
|
/// Count - The number of copies of \arg Value to insert.
|
|
|
|
uint64_t Count;
|
|
|
|
|
|
|
|
public:
|
2010-02-13 09:28:32 +00:00
|
|
|
MCFillFragment(int64_t _Value, unsigned _ValueSize, uint64_t _Count,
|
2010-02-13 09:28:03 +00:00
|
|
|
MCSectionData *SD = 0)
|
2009-08-21 18:29:01 +00:00
|
|
|
: MCFragment(FT_Fill, SD),
|
2010-02-13 09:28:32 +00:00
|
|
|
Value(_Value), ValueSize(_ValueSize), Count(_Count) {}
|
2009-08-21 18:29:01 +00:00
|
|
|
|
|
|
|
/// @name Accessors
|
|
|
|
/// @{
|
|
|
|
|
2010-02-13 09:28:32 +00:00
|
|
|
int64_t getValue() const { return Value; }
|
2010-02-13 09:28:03 +00:00
|
|
|
|
2009-08-21 18:29:01 +00:00
|
|
|
unsigned getValueSize() const { return ValueSize; }
|
|
|
|
|
|
|
|
uint64_t getCount() const { return Count; }
|
|
|
|
|
|
|
|
/// @}
|
|
|
|
|
2010-02-13 09:28:03 +00:00
|
|
|
static bool classof(const MCFragment *F) {
|
|
|
|
return F->getKind() == MCFragment::FT_Fill;
|
2009-08-21 18:29:01 +00:00
|
|
|
}
|
|
|
|
static bool classof(const MCFillFragment *) { return true; }
|
2010-02-13 09:28:03 +00:00
|
|
|
|
|
|
|
virtual void dump();
|
2009-08-21 18:29:01 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
class MCOrgFragment : public MCFragment {
|
|
|
|
/// Offset - The offset this fragment should start at.
|
2009-10-16 01:58:03 +00:00
|
|
|
const MCExpr *Offset;
|
2009-08-21 18:29:01 +00:00
|
|
|
|
2010-02-13 09:28:03 +00:00
|
|
|
/// Value - Value to use for filling bytes.
|
2009-08-21 23:07:38 +00:00
|
|
|
int8_t Value;
|
2009-08-21 18:29:01 +00:00
|
|
|
|
|
|
|
public:
|
2009-10-16 01:58:03 +00:00
|
|
|
MCOrgFragment(const MCExpr &_Offset, int8_t _Value, MCSectionData *SD = 0)
|
2009-08-21 18:29:01 +00:00
|
|
|
: MCFragment(FT_Org, SD),
|
2009-10-16 01:58:03 +00:00
|
|
|
Offset(&_Offset), Value(_Value) {}
|
2009-08-28 05:49:21 +00:00
|
|
|
|
2009-08-21 18:29:01 +00:00
|
|
|
/// @name Accessors
|
|
|
|
/// @{
|
|
|
|
|
2009-10-16 01:58:03 +00:00
|
|
|
const MCExpr &getOffset() const { return *Offset; }
|
2010-02-13 09:28:03 +00:00
|
|
|
|
2009-08-21 23:07:38 +00:00
|
|
|
uint8_t getValue() const { return Value; }
|
2009-08-21 18:29:01 +00:00
|
|
|
|
|
|
|
/// @}
|
|
|
|
|
2010-02-13 09:28:03 +00:00
|
|
|
static bool classof(const MCFragment *F) {
|
|
|
|
return F->getKind() == MCFragment::FT_Org;
|
2009-08-21 18:29:01 +00:00
|
|
|
}
|
|
|
|
static bool classof(const MCOrgFragment *) { return true; }
|
2010-02-13 09:28:03 +00:00
|
|
|
|
|
|
|
virtual void dump();
|
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:49:21 +00:00
|
|
|
/// MCZeroFillFragment - Represent data which has a fixed size and alignment,
|
|
|
|
/// but requires no physical space in the object file.
|
|
|
|
class MCZeroFillFragment : public MCFragment {
|
|
|
|
/// Size - The size of this fragment.
|
|
|
|
uint64_t Size;
|
|
|
|
|
|
|
|
/// Alignment - The alignment for this fragment.
|
|
|
|
unsigned Alignment;
|
|
|
|
|
|
|
|
public:
|
|
|
|
MCZeroFillFragment(uint64_t _Size, unsigned _Alignment, MCSectionData *SD = 0)
|
|
|
|
: MCFragment(FT_ZeroFill, SD),
|
|
|
|
Size(_Size), Alignment(_Alignment) {}
|
|
|
|
|
|
|
|
/// @name Accessors
|
|
|
|
/// @{
|
|
|
|
|
|
|
|
uint64_t getSize() const { return Size; }
|
2010-02-13 09:28:03 +00:00
|
|
|
|
2009-08-28 05:49:21 +00:00
|
|
|
unsigned getAlignment() const { return Alignment; }
|
|
|
|
|
|
|
|
/// @}
|
|
|
|
|
2010-02-13 09:28:03 +00:00
|
|
|
static bool classof(const MCFragment *F) {
|
|
|
|
return F->getKind() == MCFragment::FT_ZeroFill;
|
2009-08-28 05:49:21 +00:00
|
|
|
}
|
|
|
|
static bool classof(const MCZeroFillFragment *) { return true; }
|
2010-02-13 09:28:03 +00:00
|
|
|
|
|
|
|
virtual void dump();
|
2009-08-28 05:49:21 +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
|
|
|
// FIXME: Should this be a separate class, or just merged into MCSection? Since
|
|
|
|
// we anticipate the fast path being through an MCAssembler, the only reason to
|
|
|
|
// keep it out is for API abstraction.
|
|
|
|
class MCSectionData : public ilist_node<MCSectionData> {
|
2010-03-25 01:03:24 +00:00
|
|
|
friend class MCAsmLayout;
|
|
|
|
|
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(const MCSectionData&); // DO NOT IMPLEMENT
|
|
|
|
void operator=(const MCSectionData&); // DO NOT IMPLEMENT
|
|
|
|
|
|
|
|
public:
|
|
|
|
typedef iplist<MCFragment> FragmentListType;
|
|
|
|
|
2009-08-21 18:29:01 +00:00
|
|
|
typedef FragmentListType::const_iterator const_iterator;
|
|
|
|
typedef FragmentListType::iterator iterator;
|
|
|
|
|
2010-02-11 21:29:46 +00:00
|
|
|
typedef FragmentListType::const_reverse_iterator const_reverse_iterator;
|
|
|
|
typedef FragmentListType::reverse_iterator reverse_iterator;
|
2009-08-26 13:58: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
|
|
|
private:
|
|
|
|
iplist<MCFragment> Fragments;
|
2009-08-27 00:38:04 +00:00
|
|
|
const MCSection *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-03-25 07:10:11 +00:00
|
|
|
/// Ordinal - The section index in the assemblers section list.
|
|
|
|
unsigned Ordinal;
|
|
|
|
|
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
|
|
|
/// Alignment - The maximum alignment seen in this section.
|
|
|
|
unsigned Alignment;
|
|
|
|
|
|
|
|
/// @name Assembler Backend Data
|
|
|
|
/// @{
|
|
|
|
//
|
|
|
|
// FIXME: This could all be kept private to the assembler implementation.
|
|
|
|
|
2009-08-26 02:48:04 +00:00
|
|
|
/// Address - The computed address of this section. This is ~0 until
|
|
|
|
/// initialized.
|
|
|
|
uint64_t Address;
|
|
|
|
|
2009-08-26 04:13:32 +00:00
|
|
|
/// Size - The content size of this section. This is ~0 until initialized.
|
|
|
|
uint64_t Size;
|
|
|
|
|
2009-08-21 18:29:01 +00:00
|
|
|
/// FileSize - The size of this section in the object file. This is ~0 until
|
|
|
|
/// initialized.
|
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
|
|
|
uint64_t FileSize;
|
|
|
|
|
2010-02-02 21:44:01 +00:00
|
|
|
/// HasInstructions - Whether this section has had instructions emitted into
|
|
|
|
/// it.
|
|
|
|
unsigned HasInstructions : 1;
|
|
|
|
|
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-02-13 09:28:03 +00:00
|
|
|
public:
|
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
|
|
|
// Only for use as sentinel.
|
|
|
|
MCSectionData();
|
|
|
|
MCSectionData(const MCSection &Section, MCAssembler *A = 0);
|
|
|
|
|
2009-08-27 00:38:04 +00:00
|
|
|
const MCSection &getSection() const { return *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
|
|
|
|
|
|
|
unsigned getAlignment() const { return Alignment; }
|
|
|
|
void setAlignment(unsigned Value) { Alignment = Value; }
|
|
|
|
|
2010-03-25 02:00:07 +00:00
|
|
|
bool hasInstructions() const { return HasInstructions; }
|
|
|
|
void setHasInstructions(bool Value) { HasInstructions = Value; }
|
|
|
|
|
2010-03-25 07:10:11 +00:00
|
|
|
unsigned getOrdinal() const { return Ordinal; }
|
|
|
|
void setOrdinal(unsigned Value) { Ordinal = Value; }
|
|
|
|
|
2009-08-26 13:57:54 +00:00
|
|
|
/// @name Fragment Access
|
2009-08-21 18:29:01 +00:00
|
|
|
/// @{
|
|
|
|
|
|
|
|
const FragmentListType &getFragmentList() const { return Fragments; }
|
|
|
|
FragmentListType &getFragmentList() { return Fragments; }
|
|
|
|
|
|
|
|
iterator begin() { return Fragments.begin(); }
|
|
|
|
const_iterator begin() const { return Fragments.begin(); }
|
|
|
|
|
|
|
|
iterator end() { return Fragments.end(); }
|
|
|
|
const_iterator end() const { return Fragments.end(); }
|
|
|
|
|
2010-02-11 21:29:46 +00:00
|
|
|
reverse_iterator rbegin() { return Fragments.rbegin(); }
|
|
|
|
const_reverse_iterator rbegin() const { return Fragments.rbegin(); }
|
2009-08-26 13:58:10 +00:00
|
|
|
|
2010-02-11 21:29:46 +00:00
|
|
|
reverse_iterator rend() { return Fragments.rend(); }
|
|
|
|
const_reverse_iterator rend() const { return Fragments.rend(); }
|
2009-08-26 13:58:10 +00:00
|
|
|
|
2010-02-11 21:29:46 +00:00
|
|
|
size_t size() const { return Fragments.size(); }
|
2009-08-26 13:58:10 +00:00
|
|
|
|
2010-02-11 21:29:46 +00:00
|
|
|
bool empty() const { return Fragments.empty(); }
|
2009-08-26 13:58:10 +00:00
|
|
|
|
2010-02-13 09:28:03 +00:00
|
|
|
void dump();
|
2010-03-25 07:10:11 +00:00
|
|
|
|
|
|
|
/// @}
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
};
|
|
|
|
|
2009-08-22 10:13:24 +00:00
|
|
|
// FIXME: Same concerns as with SectionData.
|
|
|
|
class MCSymbolData : public ilist_node<MCSymbolData> {
|
|
|
|
public:
|
2009-09-01 04:09:03 +00:00
|
|
|
const MCSymbol *Symbol;
|
2009-08-22 10:13:24 +00:00
|
|
|
|
|
|
|
/// Fragment - The fragment this symbol's value is relative to, if any.
|
|
|
|
MCFragment *Fragment;
|
|
|
|
|
|
|
|
/// Offset - The offset to apply to the fragment address to form this symbol's
|
|
|
|
/// value.
|
|
|
|
uint64_t Offset;
|
2010-02-13 09:28:03 +00:00
|
|
|
|
2009-08-22 11:41:10 +00:00
|
|
|
/// IsExternal - True if this symbol is visible outside this translation
|
|
|
|
/// unit.
|
|
|
|
unsigned IsExternal : 1;
|
2009-08-22 10:13:24 +00:00
|
|
|
|
2009-08-24 08:40:12 +00:00
|
|
|
/// IsPrivateExtern - True if this symbol is private extern.
|
|
|
|
unsigned IsPrivateExtern : 1;
|
|
|
|
|
2009-08-28 07:08:35 +00:00
|
|
|
/// CommonSize - The size of the symbol, if it is 'common', or 0.
|
|
|
|
//
|
|
|
|
// FIXME: Pack this in with other fields? We could put it in offset, since a
|
|
|
|
// common symbol can never get a definition.
|
|
|
|
uint64_t CommonSize;
|
|
|
|
|
|
|
|
/// CommonAlign - The alignment of the symbol, if it is 'common'.
|
|
|
|
//
|
|
|
|
// FIXME: Pack this in with other fields?
|
|
|
|
unsigned CommonAlign;
|
|
|
|
|
2009-08-24 08:40:12 +00:00
|
|
|
/// Flags - The Flags field is used by object file implementations to store
|
|
|
|
/// additional per symbol information which is not easily classified.
|
|
|
|
uint32_t Flags;
|
|
|
|
|
2009-08-26 13:57:54 +00:00
|
|
|
/// Index - Index field, for use by the object file implementation.
|
|
|
|
uint64_t Index;
|
|
|
|
|
2009-08-22 10:13:24 +00:00
|
|
|
public:
|
|
|
|
// Only for use as sentinel.
|
|
|
|
MCSymbolData();
|
2009-08-31 08:08:06 +00:00
|
|
|
MCSymbolData(const MCSymbol &_Symbol, MCFragment *_Fragment, uint64_t _Offset,
|
2009-08-22 10:13:24 +00:00
|
|
|
MCAssembler *A = 0);
|
|
|
|
|
|
|
|
/// @name Accessors
|
|
|
|
/// @{
|
|
|
|
|
2009-09-01 04:09:03 +00:00
|
|
|
const MCSymbol &getSymbol() const { return *Symbol; }
|
2009-08-22 10:13:24 +00:00
|
|
|
|
|
|
|
MCFragment *getFragment() const { return Fragment; }
|
|
|
|
void setFragment(MCFragment *Value) { Fragment = Value; }
|
|
|
|
|
|
|
|
uint64_t getOffset() const { return Offset; }
|
|
|
|
void setOffset(uint64_t Value) { Offset = Value; }
|
|
|
|
|
2009-08-24 08:40:12 +00:00
|
|
|
/// @}
|
|
|
|
/// @name Symbol Attributes
|
|
|
|
/// @{
|
2010-02-13 09:28:03 +00:00
|
|
|
|
2009-08-24 08:40:12 +00:00
|
|
|
bool isExternal() const { return IsExternal; }
|
|
|
|
void setExternal(bool Value) { IsExternal = Value; }
|
2010-02-13 09:28:03 +00:00
|
|
|
|
2009-08-24 08:40:12 +00:00
|
|
|
bool isPrivateExtern() const { return IsPrivateExtern; }
|
|
|
|
void setPrivateExtern(bool Value) { IsPrivateExtern = Value; }
|
2009-08-28 07:08:35 +00:00
|
|
|
|
|
|
|
/// isCommon - Is this a 'common' symbol.
|
|
|
|
bool isCommon() const { return CommonSize != 0; }
|
|
|
|
|
|
|
|
/// setCommon - Mark this symbol as being 'common'.
|
|
|
|
///
|
|
|
|
/// \param Size - The size of the symbol.
|
|
|
|
/// \param Align - The alignment of the symbol.
|
|
|
|
void setCommon(uint64_t Size, unsigned Align) {
|
|
|
|
CommonSize = Size;
|
|
|
|
CommonAlign = Align;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// getCommonSize - Return the size of a 'common' symbol.
|
|
|
|
uint64_t getCommonSize() const {
|
|
|
|
assert(isCommon() && "Not a 'common' symbol!");
|
|
|
|
return CommonSize;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// getCommonAlignment - Return the alignment of a 'common' symbol.
|
|
|
|
unsigned getCommonAlignment() const {
|
|
|
|
assert(isCommon() && "Not a 'common' symbol!");
|
|
|
|
return CommonAlign;
|
|
|
|
}
|
|
|
|
|
2009-08-24 08:40:12 +00:00
|
|
|
/// getFlags - Get the (implementation defined) symbol flags.
|
|
|
|
uint32_t getFlags() const { return Flags; }
|
2009-08-22 11:41:10 +00:00
|
|
|
|
2009-08-24 08:40:12 +00:00
|
|
|
/// setFlags - Set the (implementation defined) symbol flags.
|
|
|
|
void setFlags(uint32_t Value) { Flags = Value; }
|
2010-02-13 09:28:03 +00:00
|
|
|
|
2009-08-26 13:57:54 +00:00
|
|
|
/// getIndex - Get the (implementation defined) index.
|
|
|
|
uint64_t getIndex() const { return Index; }
|
|
|
|
|
|
|
|
/// setIndex - Set the (implementation defined) index.
|
|
|
|
void setIndex(uint64_t Value) { Index = Value; }
|
2010-02-13 09:28:03 +00:00
|
|
|
|
|
|
|
/// @}
|
|
|
|
|
|
|
|
void dump();
|
2009-08-22 10:13:24 +00:00
|
|
|
};
|
|
|
|
|
2009-08-24 11:56:58 +00:00
|
|
|
// FIXME: This really doesn't belong here. See comments below.
|
|
|
|
struct IndirectSymbolData {
|
|
|
|
MCSymbol *Symbol;
|
|
|
|
MCSectionData *SectionData;
|
|
|
|
};
|
|
|
|
|
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
|
|
|
class MCAssembler {
|
2010-03-25 19:35:56 +00:00
|
|
|
friend class MCAsmLayout;
|
|
|
|
|
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:
|
|
|
|
typedef iplist<MCSectionData> SectionDataListType;
|
2009-08-22 10:13:24 +00:00
|
|
|
typedef iplist<MCSymbolData> SymbolDataListType;
|
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
|
|
|
|
|
|
|
typedef SectionDataListType::const_iterator const_iterator;
|
|
|
|
typedef SectionDataListType::iterator iterator;
|
|
|
|
|
2009-08-22 10:13:24 +00:00
|
|
|
typedef SymbolDataListType::const_iterator const_symbol_iterator;
|
|
|
|
typedef SymbolDataListType::iterator symbol_iterator;
|
|
|
|
|
2010-03-19 07:09:33 +00:00
|
|
|
typedef std::vector<IndirectSymbolData>::const_iterator
|
|
|
|
const_indirect_symbol_iterator;
|
2009-08-24 11:56:58 +00:00
|
|
|
typedef std::vector<IndirectSymbolData>::iterator indirect_symbol_iterator;
|
|
|
|
|
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
|
|
|
private:
|
|
|
|
MCAssembler(const MCAssembler&); // DO NOT IMPLEMENT
|
|
|
|
void operator=(const MCAssembler&); // DO NOT IMPLEMENT
|
|
|
|
|
2009-08-31 08:07:55 +00:00
|
|
|
MCContext &Context;
|
|
|
|
|
2010-03-11 01:34:27 +00:00
|
|
|
TargetAsmBackend &Backend;
|
|
|
|
|
2010-03-19 10:43:18 +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
|
|
|
raw_ostream &OS;
|
2010-02-13 09:28:03 +00:00
|
|
|
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
iplist<MCSectionData> Sections;
|
|
|
|
|
2009-08-22 10:13:24 +00:00
|
|
|
iplist<MCSymbolData> Symbols;
|
|
|
|
|
2010-03-10 20:58:29 +00:00
|
|
|
/// The map of sections to their associated assembler backend data.
|
|
|
|
//
|
|
|
|
// FIXME: Avoid this indirection?
|
|
|
|
DenseMap<const MCSection*, MCSectionData*> SectionMap;
|
|
|
|
|
|
|
|
/// The map of symbols to their associated assembler backend data.
|
|
|
|
//
|
|
|
|
// FIXME: Avoid this indirection?
|
|
|
|
DenseMap<const MCSymbol*, MCSymbolData*> SymbolMap;
|
|
|
|
|
2009-08-24 11:56:58 +00:00
|
|
|
std::vector<IndirectSymbolData> IndirectSymbols;
|
|
|
|
|
2010-03-25 22:49:09 +00:00
|
|
|
unsigned RelaxAll : 1;
|
2009-08-26 21:22:22 +00:00
|
|
|
unsigned SubsectionsViaSymbols : 1;
|
|
|
|
|
2009-08-21 18:29:01 +00:00
|
|
|
private:
|
2010-03-19 09:28:59 +00:00
|
|
|
/// Evaluate a fixup to a relocatable expression and the value which should be
|
|
|
|
/// placed into the fixup.
|
|
|
|
///
|
|
|
|
/// \param Layout The layout to use for evaluation.
|
|
|
|
/// \param Fixup The fixup to evaluate.
|
|
|
|
/// \param DF The fragment the fixup is inside.
|
|
|
|
/// \param Target [out] On return, the relocatable expression the fixup
|
|
|
|
/// evaluates to.
|
|
|
|
/// \param Value [out] On return, the value of the fixup as currently layed
|
|
|
|
/// out.
|
|
|
|
/// \return Whether the fixup value was fully resolved. This is true if the
|
|
|
|
/// \arg Value result is fixed, otherwise the value may change due to
|
|
|
|
/// relocation.
|
|
|
|
bool EvaluateFixup(const MCAsmLayout &Layout,
|
2010-03-22 21:49:41 +00:00
|
|
|
const MCAsmFixup &Fixup, const MCFragment *DF,
|
2010-03-19 09:28:59 +00:00
|
|
|
MCValue &Target, uint64_t &Value) const;
|
|
|
|
|
2010-03-12 22:07:14 +00:00
|
|
|
/// Check whether a fixup can be satisfied, or whether it needs to be relaxed
|
|
|
|
/// (increased in size, in order to hold its value correctly).
|
2010-03-22 21:49:41 +00:00
|
|
|
bool FixupNeedsRelaxation(const MCAsmFixup &Fixup, const MCFragment *DF,
|
2010-03-22 20:35:35 +00:00
|
|
|
const MCAsmLayout &Layout) const;
|
2010-03-12 22:07:14 +00:00
|
|
|
|
2010-03-23 03:13:05 +00:00
|
|
|
/// Check whether the given fragment needs relaxation.
|
|
|
|
bool FragmentNeedsRelaxation(const MCInstFragment *IF,
|
|
|
|
const MCAsmLayout &Layout) const;
|
|
|
|
|
2010-03-25 18:16:38 +00:00
|
|
|
/// LayoutSection - Assign the section the given \arg StartAddress, and then
|
|
|
|
/// assign offsets and sizes to the fragments in the section \arg SD, and
|
|
|
|
/// update the section size.
|
2010-03-25 18:16:42 +00:00
|
|
|
///
|
|
|
|
/// \return The address at the end of the section, for use in laying out the
|
|
|
|
/// succeeding section.
|
|
|
|
uint64_t LayoutSection(MCSectionData &SD, MCAsmLayout &Layout,
|
|
|
|
uint64_t StartAddress);
|
2009-08-21 18:29:01 +00:00
|
|
|
|
2010-03-12 22:07:14 +00:00
|
|
|
/// LayoutOnce - Perform one layout iteration and return true if any offsets
|
|
|
|
/// were adjusted.
|
2010-03-22 20:35:35 +00:00
|
|
|
bool LayoutOnce(MCAsmLayout &Layout);
|
2010-03-12 22:07:14 +00:00
|
|
|
|
2010-03-22 23:16:48 +00:00
|
|
|
/// FinishLayout - Finalize a layout, including fragment lowering.
|
|
|
|
void FinishLayout(MCAsmLayout &Layout);
|
|
|
|
|
2010-03-12 21:00:49 +00:00
|
|
|
public:
|
2010-03-19 03:18:15 +00:00
|
|
|
/// Find the symbol which defines the atom containing given address, inside
|
|
|
|
/// the given section, or null if there is no such symbol.
|
|
|
|
//
|
2010-03-24 03:43:40 +00:00
|
|
|
// FIXME-PERF: Eliminate this, it is very slow.
|
|
|
|
const MCSymbolData *getAtomForAddress(const MCAsmLayout &Layout,
|
|
|
|
const MCSectionData *Section,
|
2010-03-19 03:18:15 +00:00
|
|
|
uint64_t Address) const;
|
|
|
|
|
|
|
|
/// Find the symbol which defines the atom containing the given symbol, or
|
|
|
|
/// null if there is no such symbol.
|
|
|
|
//
|
2010-03-24 03:43:40 +00:00
|
|
|
// FIXME-PERF: Eliminate this, it is very slow.
|
|
|
|
const MCSymbolData *getAtom(const MCAsmLayout &Layout,
|
|
|
|
const MCSymbolData *Symbol) const;
|
2010-03-19 03:18:15 +00:00
|
|
|
|
2010-03-19 03:18:09 +00:00
|
|
|
/// Check whether a particular symbol is visible to the linker and is required
|
|
|
|
/// in the symbol table, or whether it can be discarded by the assembler. This
|
|
|
|
/// also effects whether the assembler treats the label as potentially
|
|
|
|
/// defining a separate atom.
|
|
|
|
bool isSymbolLinkerVisible(const MCSymbolData *SD) const;
|
|
|
|
|
2010-03-19 09:28:59 +00:00
|
|
|
/// Emit the section contents using the given object writer.
|
|
|
|
//
|
|
|
|
// FIXME: Should MCAssembler always have a reference to the object writer?
|
2010-03-25 02:00:02 +00:00
|
|
|
void WriteSectionData(const MCSectionData *Section, const MCAsmLayout &Layout,
|
|
|
|
MCObjectWriter *OW) const;
|
2010-03-12 21:00:49 +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:
|
|
|
|
/// Construct a new assembler instance.
|
|
|
|
///
|
|
|
|
/// \arg OS - The stream to output to.
|
|
|
|
//
|
|
|
|
// FIXME: How are we going to parameterize this? Two obvious options are stay
|
|
|
|
// concrete and require clients to pass in a target like object. The other
|
|
|
|
// option is to make this abstract, and have targets provide concrete
|
|
|
|
// implementations as we do with AsmParser.
|
2010-03-19 10:43:18 +00:00
|
|
|
MCAssembler(MCContext &_Context, TargetAsmBackend &_Backend,
|
|
|
|
MCCodeEmitter &_Emitter, raw_ostream &OS);
|
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();
|
|
|
|
|
2009-08-31 08:07:55 +00:00
|
|
|
MCContext &getContext() const { return Context; }
|
|
|
|
|
2010-03-11 02:28:59 +00:00
|
|
|
TargetAsmBackend &getBackend() const { return Backend; }
|
|
|
|
|
2010-03-19 10:43:18 +00:00
|
|
|
MCCodeEmitter &getEmitter() const { return 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
|
|
|
/// Finish - Do final processing and write the object to the output stream.
|
|
|
|
void Finish();
|
|
|
|
|
2009-08-26 21:22:22 +00:00
|
|
|
// FIXME: This does not belong here.
|
|
|
|
bool getSubsectionsViaSymbols() const {
|
|
|
|
return SubsectionsViaSymbols;
|
|
|
|
}
|
|
|
|
void setSubsectionsViaSymbols(bool Value) {
|
|
|
|
SubsectionsViaSymbols = Value;
|
|
|
|
}
|
|
|
|
|
2010-03-25 22:49:09 +00:00
|
|
|
bool getRelaxAll() const { return RelaxAll; }
|
|
|
|
void setRelaxAll(bool Value) { RelaxAll = 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 Section List Access
|
|
|
|
/// @{
|
|
|
|
|
|
|
|
const SectionDataListType &getSectionList() const { return Sections; }
|
2010-02-13 09:28:03 +00:00
|
|
|
SectionDataListType &getSectionList() { return Sections; }
|
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
|
|
|
|
|
|
|
iterator begin() { return Sections.begin(); }
|
|
|
|
const_iterator begin() const { return Sections.begin(); }
|
|
|
|
|
|
|
|
iterator end() { return Sections.end(); }
|
|
|
|
const_iterator end() const { return Sections.end(); }
|
|
|
|
|
|
|
|
size_t size() const { return Sections.size(); }
|
|
|
|
|
2009-08-22 10:13:24 +00:00
|
|
|
/// @}
|
|
|
|
/// @name Symbol List Access
|
|
|
|
/// @{
|
|
|
|
|
|
|
|
const SymbolDataListType &getSymbolList() const { return Symbols; }
|
|
|
|
SymbolDataListType &getSymbolList() { return Symbols; }
|
|
|
|
|
|
|
|
symbol_iterator symbol_begin() { return Symbols.begin(); }
|
|
|
|
const_symbol_iterator symbol_begin() const { return Symbols.begin(); }
|
|
|
|
|
|
|
|
symbol_iterator symbol_end() { return Symbols.end(); }
|
|
|
|
const_symbol_iterator symbol_end() const { return Symbols.end(); }
|
|
|
|
|
|
|
|
size_t symbol_size() const { return Symbols.size(); }
|
|
|
|
|
2009-08-24 11:56:58 +00:00
|
|
|
/// @}
|
|
|
|
/// @name Indirect Symbol List Access
|
|
|
|
/// @{
|
|
|
|
|
|
|
|
// FIXME: This is a total hack, this should not be here. Once things are
|
|
|
|
// factored so that the streamer has direct access to the .o writer, it can
|
|
|
|
// disappear.
|
|
|
|
std::vector<IndirectSymbolData> &getIndirectSymbols() {
|
|
|
|
return IndirectSymbols;
|
|
|
|
}
|
|
|
|
|
|
|
|
indirect_symbol_iterator indirect_symbol_begin() {
|
|
|
|
return IndirectSymbols.begin();
|
|
|
|
}
|
2010-03-19 07:09:33 +00:00
|
|
|
const_indirect_symbol_iterator indirect_symbol_begin() const {
|
|
|
|
return IndirectSymbols.begin();
|
|
|
|
}
|
2009-08-24 11:56:58 +00:00
|
|
|
|
|
|
|
indirect_symbol_iterator indirect_symbol_end() {
|
|
|
|
return IndirectSymbols.end();
|
|
|
|
}
|
2010-03-19 07:09:33 +00:00
|
|
|
const_indirect_symbol_iterator indirect_symbol_end() const {
|
|
|
|
return IndirectSymbols.end();
|
|
|
|
}
|
2009-08-24 11:56:58 +00:00
|
|
|
|
|
|
|
size_t indirect_symbol_size() const { return IndirectSymbols.size(); }
|
|
|
|
|
2010-03-10 20:58:29 +00:00
|
|
|
/// @}
|
|
|
|
/// @name Backend Data Access
|
|
|
|
/// @{
|
|
|
|
|
2010-03-12 21:00:45 +00:00
|
|
|
MCSectionData &getSectionData(const MCSection &Section) const {
|
|
|
|
MCSectionData *Entry = SectionMap.lookup(&Section);
|
2010-03-10 20:58:29 +00:00
|
|
|
assert(Entry && "Missing section data!");
|
|
|
|
return *Entry;
|
|
|
|
}
|
|
|
|
|
|
|
|
MCSectionData &getOrCreateSectionData(const MCSection &Section,
|
|
|
|
bool *Created = 0) {
|
|
|
|
MCSectionData *&Entry = SectionMap[&Section];
|
|
|
|
|
|
|
|
if (Created) *Created = !Entry;
|
|
|
|
if (!Entry)
|
|
|
|
Entry = new MCSectionData(Section, this);
|
|
|
|
|
|
|
|
return *Entry;
|
|
|
|
}
|
|
|
|
|
2010-03-12 21:00:45 +00:00
|
|
|
MCSymbolData &getSymbolData(const MCSymbol &Symbol) const {
|
|
|
|
MCSymbolData *Entry = SymbolMap.lookup(&Symbol);
|
2010-03-10 20:58:29 +00:00
|
|
|
assert(Entry && "Missing symbol data!");
|
|
|
|
return *Entry;
|
|
|
|
}
|
|
|
|
|
|
|
|
MCSymbolData &getOrCreateSymbolData(const MCSymbol &Symbol,
|
|
|
|
bool *Created = 0) {
|
|
|
|
MCSymbolData *&Entry = SymbolMap[&Symbol];
|
|
|
|
|
|
|
|
if (Created) *Created = !Entry;
|
|
|
|
if (!Entry)
|
|
|
|
Entry = new MCSymbolData(Symbol, 0, 0, this);
|
|
|
|
|
|
|
|
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
|
|
|
/// @}
|
2010-02-13 09:28:03 +00:00
|
|
|
|
|
|
|
void dump();
|
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 namespace llvm
|
|
|
|
|
|
|
|
#endif
|