[llvm] r221813 - Temporary fix for PR21528 - use mangled C++ function names in COFF debug info to un-break ASan on Windows

[Reid Kleckner]

No, I assume the debugger will display the '\01' character when it
shouldn't. This is the LLVM IR name, and we want to emit the object file
symbol name. The LLVM IR name is "\01 at foo@4", and the object file name is
"@foo at 4". There is no '\01' in the object file.

On Mon, Nov 17, 2014 at 9:54 AM, Timur Iskhodzhanov <timurrrr at google.com>
wrote:

> Wait a sec, the display name *is* correct for \01 at foo@4 (foo) already, so
> this workaround is not needed.  Is that right?
>
>
> On Thu Nov 13 2014 at 1:02:45 AM Reid Kleckner <rnk at google.com> wrote:
>
>> On Wed, Nov 12, 2014 at 12:21 PM, Timur Iskhodzhanov <timurrrr at google.com
>> > wrote:
>>>
>>> -  const StringRef FuncName = getDISubprogram(GV).getDisplayName();
>>> +  StringRef FuncName = getDISubprogram(GV).getDisplayName(),
>>> +            GVName = GV->getName();
>>> +  // FIXME Clang currently sets DisplayName to "bar" for a C++
>>> +  // "namespace_foo::bar" function, see PR21528.  Luckily, dbghelp.dll
>>> is trying
>>> +  // to demangle display names anyways, so let's just put a mangled
>>> name into
>>> +  // the symbols subsection until Clang gives us what we need.
>>> +  if (GVName.startswith("\01?"))
>>> +    FuncName = GVName.substr(1);
>>>
>>
>> Just strip \01 unconditionally, no need to check for ?. Sometimes clang
>> produces names like \01 at foo@4 for this code:
>> extern "C" void __fastcall foo(int x) {}
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141117/53d7f31d/attachment.html>