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

[Rui Ueyama]

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.

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130522/256a2123/attachment.html>