[PATCH] [ELF] Remove {ELF,}GNULinkerScript InputElements.

[Rui Ueyama]

On Mon, Dec 15, 2014 at 1:30 PM, Shankar Easwaran <shankarke at gmail.com>
wrote:
>
>
>
> On Sun, Dec 14, 2014 at 8:05 PM, Rui Ueyama <ruiu at google.com> wrote:
>>
>> On Mon, Dec 15, 2014 at 12:01 AM, Shankar Easwaran <
>> shankar.kalpathi.easwaran at gmail.com> wrote:
>>>
>>> We are trying to duplicate getfilemagic in the driver which is actually
>>> part of the registry. The linker script should not be parsed in the driver
>>> immediately. The whole reason why the linker script is being parsed in the
>>> driver is we don't have a way to handle a script when the linker script is
>>> specified just like any other input file or library  in the parser or
>>> registry. It should be parsed late whenever we figure out that the file is
>>> a linker script. We should parse more input files by using a lazy parsing
>>> method using file locator.
>>>
>>
>> I think I don't get the point yet. We do have a way to handle a linker
>> script in the driver (which is what I do in this patch, and the code is not
>> new -- it's I think written by you?). We had been figuring out whether a
>> file is a linker script or not in the driver, and that hasn't changed in
>> this patch.
>>
>> And my point still stands. The registry mechanism is designed to parse a
>> file into a File object. Yes, we could extend that interface to be able to
>> handle linker scripts, but we would get almost nothing from that
>> abstraction, although that would really mess up the registry interface.
>> We've already learned that the excessive abstraction in LLD really hurts us
>> from the experience of the InputGraph, no?
>>
>>
> It would be great if we can extend the registry interface to parse linker
> scripts too.
>

Why? As I wrote it would really mess up the registry interface but we would
get almost nothing.


> I was hoping that the cleanup changes that you are trying to model would
> create a lazy model of creating files that need to be parsed in a lazy
> fashion.
>

Files are not created in a lazy manner, but file parsing are done in a lazy
manner (r224102 to split File instantiation from file parsing), so the
change that I'm trying to make is aligned with your hope, I guess. The
difference is my approach involves fewer classes, fewer interfaces and less
code.

Yeah I agree that the new changes that you are doing doesnot change old
> functionality in any way.  LGTM.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141215/7378c747/attachment.html>