From: Tom Tromey Date: Sat, 11 Mar 2023 16:51:23 +0000 (-0700) Subject: Add some types to struct builtin_type X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=a9a775da56aaaadf906589600f5861a2c80a09a4;p=binutils-gdb.git Add some types to struct builtin_type This adds some types to struct builtin_type, ensuring it contains all the types currently used by objfile_type. Reviewed-By: Simon Marchi --- diff --git a/gdb/gdbtypes.c b/gdb/gdbtypes.c index d45452ecefe..79468332ff5 100644 --- a/gdb/gdbtypes.c +++ b/gdb/gdbtypes.c @@ -6061,6 +6061,56 @@ create_gdbtypes_data (struct gdbarch *gdbarch) builtin_type->xmethod = alloc.new_type (TYPE_CODE_XMETHOD, 0, ""); + /* This type represents a type that was unrecognized in symbol read-in. */ + builtin_type->builtin_error + = alloc.new_type (TYPE_CODE_ERROR, 0, ""); + + /* The following set of types is used for symbols with no + debug information. */ + builtin_type->nodebug_text_symbol + = alloc.new_type (TYPE_CODE_FUNC, TARGET_CHAR_BIT, + ""); + + builtin_type->nodebug_text_gnu_ifunc_symbol + = alloc.new_type (TYPE_CODE_FUNC, TARGET_CHAR_BIT, + ""); + builtin_type->nodebug_text_gnu_ifunc_symbol->set_is_gnu_ifunc (true); + + builtin_type->nodebug_got_plt_symbol + = init_pointer_type (alloc, gdbarch_addr_bit (gdbarch), + "", + builtin_type->nodebug_text_symbol); + builtin_type->nodebug_data_symbol + = alloc.new_type (TYPE_CODE_ERROR, 0, ""); + builtin_type->nodebug_unknown_symbol + = alloc.new_type (TYPE_CODE_ERROR, 0, + ""); + builtin_type->nodebug_tls_symbol + = alloc.new_type (TYPE_CODE_ERROR, 0, + ""); + + /* NOTE: on some targets, addresses and pointers are not necessarily + the same. + + The upshot is: + - gdb's `struct type' always describes the target's + representation. + - gdb's `struct value' objects should always hold values in + target form. + - gdb's CORE_ADDR values are addresses in the unified virtual + address space that the assembler and linker work with. Thus, + since target_read_memory takes a CORE_ADDR as an argument, it + can access any memory on the target, even if the processor has + separate code and data address spaces. + + In this context, builtin_type->builtin_core_addr is a bit odd: + it's a target type for a value the target will never see. It's + only used to hold the values of (typeless) linker symbols, which + are indeed in the unified virtual address space. */ + + builtin_type->builtin_core_addr + = init_integer_type (alloc, gdbarch_addr_bit (gdbarch), 1, + "__CORE_ADDR"); return builtin_type; } diff --git a/gdb/gdbtypes.h b/gdb/gdbtypes.h index 1b9a055dab3..bce7c35160e 100644 --- a/gdb/gdbtypes.h +++ b/gdb/gdbtypes.h @@ -2098,6 +2098,21 @@ struct builtin_type /* * This type is used to represent an xmethod. */ struct type *xmethod = nullptr; + + /* * This type is used to represent symbol addresses. */ + struct type *builtin_core_addr = nullptr; + + /* * This type represents a type that was unrecognized in symbol + read-in. */ + struct type *builtin_error = nullptr; + + /* * Types used for symbols with no debug information. */ + struct type *nodebug_text_symbol = nullptr; + struct type *nodebug_text_gnu_ifunc_symbol = nullptr; + struct type *nodebug_got_plt_symbol = nullptr; + struct type *nodebug_data_symbol = nullptr; + struct type *nodebug_unknown_symbol = nullptr; + struct type *nodebug_tls_symbol = nullptr; }; /* * Return the type table for the specified architecture. */