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

[Eric Christopher]

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.e. I'm
more
concerned with the testing of debug info... and Dave has just responded more
so I'll let him keep on keeping on for the thread :)

-eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20130211/dd4e4bb7/attachment.html>