llvm dev - Feb 2013 - [LLVMdev] x86_stdcallcc @<n> mangling vs. '\1' prefix [was: x86_stdcallcc and extra name mangling on Windows]

I don't remember anything other that what I've written in the bug João
has mentioned.

Probably something like this patch
http://llvm.org/bugs/show_bug.cgi?id=14410#c6
?

2013/2/20 João Matos <ripzonetriton at gmail.com>:
> I think so. There have been other reports lately related to this being
> wrong.
>
> http://llvm.org/bugs/show_bug.cgi?id=14410
>
> CC'ing Timur since he might know more about this.
>
> On Wed, Feb 20, 2013 at 5:27 PM, David Nadlinger <code at
klickverbot.at>
> wrote:
>>
>> On Tue, Feb 19, 2013 at 2:13 PM, Duncan Sands <baldrick at
free.fr> wrote:
>> >> My question: Is there an easy way of disabling the
name-mangling part
>> >> but keep the rest of the CC that I missed?
>> > if you use "\1" + "usual name", it will
disable name mangling if you are
>> > lucky.  A leading \1 is LLVM's way of saying: leave this name
alone!
>>
>> Seems like I'm out of luck - the @<n> suffix is added
>> (AddFastCallStdCallSuffix) in the GlobalValue
>> Magnler::getNameWithPrefix overload, without paying respect to whether
>> the name originally had a '\1' prefix or not.
>>
>> Should this be changed?
>>
>> David
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
>
> --
> João Matos

On Wed, Feb 20, 2013 at 8:25 PM, Timur Iskhodzhanov <timurrrr at
google.com> wrote:
> I don't remember anything other that what I've written in the bug
João
> has mentioned.
>
> Probably something like this patch
> http://llvm.org/bugs/show_bug.cgi?id=14410#c6
> ?
My problem is not related to correctly implementing the MS
stdcall/fastcall ABI itself, but rather a (sufficiently) similar one.
Thus, I need to specifically disable mangling in a case where it would
normally be needed.

For the quick-and-dirty patch I'm currently using locally, see below.

David


