<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 13, 2016 at 1:35 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On 4 January 2016 at 13:33, Kostya Serebryany <<a href="mailto:kcc@google.com">kcc@google.com</a>> wrote:<br>
> Cool!<br>
> I wonder if it makes sense to have a fuzzer for lld, similar to what we have<br>
> for clang and clang-format?<br>
<br>
</span>Maybe, it probably depends on what we are fuzzing for.<br></blockquote><div><br></div><div>Any kind of stability issues. </div><div>It's hard to limit the fuzzing to legal inputs (valid .o files), so most of the fuzzed tests will be illegal and thus may touch various dusty corners otherwise untouched by regular work flow. </div><div>Given that lld *probably* does not have much security surface, it may be a waste of time to fix those dusty corners. </div><div>But that's still the simplest way to get the interesting stability bugs by fuzzing. </div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Broken .o files are really uncommon, unless one is working on a<br>
producer (MC). For lld itself we have so far been using a "don't<br>
crash" policy, but not much more. For example, we will produce garbage<br>
if given ABI invalid TLS relocations.<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div></div>