[PATCH] Add an LTO interface to parse metadata and extract linker options

Yunzhong Gao Yunzhong_Gao at playstation.sony.com
Mon Dec 16 23:03:28 PST 2013

  On Sun, Dec 15, 2013 at 11:43 AM, "Duncan P. N. Exon Smith" <dexonsmith at apple.com> wrote:
  > Hi Gao,
  > The implementation looks correct, but given that it adds to the C API (which needs to be stable),
  > can someone else chime in?
  > Also, would you please explain the use case for embedding linker options in the object file metadata?
  > Why wouldn’t they be passed directly to the linker?  Sorry if I missed an earlier thread on this, or if
  > I’m missing something obvious.
  > Duncan

  Hi Duncan,

  Many thanks for reviewing my patch!

  Embedding linker options in the object file metadata has been the way to support
  MSVC-style auto linking since r181426. I guess your real question is why we need
  to add new APIs instead of compiling to native object files and then letting the
  linker extract the linker options from the object files. Please clarify if that
  is not the case.

  I have to discuss with our linker team for any specific use cases, but I think
  there are a few linker options which affect symbol references used by LTO,
  and they may be needed before the symbol resolution phase. For example,
  /include:<symbol> tells the linker to pretend that a symbol is referenced. Also,
  if /dll and /def:<module-definition file> are used, then the linker need to read
  the input .def file and preserve the exported symbols specified in that file from
  being deleted by LTO passes.

  Reference: http://llvm.org/docs/LinkTimeOptimization.html

  - Gao.


More information about the llvm-commits mailing list