search for: mcasminfo

...gh). I am on Ubuntu 10.04 LTS 64-Bit. And I configure and compile with CMake. The error message I get at approximatley 66% is as follows: Linking CXX executable ../../bin/llvm-mc ../../lib/libLLVMMSP430Desc.a(MSP430MCTargetDesc.cpp.o): In function `llvm::MSP430InstPrinter::MSP430InstPrinter(llvm::MCAsmInfo const&)': MSP430MCTargetDesc.cpp:(.text._ZN4llvm17MSP430InstPrinterC1ERKNS_9MCAsmInfoE[llvm::MSP430InstPrinter::MSP430InstPrinter(llvm::MCAsmInfo const&)]+0x2a): undefined reference to `vtable for llvm::MSP430InstPrinter' ../../lib/libLLVMMipsDesc.a(MipsMCTargetDesc.cpp.o): In funct...

...e format. For ELF32 they begin with '$' and for ELF64 they begin with '.L'. The object file format depends on the ABI, but multiple ABI's are usable with the same target triple so we can't select between the prefixes using triples. In the current structure, we appear to need MCAsmInfo to return different values for different object formats but it has no means to do this. It seems to me that the private label prefixes are more closely associated with the object file format than they are with the assembly syntax so I'd like to propose moving MCAsmInfo::getPrivateGlobalPrefix(...

