[cfe-dev] Semantics of __CFConstantStringClassReference variable (clang crash in PR38615)
John McCall via cfe-dev
cfe-dev at lists.llvm.org
Fri Aug 24 17:21:37 PDT 2018
> On Aug 24, 2018, at 7:28 PM, Manoj Gupta <manojgupta at google.com> wrote:
> 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.
> --- 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 <mailto:rjmccall at apple.com>> wrote:
>> On Aug 24, 2018, at 5:17 PM, Richard Smith via cfe-dev <cfe-dev at lists.llvm.org <mailto: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/2210e1aa/attachment.html>
More information about the cfe-dev
mailing list