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/MC/MCValue.h"
|
|
|
|
#include "llvm/Support/Casting.h"
|
2009-08-21 13:59:49 +00:00
|
|
|
#include "llvm/Support/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;
|
|
|
|
class MCSection;
|
|
|
|
class MCSectionData;
|
|
|
|
|
|
|
|
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,
|
|
|
|
FT_Org
|
|
|
|
};
|
|
|
|
|
|
|
|
private:
|
|
|
|
FragmentType Kind;
|
|
|
|
|
|
|
|
/// @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:
|
|
|
|
MCFragment(FragmentType _Kind, MCSectionData *SD = 0);
|
|
|
|
|
|
|
|
public:
|
|
|
|
// Only for sentinel.
|
|
|
|
MCFragment();
|
|
|
|
virtual ~MCFragment();
|
|
|
|
|
|
|
|
FragmentType getKind() const { return Kind; }
|
|
|
|
|
|
|
|
// 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-08-21 18:29:01 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
/// @name Assembler Backend Support
|
|
|
|
/// @{
|
|
|
|
//
|
|
|
|
// FIXME: This could all be kept private to the assembler implementation.
|
|
|
|
|
|
|
|
unsigned getFileSize() const {
|
|
|
|
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; }
|
|
|
|
};
|
|
|
|
|
|
|
|
class MCDataFragment : public MCFragment {
|
|
|
|
SmallString<32> Contents;
|
|
|
|
|
|
|
|
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; }
|
|
|
|
|
|
|
|
/// @}
|
|
|
|
|
|
|
|
static bool classof(const MCFragment *F) {
|
|
|
|
return F->getKind() == MCFragment::FT_Data;
|
|
|
|
}
|
|
|
|
static bool classof(const MCDataFragment *) { return true; }
|
|
|
|
};
|
|
|
|
|
|
|
|
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; }
|
|
|
|
|
|
|
|
int64_t getValue() const { return Value; }
|
|
|
|
|
|
|
|
unsigned getValueSize() const { return ValueSize; }
|
|
|
|
|
|
|
|
unsigned getMaxBytesToEmit() const { return MaxBytesToEmit; }
|
|
|
|
|
|
|
|
/// @}
|
|
|
|
|
|
|
|
static bool classof(const MCFragment *F) {
|
|
|
|
return F->getKind() == MCFragment::FT_Align;
|
|
|
|
}
|
|
|
|
static bool classof(const MCAlignFragment *) { return true; }
|
|
|
|
};
|
|
|
|
|
|
|
|
class MCFillFragment : public MCFragment {
|
|
|
|
/// Value - Value to use for filling bytes.
|
|
|
|
MCValue Value;
|
|
|
|
|
|
|
|
/// 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:
|
|
|
|
MCFillFragment(MCValue _Value, unsigned _ValueSize, uint64_t _Count,
|
|
|
|
MCSectionData *SD = 0)
|
|
|
|
: MCFragment(FT_Fill, SD),
|
|
|
|
Value(_Value), ValueSize(_ValueSize), Count(_Count) {}
|
|
|
|
|
|
|
|
/// @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;
|
|
|
|
}
|
|
|
|
|
|
|
|
MCValue getValue() const { return Value; }
|
|
|
|
|
|
|
|
unsigned getValueSize() const { return ValueSize; }
|
|
|
|
|
|
|
|
uint64_t getCount() const { return Count; }
|
|
|
|
|
|
|
|
/// @}
|
|
|
|
|
|
|
|
static bool classof(const MCFragment *F) {
|
|
|
|
return F->getKind() == MCFragment::FT_Fill;
|
|
|
|
}
|
|
|
|
static bool classof(const MCFillFragment *) { return true; }
|
|
|
|
};
|
|
|
|
|
|
|
|
class MCOrgFragment : public MCFragment {
|
|
|
|
/// Offset - The offset this fragment should start at.
|
|
|
|
MCValue Offset;
|
|
|
|
|
|
|
|
/// 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-08-21 23:07:38 +00:00
|
|
|
MCOrgFragment(MCValue _Offset, int8_t _Value, MCSectionData *SD = 0)
|
2009-08-21 18:29:01 +00:00
|
|
|
: MCFragment(FT_Org, SD),
|
2009-08-21 23:07:38 +00:00
|
|
|
Offset(_Offset), Value(_Value) {}
|
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
|
|
|
}
|
|
|
|
|
|
|
|
MCValue getOffset() const { return Offset; }
|
|
|
|
|
2009-08-21 23:07:38 +00:00
|
|
|
uint8_t getValue() const { return Value; }
|
2009-08-21 18:29:01 +00:00
|
|
|
|
|
|
|
/// @}
|
|
|
|
|
|
|
|
static bool classof(const MCFragment *F) {
|
|
|
|
return F->getKind() == MCFragment::FT_Org;
|
|
|
|
}
|
|
|
|
static bool classof(const MCOrgFragment *) { return true; }
|
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;
|
|
|
|
|
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;
|
|
|
|
const MCSection &Section;
|
|
|
|
|
|
|
|
/// 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-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;
|
|
|
|
|
|
|
|
/// @}
|
|
|
|
|
|
|
|
public:
|
|
|
|
// Only for use as sentinel.
|
|
|
|
MCSectionData();
|
|
|
|
MCSectionData(const MCSection &Section, MCAssembler *A = 0);
|
|
|
|
|
|
|
|
const MCSection &getSection() const { return Section; }
|
|
|
|
|
|
|
|
unsigned getAlignment() const { return Alignment; }
|
|
|
|
void setAlignment(unsigned Value) { Alignment = Value; }
|
|
|
|
|
2009-08-21 18:29:01 +00:00
|
|
|
/// @name Section List Access
|
|
|
|
/// @{
|
|
|
|
|
|
|
|
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(); }
|
|
|
|
|
|
|
|
size_t size() const { return Fragments.size(); }
|
|
|
|
|
2009-08-22 10:13:24 +00:00
|
|
|
bool empty() const { return Fragments.empty(); }
|
|
|
|
|
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.
|
|
|
|
|
2009-08-21 18:29:01 +00:00
|
|
|
unsigned getFileSize() const {
|
|
|
|
assert(FileSize != ~UINT64_C(0) && "File size not set!");
|
|
|
|
return FileSize;
|
|
|
|
}
|
|
|
|
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
|
|
|
|
|
|
|
/// @}
|
|
|
|
};
|
|
|
|
|
2009-08-22 10:13:24 +00:00
|
|
|
// FIXME: Same concerns as with SectionData.
|
|
|
|
class MCSymbolData : public ilist_node<MCSymbolData> {
|
|
|
|
public:
|
|
|
|
MCSymbol &Symbol;
|
|
|
|
|
|
|
|
/// 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;
|
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;
|
|
|
|
|
|
|
|
/// 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-22 10:13:24 +00:00
|
|
|
public:
|
|
|
|
// Only for use as sentinel.
|
|
|
|
MCSymbolData();
|
|
|
|
MCSymbolData(MCSymbol &_Symbol, MCFragment *_Fragment, uint64_t _Offset,
|
|
|
|
MCAssembler *A = 0);
|
|
|
|
|
|
|
|
/// @name Accessors
|
|
|
|
/// @{
|
|
|
|
|
|
|
|
MCSymbol &getSymbol() const { return Symbol; }
|
|
|
|
|
|
|
|
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
|
|
|
|
/// @{
|
|
|
|
|
|
|
|
bool isExternal() const { return IsExternal; }
|
|
|
|
void setExternal(bool Value) { IsExternal = Value; }
|
|
|
|
|
|
|
|
bool isPrivateExtern() const { return IsPrivateExtern; }
|
|
|
|
void setPrivateExtern(bool Value) { IsPrivateExtern = Value; }
|
|
|
|
|
|
|
|
/// 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; }
|
|
|
|
|
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
|
|
|
|
|
|
|
|
raw_ostream &OS;
|
|
|
|
|
|
|
|
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-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.
|
|
|
|
void LayoutSection(MCSectionData &SD);
|
|
|
|
|
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.
|
|
|
|
MCAssembler(raw_ostream &OS);
|
|
|
|
~MCAssembler();
|
|
|
|
|
|
|
|
/// Finish - Do final processing and write the object to the output stream.
|
|
|
|
void Finish();
|
|
|
|
|
|
|
|
/// @name Section List Access
|
|
|
|
/// @{
|
|
|
|
|
|
|
|
const SectionDataListType &getSectionList() const { return Sections; }
|
|
|
|
SectionDataListType &getSectionList() { return Sections; }
|
|
|
|
|
|
|
|
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
|
|
|
/// @}
|
|
|
|
};
|
|
|
|
|
|
|
|
} // end namespace llvm
|
|
|
|
|
|
|
|
#endif
|