llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
//===- MCAssembler.h - Object File Generation -------------------*- C++ -*-===//
|
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
#ifndef LLVM_MC_MCASSEMBLER_H
|
|
|
|
#define LLVM_MC_MCASSEMBLER_H
|
|
|
|
|
2010-03-10 20:58:29 +00:00
|
|
|
#include "llvm/ADT/DenseMap.h"
|
2015-01-19 21:11:14 +00:00
|
|
|
#include "llvm/ADT/DenseSet.h"
|
2014-10-11 15:07:21 +00:00
|
|
|
#include "llvm/ADT/PointerIntPair.h"
|
2010-12-14 18:46:57 +00:00
|
|
|
#include "llvm/ADT/SmallPtrSet.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"
|
2014-03-18 22:09:05 +00:00
|
|
|
#include "llvm/MC/MCDirectives.h"
|
2012-12-03 17:02:12 +00:00
|
|
|
#include "llvm/MC/MCFixup.h"
|
|
|
|
#include "llvm/MC/MCInst.h"
|
2014-03-29 07:34:53 +00:00
|
|
|
#include "llvm/MC/MCLinkerOptimizationHint.h"
|
2014-01-28 23:12:53 +00:00
|
|
|
#include "llvm/MC/MCSubtargetInfo.h"
|
2009-08-21 18:29:01 +00:00
|
|
|
#include "llvm/Support/Casting.h"
|
2010-11-29 18:16:10 +00:00
|
|
|
#include "llvm/Support/DataTypes.h"
|
2013-10-29 01:06:17 +00:00
|
|
|
#include <algorithm>
|
2009-08-24 11:56:58 +00:00
|
|
|
#include <vector> // FIXME: Shouldn't be needed.
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
|
|
|
|
namespace llvm {
|
|
|
|
class raw_ostream;
|
2010-03-12 21:00:49 +00:00
|
|
|
class MCAsmLayout;
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
class MCAssembler;
|
2009-08-31 08:07:55 +00:00
|
|
|
class MCContext;
|
2010-03-19 10:43:18 +00:00
|
|
|
class MCCodeEmitter;
|
2009-10-16 01:58:03 +00:00
|
|
|
class MCExpr;
|
2010-02-11 21:29:29 +00:00
|
|
|
class MCFragment;
|
2010-03-19 09:28:59 +00:00
|
|
|
class MCObjectWriter;
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
class MCSection;
|
|
|
|
class MCSectionData;
|
2014-01-28 23:12:53 +00:00
|
|
|
class MCSubtargetInfo;
|
2009-10-16 01:58:03 +00:00
|
|
|
class MCSymbol;
|
2010-05-10 22:45:09 +00:00
|
|
|
class MCSymbolData;
|
2010-03-12 21:00:49 +00:00
|
|
|
class MCValue;
|
2011-07-25 23:24:55 +00:00
|
|
|
class MCAsmBackend;
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
|
|
|
|
class MCFragment : public ilist_node<MCFragment> {
|
2010-03-25 01:03:24 +00:00
|
|
|
friend class MCAsmLayout;
|
|
|
|
|
2015-02-15 22:54:22 +00:00
|
|
|
MCFragment(const MCFragment&) = delete;
|
|
|
|
void operator=(const MCFragment&) = delete;
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
|
|
|
|
public:
|
2009-08-21 18:29:01 +00:00
|
|
|
enum FragmentType {
|
|
|
|
FT_Align,
|
2010-03-22 23:16:48 +00:00
|
|
|
FT_Data,
|
2013-01-15 23:22:09 +00:00
|
|
|
FT_CompactEncodedInst,
|
2009-08-21 18:29:01 +00:00
|
|
|
FT_Fill,
|
2013-01-08 00:22:56 +00:00
|
|
|
FT_Relaxable,
|
2010-09-30 17:16:09 +00:00
|
|
|
FT_Org,
|
2010-11-02 17:22:24 +00:00
|
|
|
FT_Dwarf,
|
2010-12-28 05:39:27 +00:00
|
|
|
FT_DwarfFrame,
|
2010-11-02 17:22:24 +00:00
|
|
|
FT_LEB
|
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;
|
|
|
|
|
2010-05-10 22:45:09 +00:00
|
|
|
/// Atom - The atom this fragment is in, as represented by it's defining
|
2014-03-11 21:22:57 +00:00
|
|
|
/// symbol.
|
2010-05-10 22:45:09 +00:00
|
|
|
MCSymbolData *Atom;
|
|
|
|
|
2009-08-21 18:29:01 +00:00
|
|
|
/// @name Assembler Backend Data
|
|
|
|
/// @{
|
|
|
|
//
|
|
|
|
// FIXME: This could all be kept private to the assembler implementation.
|
|
|
|
|
2009-08-22 08:27:54 +00:00
|
|
|
/// Offset - The offset of this fragment in its section. This is ~0 until
|
2009-08-21 18:29:01 +00:00
|
|
|
/// initialized.
|
2009-08-22 08:27:54 +00:00
|
|
|
uint64_t Offset;
|
|
|
|
|
2010-12-07 23:32:26 +00:00
|
|
|
/// LayoutOrder - The layout order of this fragment.
|
2010-05-14 00:37:14 +00:00
|
|
|
unsigned LayoutOrder;
|
2010-03-25 07:10:11 +00:00
|
|
|
|
2009-08-21 18:29:01 +00:00
|
|
|
/// @}
|
|
|
|
|
|
|
|
protected:
|
2015-03-16 18:06:57 +00:00
|
|
|
MCFragment(FragmentType Kind, MCSectionData *Parent = nullptr);
|
2009-08-21 18:29:01 +00:00
|
|
|
|
|
|
|
public:
|
|
|
|
// Only for sentinel.
|
|
|
|
MCFragment();
|
2010-07-28 20:28:45 +00:00
|
|
|
virtual ~MCFragment();
|
2009-08-21 18:29:01 +00:00
|
|
|
|
|
|
|
FragmentType getKind() const { return Kind; }
|
|
|
|
|
2009-08-26 02:48:04 +00:00
|
|
|
MCSectionData *getParent() const { return Parent; }
|
2013-04-17 21:18:16 +00:00
|
|
|
void setParent(MCSectionData *Value) { Parent = Value; }
|
2009-08-26 02:48:04 +00:00
|
|
|
|
2010-05-10 22:45:09 +00:00
|
|
|
MCSymbolData *getAtom() const { return Atom; }
|
|
|
|
void setAtom(MCSymbolData *Value) { Atom = Value; }
|
|
|
|
|
2010-05-14 00:37:14 +00:00
|
|
|
unsigned getLayoutOrder() const { return LayoutOrder; }
|
|
|
|
void setLayoutOrder(unsigned Value) { LayoutOrder = Value; }
|
2010-03-25 07:10:11 +00:00
|
|
|
|
2012-12-20 19:05:53 +00:00
|
|
|
/// \brief Does this fragment have instructions emitted into it? By default
|
2013-01-07 21:51:08 +00:00
|
|
|
/// this is false, but specific fragment types may set it to true.
|
2012-12-20 19:05:53 +00:00
|
|
|
virtual bool hasInstructions() const { return false; }
|
|
|
|
|
2013-01-07 21:51:08 +00:00
|
|
|
/// \brief Should this fragment be placed at the end of an aligned bundle?
|
|
|
|
virtual bool alignToBundleEnd() const { return false; }
|
2013-01-15 23:22:09 +00:00
|
|
|
virtual void setAlignToBundleEnd(bool V) { }
|
2013-01-07 21:51:08 +00:00
|
|
|
|
2012-12-20 19:05:53 +00:00
|
|
|
/// \brief Get the padding size that must be inserted before this fragment.
|
|
|
|
/// Used for bundling. By default, no padding is inserted.
|
|
|
|
/// Note that padding size is restricted to 8 bits. This is an optimization
|
|
|
|
/// to reduce the amount of space used for each fragment. In practice, larger
|
|
|
|
/// padding should never be required.
|
|
|
|
virtual uint8_t getBundlePadding() const {
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// \brief Set the padding size for this fragment. By default it's a no-op,
|
|
|
|
/// and only some fragments have a meaningful implementation.
|
|
|
|
virtual void setBundlePadding(uint8_t N) {
|
|
|
|
}
|
|
|
|
|
2010-05-26 06:50:57 +00:00
|
|
|
void dump();
|
2009-08-21 18:29:01 +00:00
|
|
|
};
|
|
|
|
|
2013-01-15 23:22:09 +00:00
|
|
|
/// Interface implemented by fragments that contain encoded instructions and/or
|
|
|
|
/// data.
|
|
|
|
///
|
2012-12-07 19:13:57 +00:00
|
|
|
class MCEncodedFragment : public MCFragment {
|
|
|
|
virtual void anchor();
|
2012-12-20 19:05:53 +00:00
|
|
|
|
|
|
|
uint8_t BundlePadding;
|
2012-12-07 19:13:57 +00:00
|
|
|
public:
|
2014-04-13 04:57:38 +00:00
|
|
|
MCEncodedFragment(MCFragment::FragmentType FType, MCSectionData *SD = nullptr)
|
2012-12-20 19:05:53 +00:00
|
|
|
: MCFragment(FType, SD), BundlePadding(0)
|
|
|
|
{
|
2012-12-07 19:13:57 +00:00
|
|
|
}
|
2015-04-11 02:11:45 +00:00
|
|
|
~MCEncodedFragment() override;
|
2012-12-07 19:13:57 +00:00
|
|
|
|
2012-12-07 22:06:56 +00:00
|
|
|
virtual SmallVectorImpl<char> &getContents() = 0;
|
|
|
|
virtual const SmallVectorImpl<char> &getContents() const = 0;
|
2012-12-07 19:13:57 +00:00
|
|
|
|
2014-03-07 09:26:03 +00:00
|
|
|
uint8_t getBundlePadding() const override {
|
2012-12-20 19:05:53 +00:00
|
|
|
return BundlePadding;
|
|
|
|
}
|
|
|
|
|
2014-03-07 09:26:03 +00:00
|
|
|
void setBundlePadding(uint8_t N) override {
|
2012-12-20 19:05:53 +00:00
|
|
|
BundlePadding = N;
|
|
|
|
}
|
|
|
|
|
2012-12-07 19:13:57 +00:00
|
|
|
static bool classof(const MCFragment *F) {
|
|
|
|
MCFragment::FragmentType Kind = F->getKind();
|
2013-01-15 23:22:09 +00:00
|
|
|
switch (Kind) {
|
|
|
|
default:
|
|
|
|
return false;
|
|
|
|
case MCFragment::FT_Relaxable:
|
|
|
|
case MCFragment::FT_CompactEncodedInst:
|
|
|
|
case MCFragment::FT_Data:
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
/// Interface implemented by fragments that contain encoded instructions and/or
|
|
|
|
/// data and also have fixups registered.
|
|
|
|
///
|
|
|
|
class MCEncodedFragmentWithFixups : public MCEncodedFragment {
|
2014-03-07 09:26:03 +00:00
|
|
|
void anchor() override;
|
2013-01-15 23:22:09 +00:00
|
|
|
|
|
|
|
public:
|
|
|
|
MCEncodedFragmentWithFixups(MCFragment::FragmentType FType,
|
2014-04-13 04:57:38 +00:00
|
|
|
MCSectionData *SD = nullptr)
|
2013-01-15 23:22:09 +00:00
|
|
|
: MCEncodedFragment(FType, SD)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2015-04-11 02:11:45 +00:00
|
|
|
~MCEncodedFragmentWithFixups() override;
|
2013-01-15 23:22:09 +00:00
|
|
|
|
|
|
|
typedef SmallVectorImpl<MCFixup>::const_iterator const_fixup_iterator;
|
|
|
|
typedef SmallVectorImpl<MCFixup>::iterator fixup_iterator;
|
|
|
|
|
|
|
|
virtual SmallVectorImpl<MCFixup> &getFixups() = 0;
|
|
|
|
virtual const SmallVectorImpl<MCFixup> &getFixups() const = 0;
|
|
|
|
|
|
|
|
virtual fixup_iterator fixup_begin() = 0;
|
|
|
|
virtual const_fixup_iterator fixup_begin() const = 0;
|
|
|
|
virtual fixup_iterator fixup_end() = 0;
|
|
|
|
virtual const_fixup_iterator fixup_end() const = 0;
|
|
|
|
|
|
|
|
static bool classof(const MCFragment *F) {
|
2013-01-16 16:52:08 +00:00
|
|
|
MCFragment::FragmentType Kind = F->getKind();
|
2014-04-10 21:53:47 +00:00
|
|
|
return Kind == MCFragment::FT_Relaxable || Kind == MCFragment::FT_Data;
|
2012-12-07 19:13:57 +00:00
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2013-01-08 00:22:56 +00:00
|
|
|
/// Fragment for data and encoded instructions.
|
|
|
|
///
|
2013-01-15 23:22:09 +00:00
|
|
|
class MCDataFragment : public MCEncodedFragmentWithFixups {
|
2014-03-07 09:26:03 +00:00
|
|
|
void anchor() override;
|
2012-12-20 19:05:53 +00:00
|
|
|
|
|
|
|
/// \brief Does this fragment contain encoded instructions anywhere in it?
|
|
|
|
bool HasInstructions;
|
|
|
|
|
2013-01-07 21:51:08 +00:00
|
|
|
/// \brief Should this fragment be aligned to the end of a bundle?
|
|
|
|
bool AlignToBundleEnd;
|
|
|
|
|
2012-12-07 22:06:56 +00:00
|
|
|
SmallVector<char, 32> Contents;
|
2009-08-21 18:29:01 +00:00
|
|
|
|
2010-02-13 09:28:43 +00:00
|
|
|
/// Fixups - The list of fixups in this fragment.
|
2012-12-05 22:11:02 +00:00
|
|
|
SmallVector<MCFixup, 4> Fixups;
|
2010-02-13 09:28:43 +00:00
|
|
|
public:
|
2014-04-13 04:57:38 +00:00
|
|
|
MCDataFragment(MCSectionData *SD = nullptr)
|
2013-01-15 23:22:09 +00:00
|
|
|
: MCEncodedFragmentWithFixups(FT_Data, SD),
|
2013-01-07 21:51:08 +00:00
|
|
|
HasInstructions(false), AlignToBundleEnd(false)
|
2012-12-20 19:05:53 +00:00
|
|
|
{
|
2012-12-07 19:13:57 +00:00
|
|
|
}
|
2009-08-21 18:29:01 +00:00
|
|
|
|
2014-03-07 09:26:03 +00:00
|
|
|
SmallVectorImpl<char> &getContents() override { return Contents; }
|
2014-03-10 05:29:18 +00:00
|
|
|
const SmallVectorImpl<char> &getContents() const override {
|
2014-03-07 09:26:03 +00:00
|
|
|
return Contents;
|
|
|
|
}
|
2009-08-21 18:29:01 +00:00
|
|
|
|
2014-03-07 09:26:03 +00:00
|
|
|
SmallVectorImpl<MCFixup> &getFixups() override {
|
2012-12-07 19:13:57 +00:00
|
|
|
return Fixups;
|
|
|
|
}
|
2010-02-13 09:28:43 +00:00
|
|
|
|
2014-03-07 09:26:03 +00:00
|
|
|
const SmallVectorImpl<MCFixup> &getFixups() const override {
|
2012-12-07 19:13:57 +00:00
|
|
|
return Fixups;
|
2010-03-12 21:00:38 +00:00
|
|
|
}
|
|
|
|
|
2014-03-07 09:26:03 +00:00
|
|
|
bool hasInstructions() const override { return HasInstructions; }
|
2012-12-20 19:05:53 +00:00
|
|
|
virtual void setHasInstructions(bool V) { HasInstructions = V; }
|
|
|
|
|
2014-03-07 09:26:03 +00:00
|
|
|
bool alignToBundleEnd() const override { return AlignToBundleEnd; }
|
|
|
|
void setAlignToBundleEnd(bool V) override { AlignToBundleEnd = V; }
|
2013-01-07 21:51:08 +00:00
|
|
|
|
2014-03-07 09:26:03 +00:00
|
|
|
fixup_iterator fixup_begin() override { return Fixups.begin(); }
|
|
|
|
const_fixup_iterator fixup_begin() const override { return Fixups.begin(); }
|
2010-02-13 09:28:43 +00:00
|
|
|
|
2014-03-07 09:26:03 +00:00
|
|
|
fixup_iterator fixup_end() override {return Fixups.end();}
|
|
|
|
const_fixup_iterator fixup_end() const override {return Fixups.end();}
|
2010-02-13 09:28:43 +00:00
|
|
|
|
2010-02-13 09:28:03 +00:00
|
|
|
static bool classof(const MCFragment *F) {
|
2014-04-10 21:53:47 +00:00
|
|
|
return F->getKind() == MCFragment::FT_Data;
|
2009-08-21 18:29:01 +00:00
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2013-01-15 23:22:09 +00:00
|
|
|
/// This is a compact (memory-size-wise) fragment for holding an encoded
|
|
|
|
/// instruction (non-relaxable) that has no fixups registered. When applicable,
|
|
|
|
/// it can be used instead of MCDataFragment and lead to lower memory
|
|
|
|
/// consumption.
|
|
|
|
///
|
|
|
|
class MCCompactEncodedInstFragment : public MCEncodedFragment {
|
2014-03-07 09:26:03 +00:00
|
|
|
void anchor() override;
|
2013-01-15 23:22:09 +00:00
|
|
|
|
|
|
|
/// \brief Should this fragment be aligned to the end of a bundle?
|
|
|
|
bool AlignToBundleEnd;
|
|
|
|
|
|
|
|
SmallVector<char, 4> Contents;
|
|
|
|
public:
|
2014-04-13 04:57:38 +00:00
|
|
|
MCCompactEncodedInstFragment(MCSectionData *SD = nullptr)
|
2013-01-15 23:22:09 +00:00
|
|
|
: MCEncodedFragment(FT_CompactEncodedInst, SD), AlignToBundleEnd(false)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
2014-03-07 09:26:03 +00:00
|
|
|
bool hasInstructions() const override {
|
2013-01-15 23:22:09 +00:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2014-03-07 09:26:03 +00:00
|
|
|
SmallVectorImpl<char> &getContents() override { return Contents; }
|
|
|
|
const SmallVectorImpl<char> &getContents() const override { return Contents; }
|
2013-01-15 23:22:09 +00:00
|
|
|
|
2014-03-07 09:26:03 +00:00
|
|
|
bool alignToBundleEnd() const override { return AlignToBundleEnd; }
|
|
|
|
void setAlignToBundleEnd(bool V) override { AlignToBundleEnd = V; }
|
2013-01-15 23:22:09 +00:00
|
|
|
|
|
|
|
static bool classof(const MCFragment *F) {
|
|
|
|
return F->getKind() == MCFragment::FT_CompactEncodedInst;
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2013-01-08 00:22:56 +00:00
|
|
|
/// A relaxable fragment holds on to its MCInst, since it may need to be
|
|
|
|
/// relaxed during the assembler layout and relaxation stage.
|
|
|
|
///
|
2013-01-15 23:22:09 +00:00
|
|
|
class MCRelaxableFragment : public MCEncodedFragmentWithFixups {
|
2014-03-07 09:26:03 +00:00
|
|
|
void anchor() override;
|
2011-12-20 02:50:00 +00:00
|
|
|
|
2010-03-22 23:16:48 +00:00
|
|
|
/// Inst - The instruction this is a fragment for.
|
|
|
|
MCInst Inst;
|
|
|
|
|
2014-01-28 23:12:53 +00:00
|
|
|
/// STI - The MCSubtargetInfo in effect when the instruction was encoded.
|
|
|
|
/// Keep a copy instead of a reference to make sure that updates to STI
|
|
|
|
/// in the assembler are not seen here.
|
|
|
|
const MCSubtargetInfo STI;
|
|
|
|
|
2012-12-07 19:13:57 +00:00
|
|
|
/// Contents - Binary data for the currently encoded instruction.
|
2012-12-07 22:06:56 +00:00
|
|
|
SmallVector<char, 8> Contents;
|
2010-03-23 01:39:05 +00:00
|
|
|
|
|
|
|
/// Fixups - The list of fixups in this fragment.
|
2010-05-26 15:18:56 +00:00
|
|
|
SmallVector<MCFixup, 1> Fixups;
|
2010-03-22 23:16:48 +00:00
|
|
|
|
2010-03-23 01:39:05 +00:00
|
|
|
public:
|
2015-03-16 18:06:57 +00:00
|
|
|
MCRelaxableFragment(const MCInst &Inst, const MCSubtargetInfo &STI,
|
2014-04-13 04:57:38 +00:00
|
|
|
MCSectionData *SD = nullptr)
|
2015-03-16 18:06:57 +00:00
|
|
|
: MCEncodedFragmentWithFixups(FT_Relaxable, SD), Inst(Inst), STI(STI) {}
|
2010-03-22 23:16:48 +00:00
|
|
|
|
2014-03-07 09:26:03 +00:00
|
|
|
SmallVectorImpl<char> &getContents() override { return Contents; }
|
|
|
|
const SmallVectorImpl<char> &getContents() const override { return Contents; }
|
2010-03-22 23:16:48 +00:00
|
|
|
|
|
|
|
const MCInst &getInst() const { return Inst; }
|
2012-08-23 07:00:48 +00:00
|
|
|
void setInst(const MCInst& Value) { Inst = Value; }
|
2010-03-23 01:39:05 +00:00
|
|
|
|
2014-01-28 23:12:53 +00:00
|
|
|
const MCSubtargetInfo &getSubtargetInfo() { return STI; }
|
|
|
|
|
2014-03-07 09:26:03 +00:00
|
|
|
SmallVectorImpl<MCFixup> &getFixups() override {
|
2012-12-07 19:13:57 +00:00
|
|
|
return Fixups;
|
|
|
|
}
|
2010-03-23 01:39:05 +00:00
|
|
|
|
2014-03-07 09:26:03 +00:00
|
|
|
const SmallVectorImpl<MCFixup> &getFixups() const override {
|
2012-12-07 19:13:57 +00:00
|
|
|
return Fixups;
|
|
|
|
}
|
2010-03-23 01:39:05 +00:00
|
|
|
|
2014-03-07 09:26:03 +00:00
|
|
|
bool hasInstructions() const override { return true; }
|
2012-12-20 19:05:53 +00:00
|
|
|
|
2014-03-07 09:26:03 +00:00
|
|
|
fixup_iterator fixup_begin() override { return Fixups.begin(); }
|
|
|
|
const_fixup_iterator fixup_begin() const override { return Fixups.begin(); }
|
2010-03-23 01:39:05 +00:00
|
|
|
|
2014-03-07 09:26:03 +00:00
|
|
|
fixup_iterator fixup_end() override {return Fixups.end();}
|
|
|
|
const_fixup_iterator fixup_end() const override {return Fixups.end();}
|
2010-03-23 01:39:05 +00:00
|
|
|
|
2010-03-22 23:16:48 +00:00
|
|
|
static bool classof(const MCFragment *F) {
|
2013-01-08 00:22:56 +00:00
|
|
|
return F->getKind() == MCFragment::FT_Relaxable;
|
2010-03-22 23:16:48 +00:00
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2009-08-21 18:29:01 +00:00
|
|
|
class MCAlignFragment : public MCFragment {
|
2011-12-20 02:50:00 +00:00
|
|
|
virtual void anchor();
|
|
|
|
|
2009-08-21 18:29:01 +00:00
|
|
|
/// Alignment - The alignment to ensure, in bytes.
|
|
|
|
unsigned Alignment;
|
|
|
|
|
|
|
|
/// Value - Value to use for filling padding bytes.
|
|
|
|
int64_t Value;
|
|
|
|
|
2012-09-14 14:57:36 +00:00
|
|
|
/// ValueSize - The size of the integer (in bytes) of \p Value.
|
2009-08-21 18:29:01 +00:00
|
|
|
unsigned ValueSize;
|
|
|
|
|
|
|
|
/// MaxBytesToEmit - The maximum number of bytes to emit; if the alignment
|
|
|
|
/// cannot be satisfied in this width then this fragment is ignored.
|
|
|
|
unsigned MaxBytesToEmit;
|
|
|
|
|
2010-05-12 22:56:23 +00:00
|
|
|
/// EmitNops - Flag to indicate that (optimal) NOPs should be emitted instead
|
|
|
|
/// of using the provided value. The exact interpretation of this flag is
|
|
|
|
/// target dependent.
|
|
|
|
bool EmitNops : 1;
|
2010-02-23 18:26:34 +00:00
|
|
|
|
2009-08-21 18:29:01 +00:00
|
|
|
public:
|
2015-03-16 18:06:57 +00:00
|
|
|
MCAlignFragment(unsigned Alignment, int64_t Value, unsigned ValueSize,
|
|
|
|
unsigned MaxBytesToEmit, MCSectionData *SD = nullptr)
|
|
|
|
: MCFragment(FT_Align, SD), Alignment(Alignment), Value(Value),
|
|
|
|
ValueSize(ValueSize), MaxBytesToEmit(MaxBytesToEmit), EmitNops(false) {}
|
2009-08-21 18:29:01 +00:00
|
|
|
|
|
|
|
/// @name Accessors
|
|
|
|
/// @{
|
|
|
|
|
|
|
|
unsigned getAlignment() const { return Alignment; }
|
2010-02-13 09:28:03 +00:00
|
|
|
|
2009-08-21 18:29:01 +00:00
|
|
|
int64_t getValue() const { return Value; }
|
|
|
|
|
|
|
|
unsigned getValueSize() const { return ValueSize; }
|
|
|
|
|
|
|
|
unsigned getMaxBytesToEmit() const { return MaxBytesToEmit; }
|
|
|
|
|
2010-05-12 22:56:23 +00:00
|
|
|
bool hasEmitNops() const { return EmitNops; }
|
|
|
|
void setEmitNops(bool Value) { EmitNops = Value; }
|
2010-02-23 18:26:34 +00:00
|
|
|
|
2009-08-21 18:29:01 +00:00
|
|
|
/// @}
|
|
|
|
|
2010-02-13 09:28:03 +00:00
|
|
|
static bool classof(const MCFragment *F) {
|
|
|
|
return F->getKind() == MCFragment::FT_Align;
|
2009-08-21 18:29:01 +00:00
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
class MCFillFragment : public MCFragment {
|
2011-12-20 02:50:00 +00:00
|
|
|
virtual void anchor();
|
|
|
|
|
2009-08-21 18:29:01 +00:00
|
|
|
/// 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
|
|
|
|
2012-09-14 14:57:36 +00:00
|
|
|
/// ValueSize - The size (in bytes) of \p Value to use when filling, or 0 if
|
2010-05-12 22:51:32 +00:00
|
|
|
/// this is a virtual fill fragment.
|
2009-08-21 18:29:01 +00:00
|
|
|
unsigned ValueSize;
|
|
|
|
|
2010-05-12 22:51:32 +00:00
|
|
|
/// Size - The number of bytes to insert.
|
|
|
|
uint64_t Size;
|
2009-08-21 18:29:01 +00:00
|
|
|
|
|
|
|
public:
|
2015-03-16 18:06:57 +00:00
|
|
|
MCFillFragment(int64_t Value, unsigned ValueSize, uint64_t Size,
|
2014-04-13 04:57:38 +00:00
|
|
|
MCSectionData *SD = nullptr)
|
2015-03-16 18:06:57 +00:00
|
|
|
: MCFragment(FT_Fill, SD), Value(Value), ValueSize(ValueSize),
|
|
|
|
Size(Size) {
|
2010-05-12 22:51:32 +00:00
|
|
|
assert((!ValueSize || (Size % ValueSize) == 0) &&
|
|
|
|
"Fill size must be a multiple of the value size!");
|
|
|
|
}
|
2009-08-21 18:29:01 +00:00
|
|
|
|
|
|
|
/// @name Accessors
|
|
|
|
/// @{
|
|
|
|
|
2010-02-13 09:28:32 +00:00
|
|
|
int64_t getValue() const { return Value; }
|
2010-02-13 09:28:03 +00:00
|
|
|
|
2009-08-21 18:29:01 +00:00
|
|
|
unsigned getValueSize() const { return ValueSize; }
|
|
|
|
|
2010-05-12 22:51:32 +00:00
|
|
|
uint64_t getSize() const { return Size; }
|
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_Fill;
|
2009-08-21 18:29:01 +00:00
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
class MCOrgFragment : public MCFragment {
|
2011-12-20 02:50:00 +00:00
|
|
|
virtual void anchor();
|
|
|
|
|
2009-08-21 18:29:01 +00:00
|
|
|
/// 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:
|
2015-03-16 18:06:57 +00:00
|
|
|
MCOrgFragment(const MCExpr &Offset, int8_t Value, MCSectionData *SD = nullptr)
|
|
|
|
: MCFragment(FT_Org, SD), Offset(&Offset), Value(Value) {}
|
2009-08-28 05:49:21 +00:00
|
|
|
|
2009-08-21 18:29:01 +00:00
|
|
|
/// @name Accessors
|
|
|
|
/// @{
|
|
|
|
|
2009-10-16 01:58:03 +00:00
|
|
|
const MCExpr &getOffset() const { return *Offset; }
|
2010-02-13 09:28:03 +00:00
|
|
|
|
2009-08-21 23:07:38 +00:00
|
|
|
uint8_t getValue() const { return Value; }
|
2009-08-21 18:29:01 +00:00
|
|
|
|
|
|
|
/// @}
|
|
|
|
|
2010-02-13 09:28:03 +00:00
|
|
|
static bool classof(const MCFragment *F) {
|
|
|
|
return F->getKind() == MCFragment::FT_Org;
|
2009-08-21 18:29:01 +00:00
|
|
|
}
|
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-11-02 17:22:24 +00:00
|
|
|
class MCLEBFragment : public MCFragment {
|
2011-12-20 02:50:00 +00:00
|
|
|
virtual void anchor();
|
|
|
|
|
2010-11-02 17:22:24 +00:00
|
|
|
/// Value - The value this fragment should contain.
|
|
|
|
const MCExpr *Value;
|
|
|
|
|
|
|
|
/// IsSigned - True if this is a sleb128, false if uleb128.
|
|
|
|
bool IsSigned;
|
|
|
|
|
2010-12-04 21:58:52 +00:00
|
|
|
SmallString<8> Contents;
|
2010-11-02 17:22:24 +00:00
|
|
|
public:
|
2014-04-13 04:57:38 +00:00
|
|
|
MCLEBFragment(const MCExpr &Value_, bool IsSigned_,
|
|
|
|
MCSectionData *SD = nullptr)
|
2010-11-02 17:22:24 +00:00
|
|
|
: MCFragment(FT_LEB, SD),
|
2010-12-04 21:58:52 +00:00
|
|
|
Value(&Value_), IsSigned(IsSigned_) { Contents.push_back(0); }
|
2010-11-02 17:22:24 +00:00
|
|
|
|
|
|
|
/// @name Accessors
|
|
|
|
/// @{
|
|
|
|
|
|
|
|
const MCExpr &getValue() const { return *Value; }
|
|
|
|
|
|
|
|
bool isSigned() const { return IsSigned; }
|
|
|
|
|
2010-12-04 21:58:52 +00:00
|
|
|
SmallString<8> &getContents() { return Contents; }
|
|
|
|
const SmallString<8> &getContents() const { return Contents; }
|
2010-11-02 17:22:24 +00:00
|
|
|
|
|
|
|
/// @}
|
|
|
|
|
|
|
|
static bool classof(const MCFragment *F) {
|
|
|
|
return F->getKind() == MCFragment::FT_LEB;
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2010-09-30 17:16:09 +00:00
|
|
|
class MCDwarfLineAddrFragment : public MCFragment {
|
2011-12-20 02:50:00 +00:00
|
|
|
virtual void anchor();
|
|
|
|
|
2010-09-30 17:16:09 +00:00
|
|
|
/// LineDelta - the value of the difference between the two line numbers
|
|
|
|
/// between two .loc dwarf directives.
|
|
|
|
int64_t LineDelta;
|
|
|
|
|
|
|
|
/// AddrDelta - The expression for the difference of the two symbols that
|
|
|
|
/// make up the address delta between two .loc dwarf directives.
|
|
|
|
const MCExpr *AddrDelta;
|
|
|
|
|
2010-12-04 21:58:52 +00:00
|
|
|
SmallString<8> Contents;
|
2010-11-07 02:07:12 +00:00
|
|
|
|
2010-09-30 17:16:09 +00:00
|
|
|
public:
|
2015-03-16 18:06:57 +00:00
|
|
|
MCDwarfLineAddrFragment(int64_t LineDelta, const MCExpr &AddrDelta,
|
|
|
|
MCSectionData *SD = nullptr)
|
|
|
|
: MCFragment(FT_Dwarf, SD), LineDelta(LineDelta), AddrDelta(&AddrDelta) {
|
|
|
|
Contents.push_back(0);
|
|
|
|
}
|
2010-09-30 17:16:09 +00:00
|
|
|
|
|
|
|
/// @name Accessors
|
|
|
|
/// @{
|
|
|
|
|
|
|
|
int64_t getLineDelta() const { return LineDelta; }
|
|
|
|
|
|
|
|
const MCExpr &getAddrDelta() const { return *AddrDelta; }
|
|
|
|
|
2010-12-04 21:58:52 +00:00
|
|
|
SmallString<8> &getContents() { return Contents; }
|
|
|
|
const SmallString<8> &getContents() const { return Contents; }
|
2010-11-07 02:07:12 +00:00
|
|
|
|
2010-09-30 17:16:09 +00:00
|
|
|
/// @}
|
|
|
|
|
|
|
|
static bool classof(const MCFragment *F) {
|
|
|
|
return F->getKind() == MCFragment::FT_Dwarf;
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2010-12-28 05:39:27 +00:00
|
|
|
class MCDwarfCallFrameFragment : public MCFragment {
|
2011-12-20 02:50:00 +00:00
|
|
|
virtual void anchor();
|
|
|
|
|
2010-12-28 05:39:27 +00:00
|
|
|
/// AddrDelta - The expression for the difference of the two symbols that
|
|
|
|
/// make up the address delta between two .cfi_* dwarf directives.
|
|
|
|
const MCExpr *AddrDelta;
|
|
|
|
|
|
|
|
SmallString<8> Contents;
|
|
|
|
|
|
|
|
public:
|
2015-03-16 18:06:57 +00:00
|
|
|
MCDwarfCallFrameFragment(const MCExpr &AddrDelta, MCSectionData *SD = nullptr)
|
|
|
|
: MCFragment(FT_DwarfFrame, SD), AddrDelta(&AddrDelta) {
|
|
|
|
Contents.push_back(0);
|
|
|
|
}
|
2010-12-28 05:39:27 +00:00
|
|
|
|
|
|
|
/// @name Accessors
|
|
|
|
/// @{
|
|
|
|
|
|
|
|
const MCExpr &getAddrDelta() const { return *AddrDelta; }
|
|
|
|
|
|
|
|
SmallString<8> &getContents() { return Contents; }
|
|
|
|
const SmallString<8> &getContents() const { return Contents; }
|
|
|
|
|
|
|
|
/// @}
|
|
|
|
|
|
|
|
static bool classof(const MCFragment *F) {
|
|
|
|
return F->getKind() == MCFragment::FT_DwarfFrame;
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
// FIXME: Should this be a separate class, or just merged into MCSection? Since
|
|
|
|
// we anticipate the fast path being through an MCAssembler, the only reason to
|
|
|
|
// keep it out is for API abstraction.
|
|
|
|
class MCSectionData : public ilist_node<MCSectionData> {
|
2010-03-25 01:03:24 +00:00
|
|
|
friend class MCAsmLayout;
|
|
|
|
|
2015-02-15 22:54:22 +00:00
|
|
|
MCSectionData(const MCSectionData&) = delete;
|
|
|
|
void operator=(const MCSectionData&) = delete;
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
|
|
|
|
public:
|
|
|
|
typedef iplist<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
|
|
|
|
2013-01-07 21:51:08 +00:00
|
|
|
/// \brief Express the state of bundle locked groups while emitting code.
|
|
|
|
enum BundleLockStateType {
|
|
|
|
NotBundleLocked,
|
|
|
|
BundleLocked,
|
|
|
|
BundleLockedAlignToEnd
|
|
|
|
};
|
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:
|
2010-07-13 05:52:36 +00:00
|
|
|
FragmentListType Fragments;
|
2009-08-27 00:38:04 +00:00
|
|
|
const MCSection *Section;
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
|
2010-03-25 07:10:11 +00:00
|
|
|
/// Ordinal - The section index in the assemblers section list.
|
|
|
|
unsigned Ordinal;
|
|
|
|
|
2010-05-13 15:17:26 +00:00
|
|
|
/// LayoutOrder - The index of this section in the layout order.
|
|
|
|
unsigned LayoutOrder;
|
|
|
|
|
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;
|
|
|
|
|
2013-01-07 21:51:08 +00:00
|
|
|
/// \brief Keeping track of bundle-locked state.
|
2014-10-15 17:10:04 +00:00
|
|
|
BundleLockStateType BundleLockState;
|
|
|
|
|
|
|
|
/// \brief Current nesting depth of bundle_lock directives.
|
|
|
|
unsigned BundleLockNestingDepth;
|
2012-12-20 19:05:53 +00:00
|
|
|
|
|
|
|
/// \brief We've seen a bundle_lock directive but not its first instruction
|
|
|
|
/// yet.
|
|
|
|
bool BundleGroupBeforeFirstInst;
|
|
|
|
|
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 Data
|
|
|
|
/// @{
|
|
|
|
//
|
|
|
|
// FIXME: This could all be kept private to the assembler implementation.
|
|
|
|
|
2010-02-02 21:44:01 +00:00
|
|
|
/// HasInstructions - Whether this section has had instructions emitted into
|
|
|
|
/// it.
|
|
|
|
unsigned HasInstructions : 1;
|
|
|
|
|
2013-04-17 21:18:16 +00:00
|
|
|
/// Mapping from subsection number to insertion point for subsection numbers
|
|
|
|
/// below that number.
|
|
|
|
SmallVector<std::pair<unsigned, MCFragment *>, 1> SubsectionFragmentMap;
|
|
|
|
|
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();
|
2014-04-13 04:57:38 +00:00
|
|
|
MCSectionData(const MCSection &Section, MCAssembler *A = nullptr);
|
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-27 00:38:04 +00:00
|
|
|
const MCSection &getSection() const { return *Section; }
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
|
|
|
|
unsigned getAlignment() const { return Alignment; }
|
|
|
|
void setAlignment(unsigned Value) { Alignment = Value; }
|
|
|
|
|
2010-03-25 02:00:07 +00:00
|
|
|
bool hasInstructions() const { return HasInstructions; }
|
|
|
|
void setHasInstructions(bool Value) { HasInstructions = Value; }
|
|
|
|
|
2010-03-25 07:10:11 +00:00
|
|
|
unsigned getOrdinal() const { return Ordinal; }
|
|
|
|
void setOrdinal(unsigned Value) { Ordinal = Value; }
|
|
|
|
|
2010-05-13 15:17:26 +00:00
|
|
|
unsigned getLayoutOrder() const { return LayoutOrder; }
|
|
|
|
void setLayoutOrder(unsigned Value) { LayoutOrder = 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
|
|
|
|
2013-04-17 21:18:16 +00:00
|
|
|
iterator getSubsectionInsertionPoint(unsigned Subsection);
|
|
|
|
|
2012-12-20 19:05:53 +00:00
|
|
|
bool isBundleLocked() const {
|
2013-01-07 21:51:08 +00:00
|
|
|
return BundleLockState != NotBundleLocked;
|
|
|
|
}
|
|
|
|
|
|
|
|
BundleLockStateType getBundleLockState() const {
|
|
|
|
return BundleLockState;
|
2012-12-20 19:05:53 +00:00
|
|
|
}
|
|
|
|
|
2014-10-15 17:10:04 +00:00
|
|
|
void setBundleLockState(BundleLockStateType NewState);
|
2012-12-20 19:05:53 +00:00
|
|
|
|
|
|
|
bool isBundleGroupBeforeFirstInst() const {
|
|
|
|
return BundleGroupBeforeFirstInst;
|
|
|
|
}
|
|
|
|
|
|
|
|
void setBundleGroupBeforeFirstInst(bool IsFirst) {
|
|
|
|
BundleGroupBeforeFirstInst = IsFirst;
|
|
|
|
}
|
|
|
|
|
2010-02-13 09:28:03 +00:00
|
|
|
void dump();
|
2010-03-25 07:10:11 +00:00
|
|
|
|
|
|
|
/// @}
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
};
|
|
|
|
|
2009-08-22 10:13:24 +00:00
|
|
|
// FIXME: Same concerns as with SectionData.
|
|
|
|
class MCSymbolData : public ilist_node<MCSymbolData> {
|
2009-09-01 04:09:03 +00:00
|
|
|
const MCSymbol *Symbol;
|
2009-08-22 10:13:24 +00:00
|
|
|
|
2014-10-11 15:07:21 +00:00
|
|
|
/// Fragment - The fragment this symbol's value is relative to, if any. Also
|
|
|
|
/// stores if this symbol is visible outside this translation unit (bit 0) or
|
|
|
|
/// if it is private extern (bit 1).
|
|
|
|
PointerIntPair<MCFragment *, 2> Fragment;
|
2010-02-13 09:28:03 +00:00
|
|
|
|
2014-10-11 15:07:21 +00:00
|
|
|
union {
|
|
|
|
/// Offset - The offset to apply to the fragment address to form this
|
|
|
|
/// symbol's value.
|
|
|
|
uint64_t Offset;
|
2009-08-22 10:13:24 +00:00
|
|
|
|
2014-10-11 15:07:21 +00:00
|
|
|
/// CommonSize - The size of the symbol, if it is 'common'.
|
|
|
|
uint64_t CommonSize;
|
|
|
|
};
|
2009-08-28 07:08:35 +00:00
|
|
|
|
2010-08-16 18:34:31 +00:00
|
|
|
/// SymbolSize - An expression describing how to calculate the size of
|
|
|
|
/// a symbol. If a symbol has no size this field will be NULL.
|
|
|
|
const MCExpr *SymbolSize;
|
|
|
|
|
2014-10-11 15:07:21 +00:00
|
|
|
/// CommonAlign - The alignment of the symbol, if it is 'common', or -1.
|
2009-08-28 07:08:35 +00:00
|
|
|
//
|
|
|
|
// 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();
|
2015-03-16 18:06:57 +00:00
|
|
|
MCSymbolData(const MCSymbol &Symbol, MCFragment *Fragment, uint64_t Offset,
|
2014-04-13 04:57:38 +00:00
|
|
|
MCAssembler *A = nullptr);
|
2009-08-22 10:13:24 +00:00
|
|
|
|
|
|
|
/// @name Accessors
|
|
|
|
/// @{
|
|
|
|
|
2009-09-01 04:09:03 +00:00
|
|
|
const MCSymbol &getSymbol() const { return *Symbol; }
|
2009-08-22 10:13:24 +00:00
|
|
|
|
2014-10-11 15:07:21 +00:00
|
|
|
MCFragment *getFragment() const { return Fragment.getPointer(); }
|
|
|
|
void setFragment(MCFragment *Value) { Fragment.setPointer(Value); }
|
2009-08-22 10:13:24 +00:00
|
|
|
|
2014-10-11 15:07:21 +00:00
|
|
|
uint64_t getOffset() const {
|
|
|
|
assert(!isCommon());
|
|
|
|
return Offset;
|
|
|
|
}
|
|
|
|
void setOffset(uint64_t Value) {
|
|
|
|
assert(!isCommon());
|
|
|
|
Offset = Value;
|
|
|
|
}
|
2009-08-22 10:13:24 +00:00
|
|
|
|
2009-08-24 08:40:12 +00:00
|
|
|
/// @}
|
|
|
|
/// @name Symbol Attributes
|
|
|
|
/// @{
|
2010-02-13 09:28:03 +00:00
|
|
|
|
2014-10-11 15:07:21 +00:00
|
|
|
bool isExternal() const { return Fragment.getInt() & 1; }
|
|
|
|
void setExternal(bool Value) {
|
|
|
|
Fragment.setInt((Fragment.getInt() & ~1) | unsigned(Value));
|
|
|
|
}
|
2010-02-13 09:28:03 +00:00
|
|
|
|
2014-10-11 15:07:21 +00:00
|
|
|
bool isPrivateExtern() const { return Fragment.getInt() & 2; }
|
|
|
|
void setPrivateExtern(bool Value) {
|
|
|
|
Fragment.setInt((Fragment.getInt() & ~2) | (unsigned(Value) << 1));
|
|
|
|
}
|
2009-08-28 07:08:35 +00:00
|
|
|
|
|
|
|
/// isCommon - Is this a 'common' symbol.
|
2014-10-11 15:07:21 +00:00
|
|
|
bool isCommon() const { return CommonAlign != -1U; }
|
2009-08-28 07:08:35 +00:00
|
|
|
|
|
|
|
/// 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) {
|
2014-10-11 15:07:21 +00:00
|
|
|
assert(getOffset() == 0);
|
2009-08-28 07:08:35 +00:00
|
|
|
CommonSize = Size;
|
|
|
|
CommonAlign = Align;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// getCommonSize - Return the size of a 'common' symbol.
|
|
|
|
uint64_t getCommonSize() const {
|
|
|
|
assert(isCommon() && "Not a 'common' symbol!");
|
|
|
|
return CommonSize;
|
|
|
|
}
|
|
|
|
|
2010-08-16 18:34:31 +00:00
|
|
|
void setSize(const MCExpr *SS) {
|
|
|
|
SymbolSize = SS;
|
|
|
|
}
|
|
|
|
|
|
|
|
const MCExpr *getSize() const {
|
|
|
|
return SymbolSize;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2009-08-28 07:08:35 +00:00
|
|
|
/// 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
|
|
|
|
2010-05-12 00:52:54 +00:00
|
|
|
/// modifyFlags - Modify the flags via a mask
|
|
|
|
void modifyFlags(uint32_t Value, uint32_t Mask) {
|
|
|
|
Flags = (Flags & ~Mask) | Value;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
|
|
|
|
/// @}
|
|
|
|
|
2014-07-05 00:39:52 +00:00
|
|
|
void dump() const;
|
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;
|
|
|
|
};
|
|
|
|
|
2012-05-18 19:12:01 +00:00
|
|
|
// FIXME: Ditto this. Purely so the Streamer and the ObjectWriter can talk
|
|
|
|
// to one another.
|
|
|
|
struct DataRegionData {
|
|
|
|
// This enum should be kept in sync w/ the mach-o definition in
|
|
|
|
// llvm/Object/MachOFormat.h.
|
|
|
|
enum KindTy { Data = 1, JumpTable8, JumpTable16, JumpTable32 } Kind;
|
|
|
|
MCSymbol *Start;
|
|
|
|
MCSymbol *End;
|
|
|
|
};
|
|
|
|
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
class MCAssembler {
|
2010-03-25 19:35:56 +00:00
|
|
|
friend class MCAsmLayout;
|
|
|
|
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
public:
|
|
|
|
typedef iplist<MCSectionData> SectionDataListType;
|
2009-08-22 10:13:24 +00:00
|
|
|
typedef iplist<MCSymbolData> SymbolDataListType;
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
|
|
|
|
typedef SectionDataListType::const_iterator const_iterator;
|
|
|
|
typedef SectionDataListType::iterator iterator;
|
|
|
|
|
2009-08-22 10:13:24 +00:00
|
|
|
typedef SymbolDataListType::const_iterator const_symbol_iterator;
|
|
|
|
typedef SymbolDataListType::iterator symbol_iterator;
|
|
|
|
|
2014-04-18 18:24:25 +00:00
|
|
|
typedef iterator_range<symbol_iterator> symbol_range;
|
|
|
|
typedef iterator_range<const_symbol_iterator> const_symbol_range;
|
|
|
|
|
2013-10-29 01:06:17 +00:00
|
|
|
typedef std::vector<std::string> FileNameVectorType;
|
|
|
|
typedef FileNameVectorType::const_iterator const_file_name_iterator;
|
|
|
|
|
2010-03-19 07:09:33 +00:00
|
|
|
typedef std::vector<IndirectSymbolData>::const_iterator
|
|
|
|
const_indirect_symbol_iterator;
|
2009-08-24 11:56:58 +00:00
|
|
|
typedef std::vector<IndirectSymbolData>::iterator indirect_symbol_iterator;
|
|
|
|
|
2012-05-18 19:12:01 +00:00
|
|
|
typedef std::vector<DataRegionData>::const_iterator
|
|
|
|
const_data_region_iterator;
|
|
|
|
typedef std::vector<DataRegionData>::iterator data_region_iterator;
|
|
|
|
|
2014-03-18 22:09:05 +00:00
|
|
|
/// MachO specific deployment target version info.
|
|
|
|
// A Major version of 0 indicates that no version information was supplied
|
|
|
|
// and so the corresponding load command should not be emitted.
|
|
|
|
typedef struct {
|
|
|
|
MCVersionMinType Kind;
|
|
|
|
unsigned Major;
|
|
|
|
unsigned Minor;
|
|
|
|
unsigned Update;
|
|
|
|
} VersionMinInfoType;
|
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:
|
2015-02-15 22:54:22 +00:00
|
|
|
MCAssembler(const MCAssembler&) = delete;
|
|
|
|
void operator=(const MCAssembler&) = delete;
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
|
2009-08-31 08:07:55 +00:00
|
|
|
MCContext &Context;
|
|
|
|
|
2011-07-25 23:24:55 +00:00
|
|
|
MCAsmBackend &Backend;
|
2010-03-11 01:34:27 +00:00
|
|
|
|
2010-03-19 10:43:18 +00:00
|
|
|
MCCodeEmitter &Emitter;
|
|
|
|
|
2010-12-17 02:45:41 +00:00
|
|
|
MCObjectWriter &Writer;
|
|
|
|
|
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;
|
|
|
|
|
2015-01-19 21:11:14 +00:00
|
|
|
DenseSet<const MCSymbol *> LocalsUsedInReloc;
|
|
|
|
|
2010-03-10 20:58:29 +00:00
|
|
|
/// The map of sections to their associated assembler backend data.
|
|
|
|
//
|
|
|
|
// FIXME: Avoid this indirection?
|
|
|
|
DenseMap<const MCSection*, MCSectionData*> SectionMap;
|
|
|
|
|
|
|
|
/// The map of symbols to their associated assembler backend data.
|
|
|
|
//
|
|
|
|
// FIXME: Avoid this indirection?
|
|
|
|
DenseMap<const MCSymbol*, MCSymbolData*> SymbolMap;
|
|
|
|
|
2009-08-24 11:56:58 +00:00
|
|
|
std::vector<IndirectSymbolData> IndirectSymbols;
|
|
|
|
|
2012-05-18 19:12:01 +00:00
|
|
|
std::vector<DataRegionData> DataRegions;
|
2013-01-18 01:26:07 +00:00
|
|
|
|
|
|
|
/// The list of linker options to propagate into the object file.
|
|
|
|
std::vector<std::vector<std::string> > LinkerOptions;
|
|
|
|
|
2013-10-29 01:06:17 +00:00
|
|
|
/// List of declared file names
|
|
|
|
FileNameVectorType FileNames;
|
|
|
|
|
2010-12-14 18:46:57 +00:00
|
|
|
/// The set of function symbols for which a .thumb_func directive has
|
|
|
|
/// been seen.
|
|
|
|
//
|
|
|
|
// FIXME: We really would like this in target specific code rather than
|
|
|
|
// here. Maybe when the relocation stuff moves to target specific,
|
|
|
|
// this can go with it? The streamer would need some target specific
|
|
|
|
// refactoring too.
|
2014-04-29 12:46:50 +00:00
|
|
|
mutable SmallPtrSet<const MCSymbol*, 64> ThumbFuncs;
|
2010-12-14 18:46:57 +00:00
|
|
|
|
2012-12-20 19:05:53 +00:00
|
|
|
/// \brief The bundle alignment size currently set in the assembler.
|
|
|
|
///
|
|
|
|
/// By default it's 0, which means bundling is disabled.
|
|
|
|
unsigned BundleAlignSize;
|
|
|
|
|
2010-03-25 22:49:09 +00:00
|
|
|
unsigned RelaxAll : 1;
|
2009-08-26 21:22:22 +00:00
|
|
|
unsigned SubsectionsViaSymbols : 1;
|
|
|
|
|
2013-01-30 02:09:52 +00:00
|
|
|
/// ELF specific e_header flags
|
|
|
|
// It would be good if there were an MCELFAssembler class to hold this.
|
|
|
|
// ELF header flags are used both by the integrated and standalone assemblers.
|
|
|
|
// Access to the flags is necessary in cases where assembler directives affect
|
|
|
|
// which flags to be set.
|
|
|
|
unsigned ELFHeaderEFlags;
|
2014-03-18 22:09:05 +00:00
|
|
|
|
2014-03-29 07:34:53 +00:00
|
|
|
/// Used to communicate Linker Optimization Hint information between
|
|
|
|
/// the Streamer and the .o writer
|
|
|
|
MCLOHContainer LOHContainer;
|
|
|
|
|
2014-03-18 22:09:05 +00:00
|
|
|
VersionMinInfoType VersionMinInfo;
|
2009-08-21 18:29:01 +00:00
|
|
|
private:
|
2010-03-19 09:28:59 +00:00
|
|
|
/// Evaluate a fixup to a relocatable expression and the value which should be
|
|
|
|
/// placed into the fixup.
|
|
|
|
///
|
|
|
|
/// \param Layout The layout to use for evaluation.
|
|
|
|
/// \param Fixup The fixup to evaluate.
|
|
|
|
/// \param DF The fragment the fixup is inside.
|
|
|
|
/// \param Target [out] On return, the relocatable expression the fixup
|
|
|
|
/// evaluates to.
|
2011-04-15 05:18:47 +00:00
|
|
|
/// \param Value [out] On return, the value of the fixup as currently laid
|
2010-03-19 09:28:59 +00:00
|
|
|
/// out.
|
|
|
|
/// \return Whether the fixup value was fully resolved. This is true if the
|
2012-09-14 14:57:36 +00:00
|
|
|
/// \p Value result is fixed, otherwise the value may change due to
|
2010-03-19 09:28:59 +00:00
|
|
|
/// relocation.
|
2011-12-06 00:03:48 +00:00
|
|
|
bool evaluateFixup(const MCAsmLayout &Layout,
|
2010-05-26 15:18:56 +00:00
|
|
|
const MCFixup &Fixup, const MCFragment *DF,
|
2010-03-19 09:28:59 +00:00
|
|
|
MCValue &Target, uint64_t &Value) const;
|
|
|
|
|
2010-03-12 22:07:14 +00:00
|
|
|
/// Check whether a fixup can be satisfied, or whether it needs to be relaxed
|
|
|
|
/// (increased in size, in order to hold its value correctly).
|
2013-01-08 00:22:56 +00:00
|
|
|
bool fixupNeedsRelaxation(const MCFixup &Fixup, const MCRelaxableFragment *DF,
|
2010-03-22 20:35:35 +00:00
|
|
|
const MCAsmLayout &Layout) const;
|
2010-03-12 22:07:14 +00:00
|
|
|
|
2010-03-23 03:13:05 +00:00
|
|
|
/// Check whether the given fragment needs relaxation.
|
2013-01-08 00:22:56 +00:00
|
|
|
bool fragmentNeedsRelaxation(const MCRelaxableFragment *IF,
|
2010-03-23 03:13:05 +00:00
|
|
|
const MCAsmLayout &Layout) const;
|
|
|
|
|
2012-12-10 20:13:43 +00:00
|
|
|
/// \brief Perform one layout iteration and return true if any offsets
|
2010-03-12 22:07:14 +00:00
|
|
|
/// were adjusted.
|
2011-12-06 00:03:48 +00:00
|
|
|
bool layoutOnce(MCAsmLayout &Layout);
|
2010-03-12 22:07:14 +00:00
|
|
|
|
2012-12-10 20:13:43 +00:00
|
|
|
/// \brief Perform one layout iteration of the given section and return true
|
|
|
|
/// if any offsets were adjusted.
|
2011-12-06 00:03:48 +00:00
|
|
|
bool layoutSectionOnce(MCAsmLayout &Layout, MCSectionData &SD);
|
2010-12-21 04:22:09 +00:00
|
|
|
|
2013-01-08 00:22:56 +00:00
|
|
|
bool relaxInstruction(MCAsmLayout &Layout, MCRelaxableFragment &IF);
|
2010-11-02 17:22:24 +00:00
|
|
|
|
2011-12-06 00:03:48 +00:00
|
|
|
bool relaxLEB(MCAsmLayout &Layout, MCLEBFragment &IF);
|
2010-11-02 17:22:24 +00:00
|
|
|
|
2011-12-06 00:03:48 +00:00
|
|
|
bool relaxDwarfLineAddr(MCAsmLayout &Layout, MCDwarfLineAddrFragment &DF);
|
|
|
|
bool relaxDwarfCallFrameFragment(MCAsmLayout &Layout,
|
2010-12-28 05:39:27 +00:00
|
|
|
MCDwarfCallFrameFragment &DF);
|
2010-11-07 02:07:12 +00:00
|
|
|
|
2011-12-06 00:03:48 +00:00
|
|
|
/// finishLayout - Finalize a layout, including fragment lowering.
|
|
|
|
void finishLayout(MCAsmLayout &Layout);
|
2010-03-22 23:16:48 +00:00
|
|
|
|
2014-03-29 06:26:49 +00:00
|
|
|
std::pair<uint64_t, bool> handleFixup(const MCAsmLayout &Layout,
|
|
|
|
MCFragment &F, const MCFixup &Fixup);
|
2010-12-06 19:08:48 +00:00
|
|
|
|
2010-03-12 21:00:49 +00:00
|
|
|
public:
|
2015-01-19 21:11:14 +00:00
|
|
|
void addLocalUsedInReloc(const MCSymbol &Sym);
|
|
|
|
bool isLocalUsedInReloc(const MCSymbol &Sym) const;
|
|
|
|
|
2011-04-15 05:18:47 +00:00
|
|
|
/// Compute the effective fragment size assuming it is laid out at the given
|
2012-09-14 14:57:36 +00:00
|
|
|
/// \p SectionAddress and \p FragmentOffset.
|
2011-12-06 00:11:13 +00:00
|
|
|
uint64_t computeFragmentSize(const MCAsmLayout &Layout,
|
|
|
|
const MCFragment &F) const;
|
2010-12-15 08:45:53 +00:00
|
|
|
|
2010-03-19 03:18:15 +00:00
|
|
|
/// Find the symbol which defines the atom containing the given symbol, or
|
|
|
|
/// null if there is no such symbol.
|
2010-09-27 18:13:03 +00:00
|
|
|
const MCSymbolData *getAtom(const MCSymbolData *Symbol) const;
|
2010-03-19 03:18:15 +00:00
|
|
|
|
2010-03-19 03:18:09 +00:00
|
|
|
/// Check whether a particular symbol is visible to the linker and is required
|
|
|
|
/// in the symbol table, or whether it can be discarded by the assembler. This
|
|
|
|
/// also effects whether the assembler treats the label as potentially
|
|
|
|
/// defining a separate atom.
|
2010-06-16 20:04:29 +00:00
|
|
|
bool isSymbolLinkerVisible(const MCSymbol &SD) const;
|
2010-03-19 03:18:09 +00:00
|
|
|
|
2010-03-19 09:28:59 +00:00
|
|
|
/// Emit the section contents using the given object writer.
|
2011-12-06 00:03:48 +00:00
|
|
|
void writeSectionData(const MCSectionData *Section,
|
2010-12-17 02:45:59 +00:00
|
|
|
const MCAsmLayout &Layout) const;
|
2010-03-12 21:00:49 +00:00
|
|
|
|
2010-12-14 18:46:57 +00:00
|
|
|
/// Check whether a given symbol has been flagged with .thumb_func.
|
2014-04-29 12:46:50 +00:00
|
|
|
bool isThumbFunc(const MCSymbol *Func) const;
|
2010-12-14 18:46:57 +00:00
|
|
|
|
|
|
|
/// Flag a function symbol as the target of a .thumb_func directive.
|
|
|
|
void setIsThumbFunc(const MCSymbol *Func) { ThumbFuncs.insert(Func); }
|
|
|
|
|
2013-01-30 02:09:52 +00:00
|
|
|
/// ELF e_header flags
|
|
|
|
unsigned getELFHeaderEFlags() const {return ELFHeaderEFlags;}
|
|
|
|
void setELFHeaderEFlags(unsigned Flags) { ELFHeaderEFlags = Flags;}
|
|
|
|
|
2014-03-18 22:09:05 +00:00
|
|
|
/// MachO deployment target version information.
|
|
|
|
const VersionMinInfoType &getVersionMinInfo() const { return VersionMinInfo; }
|
|
|
|
void setVersionMinInfo(MCVersionMinType Kind, unsigned Major, unsigned Minor,
|
|
|
|
unsigned Update) {
|
|
|
|
VersionMinInfo.Kind = Kind;
|
|
|
|
VersionMinInfo.Major = Major;
|
|
|
|
VersionMinInfo.Minor = Minor;
|
|
|
|
VersionMinInfo.Update = Update;
|
|
|
|
}
|
|
|
|
|
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.
|
|
|
|
///
|
2012-09-14 14:57:36 +00:00
|
|
|
/// \param OS The stream to output to.
|
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: 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.
|
2011-07-25 23:24:55 +00:00
|
|
|
MCAssembler(MCContext &Context_, MCAsmBackend &Backend_,
|
2010-12-17 02:45:41 +00:00
|
|
|
MCCodeEmitter &Emitter_, MCObjectWriter &Writer_,
|
|
|
|
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();
|
|
|
|
|
2012-12-12 22:59:46 +00:00
|
|
|
/// Reuse an assembler instance
|
|
|
|
///
|
|
|
|
void reset();
|
|
|
|
|
2009-08-31 08:07:55 +00:00
|
|
|
MCContext &getContext() const { return Context; }
|
|
|
|
|
2011-07-25 23:24:55 +00:00
|
|
|
MCAsmBackend &getBackend() const { return Backend; }
|
2010-03-11 02:28:59 +00:00
|
|
|
|
2010-03-19 10:43:18 +00:00
|
|
|
MCCodeEmitter &getEmitter() const { return Emitter; }
|
|
|
|
|
2010-12-17 02:45:41 +00:00
|
|
|
MCObjectWriter &getWriter() const { return Writer; }
|
|
|
|
|
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.
|
2012-09-14 14:57:36 +00:00
|
|
|
/// \p Writer is used for custom object writer (as the MCJIT does),
|
2010-07-22 05:58:53 +00:00
|
|
|
/// if not specified it is automatically created from backend.
|
2010-12-17 02:45:41 +00:00
|
|
|
void Finish();
|
llvm-mc: Start MCAssembler and MCMachOStreamer.
- Together these form the (Mach-O) back end of the assembler.
- MCAssembler is the actual assembler backend, which is designed to have a
reasonable API. This will eventually grow to support multiple object file
implementations, but for now its Mach-O/i386 only.
- MCMachOStreamer adapts the MCStreamer "actions" API to the MCAssembler API,
e.g. converting the various directives into fragments, managing state like
the current section, and so on.
- llvm-mc will use the new backend via '-filetype=obj', which may eventually
be, but is not yet, since I hear that people like assemblers which actually
assemble.
- The only thing that works at the moment is changing sections. For the time
being I have a Python Mach-O dumping tool in test/scripts so this stuff can
be easily tested, eventually I expect to replace this with a real LLVM tool.
- More doxyments to come.
I assume that since this stuff doesn't touch any of the things which are part of
2.6 that it is ok to put this in not so long before the freeze, but if someone
objects let me know, I can pull it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@79612 91177308-0d34-0410-b5e6-96231b3b80d8
2009-08-21 09:11:24 +00:00
|
|
|
|
2009-08-26 21:22:22 +00:00
|
|
|
// FIXME: This does not belong here.
|
|
|
|
bool getSubsectionsViaSymbols() const {
|
|
|
|
return SubsectionsViaSymbols;
|
|
|
|
}
|
|
|
|
void setSubsectionsViaSymbols(bool Value) {
|
|
|
|
SubsectionsViaSymbols = Value;
|
|
|
|
}
|
|
|
|
|
2010-03-25 22:49:09 +00:00
|
|
|
bool getRelaxAll() const { return RelaxAll; }
|
|
|
|
void setRelaxAll(bool Value) { RelaxAll = Value; }
|
|
|
|
|
2012-12-20 19:05:53 +00:00
|
|
|
bool isBundlingEnabled() const {
|
|
|
|
return BundleAlignSize != 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
unsigned getBundleAlignSize() const {
|
|
|
|
return BundleAlignSize;
|
|
|
|
}
|
|
|
|
|
|
|
|
void setBundleAlignSize(unsigned Size) {
|
|
|
|
assert((Size == 0 || !(Size & (Size - 1))) &&
|
|
|
|
"Expect a power-of-two bundle align size");
|
|
|
|
BundleAlignSize = 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
|
|
|
/// @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(); }
|
|
|
|
|
2014-04-18 18:24:25 +00:00
|
|
|
symbol_range symbols() { return make_range(symbol_begin(), symbol_end()); }
|
|
|
|
const_symbol_range symbols() const { return make_range(symbol_begin(), symbol_end()); }
|
|
|
|
|
2009-08-22 10:13:24 +00:00
|
|
|
size_t symbol_size() const { return Symbols.size(); }
|
|
|
|
|
2009-08-24 11:56:58 +00:00
|
|
|
/// @}
|
|
|
|
/// @name Indirect Symbol List Access
|
|
|
|
/// @{
|
|
|
|
|
|
|
|
// FIXME: This is a total hack, this should not be here. Once things are
|
|
|
|
// factored so that the streamer has direct access to the .o writer, it can
|
|
|
|
// disappear.
|
|
|
|
std::vector<IndirectSymbolData> &getIndirectSymbols() {
|
|
|
|
return IndirectSymbols;
|
|
|
|
}
|
|
|
|
|
|
|
|
indirect_symbol_iterator indirect_symbol_begin() {
|
|
|
|
return IndirectSymbols.begin();
|
|
|
|
}
|
2010-03-19 07:09:33 +00:00
|
|
|
const_indirect_symbol_iterator indirect_symbol_begin() const {
|
|
|
|
return IndirectSymbols.begin();
|
|
|
|
}
|
2009-08-24 11:56:58 +00:00
|
|
|
|
|
|
|
indirect_symbol_iterator indirect_symbol_end() {
|
|
|
|
return IndirectSymbols.end();
|
|
|
|
}
|
2010-03-19 07:09:33 +00:00
|
|
|
const_indirect_symbol_iterator indirect_symbol_end() const {
|
|
|
|
return IndirectSymbols.end();
|
|
|
|
}
|
2009-08-24 11:56:58 +00:00
|
|
|
|
|
|
|
size_t indirect_symbol_size() const { return IndirectSymbols.size(); }
|
|
|
|
|
2013-01-18 01:26:07 +00:00
|
|
|
/// @}
|
|
|
|
/// @name Linker Option List Access
|
|
|
|
/// @{
|
|
|
|
|
|
|
|
std::vector<std::vector<std::string> > &getLinkerOptions() {
|
|
|
|
return LinkerOptions;
|
|
|
|
}
|
|
|
|
|
2012-05-18 19:12:01 +00:00
|
|
|
/// @}
|
|
|
|
/// @name Data Region 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<DataRegionData> &getDataRegions() {
|
|
|
|
return DataRegions;
|
|
|
|
}
|
|
|
|
|
|
|
|
data_region_iterator data_region_begin() {
|
|
|
|
return DataRegions.begin();
|
|
|
|
}
|
|
|
|
const_data_region_iterator data_region_begin() const {
|
|
|
|
return DataRegions.begin();
|
|
|
|
}
|
|
|
|
|
|
|
|
data_region_iterator data_region_end() {
|
|
|
|
return DataRegions.end();
|
|
|
|
}
|
|
|
|
const_data_region_iterator data_region_end() const {
|
|
|
|
return DataRegions.end();
|
|
|
|
}
|
|
|
|
|
|
|
|
size_t data_region_size() const { return DataRegions.size(); }
|
|
|
|
|
2014-03-29 07:34:53 +00:00
|
|
|
/// @}
|
|
|
|
/// @name Data Region 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.
|
|
|
|
MCLOHContainer & getLOHContainer() {
|
|
|
|
return LOHContainer;
|
|
|
|
}
|
|
|
|
const MCLOHContainer & getLOHContainer() const {
|
|
|
|
return const_cast<MCAssembler *>(this)->getLOHContainer();
|
|
|
|
}
|
2010-03-10 20:58:29 +00:00
|
|
|
/// @}
|
|
|
|
/// @name Backend Data Access
|
|
|
|
/// @{
|
|
|
|
|
2010-03-12 21:00:45 +00:00
|
|
|
MCSectionData &getSectionData(const MCSection &Section) const {
|
|
|
|
MCSectionData *Entry = SectionMap.lookup(&Section);
|
2010-03-10 20:58:29 +00:00
|
|
|
assert(Entry && "Missing section data!");
|
|
|
|
return *Entry;
|
|
|
|
}
|
|
|
|
|
|
|
|
MCSectionData &getOrCreateSectionData(const MCSection &Section,
|
2014-04-13 04:57:38 +00:00
|
|
|
bool *Created = nullptr) {
|
2010-03-10 20:58:29 +00:00
|
|
|
MCSectionData *&Entry = SectionMap[&Section];
|
|
|
|
|
|
|
|
if (Created) *Created = !Entry;
|
|
|
|
if (!Entry)
|
|
|
|
Entry = new MCSectionData(Section, this);
|
|
|
|
|
|
|
|
return *Entry;
|
|
|
|
}
|
|
|
|
|
2014-01-30 21:13:05 +00:00
|
|
|
bool hasSymbolData(const MCSymbol &Symbol) const {
|
2014-04-13 04:57:38 +00:00
|
|
|
return SymbolMap.lookup(&Symbol) != nullptr;
|
2014-01-30 21:13:05 +00:00
|
|
|
}
|
|
|
|
|
2014-04-24 16:59:40 +00:00
|
|
|
MCSymbolData &getSymbolData(const MCSymbol &Symbol) {
|
2014-04-25 20:19:11 +00:00
|
|
|
return const_cast<MCSymbolData &>(
|
|
|
|
static_cast<const MCAssembler &>(*this).getSymbolData(Symbol));
|
2014-04-24 16:59:40 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
const MCSymbolData &getSymbolData(const MCSymbol &Symbol) const {
|
2010-03-12 21:00:45 +00:00
|
|
|
MCSymbolData *Entry = SymbolMap.lookup(&Symbol);
|
2010-03-10 20:58:29 +00:00
|
|
|
assert(Entry && "Missing symbol data!");
|
|
|
|
return *Entry;
|
|
|
|
}
|
|
|
|
|
|
|
|
MCSymbolData &getOrCreateSymbolData(const MCSymbol &Symbol,
|
2014-04-13 04:57:38 +00:00
|
|
|
bool *Created = nullptr) {
|
2010-03-10 20:58:29 +00:00
|
|
|
MCSymbolData *&Entry = SymbolMap[&Symbol];
|
|
|
|
|
|
|
|
if (Created) *Created = !Entry;
|
|
|
|
if (!Entry)
|
2014-04-13 04:57:38 +00:00
|
|
|
Entry = new MCSymbolData(Symbol, nullptr, 0, this);
|
2010-03-10 20:58:29 +00:00
|
|
|
|
|
|
|
return *Entry;
|
|
|
|
}
|
|
|
|
|
2013-10-29 01:06:17 +00:00
|
|
|
const_file_name_iterator file_names_begin() const {
|
|
|
|
return FileNames.begin();
|
|
|
|
}
|
|
|
|
|
|
|
|
const_file_name_iterator file_names_end() const {
|
|
|
|
return FileNames.end();
|
|
|
|
}
|
|
|
|
|
|
|
|
void addFileName(StringRef FileName) {
|
|
|
|
if (std::find(file_names_begin(), file_names_end(), FileName) ==
|
|
|
|
file_names_end())
|
|
|
|
FileNames.push_back(FileName);
|
|
|
|
}
|
|
|
|
|
2015-04-12 23:42:25 +00:00
|
|
|
/// \brief Write the necessary bundle padding to the given object writer.
|
|
|
|
/// Expects a fragment \p F containing instructions and its size \p FSize.
|
|
|
|
void writeFragmentPadding(const MCFragment &F, uint64_t FSize,
|
|
|
|
MCObjectWriter *OW) const;
|
|
|
|
|
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
|
|
|
};
|
|
|
|
|
2015-04-12 23:42:25 +00:00
|
|
|
/// \brief Compute the amount of padding required before the fragment \p F to
|
|
|
|
/// obey bundling restrictions, where \p FOffset is the fragment's offset in
|
|
|
|
/// its section and \p FSize is the fragment's size.
|
|
|
|
uint64_t computeBundlePadding(const MCAssembler &Assembler,
|
|
|
|
const MCFragment *F,
|
|
|
|
uint64_t FOffset, uint64_t FSize);
|
|
|
|
|
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
|