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.
// 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
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.
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.
// 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
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
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.
// 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
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.
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?
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
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.
