[llvm-dev] [RFC] Embedding Bitcode in Object Files

James Y Knight via llvm-dev llvm-dev at lists.llvm.org
Fri Feb 5 15:13:14 PST 2016


On Fri, Feb 5, 2016 at 6:06 PM, Steven Wu <stevenwu at apple.com> wrote:

> 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:
>
> $ clang -fembed-bitcode -O0 test.c -c -###
> "clang" "-cc1"  (...lots of options...) "-o" "test.bc" "-x" "c" "test.c"
>   <--- First stage
> "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
>
> 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?
>

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160205/de6fc416/attachment.html>


More information about the llvm-dev mailing list