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

[Manoj Gupta via cfe-dev]

Thanks everyone,

I have a simple patch to fix the crash but what I don't know if the patch
makes sense.
 I also have no idea what is an _acceptable_ type for
"__CFConstantStringClassReference" when declared in user code. Should this
be checked somewhere earlier
that  "__CFConstantStringClassReference" should be an unsized array if
declared by user code?

--- a/clang/lib/CodeGen/CodeGenModule.cpp
+++ b/clang/lib/CodeGen/CodeGenModule.cpp
@@ -4068,8 +4068,13 @@ CodeGenModule::GetAddrOfConstantCFString(const
StringLiteral *Literal) {
   if (!CFConstantStringClassRef) {
     llvm::Type *Ty = getTypes().ConvertType(getContext().IntTy);
     Ty = llvm::ArrayType::get(Ty, 0);
-    llvm::GlobalValue *GV = cast<llvm::GlobalValue>(
-        CreateRuntimeVariable(Ty, "__CFConstantStringClassReference"));
+    const std::string CFStringRef = "__CFConstantStringClassReference";
+    llvm::GlobalValue *GV =  GetGlobalValue(CFStringRef);
+    if (!GV)
+      GV = cast<llvm::GlobalValue>(
+          CreateRuntimeVariable(Ty, CFStringRef)); //  Ty is [0 x intTy ]
when created by clang.
+    else
+      Ty = GV->getValueType();  // Ok to use the user defined type? Ty =
[12 x i32] for this case.

     if (getTriple().isOSBinFormatCOFF()) {
       IdentifierInfo &II = getContext().Idents.get(GV->getName());

Is it ok to just use the type of user declared variable.  I believe, this
is still error prone since it may not match the expected type by the
following code or future consumers of this Variable (Linker?).
e.g. Clang will still crash if the  code following Ty does not match the
expected type (array of int).

Is it enough to check  if the user defined type is of [ N x intTy]  type.
In this particular case, I see the type as a sizedarray even though no size
was provided by user code:
  _CFConstantStringClassReference = global [12 x i32] zeroinitializer

Thanks,
Manoj

On Fri, Aug 24, 2018 at 4:22 PM John McCall <rjmccall at apple.com> wrote:

> 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> 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
>>
>>   // 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
>>  :
>>
>> 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)  introduced
>> this code.
>>
>> Author:     Rafael Espindola <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@*327993*
>> 91177308-0d34-0410-b5e6-96231b3b80d8
>>
>> Thanks,
>> Manoj
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> 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/e6d47949/attachment.html>