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

[Caroline Tice]

The attached patch has an updated  commit message that explains how to
run the test and what version of clang was used.  Other than that it
is identical  to the previous patch.

On Wed, Jul 15, 2020 at 7:35 PM Simon Marchi <simark@simark.ca> wrote:
>
> On 2020-07-15 6:35 p.m., Caroline Tice wrote:
> > 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.
>
> I'd be fine merging the patch with the current test and keep working on
> improving the test coverage.  I think that we'll need indeed need to do
> a bit of infrastructure work to improve the testing of DWARF5 in general.
>
> Can you please provide a final patch version where you mention in the commit
> message how to run the test in order to provoke a failure.  Please make sure
> to include the compiler version as well (output of `clang --version`) because,
> as you said, the code compilers output changes with time.  So in order to be
> able to reproduce the failure, it would be useful to know the compiler version.
>
Done.

> I'm not sure what you mean by "the .o version of the test case".  Do you
> mean check-in the .o in the git repository?  We currently don't check in
> binary test artifacts for GDB.  However, I'm of the opinion that it could
> be useful sometimes (like here).  But we'd need to have a discussion
> about this first, how we want to do that, which guidelines to follow.
>

I'll submit a separate patch, where it can be discussed.

> About this comment, in your other message:
>
> > 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.
>
> Just wondering, doesn't gcc emit at least *some* DWARF 5 by now?  If so,
> can't the GNU assembler deal with it?
>

Not that it matters for this patch, but I believe you are
misunderstanding the situation. GCC *does* emit some  DWARF 5, but at
least the GCC version I'm using (Debian 9.3.0-8) does not seem to be
generating DWARF v5 line table sections; the line table section it
generates (when I compile with -gdwarf-5) is a DWARF v3 .debug_line
sections.

In fact my gcc-generated binary has the following debug sections,
which are a mix of various dwarf versions:

.debug_aranges               (dwarf v2)
.debug_info                      (dwarf v5)
.debug_abbrev                 (dwarf v5)
.debug_line                      (dwarf v3)
.debug_str
.debug_addr                    (dwarf v5)
.debug_gnu_pubnames  (dwarf v2)
.debug_gnu_pubtypes    (dwarf v2)
.debug_rnglists               (dwarf v5)

In contrast, here are the sections my clang compiler, when passed
-gdwarf-5 is generating dwarf v5 versions
of nearly all the sections:

.debug_info                      (dwarf v5)
.debug_abbrev                 (dwarf v5)
.debug_line                      (dwarf v5)
.debug_str
.debug_addr                     (dwarf v5)
.debug_rnglists                (dwarf v5)
.debug_str_offsets           (dwarf v5)
.debug_gnu_pubnames   (dwarf v2)
.debug_gnu_pubtypes     (dwarf v2)
.debug_line_str                (dwarf v5)

So either the GNU assembler has not been updated to handle DWARF v5
.debug_line file indices because GCC is not yet generating them; or
GCC is not yet generating them because the GNU assembler has not yet
been
updated to handle them.  Take your pick.

In any case, I hope my patch is now acceptable! :-)

-- Caroline Tice
cmtice@google.com

> Simon
-------------- next part --------------
A non-text attachment was scrubbed...
Name: v6-0001-Update-GDB-to-fix-issues-with-handling-DWARF-v5-r.patch
Type: application/octet-stream
Size: 27644 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/gdb-patches/attachments/20200715/a5a4bffa/attachment-0001.obj>