similar to: [LLVMdev] Print Global Prefix Issue

> Hey, > > I have an odd problem with printing prefixed global symbols in my > AsmPrinter. > > In my MCAsmInfo subclass implementation, I set > > GlobalPrefix = "%"; > > > because my assembler needs this to avoid name collisions. > Now, whenever a global symbol (be it a label, mbb operand ,etc.) gets > printed, it is encapsulated in quotes.

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

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 | 11 +++++++---- 3 files changed, 15 insertions(+),

So GlobalPrefix is set to "_", which is fine but I want to exclude external library calls from that (I don't want the prefix on library routines), for example, something like __subsf3. What's the best way to do this? On Wed, Feb 27, 2013 at 11:05 AM, Ryan Taylor <ryta1203 at gmail.com> wrote: > I'd like to set all Global Symbols to be prefixed with '_' ;

I'd like to set all Global Symbols to be prefixed with '_' ; however, when I set GlobalPrefix in TargetMCAsmInfo.cpp, this also applies to library calls (adds extra underscore which makes 3 so linkage failure), which I don't want. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL:

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

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.

On Fri, Nov 25, 2011 at 1:47 PM, Charles Davis <cdavis at mymail.mines.edu> wrote: > > On Nov 25, 2011, at 2:22 PM, bigcheesegs at gmail.com wrote: > >> In the case I posted I had removed that line, however, you still get the __3F_ in the generated assembly with it. > Huh. It only seems to happen with a Windows triple or a Linux triple. Doesn't happen with a Mac triple,

On Nov 25, 2011, at 2:22 PM, bigcheesegs at gmail.com wrote: > In the case I posted I had removed that line, however, you still get the __3F_ in the generated assembly with it. Huh. It only seems to happen with a Windows triple or a Linux triple. Doesn't happen with a Mac triple, though--probably because the Darwin assembler supports quoted symbols (i.e. you can enclose an identifier in

In the case I posted I had removed that line, however, you still get the __3F_ in the generated assembly with it. Sent from my iPhone On Nov 25, 2011, at 2:15 PM, Charles Davis <cdavis at mymail.mines.edu> wrote: > > On Nov 25, 2011, at 8:39 AM, Michael Spencer wrote: > >> So I was taking a look at Microsoft C++ ABI support while on vacation, >> and ran into a major

Hi, I'm doing a backend port and I'm having trouble with adds that have negative immediates. My architecture only has instructions for subtracting and adding 8bit immediate values (they will be zero-extended, thus unsigned). Bigger immediates have to be moved in a register first. The problem is: Expressions like "b - 1" result in "add nsw i32 %b, -1" in LLVM IR. They

So I was taking a look at Microsoft C++ ABI support while on vacation, and ran into a major issue. Given the following llvm-ir: $ clang++ -S -emit-llvm -O3 mangling.cpp -o - -Xclang -cxx-abi -Xclang microsoft ; ModuleID = 'mangling.cpp' target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-f80:128:128-v64:64:64-

Looks to me like it converted the ? into the ascii hexadecimal representation _3F_. I don't think another underscore was pre-pended. This is probably thanks to lib/Target/Mangler.cpp. You'll want to let ? be treated as an acceptable character. static bool isAcceptableChar(char C, bool AllowPeriod) { if ((C < 'a' || C > 'z') && (C < 'A'

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

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

> 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

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

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

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