[PATCH] [lld] Add ArchiveMemoryBuffer.

[Rui Ueyama]

On Thu, Feb 5, 2015 at 4:58 AM, Shankar Kalpathi Easwaran <
shankarke at gmail.com> wrote:

> The input section descripton can contain a file pattern that need to be
> matched.
>
> Some trivial examples are :-
>
> .text.libcprintf : { libc.a:printf.o (*.text) }
> .text.alllibc : { libc.a: *(*.text*) }
>
> The first one selects text from only printf.o of libc.a (only if libc.a is
> an archive) and places that in the output section .text.libcprintf.
>

Section binning is done in the writer which is the very end of the linking
process. At that moment there are only Files and no MemoryBuffers there,
because at that time all memory buffers have been parsed already to link
them.

If you are (1) making a subclass of MemoryBuffer to save original archive
file name and (2) adding that memory buffer to File in order to get the
archive file name using a File object, that's too much. There should be a
shorter path to plumb, in which MemoryBuffer is not involved. That's not a
good design.

You don't have to add another parameter to all places where File is
instantiated. There's only place where member files are instantiated --
FileArchive.cpp.

Please see
> https://sourceware.org/binutils/docs/ld/Input-Section-Basics.html#Input-Section-Basics
> for more detailed information on other wildcards.
>
> You are right that File has to know about this memberName and FileName
> separation. I tried to do this by adding another parameter to the File
> constructor but the solution looked very ugly, The path that lld::File
> returns is the BufferIdentifier stored in the MemoryBuffer. Adding another
> parameter to all the places where a File is constructed is a overkill since
> this is only needed for Archive members.
>
> As I mentioned this in the description, the next patch would be for File
> to own the MemoryBuffer and return the path or member information directly
> using MemoryBuffer.
>
> We discussed this on llvmdev sometime late last year too :
> http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-December/079295.html
>
>
> http://reviews.llvm.org/D7428
>
> EMAIL PREFERENCES
>   http://reviews.llvm.org/settings/panel/emailpreferences/
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150205/6d7fc35d/attachment.html>