Svadev mailing list

[Baozeng <sploving1 AT gmail.com>]

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.
"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;
else
  LinkTy = GV->getLinkage();

Then when construct the new global variable, we could use LinkTy as
its LinkageType.

> -- John T.
>
>>
>> 2012/9/23 Baozeng 
>> <sploving1 AT gmail.com>:
>>> 2012/9/22 John Criswell 
>>> <criswell AT illinois.edu>:
>>>> On 9/21/12 9:58 PM, Baozeng wrote:
>>>>> 2012/9/18 John Criswell 
>>>>> <criswell AT illinois.edu>:
>>>>>> Dear All,
>>>>>>
>>>>>> I'm writing to let everyone know that SAFECode mainline (which works 
>>>>>> with
>>>>>> LLVM mainline) is now ready for development.  All SAFECode developers 
>>>>>> should
>>>>>> submit new patches and commits to mainline SAFECode; we're freezing the
>>>>>> release_30 branch of SAFECode.
>>>>>>
>>>>>> We'll be doing periodic merges with Clang and LLVM mainline to make 
>>>>>> sure we
>>>>>> stay working with the latest and greatest LLVM.  The current plan is 
>>>>>> to make
>>>>>> a release_32 branch of SAFECode when LLVM 3.2 is released.
>>>>>>
>>>>>> Because work on LLVM mainline is on-going, I won't update the web docs 
>>>>>> to
>>>>>> tell people to use mainline yet as we'll get occasional breakage.  
>>>>>> Users who
>>>>>> want something solid should continue using the release_30 branch for 
>>>>>> now;
>>>>>> use mainline SAFECode at your own risk.
>>>>>>
>>>>>> Baozeng, I haven't tested the Baggy Bounds Checking functionality 
>>>>>> you've
>>>>>> added.  When you get a chance, can you please look at it and make sure 
>>>>>> that
>>>>>> the changes are correct?
>>>>>>
>>>>> Okay.
>>>>> I download maintain llvm, poolalloc, and SAFECode
>>>>> and when compiling it, it shows the following error:
>>>>> GCall.cpp:1046: error：‘constructAlignmentFromInt’ is not a member of
>>>>> ‘llvm::Attribute’.
>>>>>
>>>>> I think it should be changed to llvm::Attributes, am I right?
>>>> There was a change to the attributes API that broke compilation of the
>>>> Baggy Bounds instrumentation pass. I fixed it so that it compiles again,
>>>> but I haven't tested it. Can you test it and make sure I didn't break
>>>> anything?
>>>>
>>> Okay.
>>>> I also merged in mainline Clang to bring in fixes to use the new
>>>> attributes API. The build now works for me on Linux.
>>>>
>>>> -- John T.
>>>>
>>>>>> Ott, I've been holding off on your patches until mainline SAFECode 
>>>>>> clang was
>>>>>> ready.  Now that it is, we can begin reviewing your optimization 
>>>>>> patches
>>>>>> again if you'd like.  I think there's one optimization that I need to 
>>>>>> review
>>>>>> since you've submitted changes. I'll take a look at that either today 
>>>>>> or
>>>>>> tomorrow.
>>>>>>
>>>>>> Thanks to John Mainzer for his work on integrating the new mainline 
>>>>>> version
>>>>>> of Clang into SAFECode.
>>>>>>
>>>>>> If anyone has any questions or comments, please feel free to email the 
>>>>>> list.
>>>>>>
>>>>>> -- John T.
>>>>>>
>>>>>
>>>
>>>
>>> --
>>>      Best Regards,
>>>                                                                  Baozeng 
>>> Ding
>>>                                                                  
>>> OSTG,NFS,ISCAS
>>
>>
>



-- 
     Best Regards,
                                                                 Baozeng Ding
                                                                 
OSTG,NFS,ISCAS