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

[H.J. Lu]

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.