mirror of
https://sourceware.org/git/binutils-gdb.git
synced 2024-12-02 14:53:46 +08:00
1d506c26d9
This commit is the result of the following actions:
- Running gdb/copyright.py to update all of the copyright headers to
include 2024,
- Manually updating a few files the copyright.py script told me to
update, these files had copyright headers embedded within the
file,
- Regenerating gdbsupport/Makefile.in to refresh it's copyright
date,
- Using grep to find other files that still mentioned 2023. If
these files were updated last year from 2022 to 2023 then I've
updated them this year to 2024.
I'm sure I've probably missed some dates. Feel free to fix them up as
you spot them.
132 lines
4.7 KiB
Modula-2
132 lines
4.7 KiB
Modula-2
/* Type codes for GDB.
|
|
|
|
Copyright (C) 1992-2024 Free Software Foundation, Inc.
|
|
|
|
This file is part of GDB.
|
|
|
|
This program is free software; you can redistribute it and/or modify
|
|
it under the terms of the GNU General Public License as published by
|
|
the Free Software Foundation; either version 3 of the License, or
|
|
(at your option) any later version.
|
|
|
|
This program is distributed in the hope that it will be useful,
|
|
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
GNU General Public License for more details.
|
|
|
|
You should have received a copy of the GNU General Public License
|
|
along with this program. If not, see <http://www.gnu.org/licenses/>. */
|
|
|
|
OP (TYPE_CODE_PTR) /**< Pointer type */
|
|
|
|
/* * Array type with lower & upper bounds.
|
|
|
|
Regardless of the language, GDB represents multidimensional
|
|
array types the way C does: as arrays of arrays. So an
|
|
instance of a GDB array type T can always be seen as a series
|
|
of instances of T->target_type () laid out sequentially in
|
|
memory.
|
|
|
|
Row-major languages like C lay out multi-dimensional arrays so
|
|
that incrementing the rightmost index in a subscripting
|
|
expression results in the smallest change in the address of the
|
|
element referred to. Column-major languages like Fortran lay
|
|
them out so that incrementing the leftmost index results in the
|
|
smallest change.
|
|
|
|
This means that, in column-major languages, working our way
|
|
from type to target type corresponds to working through indices
|
|
from right to left, not left to right. */
|
|
OP (TYPE_CODE_ARRAY)
|
|
|
|
OP (TYPE_CODE_STRUCT) /**< C struct or Pascal record */
|
|
OP (TYPE_CODE_UNION) /**< C union or Pascal variant part */
|
|
OP (TYPE_CODE_ENUM) /**< Enumeration type */
|
|
OP (TYPE_CODE_FLAGS) /**< Bit flags type */
|
|
OP (TYPE_CODE_FUNC) /**< Function type */
|
|
OP (TYPE_CODE_INT) /**< Integer type */
|
|
|
|
/* * Floating type. This is *NOT* a complex type. */
|
|
OP (TYPE_CODE_FLT)
|
|
|
|
/* * Void type. The length field specifies the length (probably
|
|
always one) which is used in pointer arithmetic involving
|
|
pointers to this type, but actually dereferencing such a
|
|
pointer is invalid; a void type has no length and no actual
|
|
representation in memory or registers. A pointer to a void
|
|
type is a generic pointer. */
|
|
OP (TYPE_CODE_VOID)
|
|
|
|
OP (TYPE_CODE_SET) /**< Pascal sets */
|
|
OP (TYPE_CODE_RANGE) /**< Range (integers within spec'd bounds). */
|
|
|
|
/* * A string type which is like an array of character but prints
|
|
differently. It does not contain a length field as Pascal
|
|
strings (for many Pascals, anyway) do; if we want to deal with
|
|
such strings, we should use a new type code. */
|
|
OP (TYPE_CODE_STRING)
|
|
|
|
/* * Unknown type. The length field is valid if we were able to
|
|
deduce that much about the type, or 0 if we don't even know
|
|
that. */
|
|
OP (TYPE_CODE_ERROR)
|
|
|
|
/* C++ */
|
|
OP (TYPE_CODE_METHOD) /**< Method type */
|
|
|
|
/* * Pointer-to-member-function type. This describes how to access a
|
|
particular member function of a class (possibly a virtual
|
|
member function). The representation may vary between different
|
|
C++ ABIs. */
|
|
OP (TYPE_CODE_METHODPTR)
|
|
|
|
/* * Pointer-to-member type. This is the offset within a class to
|
|
some particular data member. The only currently supported
|
|
representation uses an unbiased offset, with -1 representing
|
|
NULL; this is used by the Itanium C++ ABI (used by GCC on all
|
|
platforms). */
|
|
OP (TYPE_CODE_MEMBERPTR)
|
|
|
|
OP (TYPE_CODE_REF) /**< C++ Reference types */
|
|
|
|
OP (TYPE_CODE_RVALUE_REF) /**< C++ rvalue reference types */
|
|
|
|
OP (TYPE_CODE_CHAR) /**< *real* character type */
|
|
|
|
/* * Boolean type. 0 is false, 1 is true, and other values are
|
|
non-boolean (e.g. FORTRAN "logical" used as unsigned int). */
|
|
OP (TYPE_CODE_BOOL)
|
|
|
|
/* Fortran */
|
|
OP (TYPE_CODE_COMPLEX) /**< Complex float */
|
|
|
|
OP (TYPE_CODE_TYPEDEF)
|
|
|
|
OP (TYPE_CODE_NAMESPACE) /**< C++ namespace. */
|
|
|
|
OP (TYPE_CODE_DECFLOAT) /**< Decimal floating point. */
|
|
|
|
OP (TYPE_CODE_MODULE) /**< Fortran module. */
|
|
|
|
/* * Internal function type. */
|
|
OP (TYPE_CODE_INTERNAL_FUNCTION)
|
|
|
|
/* * Methods implemented in extension languages. */
|
|
OP (TYPE_CODE_XMETHOD)
|
|
|
|
/* * Fixed Point type. */
|
|
OP (TYPE_CODE_FIXED_POINT)
|
|
|
|
/* * Fortran namelist is a group of variables or arrays that can be
|
|
read or written.
|
|
|
|
Namelist syntax: NAMELIST / groupname / namelist_items ...
|
|
NAMELIST statement assign a group name to a collection of variables
|
|
called as namelist items. The namelist items can be of any data type
|
|
and can be variables or arrays.
|
|
|
|
Compiler emit DW_TAG_namelist for group name and DW_TAG_namelist_item
|
|
for each of the namelist items. GDB process these namelist dies
|
|
and print namelist variables during print and ptype commands. */
|
|
OP (TYPE_CODE_NAMELIST)
|