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