gdb/dwarf2/read.c: Handle empty CU name

I recently came across a case where a compiler would emit a CU with an
empty name.  In such case, the attribute object constructed by GDB will
return nullptr when as_string is called.  One place is not checking for
this possibility.  As a result, loading such binary results in a GDB
crash:

    $ gdb -q a.out
    Reading symbols from a.out...

    Fatal signal: Segmentation fault
    ----- Backtrace -----
    [...]
    0x742f4dd8afab __strcmp_avx2
            ../sysdeps/x86_64/multiarch/strcmp-avx2.S:283
    0x58593704a0bc prepare_one_comp_unit
            ../../gdb/dwarf2/read.c:21842
    0x585937053fd9 process_psymtab_comp_unit
            ../../gdb/dwarf2/read.c:4633
    0x585937053fd9 _ZN23cooked_index_debug_info11process_cusEmN9__gnu_cxx17__normal_iteratorIPSt10unique_ptrI18dwarf2_per_cu_data26dwarf2_per_cu_data_deleterESt6vectorIS5_SaIS5_EEEESA_
            ../../gdb/dwarf2/read.c:4943
    [...]
    ---------------------
    A fatal error internal to GDB has been detected, further
    debugging is not possible.  GDB will now terminate.

    This is a bug, please report it.  For instructions, see:
    <https://www.gnu.org/software/gdb/bugs/>.

    Segmentation fault (core dumped)

This seems to be a regression introduced by the following commit:

    commit 00105aa1c4d9933fe3cfe9bc1be0daefe9f8ca36
    Date:   Tue Sep 24 10:24:22 2024 +0200

        [gdb/symtab] Don't expand non-Ada CUs for info exceptions

This patch fixes this issue by checking if attr->as_string returns
nullptr.

Change-Id: I78fe7a090f0bd1045b8cb2f8d088a8d6cf57fe1c
Approved-By: Andrew Burgess <aburgess@redhat.com>
Approved-By: Tom Tromey <tom@tromey.com>

0 files changed, 0 insertions, 0 deletions