currently, there is no (easy) way to set the AssemblerDialect. the only method i am aware of is to set that via cl:opt. this patch fixes that by adding a public function setAssemblerDialect() to class MCAsmInfo. Signed-off-by: Jun Koi <junkoi2004 at gmail.com> diff --git a/include/llvm/MC/MCAsmInfo.h b/include/llvm/MC/MCAsmInfo.h index 97aad71..cd08a7e 100644 --- a/include/llvm/MC/MCAsmInfo.h +++ b/include/llvm/MC/MCAsmInfo.h @@ -453,6 +453,9 @@ namespace llvm { unsigned getAssemblerDialect(...

This is a behaviour configurable in the MCAsmInfo. I've decided to turn it on by default in (possibly optimistic) hopes that most assemblers are reasonably sane. If this proves a problem, switching to default seems reasonable. --- include/llvm/MC/MCAsmInfo.h | 7 +++++++ lib/MC/MCAsmInfo.cpp | 1 + lib/Target/Mangler.cpp |...

...ncoding being ABI dependant) and I've mixed them together in my original email. The split I should have described is that the label prefix is '$' for O32 and '.L' for N32/N64. Unfortunately O32/N32 are ELF32 and N64 is ELF64. I tried passing MCTargetOptions::ABIName down to the MCAsmInfo but ran into problems with some users of MCAsmInfo not initializing MCTargetOptions. There is also a problem with some users of MCAsmInfo not knowing the ABI. For example, llvm-objdump doesn't know the ABI until it starts reading the object file but has to initialize the MCAsmInfo earlier than...

On 23 May 2015 at 00:08, Jim Grosbach <grosbach at apple.com> wrote: > This is the key question. The LLVM assumption is that these sorts of things > are inferable from the triple. Your observation here that the GNU world’s > notion of triples and LLVM’s need not be the same is a good one. Having a > split and a translation up in clang seems an interesting avenue to explore. >

...S 64-Bit. And I configure and compile with CMake. > > The error message I get at approximatley 66% is as follows: > > Linking CXX executable ../../bin/llvm-mc > ../../lib/libLLVMMSP430Desc.a(MSP430MCTargetDesc.cpp.o): In function > `llvm::MSP430InstPrinter::MSP430InstPrinter(llvm::MCAsmInfo const&)': > MSP430MCTargetDesc.cpp:(.text._ZN4llvm17MSP430InstPrinterC1ERKNS_9MCAsmInfoE[llvm::MSP430InstPrinter::MSP430InstPrinter(llvm::MCAsmInfo > const&)]+0x2a): undefined reference to `vtable for > llvm::MSP430InstPrinter' > ../../lib/libLLVMMipsDesc.a(MipsMCTargetD...

Hi all. I fully understand that the problem is a bit OT for llvmdev, but I'm stuck for two days now and I really need some direct push. To the problem. I have a C++ shared library, that's working with llvm C++ api. Consider a function: static Object llvm_Target_createMCAsmInfo(Object self, Object tripleName) { llvm::Target target = from_ruby<llvm::Target>(self); char const *triple = from_ruby<char const *>(tripleName); llvm::MCAsmInfo *MAI = target.createMCAsmInfo(triple); return to_ruby<llvm::MCAsmInfo>(*MAI); } The problem here, is it's ok...

..., Jun Koi <junkoi2004 at gmail.com> wrote: > >> currently, there is no (easy) way to set the AssemblerDialect. the >> only method i am aware of is to set that via cl:opt. >> >> this patch fixes that by adding a public function >> setAssemblerDialect() to class MCAsmInfo. >> >> Signed-off-by: Jun Koi <junkoi2004 at gmail.com> >> >> >> diff --git a/include/llvm/MC/MCAsmInfo.h b/include/llvm/MC/MCAsmInfo.h >> index 97aad71..cd08a7e 100644 >> --- a/include/llvm/MC/MCAsmInfo.h >> +++ b/include/llvm/MC/MCAsmInfo.h &g...

...Oct 1, 2012, at 8:33 PM, Jun Koi <junkoi2004 at gmail.com> wrote: > currently, there is no (easy) way to set the AssemblerDialect. the > only method i am aware of is to set that via cl:opt. > > this patch fixes that by adding a public function > setAssemblerDialect() to class MCAsmInfo. > > Signed-off-by: Jun Koi <junkoi2004 at gmail.com> > > > diff --git a/include/llvm/MC/MCAsmInfo.h b/include/llvm/MC/MCAsmInfo.h > index 97aad71..cd08a7e 100644 > --- a/include/llvm/MC/MCAsmInfo.h > +++ b/include/llvm/MC/MCAsmInfo.h > @@ -453,6 +453,9 @@ namesp...

Hi all I have a question about the '-fno-exceptions' option with clang and 'ExceptionsType' on MCAsmInfo. I am looking for a way to avoid generating stack unwinding codes when compiling with the "armv7-none-linux-gnu" triple using clang. I tried the '-fno-exceptions' option in order to do that, but unwinding function symbols like '__aeabi_unwind_cpp_pr0' were still presen...

...gt; > I fully understand that the problem is a bit OT for llvmdev, but I'm stuck for two days now and I really need some direct push. > > To the problem. I have a C++ shared library, that's working with llvm C++ api. Consider a function: > > static Object llvm_Target_createMCAsmInfo(Object self, Object tripleName) > { > llvm::Target target = from_ruby<llvm::Target>(self); > char const *triple = from_ruby<char const *>(tripleName); > > llvm::MCAsmInfo *MAI = target.createMCAsmInfo(triple); > return to_ruby<llvm::MCAsmInfo>(*MA...

...> same results. Please show the exact commands you used for building LLVM with RTTI support. It would also help if you repeat your recipe for building LLVM but appending to your `make' command the text "VERBOSE=1" and then show the compiler command line for one .cpp file (lib/MC/MCAsmInfo.cpp is the best candidate.)

...se show the exact commands you used for building LLVM with RTTI > support. > > It would also help if you repeat your recipe for building LLVM but appending > to your `make' command the text "VERBOSE=1" and then show the compiler > command line for one .cpp file (lib/MC/MCAsmInfo.cpp is the best > candidate.) > There is (was?) a CMake variable for this if you're going that route. Setting LLVM_REQUIRES_RTTI=1 enabled an RTTI build that I haven't had issues with. I don't know what the ./configure equivalent is, sorry. -Gordon > _________________...

...ABI, and it's difficult for GHC to change that. Following the example of CoreCLR in LLVM, it seems one way to remedy this situation is to define a new ABI (i.e., a new llvm::Triple::EnvironmentType ) and modify the code generator as-needed to respect to our ABI, through our own definition of an MCAsmInfo class for each architecture, etc. My question is: how feasible is it to extend MCAsmInfo with an override for the stack pointer register and have that fact be respected by the code generator? Currently, MCAsmInfo only specifies the stack direction, and from what I've seen in the x86 backend...

...\AsmPrinter\AsmPrinter.cpp) and it seems that its implementation will vary quite a bit depending on what object file format is in use (MachO, ELF, or COFF). Would it make sense to delegate the implementation to a specialized object from current the object file format? I am tempted to make it the MCAsmInfo implementation for the specific target. Currently MCAsmInfo looks just to hold useful information about the target, and not any target specific code. TargetLoweringObjectFile looks to perform a similar function as MCAsmInfo, though this doesn't look to be responsible for directing the AsmPrint...

I've actually tried to compile both LLVM and my lib with -frtti with same results. On Dec 10, 2012, at 21:57, Jim Grosbach <grosbach at apple.com> wrote: > Llvm typically doesn't build with RTTI enabled. Perhaps that's what you're running into? > > Jim -- Vladimir Pouzanov http://www.farcaller.net/ -------------- next part -------------- A non-text attachment

Gordon Keiser <gkeiser at arxan.com> writes: > There is (was?) a CMake variable for this if you're going that route. > Setting LLVM_REQUIRES_RTTI=1 enabled an RTTI build that I haven't had > issues with. I don't know what the ./configure equivalent is, sorry. LLVM_REQUIRES_RTTI is an internal variable. It works as you say, but there is no guarantee about it. Adding a

...he function. The jump tables at the end of the function are unused. >> >> What would be the preferred way of dealing with this? Should I add a >> variable to AsmPrinter that can be set by targets to disable this >> emission at the end? > The attached patch adds a bool to MCAsmInfo that can be used to disable the emission of jump tables at the end of a function and updates the XCore target to set this. Is this OK to commit? Hi Richard, This shouldn't go into MCAsmInfo, it's a "lowering" issue, not a "assembly syntax" issue. ARM also has inline j...

...mentation to a specialized object from current the object file format? Why? It is AsmPrinter's job to handle the lowering of MachineInstrs and LLVM IR (for globals etc) to the MC level primitives. AsmPrinter should really be renamed MCLowering at some point. > I am tempted to make it the MCAsmInfo implementation for the specific target. Currently MCAsmInfo looks just to hold useful information about the target, and not any target specific code. Right. MCAsmInfo has been designed to be filled in by targets but not subclassed. This implies that it can't have virtual methods. > Target...