<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 5, 2016 at 6:06 PM, Steven Wu <span dir="ltr"><<a href="mailto:stevenwu@apple.com" target="_blank">stevenwu@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div class="h5"><span style="color:rgb(34,34,34)">I don't think we need any path in the command line section. We only record the command-line options that will affect CodeGen. See my example in one of the preview reply:</span><br></div></div><div><span class=""><blockquote type="cite">$ clang -fembed-bitcode -O0 test.c -c -###<br>"clang" "-cc1"  (...lots of options...) "-o" "test.bc" "-x" "c" "test.c"   <--- First stage<br>"clang" "-cc1" "-triple" "x86_64-apple-macosx10.11.0" "-emit-obj" "-fembed-bitcode" "-O0" "-disable-llvm-optzns" "-o" "test.o" "-x" "ir" "test.bc"  <--- Second stage</blockquote></span>I can't think of any source path that can affect CodeGen. There should not be any paths other than the bitcode input path and binary output path exists in the second stage and they are excluded from the command line section as well. -fdebug-prefix-map is consumed by the front-end and prefixed paths are a part of the debug info in the metadata. You don't need to encode -fdebug-prefix-map in the bitcode section to reproduce the object file with the same debug info. Did that answer your concern?</div><div></div></div></blockquote></div><br></div><div class="gmail_extra">Great -- it wasn't clear from the first message if you were just embedding the whole command-line as is. If the plan instead to embed only a few relevant options, I agree there should be no issue as far as paths go.</div></div>