[PATCH] D52344: [Clang][CodeGen][ObjC]: Fix non-bridged CoreFoundation builds on ELF targets that use `-fconstant-cfstrings`.

[David Chisnall via Phabricator via cfe-commits]

theraven added a comment.

In https://reviews.llvm.org/D52344#1242530, @rjmccall wrote:

> In https://reviews.llvm.org/D52344#1242451, @kristina wrote:
>
> > Would you be okay with me renaming `cfstring` to `.cfstring` for ELF so it's in line with ELF section naming conventions (I'm not entirely sure if that could cause issues with ObjC stuff)? And yes I think it's best to avoid that code-path altogether if it turns out to be a constant as that's likely from the declaration of the type, I'll write a FileCheck test in a moment and check that I can apply the same logic to ELF aside from the DLL stuff as CoreFoundation needs to export the symbol somehow while preserving the implicit extern attribute for every other TU that comes from the builtin that `CFSTR` expands to. Is what I'm suggesting making sense? If not, let me know, I may be misunderstanding what's happening here.
>
>
> Following the ELF conventions seems like the right thing to do, assuming it doesn't cause compatibility problems.  David Chisnall might know best here.


I don't believe it will have any compatibility issues.  We expose builtins for creating CF- and NSString objects from C code.  For Apple targets, these are equivalent.  For targets that don't care about Objective-C interop, the CF version is sensible because it doesn't introduce any dependencies on an Objective-C runtime.  For code targeting a non-Apple runtime and wanting CF / Foundation interop, the `CFSTR` macro expands to the NS version.

As others have pointed out, the section must be a valid C identifier for the magic `__start_` and `__stop_` symbols to be created.  I don't really like this limitation and it would be nice if we could improve lld (and encourage binutils to do the same) so that `__start_.cfstring` and `__stop_.cfstring` could be used to create symbols pointing to the start and end of a section because it's useful to name things in such a way that they can't conflict with any valid C identifier.  With PE/COFF, we have a mechanism for more precise control and can give sections any names that we want (and also arrange for start and end symbols for subsections).


Repository:
  rC Clang

https://reviews.llvm.org/D52344