[LLVMdev] Where does LLVM mangle characters from llvm-ir names while generating native code?

Michael Spencer bigcheesegs at gmail.com
Fri Nov 25 21:24:24 PST 2011


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, though--probably because the Darwin assembler supports quoted symbols (i.e. you can enclose an identifier in quotes). Maybe Joe is right, and you should change the LLVM mangler to not mangle '?' chars (if the assembler can handle it). Or maybe we should see if GAS supports quoted symbols (MCAsmInfo::doesAllowQuotesInName()).
>
> Chip

So setting AllowQuotesInName=true gets the correct names in the
output. However, it breaks MinGW. The issue is of course that
MCAsmInfo mixes both assembler and object file format capabilities.
Allowing quoted names has nothing to do with COFF ;/. So it seems we
need a new AsmInfo class for "real" Windows. Any other ideas on how to
implement this?

- Michael Spencer

>>
>> 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 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-
>>>> v128:128:128-a0:0:64-f80:32:32-n8:16:32-S32"
>>>> target triple = "i686-pc-win32"
>>>>
>>>> define i32 @"?heyimacxxfunction@@YAHXZ"() nounwind readnone {
>>>> entry:
>>>> ret i32 42
>>>> }
>>>>
>>>> Note the ?heyimacxxfunction@@YAHXZ. Now if I generate assembly (using
>>>> clang or llc) I get:
>>>>
>>>> $ clang++ -S -O3 mangling.cpp -o - -Xclang -cxx-abi -Xclang microsoft
>>>>      .def     __3F_heyimacxxfunction@@YAHXZ;
>>>>      .scl    2;
>>>>      .type   32;
>>>>      .endef
>>>>      .text
>>>>      .globl  __3F_heyimacxxfunction@@YAHXZ
>>>>      .align  16, 0x90
>>>> __3F_heyimacxxfunction@@YAHXZ:          # @"?heyimacxxfunction@@YAHXZ"
>>>> # BB#0:                                 # %entry
>>>>      movl    $42, %eax
>>>>      ret
>>>>
>>>> It turned the ? into _3F_, and prepended _ someplace. I get the same
>>>> symbol if I use integrated-as to generate an object file.
>>>>
>>>> I've been unable thus far to find out exactly where this occurs. And
>>>> once I do find it, I'm not sure of the correct fix. I assume that LLVM
>>>> mangles the '?' because it means something special in the gas syntax.
>>>> There also has to be a way to communicate to llvm from clang that this
>>>> symbol should not receive a prepended _.
>>> I could swear that when I wrote that code I stuck a '\1' character in front of the name to prevent LLVM's mangler from doing anything to it (see lib/AST/MicrosoftMangle.cpp:162). (I knew the prepending of '_' characters was a problem, but I didn't know LLVM magically transformed chars it doesn't like into _xx_.) That is a magic marker that says "this is the literal name of this symbol, don't mangle it in the usual way."
>>>
>>> It looks like for some reason that the '\1' character isn't getting emitted. I wish I had an answer for you, but I can't debug this because I don't run Windows. Works fine for me here on Mac. Running your command to generate LLVM IR, I get:
>>>
>>> ; ModuleID = 'mangling.cpp'
>>> target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:128:128-n8:16:32-S128"
>>> target triple = "i386-apple-macosx10.6.8"
>>>
>>> define i32 @"\01?heyimacxxfunction@@YAHXZ"() nounwind readnone ssp {
>>> ret i32 42
>>> }
>>>
>>> Note the '\01'.
>>>
>>> Chip
>>>
>>>>
>>>> Thanks,
>>>>
>>>> - Michael Spencer
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>
>
>




More information about the llvm-dev mailing list