<div dir="ltr">On Wed, May 22, 2013 at 4:08 PM, Nick Kledzik <span dir="ltr"><<a href="mailto:kledzik@apple.com" target="_blank">kledzik@apple.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br>
On May 22, 2013, at 3:15 PM, Rui Ueyama <<a href="mailto:ruiu@google.com">ruiu@google.com</a>> wrote:<br>
>  It seems that TargetInfo and its subclasses are not copyable even after separating LinkerInput. The classes have many fields that are not copyable, such as memory allocators, file readers and writers. I think such fields are implementation details and not part of the API because they are used only in Core Linking. But they make TargetInfo hard to copy.<br>


><br>
>  We may want to split TargetInfo into two classes.<br>
><br>
>   - New TargetInfo class is a public API and is constructed and modified by Driver.This class has default copy constructor.<br>
>   - A new class have other fields that are not exposed to Driver. It holds a copy of TargetInfo, list of input files, memory allocators, readers, writers, etc. This is not copyable.<br>
><br>
>  What do you think?<br>
<br>
</div>I do think we need to split up TargetInfo, but not along those boundaries.  For the library case we want to be able to create a TargetInfo that is reused to link different sets of files.  So, it is the list of files that needs to be factored out.  The rest of the TargetInfo can remain const.<br>

</blockquote><div><br></div><div style>I'd think TargetInfo cannot be const. LinkerScript can mutate TargetInfo (adding a search path for example), and on Windows input files can set arbitrary linker options. Core Linking has to mutate TargetInfo while parsing input files.</div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Backing up, it is supporting ENTRY in a linker script that is driving this, right?  So, can't we make the entrySymbolName() method in TargetInfo virtual, then have ELFTargetInfo:: entrySymbolName() check the input files to see if there is a linker script and if so check to see if it defines ENTRY, otherwise fallback to whatever command line or default was used when the ELFTargetInfo was created?<br>

</blockquote><div><br></div><div style>Currently TargetInfo does not hold a list of parsed input files, only Driver has. I think we don't want to add the list to TargetInfo, for the same reason why we want to get rid of LinkerInput from TargetInfo.</div>

<div style><br></div><div style>We could add a few methods to ELFTargetInfo for ENTRY as an interim solution. However, because my goal is adding Windows support to lld, I want something that works fine both on all platforms including Windows.</div>

</div></div></div>