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

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

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

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