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

[Caroline Tice <cmtice@google.com>]

This text, extracted from my detailed explanation, DOES explain (I
thought) why the existing DWARF assembler can't be used:

> > A further twist is that
> > the GNU assembler currently chokes on DWARF v5 .debug_line sections, because
> > they start their file index at 0 instead of 1, and the GNU assembler has not
> > been updated to handle this.  This is not a problem for
> > assembly files generated by GCC, because GCC generates DWARF v3
> > .debug_line sections, even when passed -gdwarf-5.  Clang on the other hand,
> > when passed -gdwarf-5, generates DWARF v5 .debug_line tables. So using a
> > clang-generated .s file for the test is not an option, because the GNU
> > assembler chokes on it.

-- Caroline
cmtice@google.com

On Thu, Jul 16, 2020 at 10:21 AM Andrew Burgess
<andrew.burgess@embecosm.com> wrote:
>
> * Caroline Tice via Gdb-patches <gdb-patches@sourceware.org> [2020-07-16 09:50:36 -0700]:
>
> > Since this patch will be resulting in something of a policy change, I
> > expect there will be a fair
> > amount of discussion around it.
> >
> > High level summary:
> > In some (hopefully rare) cases, certain tests MUST be built with a
> > particular compiler to work.  If that compiler is not GCC, then it
> > makes it very burdensome for developers to run the GDB testsuite and
> > test those tests.  This change allows those tests to use object files
> > (generated by the required compiler) as the test source file, so that
> > when the test suite is run with GCC those tests will still
> > execute/test properly.
> >
> > Details:
> > This change is motivated by the fact that clang and GCC sometimes generate
> > different output, which affects whether or not a test works properly.  The
> > particular motivating example is the gdb.dwarf2/dw5-rnglist-test.exp test,
> > which tests whether or not GDB is properly reading/handling DWARF v5
> > DW_AT_ranges of the form DW_FORM_rnglistx in lexical block dies.  GCC does
> > not generate that code, so compiling the test with GCC does not successfully
> > test anything. Clang does generate that code, so the only way to properly
> > test this is to compile the test case with clang.  A further twist is that
> > the GNU assembler currently chokes on DWARF v5 .debug_line sections, because
> > they start their file index at 0 instead of 1, and the GNU assembler has not
> > been updated to handle this.  This is not a problem for
> > assembly files generated by GCC, because GCC generates DWARF v3
> > .debug_line sections, even when passed -gdwarf-5.  Clang on the other hand,
> > when passed -gdwarf-5, generates DWARF v5 .debug_line tables. So using a
> > clang-generated .s file for the test is not an option, because the GNU
> > assembler chokes on it.
> >
> > This patch updates lib/gdb.exp to allow it to properly handle test
> > cases where the source file is in fact an object file, and it updates
> > the dw5-rnglist-test to use an object file rather than the .cc file.  This
> > in turn makes the test itself compiler-agnostic.
>
> I haven't looked at this particular test, but I think any
> justification for this change, especially when the example you cite is
> about different DWARF, should include an explanation about why the
> existing DWARF assembler can't be used in this case.
>
> Thanks,
> Andrew
>
> >
> >
> > -- Caroline Tice
> > cmtice@google.com
> >
> > gdb/testsuite/ChangeLog
> >
> > 2020-07-16  Caroline Tice  <cmtice@google.com>
> >
> >         * lib/gdb.exp (build_executable_from_specs): Create output_dir
> >         variable from call to standard_output_file; update code that
> >         compiles source files to object files and copies them to output
> >         directory, to check first and make sure they are not already
> >         object file.  If they are already object files, just copy them to
> >         output directory.
> >         * gdb.dwarf2/dw5-rnglist-test.o: New file (object file)
> >         * gdb.dwarf2/dw5-rnglist-test.exp: Update to use .o file rather than
> >         .cc file; this removes the dependency of this test on clang and
> >         allows it to work with GCC as well.
>
>