Svadev mailing list

[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.

-- 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
>
>