[PATCH] D58724: [gnustep-objc] Make the GNUstep v2 ABI work for Windows DLLs.

[Dustin L. Howett via Phabricator via cfe-commits]

DHowett-MSFT added inline comments.


================
Comment at: clang/lib/CodeGen/CGObjCGNU.cpp:188
 
+  Twine ManglePublicSymbol(StringRef Name) {
+    return StringRef(CGM.getTriple().isOSBinFormatCOFF() ? "$_" : "._") + Name;
----------------
DHowett-MSFT wrote:
> As of the latest revision, this now fails at runtime:
> 
> ```
>   0x01342976 (0x03D8D530 0x03D8DCA0 0x04045A08 0x04045A08), llvm::Twine::str() + 0x166 bytes(s), e:\src\llvm\lib\suppor
>   t\twine.cpp, line 29 + 0x5F byte(s)
>   0x01664F99 (0x03D8D5C4 0x0000000A 0x00000000 0x03D8DCA0), `anonymous namespace'::CGObjCGNUstep2::GetClassVar() + 0xB9
>    bytes(s), e:\src\llvm\tools\clang\lib\codegen\cgobjcgnu.cpp, line 1207 + 0x10 byte(s)
> ```
> 
> I believe we're running afoul of StringRef's lifetime here. I haven't had a chance to dig in.
Alright, I don't completely understand why Twine is the way that it is, but here:

```
  Twine ManglePublicSymbol(StringRef Name)
```

When we construct `Twine(const char*, StringRef)`, the newly-minted Twine contains a _pointer to_ the passed-in StringRef. It's invalid immediately after `ManglePublicSymbol` returns. After a few layers of stack pop off, we end up with random garbage and undefined behavior.

A quick and effective fix is to switch `Name` to be of type `const Twine&`.

```
  Twine ManglePublicSymbol(const Twine& Name)
```

Name ends up being a twine rvalue with a LHSType of cString, and all is right in the world.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58724/new/

https://reviews.llvm.org/D58724