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

[David Blaikie]

On Mon, Feb 11, 2013 at 11:36 AM, Eric Christopher <echristo at gmail.com> wrote:
>
>
>
> On Mon, Feb 11, 2013 at 11:28 AM, Eli Bendersky <eliben at google.com> wrote:
>>
>> On Mon, Feb 11, 2013 at 11:18 AM, David Blaikie <dblaikie at gmail.com>
>> wrote:
>> > 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.
>> >
>>
>> I agree. I've recently added some new capabilities to dwarfdump, and
>> added binary files to exercise them precisely for this reason. To
>> handle the maintainability issue I also included source C files with
>> simple instructions on how to generate the binaries from them. Alexey
>> Samsonov also added the C sources for the dwarfdump binary inputs he
>> had in earlier. To whom it may concern, see the files in
>> test/DebugInfo/Inputs/ and the comments on top of relevant tests in
>> test/DebugInfo
>
>
> As Dave said, he wore me down a bit this morning. That said I still find
> a lot of usefulness in the end-to-end test as well and would rather
> duplicate
> some part of the test rather than not have that side of testing.

I assume if someone's adding a new feature for llvm-dwarfdump it's
because they want to test some product feature - so no doubt those
tests will follow shortly after the llvm-dwarfdump
feature+verification case. If they don't then we might as well just
delete the feature/test (& I'll use this as an extra justification: if
the test is clearly just testing dwarfdump then it makes it more
obvious when we maintain the test cases what they're there for/how
they can be modified if we need to update them ("wait, is this test
testing dwarfdump or object file emission? My change changed object
file emission - what am I meant to do with this test case?"))

- David