llvm-6502/lib/MC/MCExternalSymbolizer.cpp

199 lines
8.3 KiB
C++
Raw Normal View History

Add MCSymbolizer for symbolic/annotated disassembly. This is a basic first step towards symbolization of disassembled instructions. This used to be done using externally provided (C API) callbacks. This patch introduces: - the MCSymbolizer class, that mimics the same functions that were used in the X86 and ARM disassemblers to symbolize immediate operands and to annotate loads based off PC (for things like c string literals). - the MCExternalSymbolizer class, which implements the old C API. - the MCRelocationInfo class, which provides a way for targets to translate relocations (either object::RelocationRef, or disassembler C API VariantKinds) to MCExprs. - the MCObjectSymbolizer class, which does symbolization using what it finds in an object::ObjectFile. This makes simple symbolization (with no fancy relocation stuff) work for all object formats! - x86-64 Mach-O and ELF MCRelocationInfos. - A basic ARM Mach-O MCRelocationInfo, that provides just enough to support the C API VariantKinds. Most of what works in otool (the only user of the old symbolization API that I know of) for x86-64 symbolic disassembly (-tvV) works, namely: - symbol references: call _foo; jmp 15 <_foo+50> - relocations: call _foo-_bar; call _foo-4 - __cf?string: leaq 193(%rip), %rax ## literal pool for "hello" Stub support is the main missing part (because libObject doesn't know, among other things, about mach-o indirect symbols). As for the MCSymbolizer API, instead of relying on the disassemblers to call the tryAdding* methods, maybe this could be done automagically using InstrInfo? For instance, even though PC-relative LEAs are used to get the address of string literals in a typical Mach-O file, a MOV would be used in an ELF file. And right now, the explicit symbolization only recognizes PC-relative LEAs. InstrInfo should have already have most of what is needed to know what to symbolize, so this can definitely be improved. I'd also like to remove object::RelocationRef::getValueString (it seems only used by relocation printing in objdump), as simply printing the created MCExpr is definitely enough (and cleaner than string concats). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182625 91177308-0d34-0410-b5e6-96231b3b80d8
2013-05-24 00:39:57 +00:00
//===-- lib/MC/MCExternalSymbolizer.cpp - External symbolizer ---*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
#include "llvm/MC/MCExternalSymbolizer.h"
#include "llvm/MC/MCContext.h"
#include "llvm/MC/MCExpr.h"
#include "llvm/MC/MCInst.h"
#include "llvm/Support/raw_ostream.h"
#include <cstring>
using namespace llvm;
// This function tries to add a symbolic operand in place of the immediate
// Value in the MCInst. The immediate Value has had any PC adjustment made by
// the caller. If the instruction is a branch instruction then IsBranch is true,
// else false. If the getOpInfo() function was set as part of the
// setupForSymbolicDisassembly() call then that function is called to get any
// symbolic information at the Address for this instruction. If that returns
// non-zero then the symbolic information it returns is used to create an MCExpr
// and that is added as an operand to the MCInst. If getOpInfo() returns zero
// and IsBranch is true then a symbol look up for Value is done and if a symbol
// is found an MCExpr is created with that, else an MCExpr with Value is
// created. This function returns true if it adds an operand to the MCInst and
// false otherwise.
bool MCExternalSymbolizer::tryAddingSymbolicOperand(MCInst &MI,
raw_ostream &cStream,
int64_t Value,
uint64_t Address,
bool IsBranch,
uint64_t Offset,
uint64_t InstSize) {
struct LLVMOpInfo1 SymbolicOp;
std::memset(&SymbolicOp, '\0', sizeof(struct LLVMOpInfo1));
SymbolicOp.Value = Value;
if (!GetOpInfo ||
!GetOpInfo(DisInfo, Address, Offset, InstSize, 1, &SymbolicOp)) {
// Clear SymbolicOp.Value from above and also all other fields.
std::memset(&SymbolicOp, '\0', sizeof(struct LLVMOpInfo1));
Tweak the MCExternalSymbolizer to not use the SymbolLookUp() call back to not guess at a symbol name in some cases. The problem is that in object files assembled starting at address 0, when trying to symbolicate something that starts like this: % cat x.s _t1: vpshufd $0x0, %xmm1, %xmm0 the symbolic disassembly can end up like this: % otool -tV x.o x.o: (__TEXT,__text) section _t1: 0000000000000000 vpshufd $_t1, %xmm1, %xmm0 Which is in this case produced incorrect symbolication. But it is useful in some cases to use the SymbolLookUp() call back to guess at some immediate values. For example one like this that does not have an external relocation entry: % cat y.s _t1: movl $_d1, %eax .data _d1: .long 0 % clang -c -arch i386 y.s % otool -tV y.o y.o: (__TEXT,__text) section _t1: 0000000000000000 movl $_d1, %eax % otool -rv y.o y.o: Relocation information (__TEXT,__text) 1 entries address pcrel length extern type scattered symbolnum/value 00000001 False long False VANILLA False 2 (__DATA,__data) So the change is based on it is not likely that an immediate Value coming from an instruction field of a width of 1 byte, other than branches and items with relocation, are not likely symbol addresses. With the change the first case above simply becomes: % otool -tV x.o x.o: (__TEXT,__text) section _t1: 0000000000000000 vpshufd $0x0, %xmm1, %xmm0 and the second case continues to work as expected. rdar://14863405 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199698 91177308-0d34-0410-b5e6-96231b3b80d8
2014-01-21 00:23:17 +00:00
// At this point, GetOpInfo() did not find any relocation information about
// this operand and we are left to use the SymbolLookUp() call back to guess
// if the Value is the address of a symbol. In the case this is a branch
// that always makes sense to guess. But in the case of an immediate it is
// a bit more questionable if it is an address of a symbol or some other
// reference. So if the immediate Value comes from a width of 1 byte,
// InstSize, we will not guess it is an address of a symbol. Because in
// object files assembled starting at address 0 this usually leads to
// incorrect symbolication.
if (!SymbolLookUp || (InstSize == 1 && !IsBranch))
Add MCSymbolizer for symbolic/annotated disassembly. This is a basic first step towards symbolization of disassembled instructions. This used to be done using externally provided (C API) callbacks. This patch introduces: - the MCSymbolizer class, that mimics the same functions that were used in the X86 and ARM disassemblers to symbolize immediate operands and to annotate loads based off PC (for things like c string literals). - the MCExternalSymbolizer class, which implements the old C API. - the MCRelocationInfo class, which provides a way for targets to translate relocations (either object::RelocationRef, or disassembler C API VariantKinds) to MCExprs. - the MCObjectSymbolizer class, which does symbolization using what it finds in an object::ObjectFile. This makes simple symbolization (with no fancy relocation stuff) work for all object formats! - x86-64 Mach-O and ELF MCRelocationInfos. - A basic ARM Mach-O MCRelocationInfo, that provides just enough to support the C API VariantKinds. Most of what works in otool (the only user of the old symbolization API that I know of) for x86-64 symbolic disassembly (-tvV) works, namely: - symbol references: call _foo; jmp 15 <_foo+50> - relocations: call _foo-_bar; call _foo-4 - __cf?string: leaq 193(%rip), %rax ## literal pool for "hello" Stub support is the main missing part (because libObject doesn't know, among other things, about mach-o indirect symbols). As for the MCSymbolizer API, instead of relying on the disassemblers to call the tryAdding* methods, maybe this could be done automagically using InstrInfo? For instance, even though PC-relative LEAs are used to get the address of string literals in a typical Mach-O file, a MOV would be used in an ELF file. And right now, the explicit symbolization only recognizes PC-relative LEAs. InstrInfo should have already have most of what is needed to know what to symbolize, so this can definitely be improved. I'd also like to remove object::RelocationRef::getValueString (it seems only used by relocation printing in objdump), as simply printing the created MCExpr is definitely enough (and cleaner than string concats). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182625 91177308-0d34-0410-b5e6-96231b3b80d8
2013-05-24 00:39:57 +00:00
return false;
Tweak the MCExternalSymbolizer to not use the SymbolLookUp() call back to not guess at a symbol name in some cases. The problem is that in object files assembled starting at address 0, when trying to symbolicate something that starts like this: % cat x.s _t1: vpshufd $0x0, %xmm1, %xmm0 the symbolic disassembly can end up like this: % otool -tV x.o x.o: (__TEXT,__text) section _t1: 0000000000000000 vpshufd $_t1, %xmm1, %xmm0 Which is in this case produced incorrect symbolication. But it is useful in some cases to use the SymbolLookUp() call back to guess at some immediate values. For example one like this that does not have an external relocation entry: % cat y.s _t1: movl $_d1, %eax .data _d1: .long 0 % clang -c -arch i386 y.s % otool -tV y.o y.o: (__TEXT,__text) section _t1: 0000000000000000 movl $_d1, %eax % otool -rv y.o y.o: Relocation information (__TEXT,__text) 1 entries address pcrel length extern type scattered symbolnum/value 00000001 False long False VANILLA False 2 (__DATA,__data) So the change is based on it is not likely that an immediate Value coming from an instruction field of a width of 1 byte, other than branches and items with relocation, are not likely symbol addresses. With the change the first case above simply becomes: % otool -tV x.o x.o: (__TEXT,__text) section _t1: 0000000000000000 vpshufd $0x0, %xmm1, %xmm0 and the second case continues to work as expected. rdar://14863405 git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199698 91177308-0d34-0410-b5e6-96231b3b80d8
2014-01-21 00:23:17 +00:00
Add MCSymbolizer for symbolic/annotated disassembly. This is a basic first step towards symbolization of disassembled instructions. This used to be done using externally provided (C API) callbacks. This patch introduces: - the MCSymbolizer class, that mimics the same functions that were used in the X86 and ARM disassemblers to symbolize immediate operands and to annotate loads based off PC (for things like c string literals). - the MCExternalSymbolizer class, which implements the old C API. - the MCRelocationInfo class, which provides a way for targets to translate relocations (either object::RelocationRef, or disassembler C API VariantKinds) to MCExprs. - the MCObjectSymbolizer class, which does symbolization using what it finds in an object::ObjectFile. This makes simple symbolization (with no fancy relocation stuff) work for all object formats! - x86-64 Mach-O and ELF MCRelocationInfos. - A basic ARM Mach-O MCRelocationInfo, that provides just enough to support the C API VariantKinds. Most of what works in otool (the only user of the old symbolization API that I know of) for x86-64 symbolic disassembly (-tvV) works, namely: - symbol references: call _foo; jmp 15 <_foo+50> - relocations: call _foo-_bar; call _foo-4 - __cf?string: leaq 193(%rip), %rax ## literal pool for "hello" Stub support is the main missing part (because libObject doesn't know, among other things, about mach-o indirect symbols). As for the MCSymbolizer API, instead of relying on the disassemblers to call the tryAdding* methods, maybe this could be done automagically using InstrInfo? For instance, even though PC-relative LEAs are used to get the address of string literals in a typical Mach-O file, a MOV would be used in an ELF file. And right now, the explicit symbolization only recognizes PC-relative LEAs. InstrInfo should have already have most of what is needed to know what to symbolize, so this can definitely be improved. I'd also like to remove object::RelocationRef::getValueString (it seems only used by relocation printing in objdump), as simply printing the created MCExpr is definitely enough (and cleaner than string concats). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182625 91177308-0d34-0410-b5e6-96231b3b80d8
2013-05-24 00:39:57 +00:00
uint64_t ReferenceType;
if (IsBranch)
ReferenceType = LLVMDisassembler_ReferenceType_In_Branch;
else
ReferenceType = LLVMDisassembler_ReferenceType_InOut_None;
const char *ReferenceName;
const char *Name = SymbolLookUp(DisInfo, Value, &ReferenceType, Address,
&ReferenceName);
if (Name) {
SymbolicOp.AddSymbol.Name = Name;
SymbolicOp.AddSymbol.Present = true;
// If Name is a C++ symbol name put the human readable name in a comment.
if(ReferenceType == LLVMDisassembler_ReferenceType_DeMangled_Name)
cStream << ReferenceName;
Add MCSymbolizer for symbolic/annotated disassembly. This is a basic first step towards symbolization of disassembled instructions. This used to be done using externally provided (C API) callbacks. This patch introduces: - the MCSymbolizer class, that mimics the same functions that were used in the X86 and ARM disassemblers to symbolize immediate operands and to annotate loads based off PC (for things like c string literals). - the MCExternalSymbolizer class, which implements the old C API. - the MCRelocationInfo class, which provides a way for targets to translate relocations (either object::RelocationRef, or disassembler C API VariantKinds) to MCExprs. - the MCObjectSymbolizer class, which does symbolization using what it finds in an object::ObjectFile. This makes simple symbolization (with no fancy relocation stuff) work for all object formats! - x86-64 Mach-O and ELF MCRelocationInfos. - A basic ARM Mach-O MCRelocationInfo, that provides just enough to support the C API VariantKinds. Most of what works in otool (the only user of the old symbolization API that I know of) for x86-64 symbolic disassembly (-tvV) works, namely: - symbol references: call _foo; jmp 15 <_foo+50> - relocations: call _foo-_bar; call _foo-4 - __cf?string: leaq 193(%rip), %rax ## literal pool for "hello" Stub support is the main missing part (because libObject doesn't know, among other things, about mach-o indirect symbols). As for the MCSymbolizer API, instead of relying on the disassemblers to call the tryAdding* methods, maybe this could be done automagically using InstrInfo? For instance, even though PC-relative LEAs are used to get the address of string literals in a typical Mach-O file, a MOV would be used in an ELF file. And right now, the explicit symbolization only recognizes PC-relative LEAs. InstrInfo should have already have most of what is needed to know what to symbolize, so this can definitely be improved. I'd also like to remove object::RelocationRef::getValueString (it seems only used by relocation printing in objdump), as simply printing the created MCExpr is definitely enough (and cleaner than string concats). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182625 91177308-0d34-0410-b5e6-96231b3b80d8
2013-05-24 00:39:57 +00:00
}
// For branches always create an MCExpr so it gets printed as hex address.
else if (IsBranch) {
SymbolicOp.Value = Value;
}
if(ReferenceType == LLVMDisassembler_ReferenceType_Out_SymbolStub)
cStream << "symbol stub for: " << ReferenceName;
else if(ReferenceType == LLVMDisassembler_ReferenceType_Out_Objc_Message)
cStream << "Objc message: " << ReferenceName;
Add MCSymbolizer for symbolic/annotated disassembly. This is a basic first step towards symbolization of disassembled instructions. This used to be done using externally provided (C API) callbacks. This patch introduces: - the MCSymbolizer class, that mimics the same functions that were used in the X86 and ARM disassemblers to symbolize immediate operands and to annotate loads based off PC (for things like c string literals). - the MCExternalSymbolizer class, which implements the old C API. - the MCRelocationInfo class, which provides a way for targets to translate relocations (either object::RelocationRef, or disassembler C API VariantKinds) to MCExprs. - the MCObjectSymbolizer class, which does symbolization using what it finds in an object::ObjectFile. This makes simple symbolization (with no fancy relocation stuff) work for all object formats! - x86-64 Mach-O and ELF MCRelocationInfos. - A basic ARM Mach-O MCRelocationInfo, that provides just enough to support the C API VariantKinds. Most of what works in otool (the only user of the old symbolization API that I know of) for x86-64 symbolic disassembly (-tvV) works, namely: - symbol references: call _foo; jmp 15 <_foo+50> - relocations: call _foo-_bar; call _foo-4 - __cf?string: leaq 193(%rip), %rax ## literal pool for "hello" Stub support is the main missing part (because libObject doesn't know, among other things, about mach-o indirect symbols). As for the MCSymbolizer API, instead of relying on the disassemblers to call the tryAdding* methods, maybe this could be done automagically using InstrInfo? For instance, even though PC-relative LEAs are used to get the address of string literals in a typical Mach-O file, a MOV would be used in an ELF file. And right now, the explicit symbolization only recognizes PC-relative LEAs. InstrInfo should have already have most of what is needed to know what to symbolize, so this can definitely be improved. I'd also like to remove object::RelocationRef::getValueString (it seems only used by relocation printing in objdump), as simply printing the created MCExpr is definitely enough (and cleaner than string concats). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182625 91177308-0d34-0410-b5e6-96231b3b80d8
2013-05-24 00:39:57 +00:00
if (!Name && !IsBranch)
return false;
}
const MCExpr *Add = NULL;
if (SymbolicOp.AddSymbol.Present) {
if (SymbolicOp.AddSymbol.Name) {
StringRef Name(SymbolicOp.AddSymbol.Name);
MCSymbol *Sym = Ctx.GetOrCreateSymbol(Name);
Add = MCSymbolRefExpr::Create(Sym, Ctx);
} else {
Add = MCConstantExpr::Create((int)SymbolicOp.AddSymbol.Value, Ctx);
}
}
const MCExpr *Sub = NULL;
if (SymbolicOp.SubtractSymbol.Present) {
if (SymbolicOp.SubtractSymbol.Name) {
StringRef Name(SymbolicOp.SubtractSymbol.Name);
MCSymbol *Sym = Ctx.GetOrCreateSymbol(Name);
Sub = MCSymbolRefExpr::Create(Sym, Ctx);
} else {
Sub = MCConstantExpr::Create((int)SymbolicOp.SubtractSymbol.Value, Ctx);
}
}
const MCExpr *Off = NULL;
if (SymbolicOp.Value != 0)
Off = MCConstantExpr::Create(SymbolicOp.Value, Ctx);
const MCExpr *Expr;
if (Sub) {
const MCExpr *LHS;
if (Add)
LHS = MCBinaryExpr::CreateSub(Add, Sub, Ctx);
else
LHS = MCUnaryExpr::CreateMinus(Sub, Ctx);
if (Off != 0)
Expr = MCBinaryExpr::CreateAdd(LHS, Off, Ctx);
else
Expr = LHS;
} else if (Add) {
if (Off != 0)
Expr = MCBinaryExpr::CreateAdd(Add, Off, Ctx);
else
Expr = Add;
} else {
if (Off != 0)
Expr = Off;
else
Expr = MCConstantExpr::Create(0, Ctx);
}
Expr = RelInfo->createExprForCAPIVariantKind(Expr, SymbolicOp.VariantKind);
if (!Expr)
return false;
MI.addOperand(MCOperand::CreateExpr(Expr));
return true;
}
// This function tries to add a comment as to what is being referenced by a load
// instruction with the base register that is the Pc. These can often be values
// in a literal pool near the Address of the instruction. The Address of the
// instruction and its immediate Value are used as a possible literal pool entry.
// The SymbolLookUp call back will return the name of a symbol referenced by the
// literal pool's entry if the referenced address is that of a symbol. Or it
// will return a pointer to a literal 'C' string if the referenced address of
// the literal pool's entry is an address into a section with C string literals.
// Or if the reference is to an Objective-C data structure it will return a
// specific reference type for it and a string.
Add MCSymbolizer for symbolic/annotated disassembly. This is a basic first step towards symbolization of disassembled instructions. This used to be done using externally provided (C API) callbacks. This patch introduces: - the MCSymbolizer class, that mimics the same functions that were used in the X86 and ARM disassemblers to symbolize immediate operands and to annotate loads based off PC (for things like c string literals). - the MCExternalSymbolizer class, which implements the old C API. - the MCRelocationInfo class, which provides a way for targets to translate relocations (either object::RelocationRef, or disassembler C API VariantKinds) to MCExprs. - the MCObjectSymbolizer class, which does symbolization using what it finds in an object::ObjectFile. This makes simple symbolization (with no fancy relocation stuff) work for all object formats! - x86-64 Mach-O and ELF MCRelocationInfos. - A basic ARM Mach-O MCRelocationInfo, that provides just enough to support the C API VariantKinds. Most of what works in otool (the only user of the old symbolization API that I know of) for x86-64 symbolic disassembly (-tvV) works, namely: - symbol references: call _foo; jmp 15 <_foo+50> - relocations: call _foo-_bar; call _foo-4 - __cf?string: leaq 193(%rip), %rax ## literal pool for "hello" Stub support is the main missing part (because libObject doesn't know, among other things, about mach-o indirect symbols). As for the MCSymbolizer API, instead of relying on the disassemblers to call the tryAdding* methods, maybe this could be done automagically using InstrInfo? For instance, even though PC-relative LEAs are used to get the address of string literals in a typical Mach-O file, a MOV would be used in an ELF file. And right now, the explicit symbolization only recognizes PC-relative LEAs. InstrInfo should have already have most of what is needed to know what to symbolize, so this can definitely be improved. I'd also like to remove object::RelocationRef::getValueString (it seems only used by relocation printing in objdump), as simply printing the created MCExpr is definitely enough (and cleaner than string concats). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182625 91177308-0d34-0410-b5e6-96231b3b80d8
2013-05-24 00:39:57 +00:00
void MCExternalSymbolizer::tryAddingPcLoadReferenceComment(raw_ostream &cStream,
int64_t Value,
uint64_t Address) {
if (SymbolLookUp) {
uint64_t ReferenceType = LLVMDisassembler_ReferenceType_In_PCrel_Load;
const char *ReferenceName;
(void)SymbolLookUp(DisInfo, Value, &ReferenceType, Address, &ReferenceName);
if(ReferenceType == LLVMDisassembler_ReferenceType_Out_LitPool_SymAddr)
cStream << "literal pool symbol address: " << ReferenceName;
else if(ReferenceType ==
LLVMDisassembler_ReferenceType_Out_LitPool_CstrAddr) {
cStream << "literal pool for: \"";
cStream.write_escaped(ReferenceName);
cStream << "\"";
}
else if(ReferenceType ==
LLVMDisassembler_ReferenceType_Out_Objc_CFString_Ref)
cStream << "Objc cfstring ref: @\"" << ReferenceName << "\"";
else if(ReferenceType ==
LLVMDisassembler_ReferenceType_Out_Objc_Message)
cStream << "Objc message: " << ReferenceName;
else if(ReferenceType ==
LLVMDisassembler_ReferenceType_Out_Objc_Message_Ref)
cStream << "Objc message ref: " << ReferenceName;
else if(ReferenceType ==
LLVMDisassembler_ReferenceType_Out_Objc_Selector_Ref)
cStream << "Objc selector ref: " << ReferenceName;
else if(ReferenceType ==
LLVMDisassembler_ReferenceType_Out_Objc_Class_Ref)
cStream << "Objc class ref: " << ReferenceName;
Add MCSymbolizer for symbolic/annotated disassembly. This is a basic first step towards symbolization of disassembled instructions. This used to be done using externally provided (C API) callbacks. This patch introduces: - the MCSymbolizer class, that mimics the same functions that were used in the X86 and ARM disassemblers to symbolize immediate operands and to annotate loads based off PC (for things like c string literals). - the MCExternalSymbolizer class, which implements the old C API. - the MCRelocationInfo class, which provides a way for targets to translate relocations (either object::RelocationRef, or disassembler C API VariantKinds) to MCExprs. - the MCObjectSymbolizer class, which does symbolization using what it finds in an object::ObjectFile. This makes simple symbolization (with no fancy relocation stuff) work for all object formats! - x86-64 Mach-O and ELF MCRelocationInfos. - A basic ARM Mach-O MCRelocationInfo, that provides just enough to support the C API VariantKinds. Most of what works in otool (the only user of the old symbolization API that I know of) for x86-64 symbolic disassembly (-tvV) works, namely: - symbol references: call _foo; jmp 15 <_foo+50> - relocations: call _foo-_bar; call _foo-4 - __cf?string: leaq 193(%rip), %rax ## literal pool for "hello" Stub support is the main missing part (because libObject doesn't know, among other things, about mach-o indirect symbols). As for the MCSymbolizer API, instead of relying on the disassemblers to call the tryAdding* methods, maybe this could be done automagically using InstrInfo? For instance, even though PC-relative LEAs are used to get the address of string literals in a typical Mach-O file, a MOV would be used in an ELF file. And right now, the explicit symbolization only recognizes PC-relative LEAs. InstrInfo should have already have most of what is needed to know what to symbolize, so this can definitely be improved. I'd also like to remove object::RelocationRef::getValueString (it seems only used by relocation printing in objdump), as simply printing the created MCExpr is definitely enough (and cleaner than string concats). git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@182625 91177308-0d34-0410-b5e6-96231b3b80d8
2013-05-24 00:39:57 +00:00
}
}
namespace llvm {
MCSymbolizer *createMCSymbolizer(StringRef TT, LLVMOpInfoCallback GetOpInfo,
LLVMSymbolLookupCallback SymbolLookUp,
void *DisInfo,
MCContext *Ctx,
MCRelocationInfo *RelInfo) {
assert(Ctx != 0 && "No MCContext given for symbolic disassembly");
std::unique_ptr<MCRelocationInfo> RelInfoOwingPtr(RelInfo);
return new MCExternalSymbolizer(*Ctx, RelInfoOwingPtr, GetOpInfo,
SymbolLookUp, DisInfo);
}
}