[llvm-commits] [PATCH] AddressSanitizer Initialization Order Checking

Reid Watson reidw at google.com
Wed Jul 18 16:16:55 PDT 2012


Thanks again for reviewing this -- I've implemented the suggested
changes, uploaded to Rietveld(http://codereview.appspot.com/6425049),
and attached the new patches to this email.

I left in the extra check which forces access to global scalar
variables to be implemented.  It remains necessary to catch the first
case in my previous email, and all initialization order problems in
which the value being initialized is some simple type.  If the
performance hit is unacceptable though, then I'd be open to adding an
extra flag to control whether or not to check initialization order on
these types of globals.

All the best,
Reid

On Tue, Jul 17, 2012 at 6:31 AM, Kostya Serebryany <kcc at google.com> wrote:
>
>
> On Sat, Jul 14, 2012 at 12:50 AM, Reid Watson <reidw at google.com> wrote:
>>
>> Ok, I've updated the code to reflect the suggested changes, except for
>> two issues still up in the air.  Once these are solved I'll email out
>> an updated patch.
>>
>> 1. Disabling ClOptGlobals, detecting linker initialized globals
>> The code which disables the optimization of access to global scalar
>> values is necessary for catching cases where the initialization order
>> happens on a dynamically initialized global scalar value.  The
>> following example prints different output depending on the order the
>> input files are given to the compiler, and requires ClOptGlobals to be
>> ignored at one point for this patch to catch it:
>
>
> Consider you have a C++ program
>
>    int A;  // linker-initialized by zero
>    int B = foo();  // initialized at start-up.
>
>    int bar() { return A + B; }
>
> Currently, with ClOptGlobals=1 (i.e. by default) both accesses in bar() are
> ignored.
> With your change, both accesses will be instrumented.
> I think we still need to ignore the access to A.
>
>
>
>>
>>
>> //File x.cpp
>> #incldue <cstdio>
>> extern int y;
>> int f() {
>>     printf("using 'y' (which is %d)\n", y);
>>     return 3*y+7;
>> }
>> int x = f();
>> int main(){}
>>
>> //File y.cpp
>> #include <cstdio>
>> int g() {
>>     puts("initializing 'y'");
>>     return 5;
>> }
>> int y = g();
>>
>> Access to linker initialized globals can still result in
>> initialization order problems.
>> Consider this example, which outputs 42 or 84 depending on the order
>> of arguments to the compiler.
>> //FIle setcode.cpp
>> static int code;
>> int getCode(){ return code;}
>> void setCode(int _code){  code = _code;}
>>
>> //File x.cpp
>> #include <cstdio>
>> void setCode(int);
>> int getCode();
>>
>> int initializeX(){
>>   setCode(42);
>>   return 0;
>> }
>> int x = initializeX();
>>
>> int main() {
>>   printf("getCode returns %d\n", getCode());
>> }
>>
>> //File y.cpp
>> void setCode(int);
>>
>> int initializeY(){
>>   setCode(84);
>>   return 0;
>> }
>>
>> int y = initializeY();
>>
>>
>> 2. Finding the global init function
>> Right now, _GLOBAL__I_a is the hardcoded name of the function which
>> will begin dynamic initialization.  It's possible to add metadata
>> identifying it as that function, but the same hard-coding would still
>> be in place.
>
>
> Ok. Let this name be hardcoded, unless someone else has a better idea.
>
> --kcc
>
>>
>> Thanks,
>> Reid
>>
>> On Fri, Jul 13, 2012 at 10:02 AM, Reid Watson <reidw at google.com> wrote:
>> > Kostya,
>> >
>> > I completely missed that (caught in a poorly written email filter).
>> > Thanks for reviewing it for me, and I'll use rietveld when submitting
>> > the update d version.
>> > I'm looking at the code now, and I'll update when I've implemented the
>> > suggested changes.
>> >
>> > --Reid
>> >
>> > On Fri, Jul 13, 2012 at 4:41 AM, Kostya Serebryany <kcc at google.com>
>> > wrote:
>> >> Reid,
>> >>
>> >> Have you seen my replies to your previous patches?
>> >> http://comments.gmane.org/gmane.comp.compilers.clang.scm/53381
>> >> http://permalink.gmane.org/gmane.comp.compilers.llvm.cvs/116782
>> >>
>> >> --kcc
>> >>
>> >> On Thu, Jul 12, 2012 at 9:19 PM, Reid Watson <reidw at google.com> wrote:
>> >>>
>> >>> Hello,
>> >>>
>> >>> Attached are two patches which add support for detecting
>> >>> initialization order problems in AddressSanitizer.
>> >>> Issues with initialization order are checked by poisoning the shadow
>> >>> memory of global variables which are not guaranteed to have been
>> >>> initialized before each modules initializers run.
>> >>> This approach catches the most obvious issues with initialization
>> >>> order, and correctly ignores access to global variables which should
>> >>> be accessible during initializers (function local statics, etc.).
>> >>>
>> >>> All the best,
>> >>> Reid
>> >>>
>> >>> _______________________________________________
>> >>> llvm-commits mailing list
>> >>> llvm-commits at cs.uiuc.edu
>> >>> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>> >>>
>> >>
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: asan-initialization-order-compilerrt.patch
Type: application/octet-stream
Size: 6235 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120718/9b12aa93/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: asan-initialization-order-llvm.patch
Type: application/octet-stream
Size: 13059 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120718/9b12aa93/attachment-0001.obj>


More information about the llvm-commits mailing list