<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></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 2:50 PM, Eric Christopher <<a href="mailto:echristo@gmail.com">echristo@gmail.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;">On Mon, Dec 9, 2013 at 1:58 PM, Filip Pizlo <<a href="mailto:fpizlo@apple.com">fpizlo@apple.com</a>> wrote:<br><blockquote type="cite"><br>On Dec 9, 2013, at 12:42 PM, Andrew Trick <<a href="mailto:atrick@apple.com">atrick@apple.com</a>> wrote:<br><br><br>On Dec 9, 2013, at 12:01 PM, Eric Christopher <<a href="mailto:echristo@gmail.com">echristo@gmail.com</a>> wrote:<br><br>Out of curiosity why isn't it able to get a compilation dir?<br><br><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<br>of the pathname.<br><br> [ENOENT] A component of the pathname no longer exists.<br><br>Phil might know for sure.<br><br><br>I'm not sure, actually. ;-) When I hit the bug it was probably ENOENT<br>caused by weirdness in our JSC test harness.<br><br>But, broadly, there is no requirement for a client of JavaScriptCore to run<br>with $PWD set to anything remotely sensible. Moreover, it's my<br>understanding that libraries and frameworks in general never assume anything<br>about the sanity of $PWD unless they are asked to do relative path IO. This<br>isn't just a JSC bug: if the claim is that LLVM is a JIT library then it's<br>probably best if LLVM gracefully handles not having a sane $PWD.<br><br></blockquote><br>That's not quite what I'm talking about, FWIW I agree that you<br>shouldn't have to have an environment at all :)<br><br>Basically the lines of code in MCDwarf.cpp are supposed to be when<br>generating dwarf for assembly files and I wasn't under the impression<br>you were compiling .s files. :)<br><br>That code should probably have some decent fallback in it, but I don't<br>think a null DW_AT_compilation_dir is the correct one. It should omit<br>the attribute if it can't get a valid value.<br></div></blockquote><div><br></div><div>You think we should omit the entire compile_unit DIE if we don’t find the absolute path? If we simply omit the DIE, do you think any tools could be confused? Is it worth adding a special case for a situation that cannot conceivably happen in the context of compiling .s files? I’d be happy to simply assert that CompilationDir is non-empty if that’s preferable to emitting a DIE with an empty path.</div><div><br></div><div>-Andy</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>-eric<br><br><br><blockquote type="cite">-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><br>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><a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a></blockquote></div></blockquote></div><br></body></html>