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

[Simon Marchi]

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.

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.

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?

Simon