gdb/dwarf2: pass correct dwarf2_cu to lookup_dwo_id in create_cus_hash_table

Commit 71a48752660b ("gdb/dwarf: remove create_dwo_cu_reader")
introduced a regression when handling files compiled with "-gsplit-dwarf
-fdebug-types-section" (at least with clang):

    $ cat test.cpp
    #include <vector>

    int main()
    {
      std::vector<int> v;
      return v.size ();
    }
    $ clang++ -O0 test.cpp -g -gdwarf-5 -gsplit-dwarf -fdebug-types-section -o test
    $ ./gdb -nx -q --data-directory=data-directory ./test -ex "maint expand-symtabs"
    Reading symbols from ./test...
    /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:6159: internal-error: setup_type_unit_groups: Assertion `per_cu->is_debug_types' failed.

In the main file, we have a skeleton CU with a certain DWO ID:

    0x00000000: Compile Unit: ..., unit_type = DW_UT_skeleton, ..., DWO_id = 0x146eaa4daf5deef2, ...

In the .dwo file, the first unit is a type unit with a certain type
signature:

    0x00000000: Type Unit: ..., unit_type = DW_UT_split_type, ..., type_signature = 0xb499dcf29e2928c4, ...

and the split compile unit matching the DWO ID from the skeleton from
the main file comes later:

    0x0000117f: Compile Unit: ..., unit_type = DW_UT_split_compile, ..., DWO_id = 0x146eaa4daf5deef2, ...

The problem introduced by the aforementioned commit is that when
creating a dwo_unit structure representing the type unit, we use the
signature (DWO id) from the skeleton, instead of the signature from the
type unit's header.  As a result, all dwo_units get created with the
same signature (the DWO id) and only the first unit gets inserted in the
hash table.  When looking up the comp unit by DWO ID later on, we
wrongly find the type unit, and try to expand a type unit as a comp
unit, hitting the assert.

Before that commit, we passed `reader.cu ()` to lookup_dwo_id, which
yields a dwarf2_cu built from parsing the type unit's header.  This
dwarf2_cu contains the comp_unit_header with the correct signature.  Fix
the code to use `reader.cu ()` again.

Another thing that enables this bug is the fact that since DWARF 5, type
and compile units are all in .debug_info, and therefore read by
create_cus_hash_table, so they both end up in dwo_file::cus.  Type units
should end up in dwo_file::tus, otherwise they won't be found by
lookup_dwo_cutu.  This bug hasn't given me trouble so far, so I'm not
fixing it right now, but it's on my todo list.

The problem can be seen with some tests, when using the
dwarf5-fission-debug-types board:

    $ make check TESTS="gdb.cp/expand-sals.exp" RUNTESTFLAGS="--target_board=dwarf5-fission-debug-types CC_FOR_TARGET=clang CXX_FOR_TARGET=clang++"
    Running /home/simark/src/binutils-gdb/gdb/testsuite/gdb.cp/expand-sals.exp ...
    FAIL: gdb.cp/expand-sals.exp: gdb_breakpoint: set breakpoint at main (GDB internal error)

But this patch also adds a DWARF assembler-based test that triggers the
internal error.

Note that the new test does not use the build_executable_and_dwo_files
proc, because I found that it is subtly broken and doesn't work to put
multiple units in a single .dwo file.  The debug abbrev offset field in
the second unit's header would be 0, when it should have been something
else.  The problem is that no linking is ever done to generate the .dwo
file, so the relocation that would apply for this field is never
applied.  Instead, I generate two DWARF debug infos separately and link
the .dwo file using gdb_compile, it seems to work fine.

Change-Id: I96f809c56f703e25f72b8622c32e6bb91de20d6a
Approved-By: Tom Tromey <tom@tromey.com>

0 files changed, 0 insertions, 0 deletions