<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Alex,<div><br></div><div>I think finding a superset of globals that will end up in the "__cstring" section and not adding red zones to them is reasonable. You might be able to factor out the code that makes the decision but does not involve TargetMachine (ex: some of TargetLoweringObjectFile::getKindForGlobal). These are all constants anyway, so we are only loosing checks for invalid reads, not invalid writes.</div><div><br></div><div>There might be other, better solutions; I am not sure..</div><div><br></div><div>Cheers,</div><div>Anna.</div><div><div style="margin: 0px; font-family: Menlo; color: rgb(79, 129, 135);"><br></div><div style="margin: 0px; font-family: Menlo; color: rgb(79, 129, 135);"><span style="color: #000000"><br></span></div><div><div>On Mar 21, 2013, at 12:03 PM, Nick Kledzik <<a href="mailto:kledzik@apple.com">kledzik@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;">Alexander,<br><br>On Darwin the "__cstring" section (really section with type S_CSTRING_LITERAL) is defined to contain zero terminate strings of bytes that the linker can merge and re-order. If you want pad bytes before and after the string, you need to put the strings in a different section (e.g. __TEXT, __const).<br><br>But, CF/NSString literals will be problematic. The compiler emits a static NS/CFString object into a data section. That object contains a pointer to its "backing" utf8 or utf16 string literal. The linker coalesce the NS/CFString objects (so that two translation units that define @"hello" will wind up using the same object). But to tell if two CF/NSString objects are the same, the linker must compare the string literal they point to. And in that check is an assertion that the string is in a __cstring or __ustring (utf16) section. So, putting the backing string for a CF/NSString into another section will cause a linker assertion.<br><br>-Nick<br><br><br>On Mar 21, 2013, at 7:05 AM, Alexander Potapenko <<a href="mailto:glider@google.com">glider@google.com</a>> wrote:<br><blockquote type="cite">(forgot to CC llvmdev)<br><br>On Thu, Mar 21, 2013 at 5:54 PM, Alexander Potapenko <<a href="mailto:glider@google.com">glider@google.com</a>> wrote:<br><blockquote type="cite">Hey Anna, Nick, Ted,<br><br>We've the following problem with string literals under ASan on Mac.<br>Some global string constants end up being put into the .cstring<br>section, for which the following rules apply:<br>- the strings can't contain zeroes in their bodies<br>- the link editor places only one copy of each literal into the<br>output file's section<br><br>ASan usually instruments the globals by adding redzones to the end of<br>them and creating a structure that contains the size of a global with<br>and without the redzone.<br>For the aforementioned strings the linker will delete the redzones,<br>but leave that structure untouched, which will lead to corrupt shadow<br>memory at run time.<br><br>Unfortunately at instrumentation time we can't tell for sure whether<br>the string constant will be put into the .cstring section or not - the<br>decision is taken at lowering time.<br><a href="https://code.google.com/p/address-sanitizer/issues/detail?id=171">https://code.google.com/p/address-sanitizer/issues/detail?id=171</a><br>contains the writeup of the problem and a couple of suggestions on how<br>it can be solved. But we aren't sure that any of the solutions is<br>correct.<br>I wonder if it's at all possible to understand that a given string<br>constant is going to end up in a mergeable section. Otherwise, is it<br>possible to make every string literal live in a non-mergeable section<br>by setting the section name explicitly?<br><br>TIA,<br>Alex</blockquote></blockquote></div></blockquote></div><br></div></body></html>