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

[Nick Kledzik]

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.

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:

  	MachOTargetInfo info(arch_x86_64, macOSX, "10.7");
 
-Nick


> 
> 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?
> 
> 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.
> 
> 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.