<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, May 26, 2015 at 3:16 PM, Michael Spencer <span dir="ltr"><<a href="mailto:bigcheesegs@gmail.com" target="_blank">bigcheesegs@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="">On Tue, May 26, 2015 at 2:18 PM, Rui Ueyama <<a href="mailto:ruiu@google.com">ruiu@google.com</a>> wrote:<br>
> Yes we should fix it if it can't handle valid objects, but I think we<br>
> probably start considering checking in object files (as opposed to checking<br>
> in yaml files) is the right thing, as IIRC Rafael said before. Object files<br>
> are the input for the linker, so in order to get a precise control over the<br>
> input, it's better to use object files themselves.<br>
<br>
</span>I would rather we not use non-human readable inputs for testing. It<br>
makes it difficult to tell what's being tested and what the file<br>
actually represents. The intent of yaml2obj is to be able to represent<br>
(almost) any valid ELF file, and some invalid ones. I'll add support<br>
for it.<br></blockquote><div><br></div><div>Human-readable files are indeed good for human, but there are many file formats that we only want to read but don't want to write, such as old .a file headers, so I don't think it's always a good idea to write a tool to convert textual formats into binary. For human readability, I think we can check in source files if it makes sense (for example, if you create an object file from an assembly, you can check both files.)</div></div></div></div>