[cfe-dev] Semantics of __CFConstantStringClassReference variable (clang crash in PR38615)

John McCall via cfe-dev cfe-dev at lists.llvm.org
Fri Aug 24 16:22:09 PDT 2018


> On Aug 24, 2018, at 5:17 PM, Richard Smith via cfe-dev <cfe-dev at lists.llvm.org> wrote:
> 
> On Tue, 21 Aug 2018 at 17:09, Manoj Gupta via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote:
> Hi,
> 
> I am looking for some help regarding a clang crash  when building opencflite. The root cause of the crash is because clang tries to create a GlobalValue "__CFConstantStringClassReference"  but a variable of same name is also present in the source file.
> 
> Crash location:
> https://github.com/llvm-mirror/clang/blob/master/lib/CodeGen/CodeGenModule.cpp#L4058 <https://github.com/llvm-mirror/clang/blob/master/lib/CodeGen/CodeGenModule.cpp#L4058>
> 
>   // If we don't already have it, get __CFConstantStringClassReference.
>   if (!CFConstantStringClassRef) {
>     llvm::Type *Ty = getTypes().ConvertType(getContext().IntTy);
>     Ty = llvm::ArrayType::get(Ty, 0);
>     llvm::GlobalValue *GV = cast<llvm::GlobalValue>(
>         CreateRuntimeVariable(Ty, "__CFConstantStringClassReference")); // Crashes here
> 
> Opencflite also declares __CFConstantStringClassReference as a variable, https://github.com/nevali/opencflite/blob/03999700cf3b79975ae2f2e5f4100ea7096acb3a/CFInternal.h#L364 <https://github.com/nevali/opencflite/blob/03999700cf3b79975ae2f2e5f4100ea7096acb3a/CFInternal.h#L364> :
> 
> extern int __CFConstantStringClassReference[];
> 
> I do not know the semantics of the name __CFConstantStringClassReference. Is this a reserved name and should opencflite not be declaring this variable ?
> 
> Yes, this is a reserved identifier and should generally not be declared by user code. (In this case, though, it looks like the code is attempting to find the variable introduced by Clang, and maybe we want to allow that?) In any case, Clang shouldn't crash :)

Well, it's supposed to be an external reference to a symbol defined in the Objective-C library.  In this case, I think opencflite is acting as the Objective-C library that defines that symbol, so it's not illegitimate.  I don't know what's different about Apple's library that it doesn't have this problem — maybe it just doesn't have any CF string literals in the equivalent to this file.

John.


>  
> If so, appreciate any advice on how to fix the offending code. 
> 
> Or is this a  bug in clang?
> 
> For reference, r327993 (https://reviews.llvm.org/rL327993 <https://reviews.llvm.org/rL327993>)  introduced this code.
> 
> Author:     Rafael Espindola <rafael.espindola at gmail.com <mailto:rafael.espindola at gmail.com>>
> AuthorDate: Tue Mar 20 15:48:00 2018 +0000
> 
>     Set dso_local for CFConstantStringClassReference.
>     
>     This one cannot use setGVProperties since it has special logic for
>     when it is dllimport or not.
>     git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@ <https://llvm.org/svn/llvm-project/cfe/trunk@>327993 91177308-0d34-0410-b5e6-96231b3b80d8
> 
> Thanks,
> Manoj
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev <http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180824/ab210431/attachment.html>


More information about the cfe-dev mailing list