<p dir="ltr"><br>
On May 28, 2015 6:55 PM, "Sean Silva" <<a href="mailto:chisophugis@gmail.com">chisophugis@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
> On Wed, May 27, 2015 at 9:19 PM, Rafael Espíndola <<a href="mailto:rafael.espindola@gmail.com">rafael.espindola@gmail.com</a>> wrote:<br>
>><br>
>> > 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>
>> 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>
><br>
><br>
> The same reason we generally reduce all other testcases before checking them in? I don't see how this is any different.</p>
<p dir="ltr">The test is two  .section directives and a relocation in .s. Trying to force it to yaml is just a waste of time. <br><br></p>
<p dir="ltr">> -- Sean Silva<br>
>  <br>
>><br>
>><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>
><br>
><br>
</p>