David Nadlinger
2013-Feb-20 17:27 UTC
[LLVMdev] x86_stdcallcc @<n> mangling vs. '\1' prefix [was: x86_stdcallcc and extra name mangling on Windows]
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
João Matos
2013-Feb-20 19:19 UTC
[LLVMdev] x86_stdcallcc @<n> mangling vs. '\1' prefix [was: x86_stdcallcc and extra name mangling on Windows]
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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130220/0c728458/attachment.html>
Timur Iskhodzhanov
2013-Feb-20 19:25 UTC
[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
Maybe Matching Threads
- [LLVMdev] x86_stdcallcc @<n> mangling vs. '\1' prefix [was: x86_stdcallcc and extra name mangling on Windows]
- [LLVMdev] x86_stdcallcc @<n> mangling vs. '\1' prefix [was: x86_stdcallcc and extra name mangling on Windows]
- [LLVMdev] x86_stdcallcc @<n> mangling vs. '\1' prefix [was: x86_stdcallcc and extra name mangling on Windows]
- [LLVMdev] x86_stdcallcc @<n> mangling vs. '\1' prefix [was: x86_stdcallcc and extra name mangling on Windows]
- [LLVMdev] x86_stdcallcc @<n> mangling vs. '\1' prefix [was: x86_stdcallcc and extra name mangling on Windows]