[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.
http://llvm-reviews.chandlerc.com/D2343
More information about the llvm-commits
mailing list