diff --git a/lib/Target/Mangler.cpp b/lib/Target/Mangler.cpp
index edfd421..e4b6368 100644
--- a/lib/Target/Mangler.cpp
+++ b/lib/Target/Mangler.cpp
@@ -185,9 +185,12 @@ void
Mangler::getNameWithPrefix(SmallVectorImpl<char> &OutName,
     PrefixTy = Mangler::Private;
   else if (GV->hasLinkerPrivateLinkage() ||
GV->hasLinkerPrivateWeakLinkage())
     PrefixTy = Mangler::LinkerPrivate;
-
+
+  bool skipMangling = false;
+
   // If this global has a name, handle it simply.
   if (GV->hasName()) {
+    skipMangling = (GV->getName()[0] == '\1');
     getNameWithPrefix(OutName, GV->getName(), PrefixTy);
   } else {
     // Get the ID for the global, assigning a new one if we haven't got one
@@ -201,7 +204,7 @@ void
Mangler::getNameWithPrefix(SmallVectorImpl<char> &OutName,

   // If we are supposed to add a microsoft-style suffix for stdcall/fastcall,
   // add it.
-  if (Context.getAsmInfo().hasMicrosoftFastStdCallMangling()) {
+  if (!skipMangling &&
Context.getAsmInfo().hasMicrosoftFastStdCallMangling()) {
     if (const Function *F = dyn_cast<Function>(GV)) {
       CallingConv::ID CC = F->getCallingConv();

The patch looks incorrect. The code just needs to handle \1 properly
and clang extended to add explicit \1 to the names which does not
require mangling.

I do not think that moving whole mangling to clang is a good idea,
because then everyone who uses LLVM to call WinApi functions will need
to mangle by hands.

On Wed, Feb 20, 2013 at 11:25 PM, Timur Iskhodzhanov
<timurrrr at google.com> wrote:
> I don't remember anything other that what I've written in the bug
João
> has mentioned.
>
> Probably something like this patch
> http://llvm.org/bugs/show_bug.cgi?id=14410#c6
> ?
>
> 2013/2/20 João Matos <ripzonetriton at gmail.com>:
>> I think so. There have been other reports lately related to this being
>> wrong.
>>
>> http://llvm.org/bugs/show_bug.cgi?id=14410
>>
>> CC'ing Timur since he might know more about this.
>>
>> On Wed, Feb 20, 2013 at 5:27 PM, David Nadlinger <code at
klickverbot.at>
>> wrote:
>>>
>>> On Tue, Feb 19, 2013 at 2:13 PM, Duncan Sands <baldrick at
free.fr> wrote:
>>> >> My question: Is there an easy way of disabling the
name-mangling part
>>> >> but keep the rest of the CC that I missed?
>>> > if you use "\1" + "usual name", it will
disable name mangling if you are
>>> > lucky.  A leading \1 is LLVM's way of saying: leave this
name alone!
>>>
>>> Seems like I'm out of luck - the @<n> suffix is added
>>> (AddFastCallStdCallSuffix) in the GlobalValue
>>> Magnler::getNameWithPrefix overload, without paying respect to
whether
>>> the name originally had a '\1' prefix or not.
>>>
>>> Should this be changed?
>>>
>>> David
>>> _______________________________________________
>>> LLVM Developers mailing list
>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>>
>>
>> --
>> João Matos
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


--
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

2013/2/21 Anton Korobeynikov <anton at
korobeynikov.info>:
> The patch looks incorrect. The code just needs to handle \1 properly
> and clang extended to add explicit \1 to the names which does not
> require mangling.
I think clang already adds \01 to __stdcall names, so only the LLVM
change is remaining.
> I do not think that moving whole mangling to clang is a good idea,
> because then everyone who uses LLVM to call WinApi functions will need
> to mangle by hands.
I agree.
> On Wed, Feb 20, 2013 at 11:25 PM, Timur Iskhodzhanov
> <timurrrr at google.com> wrote:
>> I don't remember anything other that what I've written in the
bug João
>> has mentioned.
>>
>> Probably something like this patch
>> http://llvm.org/bugs/show_bug.cgi?id=14410#c6
>> ?
>>
>> 2013/2/20 João Matos <ripzonetriton at gmail.com>:
>>> I think so. There have been other reports lately related to this
being
>>> wrong.
>>>
>>> http://llvm.org/bugs/show_bug.cgi?id=14410
>>>
>>> CC'ing Timur since he might know more about this.
>>>
>>> On Wed, Feb 20, 2013 at 5:27 PM, David Nadlinger <code at
klickverbot.at>
>>> wrote:
>>>>
>>>> On Tue, Feb 19, 2013 at 2:13 PM, Duncan Sands <baldrick at
free.fr> wrote:
>>>> >> My question: Is there an easy way of disabling the
name-mangling part
>>>> >> but keep the rest of the CC that I missed?
>>>> > if you use "\1" + "usual name", it
will disable name mangling if you are
>>>> > lucky.  A leading \1 is LLVM's way of saying: leave
this name alone!
>>>>
>>>> Seems like I'm out of luck - the @<n> suffix is added
>>>> (AddFastCallStdCallSuffix) in the GlobalValue
>>>> Magnler::getNameWithPrefix overload, without paying respect to
whether
>>>> the name originally had a '\1' prefix or not.
>>>>
>>>> Should this be changed?
>>>>
>>>> David
>>>> _______________________________________________
>>>> LLVM Developers mailing list
>>>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>
>>>
>>>
>>>
>>> --
>>> João Matos
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
> --
> With best regards, Anton Korobeynikov
> Faculty of Mathematics and Mechanics, Saint Petersburg State University

Anton, what do you think of David's patch with this test case?  OK to
commit that?


On Wed, Feb 20, 2013 at 12:43 PM, Anton Korobeynikov <
anton at korobeynikov.info> wrote:
> The patch looks incorrect. The code just needs to handle \1 properly
> and clang extended to add explicit \1 to the names which does not
> require mangling.
>
> I do not think that moving whole mangling to clang is a good idea,
> because then everyone who uses LLVM to call WinApi functions will need
> to mangle by hands.
>
> On Wed, Feb 20, 2013 at 11:25 PM, Timur Iskhodzhanov
> <timurrrr at google.com> wrote:
> > I don't remember anything other that what I've written in the
bug João
> > has mentioned.
> >
> > Probably something like this patch
> > http://llvm.org/bugs/show_bug.cgi?id=14410#c6
> > ?
> >
> > 2013/2/20 João Matos <ripzonetriton at gmail.com>:
> >> I think so. There have been other reports lately related to this
being
> >> wrong.
> >>
> >> http://llvm.org/bugs/show_bug.cgi?id=14410
> >>
> >> CC'ing Timur since he might know more about this.
> >>
> >> On Wed, Feb 20, 2013 at 5:27 PM, David Nadlinger <code at
klickverbot.at>
> >> wrote:
> >>>
> >>> On Tue, Feb 19, 2013 at 2:13 PM, Duncan Sands <baldrick at
free.fr>
> wrote:
> >>> >> My question: Is there an easy way of disabling the
name-mangling
> part
> >>> >> but keep the rest of the CC that I missed?
> >>> > if you use "\1" + "usual name", it
will disable name mangling if you
> are
> >>> > lucky.  A leading \1 is LLVM's way of saying: leave
this name alone!
> >>>
> >>> Seems like I'm out of luck - the @<n> suffix is
added
> >>> (AddFastCallStdCallSuffix) in the GlobalValue
> >>> Magnler::getNameWithPrefix overload, without paying respect to
whether
> >>> the name originally had a '\1' prefix or not.
> >>>
> >>> Should this be changed?
> >>>
> >>> David
> >>> _______________________________________________
> >>> LLVM Developers mailing list
> >>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >>
> >>
> >>
> >>
> >> --
> >> João Matos
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
> --
> With best regards, Anton Korobeynikov
> Faculty of Mathematics and Mechanics, Saint Petersburg State University
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130328/0cbd0785/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: stdcall-double-mangle.patch
Type: application/octet-stream
Size: 2505 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130328/0cbd0785/attachment.obj>