From: Tom Tromey Date: Mon, 20 Nov 2023 04:09:57 +0000 (-0700) Subject: Give names to unspecified types X-Git-Tag: gdb-15-branchpoint~1121 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=790948cb0933c835e76ada717ab857852813e04f;p=thirdparty%2Fbinutils-gdb.git Give names to unspecified types A patch later in this series will change check_typedef to also look in the type domain. This change by itself caused a regression, but one that revealed some peculiar behavior. The regression is in nullptr_t.exp, where examining a std::nullptr_t will change from the correct: typedef decltype(nullptr) std::nullptr_t; to typedef void std::nullptr_t; Right now, the DWARF reader marks all unspecified types as stub types. However, this interacts weirdly with check_typedef, which currently does not try to resolve types -- only struct-domain objects. My first attempt here was to fix this by changing void types not to be stub types, as I didn't see what value that provided. However, this caused another regression, because call_function_by_hand_dummy checks for stub-ness: if (values_type == NULL || values_type->is_stub ()) values_type = default_return_type; I'm not really sure why it does this rather than check for TYPE_CODE_VOID. While looking into this, I found another oddity: the DWARF reader correctly creates a type named 'decltype(nullptr)' when it seems a DW_TAG_unspecified_type -- but it creates a symbol named "void" instead. This patch changes the DWARF reader to give the symbol the correct name. This avoids the regression. --- diff --git a/gdb/dwarf2/read.c b/gdb/dwarf2/read.c index 1cc19b57ba8..82f969a3043 100644 --- a/gdb/dwarf2/read.c +++ b/gdb/dwarf2/read.c @@ -6492,6 +6492,7 @@ process_die (struct die_info *die, struct dwarf2_cu *cu) case DW_TAG_subrange_type: case DW_TAG_generic_subrange: case DW_TAG_typedef: + case DW_TAG_unspecified_type: /* Add a typedef symbol for the type definition, if it has a DW_AT_name. */ new_symbol (die, read_type_die (die, cu), cu);