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

[Kostya Serebryany]

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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120717/626db48f/attachment.html>