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

[Rui Ueyama]

On Thu, May 23, 2013 at 2:58 PM, Nick Kledzik <kledzik at apple.com> 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.
>
> 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?
>

It seems that #pragma (linker, "*option"*) are processed as if it's given
by a command line. You can specify conflicting command line options to the
linker, and the reuslt depends on what option is conflicting. For example,
if multiple entry points are specified by /entry:*funcname*, the last one
seems to take precedence.

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");
>

I think I like that approach. How important is reusability of TargetInfo
for library use scenario? Bigcheese?


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