similar to: [LLVMdev] Question about '-fno-exceptions' option and 'ExceptionsType' on MCAsmInfo with ARM.

> Why isn't the ABI reflected in the triple? Unfortunately, there's no easy answer to that. Some targets are better than others but generally speaking triples are very ambiguous. For example, in (most) GCC mips-linux-gnu/mips64-linux-gnu toolchains both triples produce 32-bit big-endian binaries for MIPS-I by default. Vendors can override the majority of this so it's entirely

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

Hi, I've been having trouble properly resolving an issue with our assembly syntax. The prefix our assembler uses for private local/global labels depends on the object file 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

Vladimir Pouzanov <farcaller at gmail.com> writes: > 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? >> > I've actually tried to compile both LLVM and my lib with -frtti with > same results. Please show the exact commands

> -----Original Message----- > From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] > On Behalf Of Óscar Fuentes > > Vladimir Pouzanov <farcaller at gmail.com> writes: > > > 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

Hi Gents, For those of us with out-of-tree backends which are not 32bit, the msp430 backend is a useful vehicle for examining changes and testing out ideas. So I was wondering about enabling debug output on the MSP430 backend so that I can illustrate a few issues to Adrian and you on the variable pieces side. (there doesn't appear to be any specific person claiming the msp430 code right

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. >

Dear llvm, Recently (approximately a week ago) Clang and LLVM started to failed at building. Assuming it was my incompetence, I cleared everything and started witha fresh checkout (not that I changed it though). 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

Llvm typically doesn't build with RTTI enabled. Perhaps that's what you're running into? Jim On Dec 10, 2012, at 1:27 PM, Vladimir Pouzanov <farcaller at gmail.com> wrote: > 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

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 ---

Hi Peter, Thanks for your response. > On 18 Nov 2019, at 17:44, Peter Smith <peter.smith at linaro.org> wrote: > > On Mon, 18 Nov 2019 at 12:32, Sergej Jaskiewicz via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >> >> There’s this bug: https://bugs.llvm.org/show_bug.cgi?id=38468

On Wed, Oct 3, 2012 at 1:19 AM, Jim Grosbach <grosbach at apple.com> wrote: > What's the use case? the use case is that we can print out the assembly using alternative dialect. currently, on Intel machine, the default dialect is AT&T, and we cannot change that to Intel syntax without using cl:opt. the new public method lets us change the dialect without having cl:opt involved.

What's the use case? On 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

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

Dawie Joubert <djjoubert at csir.co.za> writes: > Recently (approximately a week ago) Clang and LLVM started to failed at > building. Assuming it was my incompetence, I cleared everything and > started witha fresh checkout (not that I changed it though). I am on > Ubuntu 10.04 LTS 64-Bit. And I configure and compile with CMake. > > The error message I get at approximatley

There’s this bug: https://bugs.llvm.org/show_bug.cgi?id=38468. I’ve managed to track it down to a configuration issue. The thing is that in order for libunwind to be usable on ARM Linux, it should be built with the -funwind-tables flag. This flag is conditionally set here: https://github.com/llvm/llvm-project/blob/master/libunwind/CMakeLists.txt#L294, if the compiler “supports” it. However, the

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

I have been looking over AsmPrinter::EmitLinkage (around line 195 of lib\CodeGen\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

> On 18 Nov 2019, at 19:55, Peter Smith <peter.smith at linaro.org> wrote: > > On Mon, 18 Nov 2019 at 15:23, Sergej Jaskiewicz <jaskiewiczs at icloud.com <mailto:jaskiewiczs at icloud.com>> wrote: >> >> Hi Peter, >> >> Thanks for your response. >> >> On 18 Nov 2019, at 17:44, Peter Smith <peter.smith at linaro.org> wrote:

Hi, In the runtime system for GHC Haskell, the stack pointer register is not the same as the one defined by the operating system 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,