[LLVMbugs] [Bug 18248] New: [-cxx-abi microsoft] Mange string literals properly

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Sat Dec 14 03:12:24 PST 2013


http://llvm.org/bugs/show_bug.cgi?id=18248

            Bug ID: 18248
           Summary: [-cxx-abi microsoft] Mange string literals properly
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: david.majnemer at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified

consider:
inline char const *g() {
  static char *b = "\00\00\00";
  static wchar_t const *c = L"\00";
  return c ? 0 : b;
}
const char *h() { return g(); }

MSVC mangles the literal for 'b' as ??_C at _03NOLLCAOD@?$AA?$AA?$AA?$AA@
and the literal for 'c' as ??_C at _13NOLLCAOD@?$AA?$AA?$AA?$AA@

subtracting 'P' from 'NOLLCAOD' for each character and converting to hex yields
0xdebb20e3.

This appears to be a crc:
>>> hex(crcmod.mkCrcFun(0x104C11DB7, initCrc=0xffffffff, rev=True, xorOut=0)("\00\00\00\00"))
'0xdebb20e3L'

Here is my best bet for it's mangling:

<char-type> ::= 0   # char
            ::= 1   # wchar_t
            ::= ??? # char16_t/char32_t will need a mangling too...

<literal-length> ::= <non-negative integer> # the length of the literal

<encoded-crc> ::= <hex digit>+ @ # crc of the literal including null-terminator

<encoded-string> ::= <simple character>      # uninteresting character
                 ::= <hex digit> <hex digit> # these two nibbles encode the
byte for the character

<literal> ::= ?? _C @ _ <char-type> <literal-length> <encoded-crc>
<encoded-string>

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20131214/a25884dc/attachment.html>


More information about the llvm-bugs mailing list