<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Dec 16, 2016 at 12:58 PM, Renato Golin <span dir="ltr"><<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 16 December 2016 at 19:28, Rui Ueyama <<a href="mailto:ruiu@google.com">ruiu@google.com</a>> wrote:<br>
> It may be good to compile a wishlist about a linker to collect feature ideas<br>
> people wish to use. I honestly know only one major request: embedding a<br>
> linker to a program. I guess that this single feature satisfies a majority<br>
> of needs as per 80:20 rule, but I really want to know what people wish to<br>
> have.<br>
<br>
</span>Indeed. Getting a list of what people need and who's committing to do<br>
those things is a good idea.<br>
<br>
At this stage, we should refrain from adding any wild wish, or it'll<br>
be impossible to do anything.<br>
<br>
But given developer involvement in adding functionality as well as<br>
keeping the promise of stability and performance, a next-steps list is<br>
a good way to go.<br>
<span class=""><br>
<br>
<br>
> I agree with a fine print that I wish people working on LLVM and clang aware<br>
> that best practices in compilers may not be directly transferable to<br>
> linkers. Linkers and compilers are different kinds of programs.<br>
<br>
</span>Wholeheartedly agree!<br>
<br>
This is already true for compiler-RT, libc++, the test-suite, polly<br>
and many other "LLVM branded" projects.<br>
<span class=""><br>
<br>
> The first thing that comes up to my mind with regard to pushing LLD forward<br>
> as an LLVM project is to move more code to LLVM libraries so that we can<br>
> make LLD smaller. What do you think?<br>
<br>
</span>As you and Rafael have said in this thread, the reusable part of<br>
linkers is not that big, so having LLD libraries in objdump (for<br>
example) may not be practical, but having a separate (small) symbol<br>
handling library that both use could be a potential way forward. I<br>
don't know enough about LLD or objdump to have any concrete opinion,<br>
but I have a feeling that objdump is a much bigger program than it<br>
should be.<br>
<br>
People usually say it's because the code is not really reusable. That<br>
may be true, but if we can find reusability on small tools and LLD,<br>
that'd at least reduce code a bit. Given that LLD already depends on<br>
Clang and LLVM, there's no bad side of the increased dependency. (is<br>
there?).<br></blockquote><div><br></div><div>Nope, it doesn't depend on Clang. We uses a lot of LLVM libraries that Clang depends on, but not on Clang.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
But I would personally follow a more pragmatic approach. It should be<br>
ok for LLD to have its own infrastructure, as long as it's not<br>
completely duplicating and increasing maintenance for both LLD and<br>
LLVM developers.<br>
<br>
cheers,<br>
--renato<br>
</blockquote></div><br></div></div>