<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Dec 15, 2014 at 1:30 PM, Shankar Easwaran <span dir="ltr"><<a href="mailto:shankarke@gmail.com" target="_blank">shankarke@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Sun, Dec 14, 2014 at 8:05 PM, Rui Ueyama <span dir="ltr"><<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span>On Mon, Dec 15, 2014 at 12:01 AM, Shankar Easwaran <span dir="ltr"><<a href="mailto:shankar.kalpathi.easwaran@gmail.com" target="_blank">shankar.kalpathi.easwaran@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.<br></blockquote><div><br></div></span><div>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.</div><div><br></div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div>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?</div><span><div><br></div></span></div></div></div></blockquote></div></div><div><br>It would be great if we can extend the registry interface to parse linker scripts too.<br></div></div></div></div></blockquote><div><br></div><div>Why? As I wrote it would really mess up the registry interface but we would get almost nothing.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>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.<br></div></div></div></div></blockquote><div><br></div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>Yeah I agree that the new changes that you are doing doesnot change old functionality in any way.  LGTM.<br><br><br></div></div></div></div>
</blockquote></div></div></div>