x86_stdcallcc @<n> mangling vs. '\1' prefix [was: x86_stdcallcc and extra name mangling on Windows]

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

x86_stdcallcc @<n> mangling vs. '\1' prefix [was: x86_stdcallcc and extra name mangling on Windows]

David Nadlinger-2
On Tue, Feb 19, 2013 at 2:13 PM, Duncan Sands <[hidden email]> 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
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: x86_stdcallcc @<n> mangling vs. '\1' prefix [was: x86_stdcallcc and extra name mangling on Windows]

João Matos
I think so. There have been other reports lately related to this being wrong.


CC'ing Timur since he might know more about this.

On Wed, Feb 20, 2013 at 5:27 PM, David Nadlinger <[hidden email]> wrote:
On Tue, Feb 19, 2013 at 2:13 PM, Duncan Sands <[hidden email]> 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
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev



--
João Matos

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: x86_stdcallcc @<n> mangling vs. '\1' prefix [was: x86_stdcallcc and extra name mangling on Windows]

Timur Iskhodzhanov
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 <[hidden email]>:

> 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 <[hidden email]>
> wrote:
>>
>> On Tue, Feb 19, 2013 at 2:13 PM, Duncan Sands <[hidden email]> 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
>> [hidden email]         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
>
>
> --
> João Matos

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: x86_stdcallcc @<n> mangling vs. '\1' prefix [was: x86_stdcallcc and extra name mangling on Windows]

David Nadlinger-2
On Wed, Feb 20, 2013 at 8:25 PM, Timur Iskhodzhanov <[hidden email]> 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();

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: x86_stdcallcc @<n> mangling vs. '\1' prefix [was: x86_stdcallcc and extra name mangling on Windows]

Anton Korobeynikov-2
In reply to this post by Timur Iskhodzhanov
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
<[hidden email]> 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 <[hidden email]>:
>> 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 <[hidden email]>
>> wrote:
>>>
>>> On Tue, Feb 19, 2013 at 2:13 PM, Duncan Sands <[hidden email]> 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
>>> [hidden email]         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>>
>>
>> --
>> João Matos
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         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
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: x86_stdcallcc @<n> mangling vs. '\1' prefix [was: x86_stdcallcc and extra name mangling on Windows]

Timur Iskhodzhanov
2013/2/21 Anton Korobeynikov <[hidden email]>:
> 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
> <[hidden email]> 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 <[hidden email]>:
>>> 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 <[hidden email]>
>>> wrote:
>>>>
>>>> On Tue, Feb 19, 2013 at 2:13 PM, Duncan Sands <[hidden email]> 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
>>>> [hidden email]         http://llvm.cs.uiuc.edu
>>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>>
>>>
>>>
>>>
>>> --
>>> João Matos
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> [hidden email]         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
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: x86_stdcallcc @<n> mangling vs. '\1' prefix [was: x86_stdcallcc and extra name mangling on Windows]

Timur Iskhodzhanov
2013/2/22 Timur Iskhodzhanov <[hidden email]>:
> 2013/2/21 Anton Korobeynikov <[hidden email]>:
>> 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.
... and LLVM drops \01 in getNameWithPrefixat lib/Target/Mangler.cpp:116
right before returning the rest in OutName.

Ahh you were replying to me, not to David.
How does David's patch look to you?
_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: x86_stdcallcc @<n> mangling vs. '\1' prefix [was: x86_stdcallcc and extra name mangling on Windows]

Reid Kleckner-2
In reply to this post by Anton Korobeynikov-2
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 <[hidden email]> 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
<[hidden email]> 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 <[hidden email]>:
>> 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 <[hidden email]>
>> wrote:
>>>
>>> On Tue, Feb 19, 2013 at 2:13 PM, Duncan Sands <[hidden email]> 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
>>> [hidden email]         http://llvm.cs.uiuc.edu
>>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>>
>>
>> --
>> João Matos
>
> _______________________________________________
> LLVM Developers mailing list
> [hidden email]         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
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

stdcall-double-mangle.patch (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: x86_stdcallcc @<n> mangling vs. '\1' prefix [was: x86_stdcallcc and extra name mangling on Windows]

Timur Iskhodzhanov
Looks good to me, except for
  ; CHECK: MyFunc@0:
should be probably
  ; CHECK: {{^_MyFunc@0:}}
and
+; CHECK: alreadyMangled:
should be
+; CHECK: {{^alreadyMangled:}}

2013/3/28 Reid Kleckner <[hidden email]>:

> 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
> <[hidden email]> 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
>> <[hidden email]> 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 <[hidden email]>:
>> >> 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 <[hidden email]>
>> >> wrote:
>> >>>
>> >>> On Tue, Feb 19, 2013 at 2:13 PM, Duncan Sands <[hidden email]>
>> >>> 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
>> >>> [hidden email]         http://llvm.cs.uiuc.edu
>> >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> João Matos
>> >
>> > _______________________________________________
>> > LLVM Developers mailing list
>> > [hidden email]         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
>> [hidden email]         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>

_______________________________________________
LLVM Developers mailing list
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Reply | Threaded
Open this post in threaded view
|

Re: x86_stdcallcc @<n> mangling vs. '\1' prefix [was: x86_stdcallcc and extra name mangling on Windows]

Anton Korobeynikov-2
In reply to this post by Reid Kleckner-2
Reid,

I believe I had some concerns over the patch... Let me find / resurrect them :)

On Fri, Mar 29, 2013 at 4:12 AM, Reid Kleckner <[hidden email]> wrote:

> 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
> <[hidden email]> 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
>> <[hidden email]> 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 <[hidden email]>:
>> >> 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 <[hidden email]>
>> >> wrote:
>> >>>
>> >>> On Tue, Feb 19, 2013 at 2:13 PM, Duncan Sands <[hidden email]>
>> >>> 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
>> >>> [hidden email]         http://llvm.cs.uiuc.edu
>> >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> João Matos
>> >
>> > _______________________________________________
>> > LLVM Developers mailing list
>> > [hidden email]         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
>> [hidden email]         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
[hidden email]         http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev