GDB's target architecture defines what sort of machine-language programs GDB can work with, and how it works with them.
The target architecture object is implemented as the C structure
struct gdbarch *
. The structure, and its methods, are generated
using the Bourne shell script `gdbarch.sh'.
GDB provides a mechanism for handling variations in OS ABIs. An OS ABI variant may have influence over any number of variables in the target architecture definition. There are two major components in the OS ABI mechanism: sniffers and handlers.
A sniffer examines a file matching a BFD architecture/flavour pair
(the architecture may be wildcarded) in an attempt to determine the
OS ABI of that file. Sniffers with a wildcarded architecture are considered
to be generic, while sniffers for a specific architecture are
considered to be specific. A match from a specific sniffer
overrides a match from a generic sniffer. Multiple sniffers for an
architecture/flavour may exist, in order to differentiate between two
different operating systems which use the same basic file format. The
OS ABI framework provides a generic sniffer for ELF-format files which
examines the EI_OSABI
field of the ELF header, as well as note
sections known to be used by several operating systems.
A handler is used to fine-tune the gdbarch
structure for the
selected OS ABI. There may be only one handler for a given OS ABI
for each BFD architecture.
The following OS ABI variants are defined in `osabi.h':
GDB_OSABI_UNKNOWN
gdbarch
settings for the architecture will be used.
GDB_OSABI_SVR4
GDB_OSABI_HURD
GDB_OSABI_SOLARIS
GDB_OSABI_OSF1
GDB_OSABI_LINUX
GDB_OSABI_FREEBSD_AOUT
GDB_OSABI_FREEBSD_ELF
GDB_OSABI_NETBSD_AOUT
GDB_OSABI_NETBSD_ELF
GDB_OSABI_WINCE
GDB_OSABI_GO32
GDB_OSABI_NETWARE
GDB_OSABI_ARM_EABI_V1
GDB_OSABI_ARM_EABI_V2
GDB_OSABI_ARM_APCS
Here are the functions that make up the OS ABI framework:
bfd_arch_unknown
, the sniffer is considered to
be generic, and is allowed to examine flavour-flavoured files for
any architecture.
GDB_OSABI_UNKNOWN
is returned if the OS ABI cannot
be determined.
gdbarch
structure specified by gdbarch. If a handler
corresponding to osabi has not been registered for gdbarch's
architecture, a warning will be issued and the debugging session will continue
with the defaults already established for gdbarch.
GDB's model of the target machine is rather simple. GDB assumes the machine includes a bank of registers and a block of memory. Each register may have a different size.
GDB does not have a magical way to match up with the
compiler's idea of which registers are which; however, it is critical
that they do match up accurately. The only way to make this work is
to get accurate information about the order that the compiler uses,
and to reflect that in the REGISTER_NAME
and related macros.
GDB can handle big-endian, little-endian, and bi-endian architectures.
On almost all 32-bit architectures, the representation of a pointer is indistinguishable from the representation of some fixed-length number whose value is the byte address of the object pointed to. On such machines, the words "pointer" and "address" can be used interchangeably. However, architectures with smaller word sizes are often cramped for address space, so they may choose a pointer representation that breaks this identity, and allows a larger code address space.
For example, the Renesas D10V is a 16-bit VLIW processor whose instructions are 32 bits long(3). If the D10V used ordinary byte addresses to refer to code locations, then the processor would only be able to address 64kb of instructions. However, since instructions must be aligned on four-byte boundaries, the low two bits of any valid instruction's byte address are always zero--byte addresses waste two bits. So instead of byte addresses, the D10V uses word addresses--byte addresses shifted right two bits--to refer to code. Thus, the D10V can use 16-bit words to address 256kb of code space.
However, this means that code pointers and data pointers have different
forms on the D10V. The 16-bit word 0xC020
refers to byte address
0xC020
when used as a data address, but refers to byte address
0x30080
when used as a code address.
(The D10V also uses separate code and data address spaces, which also affects the correspondence between pointers and addresses, but we're going to ignore that here; this example is already too long.)
To cope with architectures like this--the D10V is not the only
one!---GDB tries to distinguish between addresses, which are
byte numbers, and pointers, which are the target's representation
of an address of a particular type of data. In the example above,
0xC020
is the pointer, which refers to one of the addresses
0xC020
or 0x30080
, depending on the type imposed upon it.
GDB provides functions for turning a pointer into an address
and vice versa, in the appropriate way for the current architecture.
Unfortunately, since addresses and pointers are identical on almost all processors, this distinction tends to bit-rot pretty quickly. Thus, each time you port GDB to an architecture which does distinguish between pointers and addresses, you'll probably need to clean up some architecture-independent code.
Here are functions which convert between pointers and addresses:
For example, if the current architecture is the Intel x86, this function extracts a little-endian integer of the appropriate length from buf and returns it. However, if the current architecture is the D10V, this function will return a 16-bit integer extracted from buf, multiplied by four if type is a pointer to a function.
If type is not a pointer or reference type, then this function will signal an internal error.
For example, if the current architecture is the Intel x86, this function stores addr unmodified as a little-endian integer of the appropriate length in buf. However, if the current architecture is the D10V, this function divides addr by four if type is a pointer to a function, and then stores it in buf.
If type is not a pointer or reference type, then this function will signal an internal error.
This function actually works on integral values, as well as pointers.
For pointers, it performs architecture-specific conversions as
described above for extract_typed_address
.
store_typed_address
.
Here are some macros which architectures can define to indicate the relationship between pointers and addresses. These have default definitions, appropriate for architectures on which all pointers are simple unsigned byte addresses.
This function may safely assume that type is either a pointer or a C++ reference type.
This function may safely assume that type is either a pointer or a C++ reference type.
Sometimes information about different kinds of addresses is available
via the debug information. For example, some programming environments
define addresses of several different sizes. If the debug information
distinguishes these kinds of address classes through either the size
info (e.g, DW_AT_byte_size
in DWARF 2) or through an explicit
address class attribute (e.g, DW_AT_address_class
in DWARF 2), the
following macros should be defined in order to disambiguate these
types within GDB as well as provide the added information to
a GDB user when printing type expressions.
int
refererenced by type_flags_ptr to the type flags
for that address class qualifier.
Since the need for address classes is rather rare, none of the address class macros defined by default. Predicate macros are provided to detect when they are defined.
Consider a hypothetical architecture in which addresses are normally
32-bits wide, but 16-bit addresses are also supported. Furthermore,
suppose that the DWARF 2 information for this architecture simply
uses a DW_AT_byte_size
value of 2 to indicate the use of one
of these "short" pointers. The following functions could be defined
to implement the address class macros:
somearch_address_class_type_flags (int byte_size, int dwarf2_addr_class) { if (byte_size == 2) return TYPE_FLAG_ADDRESS_CLASS_1; else return 0; } static char * somearch_address_class_type_flags_to_name (int type_flags) { if (type_flags & TYPE_FLAG_ADDRESS_CLASS_1) return "short"; else return NULL; } int somearch_address_class_name_to_type_flags (char *name, int *type_flags_ptr) { if (strcmp (name, "short") == 0) { *type_flags_ptr = TYPE_FLAG_ADDRESS_CLASS_1; return 1; } else return 0; }
The qualifier @short
is used in GDB's type expressions
to indicate the presence of one of these "short" pointers. E.g, if
the debug information indicates that short_ptr_var
is one of these
short pointers, GDB might show the following behavior:
(gdb) ptype short_ptr_var type = int * @short
Maintainer note: This section is pretty much obsolete. The functionality described here has largely been replaced by pseudo-registers and the mechanisms described in section Target Architecture Definition. See also @uref{http://www.gnu.org/software/gdb/bugs/, Bug Tracking Database and @uref{http://sources.redhat.com/gdb/current/ari/, ARI Index} for more up-to-date information.}
Some architectures use one representation for a value when it lives in a
register, but use a different representation when it lives in memory.
In GDB's terminology, the raw representation is the one used in
the target registers, and the virtual representation is the one
used in memory, and within GDB struct value
objects.
Maintainer note: Notice that the same mechanism is being used to
both convert a register to a struct value
and alternative
register forms.
For almost all data types on almost all architectures, the virtual and raw representations are identical, and no special handling is needed. However, they do occasionally differ. For example:
long double
type. However, when
we store those values in memory, they occupy twelve bytes: the
floating-point number occupies the first ten, and the final two bytes
are unused. This keeps the values aligned on four-byte boundaries,
allowing more efficient access. Thus, the x86 80-bit floating-point
type is the raw representation, and the twelve-byte loosely-packed
arrangement is the virtual representation.
In general, the raw representation is determined by the architecture, or
GDB's interface to the architecture, while the virtual representation
can be chosen for GDB's convenience. GDB's register file,
registers
, holds the register contents in raw format, and the
GDB remote protocol transmits register values in raw format.
Your architecture may define the following macros to request conversions between the raw and virtual format:
You should not use REGISTER_CONVERT_TO_VIRTUAL
for a register
unless this macro returns a non-zero value for that register.
registers
, or in a GDB
remote protocol packet.
struct value
's buffer will have, holding that
register's value.
DEPRECATED_REGISTER_VIRTUAL_TYPE (reg)
. The buffer
at from holds the register's value in raw format; the macro should
convert the value to virtual format, and place it at to.
Note that REGISTER_CONVERT_TO_VIRTUAL
and
REGISTER_CONVERT_TO_RAW
take their reg and type
arguments in different orders.
You should only use REGISTER_CONVERT_TO_VIRTUAL
with registers
for which the REGISTER_CONVERTIBLE
macro returns a non-zero
value.
DEPRECATED_REGISTER_VIRTUAL_TYPE (reg)
. The buffer
at from holds the register's value in raw format; the macro should
convert the value to virtual format, and place it at to.
Note that REGISTER_CONVERT_TO_VIRTUAL and REGISTER_CONVERT_TO_RAW take their reg and type arguments in different orders.
Maintainer's note: The way GDB manipulates registers is undergoing significant change. Many of the macros and functions refered to in this section are likely to be subject to further revision. See @uref{http://sources.redhat.com/gdb/current/ari/, A.R. Index and @uref{http://www.gnu.org/software/gdb/bugs, Bug Tracking Database} for further information. cagney/2002-05-06.}
Some architectures can represent a data object in a register using a form that is different to the objects more normal memory representation. For example:
long double
data type occupies 96 bits in memory but only 80 bits
when stored in a register.
In general, the register representation of a data type is determined by the architecture, or GDB's interface to the architecture, while the memory representation is determined by the Application Binary Interface.
For almost all data types on almost all architectures, the two representations are identical, and no special handling is needed. However, they do occasionally differ. Your architecture may define the following macros to request conversions between the register and memory representations of a data type:
When non-zero, the macros REGISTER_TO_VALUE
and
VALUE_TO_REGISTER
are used to perform any necessary conversion.
Note that REGISTER_TO_VALUE
and VALUE_TO_REGISTER
take
their reg and type arguments in different orders.
You should only use REGISTER_TO_VALUE
with registers for which
the CONVERT_REGISTER_P
macro returns a non-zero value.
Note that REGISTER_TO_VALUE
and VALUE_TO_REGISTER
take
their reg and type arguments in different orders.
You should only use VALUE_TO_REGISTER
with registers for which
the CONVERT_REGISTER_P
macro returns a non-zero value.
This section describes the macros that you can use to define the target machine.
ADDR_BITS_REMOVE (addr)
((addr) & ~3)
.
ADDRESS_CLASS_NAME_TO_TYPE_FLAGS (name, type_flags_ptr)
int
referenced by type_flags_ptr to the mask representing the qualifier
and return 1. If name is not a valid address class qualifier name,
return 0.
The value for type_flags_ptr should be one of
TYPE_FLAG_ADDRESS_CLASS_1
, TYPE_FLAG_ADDRESS_CLASS_2
, or
possibly some combination of these values or'd together.
See section Target Architecture Definition.
ADDRESS_CLASS_NAME_TO_TYPE_FLAGS_P ()
ADDRESS_CLASS_NAME_TO_TYPE_FLAGS
has been defined.
ADDRESS_CLASS_TYPE_FLAGS (byte_size, dwarf2_addr_class)
DW_AT_address_class
value, return the type flags
used by GDB to represent this address class. The value
returned should be one of TYPE_FLAG_ADDRESS_CLASS_1
,
TYPE_FLAG_ADDRESS_CLASS_2
, or possibly some combination of these
values or'd together.
See section Target Architecture Definition.
ADDRESS_CLASS_TYPE_FLAGS_P ()
ADDRESS_CLASS_TYPE_FLAGS
has
been defined.
ADDRESS_CLASS_TYPE_FLAGS_TO_NAME (type_flags)
ADDRESS_CLASS_TYPE_FLAGS_TO_NAME_P ()
ADDRESS_CLASS_TYPE_FLAGS_TO_NAME
has
been defined.
See section Target Architecture Definition.
ADDRESS_TO_POINTER (type, buf, addr)
BELIEVE_PCC_PROMOTION
short
or char
parameter to an int
, but still reports the parameter as its
original type, rather than the promoted type.
BITS_BIG_ENDIAN
BREAKPOINT
BREAKPOINT
has been deprecated in favor of
BREAKPOINT_FROM_PC
.
BIG_BREAKPOINT
LITTLE_BREAKPOINT
BIG_BREAKPOINT
and LITTLE_BREAKPOINT
have been deprecated in
favor of BREAKPOINT_FROM_PC
.
DEPRECATED_REMOTE_BREAKPOINT
DEPRECATED_LITTLE_REMOTE_BREAKPOINT
DEPRECATED_BIG_REMOTE_BREAKPOINT
DEPRECATED_REMOTE_BREAKPOINT
,
DEPRECATED_BIG_REMOTE_BREAKPOINT
and
DEPRECATED_LITTLE_REMOTE_BREAKPOINT
have been deprecated in
favor of BREAKPOINT_FROM_PC
(@xref{BREAKPOINT_FROM_PC}).
BREAKPOINT_FROM_PC (pcptr, lenptr)
*lenptr
, and adjusts the program
counter (if necessary) to point to the actual memory location where the
breakpoint should be inserted.
Although it is common to use a trap instruction for a breakpoint, it's
not required; for instance, the bit pattern could be an invalid
instruction. The breakpoint must be no longer than the shortest
instruction of the architecture.
Replaces all the other BREAKPOINT macros.
MEMORY_INSERT_BREAKPOINT (addr, contents_cache)
MEMORY_REMOVE_BREAKPOINT (addr, contents_cache)
default_memory_insert_breakpoint
and
default_memory_remove_breakpoint
respectively) have been
provided so that it is not necessary to define these for most
architectures. Architectures which may want to define
MEMORY_INSERT_BREAKPOINT
and MEMORY_REMOVE_BREAKPOINT
will
likely have instructions that are oddly sized or are not stored in a
conventional manner.
It may also be desirable (from an efficiency standpoint) to define
custom breakpoint insertion and removal routines if
BREAKPOINT_FROM_PC
needs to read the target's memory for some
reason.
ADJUST_BREAKPOINT_ADDRESS (address)
ADJUST_BREAKPOINT_ADDRESS
method will adjust a
breakpoint's address by scanning backwards for the beginning of
the bundle, returning the address of the bundle.
Since the adjustment of a breakpoint may significantly alter a user's
expectation, GDB prints a warning when an adjusted breakpoint
is initially set and each time that that breakpoint is hit.
CALL_DUMMY_LOCATION
push_dummy_code
(@xref{push_dummy_code}).
CANNOT_FETCH_REGISTER (regno)
FETCH_INFERIOR_REGISTERS
is not defined.
CANNOT_STORE_REGISTER (regno)
int CONVERT_REGISTER_P(regnum)
DECR_PC_AFTER_BREAK
BREAKPOINT
, though not always. For most targets this value will be 0.
DISABLE_UNSETTABLE_BREAK (addr)
PRINT_FLOAT_INFO()
print_registers_info (gdbarch, frame, regnum, all)
PRINT_VECTOR_INFO()
DWARF_REG_TO_REGNUM
DWARF2_REG_TO_REGNUM
ECOFF_REG_TO_REGNUM
END_OF_TEXT_DEFAULT
EXTRACT_RETURN_VALUE(type, regbuf, valbuf)
gdbarch_return_value
(@xref{gdbarch_return_value}).
DEPRECATED_EXTRACT_STRUCT_VALUE_ADDRESS(regbuf)
CORE_ADDR
at which a function should return
its structure value.
@xref{gdbarch_return_value}.
DEPRECATED_EXTRACT_STRUCT_VALUE_ADDRESS_P()
DEPRECATED_EXTRACT_STRUCT_VALUE_ADDRESS
.
DEPRECATED_FP_REGNUM
DEPRECATED_TARGET_READ_FP
is not defined.
DEPRECATED_FRAMELESS_FUNCTION_INVOCATION(fi)
frame_align (address)
DEPRECATED_STACK_ALIGN
, this function always adjusts the
address in the direction of stack growth.
By default, no frame based stack alignment is performed.
int frame_red_zone_size
DEPRECATED_FRAME_CHAIN(frame)
DEPRECATED_FRAME_CHAIN_VALID(chain, thisframe)
NULL
chain pointers, dummy frames, and frames whose PC values are inside the
startup file (e.g. `crt0.o'), inside main
, or inside
_start
.
DEPRECATED_FRAME_INIT_SAVED_REGS(frame)
frame->saved_regs
. Space for
frame->saved_regs
shall be allocated by
DEPRECATED_FRAME_INIT_SAVED_REGS
using
frame_saved_regs_zalloc
.
FRAME_FIND_SAVED_REGS
is deprecated.
FRAME_NUM_ARGS (fi)
-1
.
DEPRECATED_FRAME_SAVED_PC(frame)
CORE_ADDR unwind_pc (struct frame_info *this_frame)
ULONGEST pc; frame_unwind_unsigned_register (this_frame, D10V_PC_REGNUM, &pc); return d10v_make_iaddr (pc);@xref{DEPRECATED_FRAME_SAVED_PC}, which this method replaces.
CORE_ADDR unwind_sp (struct frame_info *this_frame)
ULONGEST sp; frame_unwind_unsigned_register (this_frame, D10V_SP_REGNUM, &sp); return d10v_make_daddr (sp);@xref{TARGET_READ_SP}, which this method replaces.
FUNCTION_EPILOGUE_SIZE
x_sym.x_misc.x_fsize
field of the
function end symbol is 0. For such targets, you must define
FUNCTION_EPILOGUE_SIZE
to expand into the standard size of a
function's epilogue.
DEPRECATED_FUNCTION_START_OFFSET
call
instructions check this value, and save the
appropriate registers automatically. Thus, since the offset from the
function's address to its first instruction is two bytes,
DEPRECATED_FUNCTION_START_OFFSET
would be 2 on the VAX.
GCC_COMPILED_FLAG_SYMBOL
GCC2_COMPILED_FLAG_SYMBOL
gcc_compiled.
and gcc2_compiled.
,
respectively. (Currently only defined for the Delta 68.)
GDB_MULTI_ARCH
GDB_TARGET_IS_HPPA
GET_LONGJMP_TARGET
longjmp
will jump to,
assuming that we have just stopped at a longjmp
breakpoint. It takes a
CORE_ADDR *
as argument, and stores the target PC value through this
pointer. It examines the current state of the machine as needed.
DEPRECATED_GET_SAVED_REGISTER
DEPRECATED_GET_SAVED_REGISTER
.
DEPRECATED_IBM6000_TARGET
I386_USE_GENERIC_WATCHPOINTS
SYMBOLS_CAN_START_WITH_DOLLAR
$$dyncall
is a millicode
routine that handles inter-space procedure calls on PA-RISC.
DEPRECATED_INIT_EXTRA_FRAME_INFO (fromleaf, frame)
frame->extra_info
. Space for frame->extra_info
is allocated using frame_extra_info_zalloc
.
DEPRECATED_INIT_FRAME_PC (fromleaf, prev)
INNER_THAN (lhs, rhs)
lhs < rhs
if
the target's stack grows downward in memory, or lhs > rsh
if the
stack grows upward.
gdbarch_in_function_epilogue_p (gdbarch, pc)
DEPRECATED_SIGTRAMP_START (pc)
DEPRECATED_SIGTRAMP_END (pc)
sigtramp
for the
given pc. On machines where the address is just a compile time
constant, the macro expansion will typically just ignore the supplied
pc.
IN_SOLIB_CALL_TRAMPOLINE (pc, name)
IN_SOLIB_RETURN_TRAMPOLINE (pc, name)
IN_SOLIB_DYNSYM_RESOLVE_CODE (pc)
SKIP_SOLIB_RESOLVER (pc)
INTEGER_TO_ADDRESS (type, buf)
print
command, they should get the same value as would have been
computed by the target program. Any deviation from this rule can cause
major confusion and annoyance, and needs to be justified carefully. In
other words, GDB doesn't really have the freedom to do these
conversions in clever and useful ways. It has, however, been pointed
out that users aren't complaining about how GDB casts integers
to pointers; they are complaining that they can't take an address from a
disassembly listing and give it to x/i
. Adding an architecture
method like INTEGER_TO_ADDRESS
certainly makes it possible for
GDB to "get it right" in all circumstances.
See section Target Architecture Definition.
NO_HIF_SUPPORT
POINTER_TO_ADDRESS (type, buf)
REGISTER_CONVERTIBLE (reg)
REGISTER_TO_VALUE(regnum, type, from, to)
DEPRECATED_REGISTER_RAW_SIZE (reg)
register_reggroup_p (gdbarch, regnum, reggroup)
float_reggroup
vector_reggroup
general_reggroup
save_reggroup
restore_reggroup
all_reggroup
DEPRECATED_REGISTER_VIRTUAL_SIZE (reg)
DEPRECATED_REGISTER_VIRTUAL_TYPE (reg)
struct type *register_type (gdbarch, reg)
DEPRECATED_REGISTER_VIRTUAL_TYPE
. See section Target Architecture Definition.
REGISTER_CONVERT_TO_VIRTUAL(reg, type, from, to)
REGISTER_CONVERT_TO_RAW(type, reg, from, to)
const struct regset *regset_from_core_section (struct gdbarch * gdbarch, const char * sect_name, size_t sect_size)
SOFTWARE_SINGLE_STEP_P()
SOFTWARE_SINGLE_STEP
must also be defined.
SOFTWARE_SINGLE_STEP(signal, insert_breapoints_p)
SOFUN_ADDRESS_MAYBE_MISSING
SOFUN_ADDRESS_MAYBE_MISSING
indicates that a particular set of
hacks of this sort are in use, affecting N_SO
and N_FUN
entries in stabs-format debugging information. N_SO
stabs mark
the beginning and ending addresses of compilation units in the text
segment. N_FUN
stabs mark the starts and ends of functions.
SOFUN_ADDRESS_MAYBE_MISSING
means two things:
N_FUN
stabs have an address of zero. Instead, you should find the
addresses where the function starts by taking the function name from
the stab, and then looking that up in the minsyms (the
linker/assembler symbol table). In other words, the stab has the
name, and the linker/assembler symbol table is the only place that carries
the address.
N_SO
stabs have an address of zero, too. You just look at the
N_FUN
stabs that appear before and after the N_SO
stab,
and guess the starting and ending addresses of the compilation unit from
them.
PC_LOAD_SEGMENT
PC_REGNUM
TARGET_READ_PC
and
TARGET_WRITE_PC
are not defined.
PARM_BOUNDARY
stabs_argument_has_addr (gdbarch, type)
DEPRECATED_REG_STRUCT_HAS_ADDR
(@xref{DEPRECATED_REG_STRUCT_HAS_ADDR}).
PROCESS_LINENUMBER_HOOK
PROLOGUE_FIRSTLINE_OVERLAP
PS_REGNUM
DEPRECATED_POP_FRAME
frame_pop
to remove a stack frame. This
method has been superseeded by generic code.
push_dummy_call (gdbarch, function, regcache, pc_addr, nargs, args, sp, struct_return, struct_addr)
struct value
; on architectures that use
function descriptors, this contains the function descriptor value.
Returns the updated top-of-stack pointer.
This method replaces DEPRECATED_PUSH_ARGUMENTS
.
CORE_ADDR push_dummy_code (gdbarch, sp, funaddr, using_gcc, args, nargs, value_type, real_pc, bp_addr)
CALL_DUMMY_LOCATION
,
DEPRECATED_REGISTER_SIZE
.
REGISTER_NAME(i)
NULL
or NUL
to indicate that register i is not valid.
DEPRECATED_REG_STRUCT_HAS_ADDR (gcc_p, type)
stabs_argument_has_addr
(@xref{stabs_argument_has_addr}).
SAVE_DUMMY_FRAME_TOS (sp)
SP
after both the dummy frame and space for parameters/results have been
allocated on the stack. @xref{unwind_dummy_id}.
SDB_REG_TO_REGNUM
enum return_value_convention gdbarch_return_value (struct gdbarch *gdbarch, struct type *valtype, struct regcache *regcache, void *readbuf, const void *writebuf)
RETURN_VALUE_REGISTER_CONVENTION
where the return value is found
in registers; and RETURN_VALUE_STRUCT_CONVENTION
where the return
value is found in memory and the address of that memory location is
passed in as the function's first parameter.
If the register convention is being used, and writebuf is
non-NULL
, also copy the return-value in writebuf into
regcache.
If the register convention is being used, and readbuf is
non-NULL
, also copy the return value from regcache into
readbuf (regcache contains a copy of the registers from the
just returned function).
@xref{DEPRECATED_EXTRACT_STRUCT_VALUE_ADDRESS}, for a description of how
return-values that use the struct convention are handled.
Maintainer note: This method replaces separate predicate, extract,
store methods. By having only one method, the logic needed to determine
the return-value convention need only be implemented in one place. If
GDB were written in an OO language, this method would
instead return an object that knew how to perform the register
return-value extract and store.
Maintainer note: This method does not take a gcc_p
parameter, and such a parameter should not be added. If an architecture
that requires per-compiler or per-function information be identified,
then the replacement of rettype with struct value
function should be persued.
Maintainer note: The regcache parameter limits this methods
to the inner most frame. While replacing regcache with a
struct frame_info
frame parameter would remove that
limitation there has yet to be a demonstrated need for such a change.
SKIP_PERMANENT_BREAKPOINT
SKIP_PERMANENT_BREAKPOINT
adjusts the processor's
state so that execution will resume just after the breakpoint. This
macro does the right thing even when the breakpoint is in the delay slot
of a branch or jump.
SKIP_PROLOGUE (pc)
SKIP_TRAMPOLINE_CODE (pc)
SP_REGNUM
STAB_REG_TO_REGNUM
DEPRECATED_STACK_ALIGN (addr)
STEP_SKIPS_DELAY (addr)
STORE_RETURN_VALUE (type, regcache, valbuf)
gdbarch_return_value
(@xref{gdbarch_return_value}).
SYMBOL_RELOADING_DEFAULT
TARGET_CHAR_BIT
TARGET_CHAR_SIGNED
char
is normally signed on this architecture; zero if
it should be unsigned.
The ISO C standard requires the compiler to treat char
as
equivalent to either signed char
or unsigned char
; any
character in the standard execution set is supposed to be positive.
Most compilers treat char
as signed, but char
is unsigned
on the IBM S/390, RS6000, and PowerPC targets.
TARGET_COMPLEX_BIT
2 * TARGET_FLOAT_BIT
.
At present this macro is not used.
TARGET_DOUBLE_BIT
8 * TARGET_CHAR_BIT
.
TARGET_DOUBLE_COMPLEX_BIT
2 * TARGET_DOUBLE_BIT
.
At present this macro is not used.
TARGET_FLOAT_BIT
4 * TARGET_CHAR_BIT
.
TARGET_INT_BIT
4 * TARGET_CHAR_BIT
.
TARGET_LONG_BIT
4 * TARGET_CHAR_BIT
.
TARGET_LONG_DOUBLE_BIT
2 * TARGET_DOUBLE_BIT
.
TARGET_LONG_LONG_BIT
2 * TARGET_LONG_BIT
.
TARGET_PTR_BIT
TARGET_INT_BIT
.
TARGET_SHORT_BIT
2 * TARGET_CHAR_BIT
.
TARGET_READ_PC
TARGET_WRITE_PC (val, pid)
TARGET_READ_SP
TARGET_READ_FP
read_pc
,
write_pc
, and read_sp
. For most targets, these may be
left undefined. GDB will call the read and write register
functions with the relevant _REGNUM
argument.
These macros are useful when a target keeps one of these registers in a
hard to get at place; for example, part in a segment register and part
in an ordinary register.
@xref{unwind_sp}, which replaces TARGET_READ_SP
.
TARGET_VIRTUAL_FRAME_POINTER(pc, regp, offsetp)
(register, offset)
pair representing the virtual frame
pointer in use at the code address pc. If virtual frame pointers
are not used, a default definition simply returns
DEPRECATED_FP_REGNUM
, with an offset of zero.
TARGET_HAS_HARDWARE_WATCHPOINTS
TARGET_PRINT_INSN (addr, info)
deprecated_tm_print_insn
. This usually points to a function in
the opcodes
library (see section Support Libraries).
info is a structure (of type disassemble_info
) defined in
`include/dis-asm.h' used to pass information to the instruction
decoding routine.
struct frame_id unwind_dummy_id (struct frame_info *frame)
SAVE_DUMMY_FRAME_TOS
.
@xref{SAVE_DUMMY_FRAME_TOS}.
DEPRECATED_USE_STRUCT_CONVENTION (gcc_p, type)
gdbarch_return_value
(@xref{gdbarch_return_value}).
VALUE_TO_REGISTER(type, regnum, from, to)
VARIABLES_INSIDE_BLOCK (desc, gcc_p)
n_desc
from the
N_RBRAC
symbol, and gcc_p is true if GDB has noticed the
presence of either the GCC_COMPILED_SYMBOL
or the
GCC2_COMPILED_SYMBOL
. By default, this is 0.
OS9K_VARIABLES_INSIDE_BLOCK (desc, gcc_p)
Motorola M68K target conditionals.
BPT_VECTOR
0xf
.
REMOTE_BPT_VECTOR
1
.
NAME_OF_MALLOC
The following files add a target to GDB:
configure
). Contains
macro definitions about the target machine's registers, stack frame
format and instructions.
New targets do not need this file and should not create it.
If you are adding a new operating system for an existing CPU chip, add a
`config/tm-os.h' file that describes the operating system
facilities that are unusual (extra symbol table info; the breakpoint
instruction needed; etc.). Then write a `arch/tm-os.h'
that just #include
s `tm-arch.h' and
`config/tm-os.h'.
This section describes the current accepted best practice for converting an existing target architecture to the multi-arch framework.
The process consists of generating, testing, posting and committing a sequence of patches. Each patch must contain a single change, for instance:
FRAME_INFO
).
There isn't a size limit on a patch, however, a developer is strongly encouraged to keep the patch size down.
Since each patch is well defined, and since each change has been tested and shows no regressions, the patches are considered fairly obvious. Such patches, when submitted by developers listed in the `MAINTAINERS' file, do not need approval. Occasional steps in the process may be more complicated and less clear. The developer is expected to use their judgment and is encouraged to seek advice as needed.
The first step is to establish control. Build (with @option{-Werror} enabled) and test the target so that there is a baseline against which the debugger can be compared.
At no stage can the test results regress or GDB stop compiling with @option{-Werror}.
The objective of this step is to establish the basic multi-arch framework. It involves
arch_gdbarch_init
function(4) that creates
the architecture:
static struct gdbarch * d10v_gdbarch_init (info, arches) struct gdbarch_info info; struct gdbarch_list *arches; { struct gdbarch *gdbarch; /* there is only one d10v architecture */ if (arches != NULL) return arches->gdbarch; gdbarch = gdbarch_alloc (&info, NULL); return gdbarch; }
static void mips_dump_tdep (struct gdbarch *current_gdbarch, struct ui_file *file) { ... code to print architecture specific info ... }
_initialize_arch_tdep
to register this new
architecture:
void _initialize_mips_tdep (void) { gdbarch_register (bfd_arch_mips, mips_gdbarch_init, mips_dump_tdep);
GDB_MULTI_ARCH
, defined as 0 (zero), to the fileSome mechanisms do not work with multi-arch. They include:
FRAME_FIND_SAVED_REGS
DEPRECATED_FRAME_INIT_SAVED_REGS
At this stage you could also consider converting the macros into functions.
Temporally set GDB_MULTI_ARCH
to GDB_MULTI_ARCH_PARTIAL
and then build and start GDB (the change should not be
committed). GDB may not build, and once built, it may die with
an internal error listing the architecture methods that must be
provided.
Fix any build problems (patch(es)).
Convert all the architecture methods listed, which are only macros, into functions (patch(es)).
Update arch_gdbarch_init
to set all the missing
architecture methods and wrap the corresponding macros in #if
!GDB_MULTI_ARCH
(patch(es)).
Change the value of GDB_MULTI_ARCH
to GDB_MULTI_ARCH_PARTIAL (a
single patch).
Any problems with throwing "the switch" should have been fixed already.
Suggest converting macros into functions (and setting the corresponding architecture method) in small batches.
This should go smoothly.
The `tm-arch.h' can be deleted. `arch.mt' and `configure.in' updated.
Go to the first, previous, next, last section, table of contents.