[llvm-dev] lld: --start-lib and --end-lib
Sean Silva via llvm-dev
llvm-dev at lists.llvm.org
Wed Apr 6 13:08:12 PDT 2016
On Tue, Apr 5, 2016 at 9:07 PM, Rui Ueyama via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> I hacked up a patch to support --start-lib and --end-lib in the second way.
> In this patch, I introduced a new notion, LazyObject. That is analogous to
> Archive file type, but that works for a single object file instead of an
> archive file. This patch is +160 and -26 lines, so I can say that it is
> pretty simple.
Have you tried creating a thin archive in memory and loading it in the
normal way? That seems potentially simpler.
-- Sean Silva
> This is not directly related to --start-lib and --end-lib, but LazyObject
> may be useful for --gc-sections as well. This is the suggestion I got in
> the EuroLLVM 2016 meeting (I'm sorry but I don't remember who his name),
> but he suggested handling all object files as lazy object files for
> --gc-sections. It means by default no object files are linked. The entry
> point symbol would link one object file, and that triggers all used object
> files to be instantiated. I think this is very interesting idea because we
> don't need to do mark-sweep garbage collection to do --gc-sections;
> instead, everything will be linked only when they are needed.
> On Tue, Apr 5, 2016 at 7:51 PM, Rui Ueyama <ruiu at google.com> wrote:
>> You seems to be the person who added --start-lib and --end-lib to gold
>> (*1), so I think you are the best person to ask about it. :)
>> What is the intended use case of the options? Do you think we should
>> support that in LLD?
>> If we want to support that, then I think we can think of two
>> implementation strategies:
>> - Link object files between --start-lib and --end-lib normally and
>> garbage collect unused sections, or
>> - create lazy symbols for object files between --start-lib and --end-lib
>> and handle just like archive files.
>> What do you think?
>> *1 https://sourceware.org/ml/binutils/2010-03/msg00233.html
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev