<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br><div><div>On Dec 9, 2013, at 12:42 PM, Andrew Trick <<a href="mailto:atrick@apple.com">atrick@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br>On Dec 9, 2013, at 12:01 PM, Eric Christopher <<a href="mailto:echristo@gmail.com">echristo@gmail.com</a>> wrote:<br><br><blockquote type="cite">Out of curiosity why isn't it able to get a compilation dir?<br></blockquote><br>Probably one of these.<br><br> The getcwd() function will fail if:<br><br> [EACCES] Read or search permission was denied for a component of the pathname.<br><br> [ENOENT] A component of the pathname no longer exists.<br><br>Phil might know for sure.<br></div></blockquote><div dir="auto"><br></div><div dir="auto">I'm not sure, actually. ;-) When I hit the bug it was probably ENOENT caused by weirdness in our JSC test harness.</div><div dir="auto"><br></div><div dir="auto">But, broadly, there is no requirement for a client of JavaScriptCore to run with $PWD set to anything remotely sensible. Moreover, it's my understanding that libraries and frameworks in general never assume anything about the sanity of $PWD unless they are asked to do relative path IO. This isn't just a JSC bug: if the claim is that LLVM is a JIT library then it's probably best if LLVM gracefully handles not having a sane $PWD.</div><div dir="auto"><br></div><div dir="auto">-Filip</div><div dir="auto"><br></div><br><blockquote type="cite"><div style="font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br>-Andy<br><br><blockquote type="cite"><br>-eric<br><br>On Mon, Dec 9, 2013 at 11:41 AM, Andrew Trick <<a href="mailto:atrick@apple.com">atrick@apple.com</a>> wrote:<br><blockquote type="cite">MCJIT needs to be able to run in hostile environments, even when PWD<br>is invalid. There's no need to crash MCJIT in this case.<br><br>If we do want to guarantee valid CompilationDir, that should be done<br>only for clients of getCompilationDir(). This is as simple as checking<br>for an empty string.<br><br>The obvious fix is to simply leave MCContext's CompilationDir empty<br>when PWD can't be determined. The only behavioral difference would be<br>that EmitGenDwarfInfo would output an empty string when recording the<br>working dir for the assembly output.<br><br><br>_______________________________________________<br>llvm-commits mailing list<br><a href="mailto:llvm-commits@cs.uiuc.edu">llvm-commits@cs.uiuc.edu</a><br>http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</blockquote></blockquote></div></blockquote></div><br></body></html>