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