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
|
|
|
|
|
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"
|
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;
|
|
|
|
class MCAssembler;
|
2009-08-31 08:07:55 +00:00
|
|
|
class MCContext;
|
2009-10-16 01:58:03 +00:00
|
|
|
class MCExpr;
|
2010-02-11 21:29:29 +00:00
|
|
|
class MCFragment;
|
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;
|
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.
|
|
|
|
struct MCAsmFixup {
|
|
|
|
/// 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;
|
|
|
|
|
|
|
|
/// Size - The fixup size.
|
|
|
|
unsigned Size;
|
|
|
|
|
|
|
|
/// FixedValue - The value to replace the fix up by.
|
|
|
|
//
|
|
|
|
// FIXME: This should not be here.
|
|
|
|
uint64_t FixedValue;
|
|
|
|
|
|
|
|
public:
|
2010-02-13 09:28:03 +00:00
|
|
|
MCAsmFixup(uint64_t _Offset, const MCExpr &_Value, unsigned _Size)
|
2010-02-11 21:29:46 +00:00
|
|
|
: Offset(_Offset), Value(&_Value), Size(_Size), FixedValue(0) {}
|
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> {
|
|
|
|
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_Data,
|
|
|
|
FT_Align,
|
|
|
|
FT_Fill,
|
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;
|
|
|
|
|
|
|
|
/// FileSize - The file size of this section. This is ~0 until initialized.
|
2009-08-21 18:29:01 +00:00
|
|
|
uint64_t FileSize;
|
|
|
|
|
|
|
|
/// @}
|
|
|
|
|
|
|
|
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; }
|
|
|
|
|
2009-08-21 18:29:01 +00:00
|
|
|
// FIXME: This should be abstract, fix sentinel.
|
2009-08-21 23:07:38 +00:00
|
|
|
virtual uint64_t getMaxFileSize() const {
|
2009-08-22 10:13:24 +00:00
|
|
|
assert(0 && "Invalid getMaxFileSize call!");
|
2009-08-21 23:11:36 +00:00
|
|
|
return 0;
|
2009-12-19 07:05:23 +00:00
|
|
|
}
|
2009-08-21 18:29:01 +00:00
|
|
|
|
|
|
|
/// @name Assembler Backend Support
|
|
|
|
/// @{
|
|
|
|
//
|
|
|
|
// FIXME: This could all be kept private to the assembler implementation.
|
|
|
|
|
2009-08-26 02:48:04 +00:00
|
|
|
uint64_t getAddress() const;
|
|
|
|
|
2010-02-13 09:28:03 +00:00
|
|
|
uint64_t getFileSize() const {
|
2009-08-21 18:29:01 +00:00
|
|
|
assert(FileSize != ~UINT64_C(0) && "File size not set!");
|
|
|
|
return FileSize;
|
|
|
|
}
|
|
|
|
void setFileSize(uint64_t Value) {
|
|
|
|
assert(Value <= getMaxFileSize() && "Invalid file size!");
|
|
|
|
FileSize = Value;
|
|
|
|
}
|
|
|
|
|
2009-08-22 08:27:54 +00:00
|
|
|
uint64_t getOffset() const {
|
|
|
|
assert(Offset != ~UINT64_C(0) && "File offset not set!");
|
|
|
|
return Offset;
|
2009-08-21 18:29:01 +00:00
|
|
|
}
|
2009-08-22 08:27:54 +00:00
|
|
|
void setOffset(uint64_t Value) { Offset = 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
|
|
|
|
/// @{
|
|
|
|
|
2009-08-21 23:07:38 +00:00
|
|
|
uint64_t getMaxFileSize() const {
|
2009-08-21 18:29:01 +00:00
|
|
|
return Contents.size();
|
|
|
|
}
|
|
|
|
|
|
|
|
SmallString<32> &getContents() { return Contents; }
|
|
|
|
const SmallString<32> &getContents() const { return Contents; }
|
|
|
|
|
|
|
|
/// @}
|
|
|
|
|
2010-02-13 09:28:43 +00:00
|
|
|
/// @name Fixup Access
|
|
|
|
/// @{
|
|
|
|
|
|
|
|
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
|
|
|
};
|
|
|
|
|
|
|
|
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;
|
|
|
|
|
|
|
|
public:
|
|
|
|
MCAlignFragment(unsigned _Alignment, int64_t _Value, unsigned _ValueSize,
|
|
|
|
unsigned _MaxBytesToEmit, MCSectionData *SD = 0)
|
|
|
|
: MCFragment(FT_Align, SD), Alignment(_Alignment),
|
|
|
|
Value(_Value),ValueSize(_ValueSize),
|
|
|
|
MaxBytesToEmit(_MaxBytesToEmit) {}
|
|
|
|
|
|
|
|
/// @name Accessors
|
|
|
|
/// @{
|
|
|
|
|
2009-08-21 23:07:38 +00:00
|
|
|
uint64_t getMaxFileSize() const {
|
2009-08-21 18:29:01 +00:00
|
|
|
return std::max(Alignment - 1, MaxBytesToEmit);
|
|
|
|
}
|
|
|
|
|
|
|
|
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-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
|
|
|
|
/// @{
|
|
|
|
|
2009-08-21 23:07:38 +00:00
|
|
|
uint64_t getMaxFileSize() const {
|
2009-08-21 18:29:01 +00:00
|
|
|
return ValueSize * Count;
|
|
|
|
}
|
|
|
|
|
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-08-21 23:07:38 +00:00
|
|
|
uint64_t getMaxFileSize() const {
|
|
|
|
// FIXME: This doesn't make much sense.
|
|
|
|
return ~UINT64_C(0);
|
2009-08-21 18:29:01 +00:00
|
|
|
}
|
|
|
|
|
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 getMaxFileSize() const {
|
|
|
|
// FIXME: This also doesn't make much sense, this method is misnamed.
|
|
|
|
return ~UINT64_C(0);
|
|
|
|
}
|
|
|
|
|
|
|
|
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> {
|
|
|
|
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
|
|
|
|
|
|
|
/// 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; }
|
|
|
|
|
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
|
|
|
|
2009-08-21 18:29:01 +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 Assembler Backend Support
|
|
|
|
/// @{
|
|
|
|
//
|
|
|
|
// FIXME: This could all be kept private to the assembler implementation.
|
|
|
|
|
2010-02-13 09:28:03 +00:00
|
|
|
uint64_t getAddress() const {
|
2009-08-26 02:48:04 +00:00
|
|
|
assert(Address != ~UINT64_C(0) && "Address not set!");
|
|
|
|
return Address;
|
|
|
|
}
|
|
|
|
void setAddress(uint64_t Value) { Address = Value; }
|
|
|
|
|
2010-02-13 09:28:03 +00:00
|
|
|
uint64_t getSize() const {
|
2009-08-26 04:13:32 +00:00
|
|
|
assert(Size != ~UINT64_C(0) && "File size not set!");
|
|
|
|
return Size;
|
|
|
|
}
|
|
|
|
void setSize(uint64_t Value) { Size = Value; }
|
|
|
|
|
2010-02-13 09:28:03 +00:00
|
|
|
uint64_t getFileSize() const {
|
2009-08-21 18:29:01 +00:00
|
|
|
assert(FileSize != ~UINT64_C(0) && "File size not set!");
|
|
|
|
return FileSize;
|
|
|
|
}
|
2010-02-13 09:28:03 +00:00
|
|
|
void setFileSize(uint64_t Value) { FileSize = 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
|
|
|
|
2010-02-02 21:44:01 +00:00
|
|
|
bool hasInstructions() const { return HasInstructions; }
|
|
|
|
void setHasInstructions(bool Value) { HasInstructions = 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
|
|
|
/// @}
|
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
|
|
|
};
|
|
|
|
|
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 {
|
|
|
|
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;
|
|
|
|
|
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;
|
|
|
|
|
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;
|
|
|
|
|
2009-08-24 11:56:58 +00:00
|
|
|
std::vector<IndirectSymbolData> IndirectSymbols;
|
|
|
|
|
2009-08-26 21:22:22 +00:00
|
|
|
unsigned SubsectionsViaSymbols : 1;
|
|
|
|
|
2009-08-21 18:29:01 +00:00
|
|
|
private:
|
|
|
|
/// LayoutSection - Assign offsets and sizes to the fragments in the section
|
|
|
|
/// \arg SD, and update the section size. The section file offset should
|
|
|
|
/// already have been computed.
|
2009-08-28 05:49:04 +00:00
|
|
|
void LayoutSection(MCSectionData &SD);
|
2009-08-21 18:29:01 +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.
|
2009-08-31 08:07:55 +00:00
|
|
|
MCAssembler(MCContext &_Context, 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; }
|
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
|
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();
|
|
|
|
}
|
|
|
|
|
|
|
|
indirect_symbol_iterator indirect_symbol_end() {
|
|
|
|
return IndirectSymbols.end();
|
|
|
|
}
|
|
|
|
|
|
|
|
size_t indirect_symbol_size() const { return IndirectSymbols.size(); }
|
|
|
|
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
/// @}
|
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
|