| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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'.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 `defs.h':
GDB_OSABI_UNINITIALIZED
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
a.out executable format.
GDB_OSABI_FREEBSD_ELF
GDB_OSABI_NETBSD_AOUT
a.out executable format.
GDB_OSABI_NETBSD_ELF
GDB_OSABI_OPENBSD_ELF
GDB_OSABI_WINCE
GDB_OSABI_GO32
GDB_OSABI_IRIX
GDB_OSABI_INTERIX
GDB_OSABI_HPUX_ELF
GDB_OSABI_HPUX_SOM
GDB_OSABI_QNXNTO
GDB_OSABI_CYGWIN
GDB_OSABI_AIX
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.
bfd_map_over_sections.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Each gdbarch is associated with a single BFD architecture,
via a bfd_arch_arch constant. The gdbarch is
registered by a call to register_gdbarch_init, usually from
the file's _initialize_filename routine, which will
be automatically called during GDB startup. The arguments
are a BFD architecture constant and an initialization function.
The initialization function has this type:
static struct gdbarch *
arch_gdbarch_init (struct gdbarch_info info,
struct gdbarch_list *arches)
|
The info argument contains parameters used to select the correct
architecture, and arches is a list of architectures which
have already been created with the same bfd_arch_arch
value.
The initialization function should first make sure that info
is acceptable, and return NULL if it is not. Then, it should
search through arches for an exact match to info, and
return one if found. Lastly, if no exact match was found, it should
create a new architecture based on info and return it.
Only information in info should be used to choose the new
architecture. Historically, info could be sparse, and
defaults would be collected from the first element on arches.
However, GDB now fills in info more thoroughly,
so new gdbarch initialization functions should not take
defaults from arches.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 referenced 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 |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Maintainer note: This section is pretty much obsolete. The functionality described here has largely been replaced by pseudo-registers and the mechanisms described in Using Different Register and Memory Data Representations. See also Bug Tracking Database and 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.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Maintainer's note: The way GDB manipulates registers is undergoing significant change. Many of the macros and functions referred to in this section are likely to be subject to further revision. See A.R. Index and 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.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This section describes the macros that you can use to define the target machine.
ADDR_BITS_REMOVE (addr)
For example, the two low-order bits of the PC on the Hewlett-Packard PA
2.0 architecture contain the privilege level of the corresponding
instruction. Since instructions must always be aligned on four-byte
boundaries, the processor masks out these bits to generate the actual
address of the instruction. ADDR_BITS_REMOVE should filter out these
bits with an expression such as ((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 Address Classes.
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 Address Classes.
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 Address Classes.
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.
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 (bp_tgt)
MEMORY_REMOVE_BREAKPOINT (bp_tgt)
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)
The FR-V target (see `frv-tdep.c') requires this method. The FR-V is a VLIW architecture in which a number of RISC-like instructions are grouped (packed) together into an aggregate instruction or instruction bundle. When the processor executes one of these bundles, the component instructions are executed in parallel.
In the course of optimization, the compiler may group instructions from distinct source statements into the same bundle. The line number information associated with one of the latter statements will likely refer to some instruction other than the first one in the bundle. So, if the user attempts to place a breakpoint on one of these latter statements, GDB must be careful to not place the break instruction on any instruction other than the first one in the bundle. (Remember though that the instructions within a bundle execute in parallel, so the first instruction is the instruction at the lowest address and has nothing to do with execution order.)
The FR-V's 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
This method has been replaced by push_dummy_code
(see 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)
The default method prints one register per line, and if all is zero omits floating-point registers.
PRINT_VECTOR_INFO()
By default, the `info vector' command will print all vector registers (the register's type having the vector attribute).
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
(see gdbarch_return_value).
DEPRECATED_EXTRACT_STRUCT_VALUE_ADDRESS(regbuf)
CORE_ADDR at which a function should return
its structure value.
See gdbarch_return_value.
DEPRECATED_EXTRACT_STRUCT_VALUE_ADDRESS_P()
DEPRECATED_EXTRACT_STRUCT_VALUE_ADDRESS.
DEPRECATED_FP_REGNUM
This should only need to be defined if DEPRECATED_TARGET_READ_FP
is not defined.
DEPRECATED_FRAMELESS_FUNCTION_INVOCATION(fi)
frame_align (address)
This function is used to ensure that, when creating a dummy frame, both the initial stack pointer and (if needed) the address of the return value are correctly aligned.
Unlike 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
The number of bytes, beyond the innermost-stack-address, reserved by the ABI. A function is permitted to use this scratch area (instead of allocating extra stack space).
When performing an inferior function call, to ensure that it does not modify this area, GDB adjusts the innermost-stack-address by frame_red_zone_size bytes before pushing parameters onto the stack.
By default, zero bytes are allocated. The value must be aligned (see frame_align).
The AMD64 (nee x86-64) ABI documentation refers to the red zone when describing this scratch area.
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)
This method is deprecated. See unwind_pc.
CORE_ADDR unwind_pc (struct frame_info *this_frame)
The implementation, which must be frame agnostic (work with any frame), is typically no more than:
ULONGEST pc; frame_unwind_unsigned_register (this_frame, D10V_PC_REGNUM, &pc); return d10v_make_iaddr (pc); |
See DEPRECATED_FRAME_SAVED_PC, which this method replaces.
CORE_ADDR unwind_sp (struct frame_info *this_frame)
The implementation, which must be frame agnostic (work with any frame), is typically no more than:
ULONGEST sp; frame_unwind_unsigned_register (this_frame, D10V_SP_REGNUM, &sp); return d10v_make_daddr (sp); |
See 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
This is zero on almost all machines: the function's address is usually
the address of its first instruction. However, on the VAX, for
example, each function starts with two bytes containing a bitmask
indicating which registers to save upon entry to the function. The
VAX 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
This support can be enabled at two levels. At level one, only definitions for previously undefined macros are provided; at level two, a multi-arch definition of all architecture dependent macros will be defined.
GDB_TARGET_IS_HPPA
GET_LONGJMP_TARGET
This macro determines the target PC address that 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
On HP-UX, certain system routines (millicode) have names beginning with
`$' or `$$'. For example, $$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)
Pragmatics: When the user copies a well defined expression from
their source code and passes it, as a parameter, to GDB's
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 Pointers Are Not Always Addresses.
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)
By default, registers are grouped as follows:
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 Raw and Virtual Register Representations.
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_breakpoints_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
This should only need to be defined if TARGET_READ_PC and
TARGET_WRITE_PC are not defined.
PARM_BOUNDARY
stabs_argument_has_addr (gdbarch, type)
This method replaces DEPRECATED_REG_STRUCT_HAS_ADDR
(see 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 superseded by generic code.
push_dummy_call (gdbarch, function, regcache, pc_addr, nargs, args, sp, struct_return, struct_addr)
function is a pointer to a 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)
Set bp_addr to the address at which the breakpoint instruction should be inserted, real_pc to the resume address when starting the call sequence, and return the updated inner-most stack address.
By default, the stack is grown sufficient to hold a frame-aligned (see frame_align) breakpoint, bp_addr is set to the address reserved for that breakpoint, and real_pc set to funaddr.
This method replaces 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)
This method has been replaced by stabs_argument_has_addr
(see 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. See 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)
GDB currently recognizes two function return-value conventions:
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).
See 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 pursued.
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)
Unlike frame_align, this function always adjusts addr upwards.
By default, no stack alignment is performed.
STEP_SKIPS_DELAY (addr)
STORE_RETURN_VALUE (type, regcache, valbuf)
This method has been deprecated in favour of gdbarch_return_value
(see 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.
See 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 Opcodes).
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)
struct
frame_id that uniquely identifies an inferior function call's dummy
frame. The value returned must match the dummy frame stack value
previously saved using SAVE_DUMMY_FRAME_TOS.
See SAVE_DUMMY_FRAME_TOS.
DEPRECATED_USE_STRUCT_CONVENTION (gcc_p, type)
This method has been deprecated in favour of gdbarch_return_value
(see 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
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The following files add a target to GDB:
You can also define `TM_CFLAGS', `TM_CLIBS', `TM_CDEPS', but these are now deprecated, replaced by autoconf, and may go away in future versions of 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.
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 #includes `tm-arch.h' and
`config/tm-os.h'.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The first step is to establish control. Build (with `-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 `-Werror'.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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 file
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Some 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.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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)).
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
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.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Suggest converting macros into functions (and setting the corresponding architecture method) in small batches.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This should go smoothly.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The `tm-arch.h' can be deleted. `arch.mt' and `configure.in' updated.
| [ << ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Please send FSF & GNU inquiries & questions to gnu@gnu.org. There are also other ways to contact the FSF.
These pages are maintained by the GDB developers.
Copyright Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111, USA.
Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
This document was generated by GDB Administrator on March, 31 2007 using texi2html