gdb/testsuite/dwarf: use single abbrev table in .dwo files

gdb/testsuite/dwarf: use single abbrev table in .dwo files

When I wrote test gdb.dwarf2/fission-with-type-unit.exp, I did not use
build_executable_and_dwo_files, because it wouldn't work to have
multiple units in the .dwo file, each referring to their own abbrev
table using labels.  build_executable_and_dwo_files extracts the .dwo
file content from the .o using objcopy (just like gcc does, I learned),
meaning that the .dwo file never runs through a linker.  Anything
needing relocation (like labels pointing to abbrev tables) doesn't work.

I instead opted to use gdb_compile_shlib to build the .dwo file on its
own, so that those labels would get resolved.  That causes problems now
that I'm trying to write a test with multiple type units in a .dwo file,
where each type unit should be in its own .debug_types section.  Running
the .dwo file through the linker causes all the .debug_types section to
be collapsed into one.  And generally, I think it was a bad idea to
generate a .dwo file using the linker, since the idea behind .dwo files
is that they do not need to be linked (therefore improving link
times).  We want to produce files as close to what an actual compiler
would produce.

This patch fixes this by doing what compilers do in the same situation:
use a single abbrev table shared by all units in the .dwo file.  This
requires the following changes in lib/dwarf.exp:

 - Declare a new variable _dwo_abbrev_num, which holds the next
   abbrev number to use in the .dwo file's abbrev section
   (.debug_abbrev.dwo).  Initialize this variable to 1.
 - When producing a CU or TU in a .dwo file, use 0 as the abbrev table
   offset.
 - When generating a DIE, return $_dwo_abbrev_num or $_abbrev_num,
   depending on whether the current CU is in a .dwo file.
 - After producing a CU or TU in a .dwo file, don't append the
   terminator byte.
 - After finishing producing the CUs and TUs, append the terminator byte
   in .debug_abbrev.dwo if we did output anything there.

Update gdb.dwarf2/fission-with-type-unit.exp to use
build_executable_and_dwo_files, as it should.  Remove the
gdb_remote_download call from gdb.dwarf/fission-with-type-unit.exp,
because build_executable_and_dwo_files does not support remote hosts
anyway.

With this change, running with the cc-with-gdb-index board, I see:

    (gdb) maint expand-symtabs
    /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:3056: internal-error: cutu_reader: Assertion `sig_type->signature == cu->header.signature' failed.
    A problem internal to GDB has been detected,
    further debugging may prove unreliable.
    ----- Backtrace -----
    FAIL: gdb.dwarf2/fission-with-type-unit.exp: maint expand-symtabs (GDB internal error)

This is actually an improvement, as the test case didn't run properly
before.  The compilation failed with:

    gdb compile failed, During symbol reading: Could not find DWO CU fission-with-type-unit.dwo(0xf00d) referenced by CU at offset 0xc [in module /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.dwarf2/fission-with-type-unit/.tmp/fission-with-type-unit]

The reason was that the old code would try to generate the GDB index
during this step:

    # Build main file.
    if { [build_executable "${testfile}.exp" $binfile \
   	 [list ${srcfile} ${main_asm_file}] {nodebug}] } {
        return
    }

... which is before the DWO file is even generated.  With this patch
things are done in the correct order:

 - The -dw.S file is generated
 - The -dw.o file is compiled from the -dw.S
 - The .dwo sections are extracted to the .dwo file, and stripped from
   the -dw.o file
 - The executable is linked from the .o and -dw.o
 - gdb-add-index is ran on the executable

When gdb-add-index runs, the .dwo file exists, so GDB is able to produce
an index.  That index is bogus though, because the .gdb_index format is
unable to describe skeletonless type units.  And then GDB gets confused
trying to use that index, leading to the internal error.

Change-Id: Iabbcf00db97faf2a4fa5fc71652ad273081189f9
Approved-By: Andrew Burgess <aburgess@redhat.com>