Re: [PATCH V5] Fix issues with reading rnglists, especially from dwo files, for DWARF v5

[Caroline Tice <cmtice@google.com>]

Thank you for that suggestion!

It turns out that I CAN create the .o file with clang, then use that
for the basis of my test; linking it with GCC works and gives the
results I expect (it fails with ToT GDB , but passes with my patch).

In order to make this work, however, I have to make a small change to
gdb/testsuite/lib/gdb.exp (in build_executable_from_specs, I have to
check to see if the source file is already an object file before
trying to compile it into an object file, and if it is an object file,
copy it into the proper directory)l

Should I add that (and the .o version of the test case) to this patch,
or should I make it a separate patch?  If the latter (which is what
feels right to me), then if this patch can receive final approval (and
someone can commit it, as I do not have write privileges to the GDB
code base), then I will submit the subsequent patch to replace the
current test with the .o version and update  gdb/testsuite/lib/gdb.exp
to make it work.

-- Caroline
cmtice@google.com

On Wed, Jul 15, 2020 at 10:05 AM H.J. Lu <hjl.tools@gmail.com> wrote:
>
> On Wed, Jul 15, 2020 at 9:58 AM Caroline Tice via Gdb-patches
> <gdb-patches@sourceware.org> wrote:
> >
> > On Tue, Jul 14, 2020 at 8:15 PM Simon Marchi <simark@simark.ca> wrote:
> > >
> > > On 2020-07-14 10:04 p.m., Simon Marchi wrote:
> > > > I don't think I have any more comments.  Tom, are you ok with this?
> > >
> > > I just had a thought about the test, and testing in general of DWARF5 and
> > > split DWARF.  Right now, it's not really testing DWARF5 range lists, as the
> > > name implies.  It's more a general program that may happen to fail given the
> > > right compiler and compiler version.
> > >
> > > [In fact, could you mention (here and in the commit message) how to run your
> > > test case so that it fails, when the rest of your patch is not applied?  The
> > > full "make check" command line, plus the compiler version used to compiler
> > > the test case.
> > >
> > > Ideally, we would have:
> > >
> > > - one test such for the very specific case you are fixing (DW_AT_ranges inside
> > >   a dwo with DWARF5).  We would use the DWARF assembler in lib/dwarf.exp to
> > >   generate exactly what we want to test.  It would probably need to be improved
> > >   a bit to learn about rnglists though.
> > > - a new board file that tests with "-gsplit-dwarf -gdwarf5".  A bit like
> > >   fission.exp, but for DWARF5.  I think a plain "-gdwarf5" board file would
> > >   be useful too.
> > >
> > > Simon
> > >
> > >
> >
> > The test program is the best I could manage under difficult
> > constraints.  It does (currently) generate a lexical block with a
> > DW_AT_ranges attribute of the form DW_FORM_rnglistx, if it is compiled
> > with clang.  If it is compiled with GCC, then, sadly,  the
> > DW_AT_ranges is not of the form DW_FORM_rnglistx, so the test always
> > passes.  In order to test with clang, I do:
> >
> > $ export CLANG_CC="/usr/local/google3/cmtice/llvm-project/build2/bin/clang"
> > $ export CLANG_CXX="/usr/local/google3/cmtice/llvm-project/build2/bin/clang++"
> >
> > $ make check RUNTESTFLAGS="CC_FOR_TARGET=${CLANG_CC}
> > CXX_FOR_TARGET=${CLANG_CXX} dw5-rnglist-test.exp"
> >
> > With ToT GDB (without my patch), the result is:
> >
> > Running /usr/local/google/home/cmtice/fsf-gdb.clean.obj/gdb/testsuite/../../../fsf-gdb.clean/gdb/testsuite/gdb.dwarf2/dw5-rnglist-test.exp
> > ...
> > FAIL: gdb.dwarf2/dw5-rnglist-test.exp: print curr
> > FAIL: gdb.dwarf2/dw5-rnglist-test.exp: print *curr
> >
> > === gdb Summary ===
> >
> > # of expected passes 1
> > # of unexpected failures 2
> >
> > I did try, originally, to make this an assembly code test, as I do
> > understand that compilers change, and the code they generate today is
> > not necessarily the code they generate tomorrow.  Unfortunately the
> > GNU assembler cannot process the DWARF v5 that is generated by clang
> > (e.g. it can't handle file numbers that start at 0 instead of 1 (which
> > is in the DWARF v5 spec, and which clang generates); and I have not
> > been able to figure out a way to get GDB test to use the clang
> > integrated assembler.
> >
>
> I have used object files in binutils tests:
>
> commit d0dded5bc251e506ef65b13696c624ea8669ed6e
> Author: H.J. Lu <hjl.tools@gmail.com>
> Date:   Tue Jun 23 09:19:05 2020 -0700
>
>     Add a testcase for PR binutils/26160
>
>             PR binutils/26160
>             * testsuite/binutils-all/pr26160.dwp.bz2: New file.
>             * testsuite/binutils-all/pr26160.r: Likewise.
>             * testsuite/binutils-all/readelf.exp: Run PR binutils/26160 test.
>
> --
> H.J.