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

[Reid Watson]

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:

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

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