[PATCH] [lld][ELF] Add linker script ENTRY command

[Shankar Easwaran]

On 5/23/2013 4:58 PM, Nick Kledzik wrote:
> On May 22, 2013, at 8:47 PM, Rui Ueyama wrote:
>> On Wed, May 22, 2013 at 4:08 PM, Nick Kledzik <kledzik at apple.com> wrote:
>> On May 22, 2013, at 3:15 PM, Rui Ueyama <ruiu at google.com> wrote:
>>>   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.
>>>
>>>   We may want to split TargetInfo into two classes.
>>>
>>>    - New TargetInfo class is a public API and is constructed and modified by Driver.This class has default copy constructor.
>>>    - 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.
>>>
>>>   What do you think?
>> 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.
>>
>> 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.
> Is there some reason why the linker scripts cannot be parsed just to extract the info that effects TargetInfo, and do that up front when the TargetInfo is being set up by the Driver?  Then the TargetInfo can be const from then on.
Why do we want to add members into TargetInfo, only if specific targets 
use. I think LinkerScripts for ELF should be parsed and those functions 
should be present only in ELFTargetInfo, Isnt it ?
> How does Windows arbitrary linker options in object files work?  What happens when object files supply conflicting options? Or try to add some option that would have made previous object files invalid?
>
> In a previous post you suggested an interface like:
>      bool Driver::link(TargetInfo &targetInfo, const std::vector<LinkerInput> &inputs, raw_ostream &diagnostics);
> I'm not sure how that all works about because the Drivers currently have a parse() method that takes command line args and returns a TargetInfo object, but how will they return an std::vector<LinkerInput> too?  In addition, ELF has a way to group input files to be re-searched.  Using a vector<> means there is no where to store that grouping info.  That sort of info is why I had the InputFiles class (instead of vector).
>
> The more I look at the uses of TargetInfo the less sense it makes to split it up.  If there are two objects, then which owns which, and which one is passed around, or are both always passed?
>
> I'm coming around to the idea that TargetInfo should be passed non-const to link().  Part of the problem is that the current name is misleading.  If TargetInfo was called something like "LinkingState" it would make more sense to be non-const.  We wanted it const for the library scenario where it is reused multiple times.  Another approach for the library case is to make construction of a new TargetInfo cheap and easy. Something like:
I though you were planning to make it as LinkerOptions earlier.
>    	MachOTargetInfo info(arch_x86_64, macOSX, "10.7");
>   
> -Nick
Shankar Easwaran