<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 27, 2015 at 9:19 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> It sort of got lost among the other points, but this was meant to be<br>
> accompanied by "and if the binary is created with yaml2obj anyway, why not<br>
> just check in the yaml?"<br>
<br>
</span>So, there may be a line between the two groups where yaml is the<br>
easiest way to create a test. So lets say you are reading the code,<br>
notice something odd and decide to try create a file that will hit an<br>
assert. Depending on what that assert is, yaml2obj might be the tool<br>
for the job (or llvm-mc, or an hex editor depending on the assert).<br>
<br>
But most cases I have seen yaml2obj mentioned are for cases that<br>
someone chanced upon a file that causes an issue and now is trying to<br>
figure out a way to recreate it with yaml2obj. Since we will always<br>
want to do something reasonable with that file, why not check it in?<br></blockquote><div><br></div><div>The same reason we generally reduce all other testcases before checking them in? I don't see how this is any different.</div><div><br></div><div>-- Sean Silva</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
This patch was just one such case: the patch was written fixing an<br>
issue on a file that was trivial to create: compile a file with two<br>
functions using -ffunction-sections -fno-unique-section-names.<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div></div>