[llvm] r174874 - AArch64: Add basic relocation processing for llvm-dwarfdump.

[David Blaikie]

On Mon, Feb 11, 2013 at 8:31 AM, Eric Christopher <echristo at gmail.com> wrote:
>
>
>
> On Mon, Feb 11, 2013 at 8:29 AM, Tim Northover <t.p.northover at gmail.com>
> wrote:
>>
>> On Mon, Feb 11, 2013 at 4:09 PM, Eric Christopher <echristo at gmail.com>
>> wrote:
>> > In this case you could use a .ll file to do this and just have it
>> > generated
>> > rather than an object file that you check. Just compile a basic object
>> > file
>> > with a function or two and it'll get you what you need. For the aarch64
>> > bits
>> > go ahead and make a directory parallel to the X86 directory for this
>> > specific thing.
>>
>> Thanks Eric; a good suggestion implemented in r174891.
>
> Awesome. Thanks :)

Chiming in a little late here, but summarizing my perspective that
I've chatted to Eric about offline:

I'm of the opinion that dwarfdump test cases should, as much as
possible, only test dwarfdump & thus your original version (with a
binary file committed as the input).

There is, to be fair, some aversion to committing binary files to the
repository (a minor technical concern about how SubVersion stores
binary files & changes (not as diffs), as well as practical concerns
about maintainability (making changes - though I'm happy to have
source code (IR and/or C code) in comments or elsewhere nearby))

The idea being that we should test our test infrastructure (once it
reaches the level of complexity that it can actually have bugs - which
llvm-dwarfdump seems to be) in isolation so we have a good foundation
on which we can trust it when we write feature tests. If we're testing
llvm-dwarfdump with the output of LLVM then we lack that baseline to
some degree.

This way, we get a clear sense of when dwarfdump is broken (hey, the
dwarfdump tests failed) as compared to when the product is broken
(hey, the tests that use dwarfdump failed - the product must be
broken)

Anyway - it's just a thought/different perspective. Thought I'd
mention it here in case others in the community have other
perspectives/data to add to this point.

- David