<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 16, 2017 at 11:02 PM, Rui Ueyama <span dir="ltr"><<a href="mailto:ruiu@google.com" target="_blank">ruiu@google.com</a>></span> wrote:<br><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 class="gmail-">On Mon, Jan 16, 2017 at 12:31 PM, Sean Silva <span dir="ltr"><<a href="mailto:chisophugis@gmail.com" target="_blank">chisophugis@gmail.com</a>></span> wrote:<br><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">Do we have any open projects on LLD?<div><br><div>I know we usually try to avoid any big "projects" and mainly add/fix things in response to user needs, but just wondering if somebody has any ideas.</div><div><br></div><div>Some really generic/simple stuff I can think of:</div><div>1. trying out LLD on a large program corpus and reporting/reducing/fixing bugs (e.g. contributing to the FreeBSD effort or trying to build a bunch of packages from a linux distro like Debian or Gentoo)</div></div></div></blockquote><div><br></div></span><div>I like that idea. FreeBSD is using a very old version of ld.bfd, so on Linux systems we may be able to find programs that use recent linker features which LLD does not support. This may sound like an ambitious goal, but I want make Linux distributions to use LLD as default linker, so it needs to be able to link entire Linux distributions.</div></div></div></div></blockquote><div><br></div><div>That's indeed ambitious, as even Gold has not managed to become the default on any prominent Linux distro I'm aware of. IIRC gold doesn't link all of Gentoo (there was a blog post / article but I can't find it). One intermediate goal we can strive for is to reach parity with Clang, which currently builds about 95% of the packages: <a href="http://clang.debian.net/">http://clang.debian.net/</a></div><div><br></div><div> </div><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 class="gmail-"><div><br></div><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><div>2. performance analysis and optimization of LLD</div><div>3. getting LLD to link a bootable Linux kernel and/or GRUB</div></div></div></blockquote><div><br></div></span><div>I don't know how hard/easy it is to link Linux kernel with LLD, but that should be doable if we spend enough effort on that. That should be a good project.</div><div><br></div><div>As to porting LLD to other architectures, you can use emulators like bochs, can't you? You don't even need any emulator for x86 32-bit.</div></div></div></div></blockquote><div><br></div><div>These open projects are largely targeted at new contributors, so ideally we would provide some instructions on how to set up a test system, what to do on it, etc. The less effort they have to spend yak-shaving setting things up, the sooner they will be doing useful work on LLD (or even, contributing to LLD at all, if they can't figure out how to set things up). We already have community members with workflows for doing this kind of testing, it's just a matter of writing it down so it is easy to follow. Ideally it's just "download this emulator and grab this image for <architecture>, then boot it and try building/linking/running some programs"; also, any relevant cross-compile setup would make things easier too.</div><div><br></div><div>Similarly for the Linux kernel; all the setup for getting qemu and stuff working is annoying and I remember it took Davide, Michael, and quite a bit of time yak-shaving to find a nice workflow that we could iterate on for FreeBSD. Honestly the Linux/GRUB project is a bit of a stretch: I think this "open projects" page is mainly aimed at a student/intern-level audience, and to attack that project a student/intern-level contributor would have to be truly extraordinary (though I guess we may want to attract those types too ;-) ). Filling in architecture support in userland is a much more tractable for a larger audience.</div><div><br></div><div>-- Sean Silva</div><div> </div><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 class="gmail-"><div><br></div><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><div>4. write an input verifier such that LLD can survive intensive fuzzing with no crashes / fatal errors [1] when the verifier says the input is okay. This will allow us to measure what the overhead of doing this actually is.</div><div><br></div><div><br></div><div>[1] As of the latest LLD discussion (in the thread "[llvm-dev] LLD status update and performance chart") it sounds like people are okay with LLD treating fatal errors the same way that LLVM uses assertions; for inputs from the C++ API, we can document to not pass corrupted object files. For inputs read from files, there is still community interest in at least having the option to run a "verifier" to validate the inputs. I think the best way to approach the verifier is to essentially follow the approach suggested by Peter (in the context of "hardening") in <a href="https://llvm.org/bugs/show_bug.cgi?id=30540#c5" target="_blank">https://llvm.org/bugs/show_<wbr>bug.cgi?id=30540#c5</a> i.e. getting to the point where LLD can survive intensive fuzzing.</div><span class="gmail-m_648141286970592667HOEnZb"><font color="#888888"><div><br></div><div>-- Sean Silva</div></font></span></div></div><div class="gmail-m_648141286970592667HOEnZb"><div class="gmail-m_648141286970592667h5"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 16, 2017 at 5:18 AM, Vassil Vassilev via llvm-dev <span dir="ltr"><<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi folks,<br>
<br>
  Happy new year!<br>
<br>
  Last LLVM Developers' Meeting I had a BoF: 'Raising Next Generation LLVM Developers'. It was suggested that we should update our open projects page and possibly restructure it a little bit.<br>
<br>
  I volunteered to do this work and I need your help.<br>
<br>
<br>
  Chandler and I started working on a google doc [1]. We pinged few code owners asking them to list of work items we should get done in 2017 but we do not have the manpower. Now we would like to ask for your input, too.<br>
<br>
  I believe an up to date list can serve as a good entry point for students, interns and new contributors.<br>
<br>
  Feel free to propose a new item or comment under an existing one. I expect to start gradually updating the page beginning of Feb.<br>
<br>
-- Vassil<br>
<br>
[1] <a href="https://docs.google.com/document/d/1YLK_xINSg1Ei0w8w39uAMR1n0dlf6wrzfypiX0YDQBc/edit?usp=sharing" rel="noreferrer" target="_blank">https://docs.google.com/docume<wbr>nt/d/1YLK_xINSg1Ei0w8w39uAMR1n<wbr>0dlf6wrzfypiX0YDQBc/edit?usp=s<wbr>haring</a> <br>
______________________________<wbr>_________________<br>
LLVM Developers mailing list<br>
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank">llvm-dev@lists.llvm.org</a><br>
<a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/llvm-dev</a><br>
</blockquote></div><br></div>
</div></div></blockquote></span></div><br></div></div>
</blockquote></div><br></div></div>