LLD: TargetInfo constness
Reid Kleckner
rnk at google.com
Tue Jul 23 11:15:36 PDT 2013
On Sun, Jul 21, 2013 at 8:25 PM, Rui Ueyama <ruiu at google.com> wrote:
> I remember Nick suggested two pass solution. In the first pass, we read
> all the object files given via the command line only to gather linker
> directives to construct a TargetInfo. In the second pass, the TargetInfo is
> passed to the core linker and is treated as a const object. This might work
> for ELF, but wouldn't for COFF, because of the issue when linking the
> archive file. We should not parse directives of all files in a library
> file, but parse only the file needed for linking. That information is not
> available until we actually try to link objects, so we can't split it into
> two passes.
>
Hm, that's really frustrating, and is probably worth elaborating on. It
seems like the following could happen:
foo.lib contains objs:
use_bar.obj contains .drectve /defaultlib:bar.lib
use_baz.obj contains .drectve /defaultlib:baz.lib
A user of foo.lib might only ever call into one of use_bar.obj or
use_baz.obj depending on some define like NDEBUG or _MSC_VER. bar.lib and
baz.lib might have conflicting symbols, so they can't both be linked in as
would happen in a two-pass solution.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130723/5c889a83/attachment.html>
More information about the llvm-commits
mailing list