[PATCH] Update testsuite mechanism to allow object files as source files.

[Andrew Burgess]

* Caroline Tice via Gdb-patches <gdb-patches@sourceware.org> [2020-07-16 14:10:25 -0700]:

> Has the DWARF assembler in the GDB testsuite been updated to handle
> DWARF v5?  Or can it handle that automatically?  Is there a good
> example I can look at to see how to use it?

To find examples look for the pattern 'Dwarf::assemble" in
gdb/testsuite/gdb.dwarf2/*.exp.

The dwarf assembler does use include/dwarf.h and include/dwarf.def to
build up the set of attributes and form types that are supported, so
in that sense the basics of DWARF5 will be supported, but when you
start to look at new sections, or new layouts for existing sections,
then no, this is most likely not supported, yet.

Thanks,
Andrew







> 
> -- Caroline
> cmtice@google.com
> 
> On Thu, Jul 16, 2020 at 1:12 PM Tom Tromey <tom@tromey.com> wrote:
> >
> > Joseph> On general free software and reproducible builds principles:
> > Joseph> * The source for any checked-in object file should be checked in.
> > Joseph> * That source should include comments giving all information required to
> > Joseph> be able to reproduce the object file byte-for-byte
> >
> > In the past we tried this kind of thing, by taking the assembly
> > generated by the compiler, then editing it and checking it in.
> >
> > However, IMO, this turned out to be a pain.  The hand editing was often
> > not sufficiently documented, and the tests were still
> > architecture-dependent.  Once or twice I think someone has had to edit
> > the .S file later, which is error-prone.  Also, the earliest test suite
> > additions like this didn't include the original source, making this
> > harder to handle.
> >
> > The "DWARF assembler" in the test suite avoids all this, at least for
> > tests that require particular debuginfo.  The main drawbacks of this
> > approach are (again IMO) that sometimes it's a pain to write the DWARF
> > by hand, and that sometimes the assembler framework itself needs
> > upgrades before one can even begin.  However, the tests are much more
> > robust.
> >
> > I'd encourage the extension of the latter approach as much as possible.
> > It isn't perfect but IME has been better on the whole.
> >
> > Tom