Semantics of __CFConstantStringClassReference variable (clang crash in PR38615)

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 = castllvm::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 ? 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@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

  • llvm-dev .

Any ideas about the semantics of “__CFConstantStringClassReference” and the best way to fix the clang crash issue.

Thanks,
Manoj

What exactly is failing? The cast to GlobalValue? If so, try stripping casts, as in this existing code:

setDSOLocal(castllvm::GlobalValue(Ret->stripPointerCasts()));

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 = castllvm::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 :slight_smile:

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 = castllvm::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 :slight_smile:

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.

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 = castllvm::GlobalValue(
  • CreateRuntimeVariable(Ty, “__CFConstantStringClassReference”));
  • const std::string CFStringRef = “__CFConstantStringClassReference”;
  • llvm::GlobalValue *GV = GetGlobalValue(CFStringRef);
  • if (!GV)
  • GV = castllvm::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

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?

The type of __CFConstantStringClassReference in user code shouldn’t matter. User code is under no obligation to make it match anything.

IRGen should just leave the declaration alone if it already exists.

John.