| [ < ] | [ > ] | [ << ] | [ 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 gdbarch_register_name and related functions.
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 two functions 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 functions are defined by default. Predicate functions 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 functions:
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 gdbarch_register_to_value and
value_to_register are used to perform any necessary conversion.
This function should return zero for the register's native type, when no conversion is necessary.
Note that gdbarch_register_to_value and gdbarch_value_to_register
take their reg and type arguments in different orders.
You should only use gdbarch_register_to_value with registers for which
the gdbarch_convert_register_p function returns a non-zero value.
Note that gdbarch_register_to_value and gdbarch_value_to_register
take their reg and type arguments in different orders.
You should only use gdbarch_value_to_register with registers for which
the gdbarch_convert_register_p function 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 and functions that you can use to define the target machine.
CORE_ADDR gdbarch_addr_bits_remove (gdbarch, 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. gdbarch_addr_bits_remove would then for
example look like that:
arch_addr_bits_remove (CORE_ADDR addr)
{
return (addr &= ~0x3);
}
|
int address_class_name_to_type_flags (gdbarch, 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.
int address_class_name_to_type_flags_p (gdbarch)
address_class_name_to_type_flags
has been defined.
int gdbarch_address_class_type_flags (gdbarch, 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.
int gdbarch_address_class_type_flags_p (gdbarch)
gdbarch_address_class_type_flags_p has
been defined.
const char *gdbarch_address_class_type_flags_to_name (gdbarch, type_flags)
int gdbarch_address_class_type_flags_to_name_p (gdbarch)
gdbarch_address_class_type_flags_to_name has been defined.
See section Address Classes.
void gdbarch_address_to_pointer (gdbarch, type, buf, addr)
int gdbarch_believe_pcc_promotion (gdbarch)
short or char
parameter to an int, but still reports the parameter as its
original type, rather than the promoted type.
gdbarch_bits_big_endian (gdbarch)
set_gdbarch_bits_big_endian (gdbarch, bits_big_endian)
BREAKPOINT
BREAKPOINT has been deprecated in favor of
gdbarch_breakpoint_from_pc.
BIG_BREAKPOINT
LITTLE_BREAKPOINT
BIG_BREAKPOINT and LITTLE_BREAKPOINT have been deprecated in
favor of gdbarch_breakpoint_from_pc.
const gdb_byte *gdbarch_breakpoint_from_pc (gdbarch, 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.
int gdbarch_memory_insert_breakpoint (gdbarch, bp_tgt)
gdbarch_memory_remove_breakpoint (gdbarch, bp_tgt)
default_memory_insert_breakpoint and
default_memory_remove_breakpoint respectively) have been
provided so that it is not necessary to set these for most
architectures. Architectures which may want to set
gdbarch_memory_insert_breakpoint and gdbarch_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
gdbarch_breakpoint_from_pc needs to read the target's memory for some
reason.
CORE_ADDR gdbarch_adjust_breakpoint_address (gdbarch, bpaddr)
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 gdbarch_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.
int gdbarch_call_dummy_location (gdbarch)
This method has been replaced by gdbarch_push_dummy_code
(see gdbarch_push_dummy_code).
int gdbarch_cannot_fetch_register (gdbarch, regum)
FETCH_INFERIOR_REGISTERS is not defined.
int gdbarch_cannot_store_register (gdbarch, regnum)
int gdbarch_convert_register_p (gdbarch, regnum, struct type *type)
CORE_ADDR gdbarch_decr_pc_after_break (gdbarch)
BREAKPOINT, though not always. For most targets this value will be 0.
DISABLE_UNSETTABLE_BREAK (addr)
void gdbarch_print_float_info (gdbarch, file, frame, args)
void gdbarch_print_registers_info (gdbarch, frame, regnum, all)
The default method prints one register per line, and if all is zero omits floating-point registers.
int gdbarch_print_vector_info (gdbarch, file, frame, args)
By default, the `info vector' command will print all vector registers (the register's type having the vector attribute).
int gdbarch_dwarf_reg_to_regnum (gdbarch, dwarf_regnr)
int gdbarch_dwarf2_reg_to_regnum (gdbarch, dwarf2_regnr)
int gdbarch_ecoff_reg_to_regnum (gdbarch, ecoff_regnr)
DEPRECATED_FP_REGNUM
This should only need to be defined if DEPRECATED_TARGET_READ_FP
is not defined.
DEPRECATED_FRAMELESS_FUNCTION_INVOCATION(fi)
CORE_ADDR frame_align (gdbarch, 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.
This function always adjusts the address in the direction of stack growth.
By default, no frame based stack alignment is performed.
int gdbarch_frame_red_zone_size (gdbarch)
When performing an inferior function call, to ensure that it does not modify this area, GDB adjusts the innermost-stack-address by gdbarch_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.
int gdbarch_frame_num_args (gdbarch, frame)
-1.
DEPRECATED_FRAME_SAVED_PC(frame)
This method is deprecated. See gdbarch_unwind_pc.
CORE_ADDR gdbarch_unwind_pc (next_frame)
The implementation, which must be frame agnostic (work with any frame), is typically no more than:
ULONGEST pc; pc = frame_unwind_register_unsigned (next_frame, S390_PC_REGNUM); return gdbarch_addr_bits_remove (gdbarch, pc); |
See DEPRECATED_FRAME_SAVED_PC, which this method replaces.
CORE_ADDR gdbarch_unwind_sp (gdbarch, next_frame)
The implementation, which must be frame agnostic (work with any frame), is typically no more than:
ULONGEST sp; sp = frame_unwind_register_unsigned (next_frame, S390_SP_REGNUM); return gdbarch_addr_bits_remove (gdbarch, 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.)
gdbarch_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_IBM6000_TARGET
I386_USE_GENERIC_WATCHPOINTS
int gdbarch_inner_than (gdbarch, 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, addr)
int gdbarch_in_solib_return_trampoline (gdbarch, pc, name)
IN_SOLIB_DYNSYM_RESOLVE_CODE (pc)
SKIP_SOLIB_RESOLVER (pc)
CORE_ADDR gdbarch_integer_to_address (gdbarch, 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 gdbarch_integer_to_address certainly makes it possible for
GDB to "get it right" in all circumstances.
See section Pointers Are Not Always Addresses.
CORE_ADDR gdbarch_pointer_to_address (gdbarch, type, buf)
void gdbarch_register_to_value(gdbarch, frame, regnum, type, fur)
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)
set_gdbarch_sofun_address_maybe_missing (gdbarch, set)
Calling set_gdbarch_sofun_address_maybe_missing with a non-zero
argument set 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.
In this case, GDB assumes two things:
N_FUN stabs have an address of zero. Instead of using those
addresses, you should find the address 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.
int gdbarch_pc_regnum (gdbarch)
This should only need to be defined if gdbarch_read_pc and
gdbarch_write_pc are not defined.
int gdbarch_stabs_argument_has_addr (gdbarch, type)
PROCESS_LINENUMBER_HOOK
gdbarch_ps_regnum (gdbarch
CORE_ADDR gdbarch_push_dummy_call (gdbarch, function, regcache, bp_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 gdbarch_push_dummy_code (gdbarch, sp, funaddr, using_gcc, args, nargs, value_type, real_pc, bp_addr, regcache)
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 gdbarch_call_dummy_location (gdbarch) and
DEPRECATED_REGISTER_SIZE.
const char *gdbarch_register_name (gdbarch, regnr)
NULL
to indicate that regnr is not a valid register.
SAVE_DUMMY_FRAME_TOS (sp)
SP
after both the dummy frame and space for parameters/results have been
allocated on the stack. See gdbarch_unwind_dummy_id.
int gdbarch_sdb_reg_to_regnum (gdbarch, sdb_regnr)
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).
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.
void gdbarch_skip_permanent_breakpoint (gdbarch, regcache)
gdbarch_skip_permanent_breakpoint adjusts the
processor's state so that execution will resume just after the breakpoint.
This function does the right thing even when the breakpoint is in the delay slot
of a branch or jump.
CORE_ADDR gdbarch_skip_prologue (gdbarch, ip)
CORE_ADDR gdbarch_skip_trampoline_code (gdbarch, frame, pc)
int gdbarch_sp_regnum (gdbarch)
int gdbarch_stab_reg_to_regnum (gdbarch, stab_regnr)
SYMBOL_RELOADING_DEFAULT
TARGET_CHAR_BIT
int gdbarch_char_signed (gdbarch)
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.
int gdbarch_double_bit (gdbarch)
8 * TARGET_CHAR_BIT.
int gdbarch_float_bit (gdbarch)
4 * TARGET_CHAR_BIT.
int gdbarch_int_bit (gdbarch)
4 * TARGET_CHAR_BIT.
int gdbarch_long_bit (gdbarch)
4 * TARGET_CHAR_BIT.
int gdbarch_long_double_bit (gdbarch)
2 * gdbarch_double_bit (gdbarch).
int gdbarch_long_long_bit (gdbarch)
2 * gdbarch_long_bit (gdbarch).
int gdbarch_ptr_bit (gdbarch)
gdbarch_int_bit (gdbarch).
int gdbarch_short_bit (gdbarch)
2 * TARGET_CHAR_BIT.
CORE_ADDR gdbarch_read_pc (gdbarch, regcache)
gdbarch_write_pc (gdbarch, regcache, val)
TARGET_READ_SP
TARGET_READ_FP
gdbarch_read_pc,
gdbarch_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 and functions 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 gdbarch_unwind_sp, which replaces TARGET_READ_SP.
void gdbarch_virtual_frame_pointer (gdbarch, pc, frame_regnum, frame_offset)
(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
int gdbarch_print_insn (gdbarch, vma, 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.
frame_id gdbarch_unwind_dummy_id (gdbarch, 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).
void gdbarch_value_to_register (gdbarch, frame, type, buf)
Motorola M68K target conditionals.
BPT_VECTOR
0xf.
REMOTE_BPT_VECTOR
1.
const char *gdbarch_name_of_malloc (gdbarch)
| [ < ] | [ > ] | [ << ] | [ 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'.
| [ << ] | [ >> ] | [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, 1 2008 using texi2html