<div dir="ltr"><div class="gmail_extra">On Thu, Feb 5, 2015 at 4:58 AM, Shankar Kalpathi Easwaran <span dir="ltr"><<a href="mailto:shankarke@gmail.com" target="_blank">shankarke@gmail.com</a>></span> wrote:<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The input section descripton can contain a file pattern that need to be matched.<br>
<br>
Some trivial examples are :-<br>
<br>
.text.libcprintf : { libc.a:printf.o (*.text) }<br>
.text.alllibc : { libc.a: *(*.text*) }<br>
<br>
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.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Please see <a href="https://sourceware.org/binutils/docs/ld/Input-Section-Basics.html#Input-Section-Basics" target="_blank">https://sourceware.org/binutils/docs/ld/Input-Section-Basics.html#Input-Section-Basics</a> for more detailed information on other wildcards.<br>
<br>
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.<br>
<br>
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.<br>
<br>
We discussed this on llvmdev sometime late last year too : <a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-December/079295.html" target="_blank">http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-December/079295.html</a><br>
<div class="HOEnZb"><div class="h5"><br>
<br>
<a href="http://reviews.llvm.org/D7428" target="_blank">http://reviews.llvm.org/D7428</a><br>
<br>
EMAIL PREFERENCES<br>
  <a href="http://reviews.llvm.org/settings/panel/emailpreferences/" target="_blank">http://reviews.llvm.org/settings/panel/emailpreferences/</a><br>
<br>
<br>
</div></div></blockquote></div><br></div></div>