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

[John McCall via cfe-commits]

On Sun, Sep 23, 2018 at 5:39 AM David Chisnall via Phabricator <
reviews at reviews.llvm.org> wrote:

> 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).
>

Okay.  I can respect wanting to change the rules on ELF, but it sounds like
we do need to stick with the current section names.  Absent an ABI break to
stop looking for the existing section names, CF will misbehave if they
exist even if we change the compiler output, so effectively those
identifiers are claimed in a way that cannot be incrementally changed.
Wishing otherwise won't make it so.

Also, it's probably correct for CF on non-Darwin OSes to stick to
non-system namespaces anyway.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20180924/be6c2f4d/attachment.html>