<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Feb 11, 2013 at 11:28 AM, Eli Bendersky <span dir="ltr"><<a href="mailto:eliben@google.com" target="_blank">eliben@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Mon, Feb 11, 2013 at 11:18 AM, David Blaikie <<a href="mailto:dblaikie@gmail.com">dblaikie@gmail.com</a>> wrote:<br>

> On Mon, Feb 11, 2013 at 8:31 AM, Eric Christopher <<a href="mailto:echristo@gmail.com">echristo@gmail.com</a>> wrote:<br>
>><br>
>><br>
>><br>
>> On Mon, Feb 11, 2013 at 8:29 AM, Tim Northover <<a href="mailto:t.p.northover@gmail.com">t.p.northover@gmail.com</a>><br>
>> wrote:<br>
>>><br>
>>> On Mon, Feb 11, 2013 at 4:09 PM, Eric Christopher <<a href="mailto:echristo@gmail.com">echristo@gmail.com</a>><br>
>>> wrote:<br>
>>> > In this case you could use a .ll file to do this and just have it<br>
>>> > generated<br>
>>> > rather than an object file that you check. Just compile a basic object<br>
>>> > file<br>
>>> > with a function or two and it'll get you what you need. For the aarch64<br>
>>> > bits<br>
>>> > go ahead and make a directory parallel to the X86 directory for this<br>
>>> > specific thing.<br>
>>><br>
>>> Thanks Eric; a good suggestion implemented in r174891.<br>
>><br>
>> Awesome. Thanks :)<br>
><br>
> Chiming in a little late here, but summarizing my perspective that<br>
> I've chatted to Eric about offline:<br>
><br>
> I'm of the opinion that dwarfdump test cases should, as much as<br>
> possible, only test dwarfdump & thus your original version (with a<br>
> binary file committed as the input).<br>
><br>
> There is, to be fair, some aversion to committing binary files to the<br>
> repository (a minor technical concern about how SubVersion stores<br>
> binary files & changes (not as diffs), as well as practical concerns<br>
> about maintainability (making changes - though I'm happy to have<br>
> source code (IR and/or C code) in comments or elsewhere nearby))<br>
><br>
> The idea being that we should test our test infrastructure (once it<br>
> reaches the level of complexity that it can actually have bugs - which<br>
> llvm-dwarfdump seems to be) in isolation so we have a good foundation<br>
> on which we can trust it when we write feature tests. If we're testing<br>
> llvm-dwarfdump with the output of LLVM then we lack that baseline to<br>
> some degree.<br>
><br>
> This way, we get a clear sense of when dwarfdump is broken (hey, the<br>
> dwarfdump tests failed) as compared to when the product is broken<br>
> (hey, the tests that use dwarfdump failed - the product must be<br>
> broken)<br>
><br>
> Anyway - it's just a thought/different perspective. Thought I'd<br>
> mention it here in case others in the community have other<br>
> perspectives/data to add to this point.<br>
><br>
<br>
</div></div>I agree. I've recently added some new capabilities to dwarfdump, and<br>
added binary files to exercise them precisely for this reason. To<br>
handle the maintainability issue I also included source C files with<br>
simple instructions on how to generate the binaries from them. Alexey<br>
Samsonov also added the C sources for the dwarfdump binary inputs he<br>
had in earlier. To whom it may concern, see the files in<br>
test/DebugInfo/Inputs/ and the comments on top of relevant tests in<br>
test/DebugInfo<br></blockquote><div><br></div><div style>As Dave said, he wore me down a bit this morning. That said I still find</div><div style>a lot of usefulness in the end-to-end test as well and would rather duplicate</div>
<div style>some part of the test rather than not have that side of testing. i.e. I'm more</div><div style>concerned with the testing of debug info... and Dave has just responded more</div><div style>so I'll let him keep on keeping on for the thread :)</div>
<div style><br></div><div style>-eric </div></div></div></div>