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

[Eli Bendersky]

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

Eli