Benoit Belley
2014-Dec-10 17:15 UTC
[LLVMdev] [PATCH] MCJIT/ELF should support MSVC C++ mangled symbols
Hi everyone, We have found a problem while using the MCJIT engine on Windows. Our jitted code is invoking some external C++ functions. These external functions have names that are mangled using the MSVC C++ naming convention. These were not handled properly by the ELObjectWriter. The attached patch addresses this issue. The patch is against the LLVM release_35 branch (Revision 223459). The patch also includes a regression test. We have successfully ran all LLVM & Clang regression tests after applying the patch on both Debug+Assert and Release builds. Regards, Benoit ------ The ELF format is used on Windows by the MCJIT engine. Thus, on Windows, the ELFObjectWriter can encounter symbols mangled using the MS Visual Studio C++ name mangling. Symbols mangled using the MSVC C++ name mangling can legally have "@@@" as a substring. The EFLObjectWriter should not interpret the "@@@" substring as specifying GNU-style symbol versioning. The ELFObjectWriter therefore check for the MSVC C++ name mangling prefix which is either "?", "@?", "__imp_?" or "__imp_?@". --- lib/MC/ELFObjectWriter.cpp | 38 +++++++++++++++++++++++------ test/MC/ELF/symver-msvc.s | 60 ++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 91 insertions(+), 7 deletions(-) create mode 100644 test/MC/ELF/symver-msvc.s diff --git a/lib/MC/ELFObjectWriter.cpp b/lib/MC/ELFObjectWriter.cpp index 5779b27..9fddca5 100644 --- a/lib/MC/ELFObjectWriter.cpp +++ b/lib/MC/ELFObjectWriter.cpp @@ -1051,14 +1051,38 @@ ELFObjectWriter::computeSymbolTable(MCAssembler &Asm, const MCAsmLayout &Layout, // The @@@ in symbol version is replaced with @ in undefined symbols and // @@ in defined ones. + // + // We have to be careful though: + // + // The ELF format is used on Windows by the MCJIT engine. Thus, on + // Windows, the ELFObjectWriter can encounter symbols mangled using the MS + // Visual Studio C++ name mangling. Symbols mangled using the MSVC C++ + // name mangling can legally have "@@@" as a sub-string. The + // EFLObjectWriter should not interpret the "@@@" sub-string as specifying + // GNU-style symbol versioning. The ELFObjectWriter therefore check for + // the MSVC C++ name mangling prefix which is either "?", "@?", "__imp_?" + // or "__imp_@?". + // + // It would have been interesting to be able to perform this ms mangling + // prefix check only when the target triple is of the form *-pc-windows-elf + // but it seems that this information is not easily accessible from the + // ELFObjectWriter. StringRef Name = Symbol.getName(); - SmallString<32> Buf; - size_t Pos = Name.find("@@@"); - if (Pos != StringRef::npos) { - Buf += Name.substr(0, Pos); - unsigned Skip = MSD.SectionIndex == ELF::SHN_UNDEF ? 2 : 1; - Buf += Name.substr(Pos + Skip); - Name = Buf; + if ( !Name.startswith("?") + && !Name.startswith("@?") + && !Name.startswith("__imp_?") + && !Name.startswith("__imp_@?")) { + // This symbol isn't following the MSVC C++ name mangling convention. We + // can thus safely interpret the @@@ in symbol names as specifying + // symbol versioning. + SmallString<32> Buf; + size_t Pos = Name.find("@@@"); + if (Pos != StringRef::npos) { + Buf += Name.substr(0, Pos); + unsigned Skip = MSD.SectionIndex == ELF::SHN_UNDEF ? 2 : 1; + Buf += Name.substr(Pos + Skip); + Name = Buf; + } } MSD.Name = StrTabBuilder.add(Name); diff --git a/test/MC/ELF/symver-msvc.s b/test/MC/ELF/symver-msvc.s new file mode 100644 index 0000000..4a40791 --- /dev/null +++ b/test/MC/ELF/symver-msvc.s @@ -0,0 +1,60 @@ +// RUN: llvm-mc -filetype=obj -triple x86_64-pc-windows-elf %s -o - | llvm-readobj -r -t | FileCheck %s + +// Verify that MSVC C++ mangled symbol are not affected by the +// ELF symbol versioning. The ELF format is used on Windows by the +// MCJIT execution engine. + + + .long "??_R0?AVexception at std@@@8" + .long "@??_R0?AVinvalid_argument at std@@@8" + .long "__imp_??_R0?AVlogic_error at std@@@8" + .long "__imp_@??_R0PAVexception at std@@@8" + + +// CHECK: Relocations [ +// CHECK-NEXT: Section (2) .rela.text { +// CHECK-NEXT: 0x0 R_X86_64_32 ??_R0?AVexception at std@@@8 0x0 +// CHECK-NEXT: 0x4 R_X86_64_32 @??_R0?AVinvalid_argument at std@@@8 0x0 +// CHECK-NEXT: 0x8 R_X86_64_32 __imp_??_R0?AVlogic_error at std@@@8 0x0 +// CHECK-NEXT: 0xC R_X86_64_32 __imp_@??_R0PAVexception at std@@@8 0x0 +// CHECK-NEXT: } +// CHECK-NEXT: ] + +// CHECK: Symbols [ +// CHECK: Symbol { +// CHECK: Name: ??_R0?AVexception at std@@@8 (102) +// CHECK-NEXT: Value: 0x0 +// CHECK-NEXT: Size: 0 +// CHECK-NEXT: Binding: Global (0x1) +// CHECK-NEXT: Type: None (0x0) +// CHECK-NEXT: Other: 0 +// CHECK-NEXT: Section: Undefined (0x0) +// CHECK-NEXT: } +// CHECK-NEXT: Symbol { +// CHECK-NEXT: Name: @??_R0?AVinvalid_argument at std@@@8 (1) +// CHECK-NEXT: Value: 0x0 +// CHECK-NEXT: Size: 0 +// CHECK-NEXT: Binding: Global (0x1) +// CHECK-NEXT: Type: None (0x0) +// CHECK-NEXT: Other: 0 +// CHECK-NEXT: Section: Undefined (0x0) +// CHECK-NEXT: } +// CHECK-NEXT: Symbol { +// CHECK-NEXT: Name: __imp_??_R0?AVlogic_error at std@@@8 (35) +// CHECK-NEXT: Value: 0x0 +// CHECK-NEXT: Size: 0 +// CHECK-NEXT: Binding: Global (0x1) +// CHECK-NEXT: Type: None (0x0) +// CHECK-NEXT: Other: 0 +// CHECK-NEXT: Section: Undefined (0x0) +// CHECK-NEXT: } +// CHECK-NEXT: Symbol { +// CHECK-NEXT: Name: __imp_@??_R0PAVexception at std@@@8 (69) +// CHECK-NEXT: Value: 0x0 +// CHECK-NEXT: Size: 0 +// CHECK-NEXT: Binding: Global (0x1) +// CHECK-NEXT: Type: None (0x0) +// CHECK-NEXT: Other: 0 +// CHECK-NEXT: Section: Undefined (0x0) +// CHECK-NEXT: } +// CHECK-NEXT: ] -- 1.8.4.2 Benoit Belley Sr Principal Developer M&E-Product Development Group MAIN +1 514 393 1616 DIRECT +1 438 448 6304 FAX +1 514 393 0110 Twitter<http://twitter.com/autodesk> Facebook<https://www.facebook.com/Autodesk> Autodesk, Inc. 10 Duke Street Montreal, Quebec, Canada H3C 2L7 www.autodesk.com<http://www.autodesk.com/> [Description: Email_Signature_Logobar] -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141210/5901b7c9/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: 350F40DB-4457-4455-A632-0DF05738AF15[6].png Type: image/png Size: 4316 bytes Desc: 350F40DB-4457-4455-A632-0DF05738AF15[6].png URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141210/5901b7c9/attachment.png>