Svadev mailing list

[John Criswell <criswell AT illinois.edu>]

On 9/24/12 9:05 PM, Baozeng wrote:
> 2012/9/24 John Criswell 
> <criswell AT illinois.edu>:
>> On 9/24/12 5:31 AM, Baozeng wrote:
>>> Dear John,
>>>
>>> When I tested BBC (mainline) as the following:
>>>  clang -fmemsafety -bbc test/core/buffer-002.c -o buffer
>>>
>>> It reported:
>>>
>>> 'common' global must have a zero initializer!
>>> { [1024 x i8], [1016 x i8], { i32, i32* } }* @array
>>>
>>> I think that is because the linkage is not set correctly.
>>>
>>> The related code is in lib/BaggyBoundsChecks/BaggyBoundsChecks.cpp
>>>
>>>
>>> GlobalVariable *GV_new = new GlobalVariable (*(GV->getParent()),
>>>                                                  newType,
>>>                                                  GV->isConstant(),
>>>                                                  GV->getLinkage(),
>>>                                                  c,
>>>                                                  "baggy." + 
>>> GV->getName());
>>>
>>> Which kind of linkage should be used?  The mainline LLVM has strict type 
>>> checks.
>> Hrm. I think I see the problem. The original global variable (GV) had
>> linkage "common" and had a zero initializer. The BBC pass is creating a
>> new global with an explicit initializer for the bounds information.
>> However, LLVM now requires globals with common linkage to have zero
>> initializers, and so we hit the above assertion.
>>
>> I suspect the reason why common globals must have a zeroinitializer is
>> because they can be merged with other globals from other translation
>> units; requiring them all to have zeroinitialzers ensures that there
>> isn't a case where two globals with the same name in two different
>> translation units gets merged together but have different initializers.
>>
>> I'm not sure what the best solution is to this problem. One solution
>> would be to add the padding but to leave initialization to
>> pool_register_global() at run-time; a special pass in libLTO could
>> reduce run-time overhead by adding the initialization back in and
>> changing pool_register_global() to a special
>> pool_register_global_noinit() that doesn't initialize the padding.
>>
>> Another possibility might be to change the linkage type. I'd see what
>> Clang generates for "int x = 5;" and "extern int x;" when defined a
>> global scope; that might reveal which linkage type to change common to.
>>
> "int x = 5": its IR is : @x = global i32 5, align 4. It has no linkageTypes.

Actually, I think it has ExternalLinkage (external is implied if no
other linkage types are specified).

> "extern int x;" its IR is: @x = external global i32
> "int x;": its IR is @x = common global i32 0, align 4
>
> So we could use if..else statements:
>
> GlobalValue::LinkageTypes LinkTy;
> if (GV->getLinkage() is "common")
>   LinkTy = no linkageTypes;

You should change the above line to set the linkage to ExternalLinkage,
but otherwise, I think you should try this approach and see if it works.

-- John T.

> else
>   LinkTy = GV->getLinkage();
>
> Then when construct the new global variable, we could use LinkTy as
> its LinkageType.
>
>