| [ < ] | [ > ] | [ << ] | [ 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] | [ ? ] |
11.2.1 How an Architecture is Represented 11.2.2 Looking Up an Existing Architecture 11.2.3 Creating a New Architecture
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Each gdbarch is associated with a single BFD architecture,
via a bfd_arch_arch in the bfd_architecture
enumeration. 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.
A GDB description for a new architecture, arch is created by
defining a global function _initialize_arch_tdep, by
convention in the source file `arch-tdep.c'. For example,
in the case of the OpenRISC 1000, this function is called
_initialize_or1k_tdep and is found in the file
`or1k-tdep.c'.
The resulting object files containing the implementation of the
_initialize_arch_tdep function are specified in the GDB
`configure.tgt' file, which includes a large case statement
pattern matching against the --target option of the
configure script. The new struct gdbarch is created
within the _initialize_arch_tdep function by calling
gdbarch_register:
void gdbarch_register (enum bfd_architecture architecture,
gdbarch_init_ftype *init_func,
gdbarch_dump_tdep_ftype *tdep_dump_func);
|
The architecture will identify the unique BFD to be
associated with this gdbarch. The init_func funciton is
called to create and return the new struct gdbarch. The
tdep_dump_func function will dump the target specific details
associated with this architecture.
For example the function _initialize_or1k_tdep creates its
architecture for 32-bit OpenRISC 1000 architectures by calling:
gdbarch_register (bfd_arch_or32, or1k_gdbarch_init, or1k_dump_tdep); |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The initialization function has this prototype:
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.
The lookup is done using gdbarch_list_lookup_by_info. It is
passed the list of existing architectures, arches, and the
struct gdbarch_info, info, and returns the first matching
architecture it finds, or NULL if none are found. If an
architecture is found it can be returned as the result from the
initialization function, otherwise a new struct gdbach will need
to be created.
The struct gdbarch_info has the following components:
struct gdbarch_info
{
const struct bfd_arch_info *bfd_arch_info;
int byte_order;
bfd *abfd;
struct gdbarch_tdep_info *tdep_info;
enum gdb_osabi osabi;
const struct target_desc *target_desc;
};
|
The bfd_arch_info member holds the key details about the
architecture. The byte_order member is a value in an
enumeration indicating the endianism. The abfd member is a
pointer to the full BFD, the tdep_info member is
additional custom target specific information, osabi identifies
which (if any) of a number of operating specific ABIs are used by this
architecture and the target_desc member is a set of name-value
pairs with information about register usage in this target.
When the struct gdbarch initialization function is called, not
all the fields are provided--only those which can be deduced from the
BFD. The struct gdbarch_info, info is used as a
look-up key with the list of existing architectures, arches to
see if a suitable architecture already exists. The tdep_info,
osabi and target_desc fields may be added before this
lookup to refine the search.
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] | [ ? ] |
If no architecture is found, then a new architecture must be created,
by calling gdbarch_alloc using the supplied struct
gdbarch_info and any additional custom target specific
information in a struct gdbarch_tdep. The prototype for
gdbarch_alloc is:
struct gdbarch *gdbarch_alloc (const struct gdbarch_info *info,
struct gdbarch_tdep *tdep);
|
The newly created struct gdbarch must then be populated. Although there are default values, in most cases they are not what is required.
For each element, X, there is are a pair of corresponding accessor
functions, one to set the value of that element,
set_gdbarch_X, the second to either get the value of an
element (if it is a variable) or to apply the element (if it is a
function), gdbarch_X. Note that both accessor functions
take a pointer to the struct gdbarch as first
argument. Populating the new gdbarch should use the
set_gdbarch functions.
The following sections identify the main elements that should be set in this way. This is not the complete list, but represents the functions and elements that must commonly be specified for a new architecture. Many of the functions and variables are described in the header file `gdbarch.h'.
This is the main work in defining a new architecture. Implementing the
set of functions to populate the struct gdbarch.
struct gdbarch_tdep is not defined within GDB---it is up
to the user to define this struct if it is needed to hold custom target
information that is not covered by the standard struct
gdbarch. For example with the OpenRISC 1000 architecture it is used to
hold the number of matchpoints available in the target (along with other
information).
If there is no additional target specific information, it can be set to
NULL.
| [ < ] | [ > ] | [ << ] | [ 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. For
example 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] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
GDB considers registers to be a set with members numbered linearly from 0 upwards. The first part of that set corresponds to real physical registers, the second part to any pseudo-registers. Pseudo-registers have no independent physical existence, but are useful representations of information within the architecture. For example the OpenRISC 1000 architecture has up to 32 general purpose registers, which are typically represented as 32-bit (or 64-bit) integers. However the GPRs are also used as operands to the floating point operations, and it could be convenient to define a set of pseudo-registers, to show the GPRs represented as floating point values.
For any architecture, the implementer will decide on a mapping from hardware to GDB register numbers. The registers corresponding to real hardware are referred to as raw registers, the remaining registers are pseudo-registers. The total register set (raw and pseudo) is called the cooked register set.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
These struct gdbarch functions and variables specify the number
and type of registers in the architecture.
Read or write the program counter. The default value of both
functions is NULL (no function available). If the program
counter is just an ordinary register, it can be specified in
struct gdbarch instead (see pc_regnum below) and it will
be read or written using the standard routines to access registers. This
function need only be specified if the program counter is not an
ordinary register.
Any register information can be obtained using the supplied register cache, regcache. See section Register Caching.
These functions should be defined if there are any pseudo-registers.
The default value is NULL. regnum is the number of the
register to read or write (which will be a cooked register
number) and buf is the buffer where the value read will be
placed, or from which the value to be written will be taken. The
value in the buffer may be converted to or from a signed or unsigned
integral value using one of the utility functions (see section Using Different Register and Memory Data Representations).
The access should be for the specified architecture, gdbarch. Any register information can be obtained using the supplied register cache, regcache. See section Register Caching.
This specifies the register holding the stack pointer, which may be a raw or pseudo-register. It defaults to -1 (not defined), but it is an error for it not to be defined.
The value of the stack pointer register can be accessed withing GDB as the variable $sp.
This specifies the register holding the program counter, which may be a
raw or pseudo-register. It defaults to -1 (not defined). If
pc_regnum is not defined, then the functions read_pc and
write_pc (see above) must be defined.
The value of the program counter (whether defined as a register, or
through read_pc and write_pc) can be accessed withing
GDB as the variable $pc.
This specifies the register holding the processor status (often called the status register), which may be a raw or pseudo-register. It defaults to -1 (not defined).
If defined, the value of this register can be accessed withing GDB as the variable $ps.
This specifies the first floating point register. It defaults to
0. fp0_regnum is not needed unless the target offers support
for floating point.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
These functions return information about registers.
This function should convert a register number (raw or pseudo) to a
register name (as a C const char *). This is used both to
determine the name of a register for output and to work out the meaning
of any register names used as input. The function may also return
NULL, to indicate that regnum is not a valid register.
For example with the OpenRISC 1000, GDB registers 0-31 are the
General Purpose Registers, register 32 is the program counter and
register 33 is the supervision register (i.e. the processor status
register), which map to the strings "gpr00" through
"gpr31", "pc" and "sr" respectively. This means
that the GDB command print $gpr5 should print the value of
the OR1K general purpose register 5(4).
The default value for this function is NULL, meaning
undefined. It should always be defined.
The access should be for the specified architecture, gdbarch.
Given a register number, this function identifies the type of data it
may be holding, specified as a struct type. GDB allows
creation of arbitrary types, but a number of built in types are
provided (builtin_type_void, builtin_type_int32 etc),
together with functions to derive types from these.
Typically the program counter will have a type of "pointer to function" (it points to code), the frame pointer and stack pointer will have types of "pointer to void" (they point to data on the stack) and all other integer registers will have a type of 32-bit integer or 64-bit integer.
This information guides the formatting when displaying register
information. The default value is NULL meaning no information is
available to guide formatting when displaying registers.
Define this function to print out one or all of the registers for the
GDB info registers command. The default value is the
function default_print_registers_info, which uses the register
type information (see register_type above) to determine how each
register should be printed. Define a custom version of this function
for fuller control over how the registers are displayed.
The access should be for the specified architecture, gdbarch,
with output to the the file specified by the User Interface
Independent Output file handle, file (see section UI-Independent Output--the ui_out Functions).
The registers should show their values in the frame specified by frame. If regnum is -1 and all is zero, then all the "significant" registers should be shown (the implementer should decide which registers are "significant"). Otherwise only the value of the register specified by regnum should be output. If regnum is -1 and all is non-zero (true), then the value of all registers should be shown.
By default default_print_registers_info prints one register per
line, and if all is zero omits floating-point registers.
Define this function to provide output about the floating point unit and
registers for the GDB info float command respectively.
The default value is NULL (not defined), meaning no information
will be provided.
The gdbarch and file and frame arguments have the same
meaning as in the print_registers_info function above. The string
args contains any supplementary arguments to the info float
command.
Define this function if the target supports floating point operations.
Define this function to provide output about the vector unit and
registers for the GDB info vector command respectively.
The default value is NULL (not defined), meaning no information
will be provided.
The gdbarch, file and frame arguments have the
same meaning as in the print_registers_info function above. The
string args contains any supplementary arguments to the info
vector command.
Define this function if the target supports vector operations.
GDB groups registers into different categories (general, vector, floating point etc). This function, given a register, regnum, and group, group, returns 1 (true) if the register is in the group and 0 (false) otherwise.
The information should be for the specified architecture, gdbarch
The default value is the function default_register_reggroup_p
which will do a reasonable job based on the type of the register (see
the function register_type above), with groups for general
purpose registers, floating point registers, vector registers and raw
(i.e not pseudo) registers.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Some architectures have different representations of data objects, depending whether the object is held in a register or memory. 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. An architecture may define the
following struct gdbarch functions to request conversions
between the register and memory representations of a data type:
Return non-zero (true) if the representation of a data value stored in
this register may be different to the representation of that same data
value when stored in memory. The default value is NULL
(undefined).
If this function is defined and returns non-zero, the struct
gdbarch functions gdbarch_register_to_value and
gdbarch_value_to_register (see below) should be used to perform
any necessary conversion.
If defined, this function should return zero for the register's native type, when no conversion is necessary.
Convert the value of register number reg to a data object of type type. The buffer at from holds the register's value in raw format; the converted value should be placed in the buffer at to.
Note:gdbarch_register_to_valueandgdbarch_value_to_registertake their reg and type arguments in different orders.
gdbarch_register_to_value should only be used with registers
for which the gdbarch_convert_register_p function returns a
non-zero value.
Convert a data value of type type to register number reg' raw format.
Note:gdbarch_register_to_valueandgdbarch_value_to_registertake their reg and type arguments in different orders.
gdbarch_value_to_register should only be used with registers
for which the gdbarch_convert_register_p function returns a
non-zero value.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
Caching of registers is used, so that the target does not need to be accessed and reanalyzed multiple times for each register in circumstances where the register value cannot have changed.
GDB provides struct regcache, associated with a
particular struct gdbarch to hold the cached values of the raw
registers. A set of functions is provided to access both the raw
registers (with raw in their name) and the full set of cooked
registers (with cooked in their name). Functions are provided
to ensure the register cache is kept synchronized with the values of
the actual registers in the target.
Accessing registers through the struct regcache routines will
ensure that the appropriate struct gdbarch functions are called
when necessary to access the underlying target architecture. In general
users should use the cooked functions, since these will map to the
raw functions automatically as appropriate.
The two key functions are regcache_cooked_read and
regcache_cooked_write which read or write a register from or to
a byte buffer (type gdb_byte *). For convenience the wrapper
functions regcache_cooked_read_signed,
regcache_cooked_read_unsigned,
regcache_cooked_write_signed and
regcache_cooked_write_unsigned are provided, which read or
write the value using the buffer and convert to or from an integral
value as appropriate.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
GDB needs to understand the stack on which local (automatic) variables are stored. The area of the stack containing all the local variables for a function invocation is known as the stack frame for that function (or colloquially just as the frame). In turn the function that called the function will have its stack frame, and so on back through the chain of functions that have been called.
Almost all architectures have one register dedicated to point to the end of the stack (the stack pointer). Many have a second register which points to the start of the currently active stack frame (the frame pointer). The specific arrangements for an architecture are a key part of the ABI.
A diagram helps to explain this. Here is a simple program to compute factorials:
#include <stdio.h>
int fact (int n)
{
if (0 == n)
{
return 1;
}
else
{
return n * fact (n - 1);
}
}
main ()
{
int i;
for (i = 0; i < 10; i++)
{
int f = fact (i);
printf ("%d! = %d\n", i, f);
}
}
|
Consider the state of the stack when the code reaches line 6 after the
main program has called fact (3). The chain of function
calls will be main (), fact (3), fact
(2), fact (1) and fact (0).
In this illustration the stack is falling (as used for example by the OpenRISC 1000 ABI). The stack pointer (SP) is at the end of the stack (lowest address) and the frame pointer (FP) is at the highest address in the current stack frame. The following diagram shows how the stack looks.
In each stack frame, offset 0 from the stack pointer is the frame
pointer of the previous frame and offset 4 (this is illustrating a
32-bit architecture) from the stack pointer is the return address.
Local variables are indexed from the frame pointer, with negative
indexes. In the function fact, offset -4 from the frame
pointer is the argument n. In the main function, offset
-4 from the frame pointer is the local variable i and offset -8
from the frame pointer is the local variable f(5).
It is very easy to get confused when examining stacks. GDB
has terminology it uses rigorously throughout. The stack frame of the
function currently executing, or where execution stopped is numbered
zero. In this example frame #0 is the stack frame of the call to
fact (0). The stack frame of its calling function
(fact (1) in this case) is numbered #1 and so on back
through the chain of calls.
The main GDB data structure describing frames is
struct frame_info. It is not used directly, but only via
its accessor functions. frame_info includes information about
the registers in the frame and a pointer to the code of the function
with which the frame is associated. The entire stack is represented as
a linked list of frame_info structs.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
It is easy to get confused when referencing stack frames. GDB uses some precise terminology.
So in the example in the previous section (see section All About Stack Frames), if THIS frame is #3 (the call to
fact (3)), the NEXT frame is frame #2 (the call to
fact (2)) and the PREVIOUS frame is frame #4 (the call to
main ()).
The innermost frame is the frame of the current executing
function, or where the program stopped, in this example, in the middle
of the call to fact (0)). It is always numbered frame #0.
The base of a frame is the address immediately before the start of the NEXT frame. For a stack which grows down in memory (a falling stack) this will be the lowest address and for a stack which grows up in memory (a rising stack) this will be the highest address in the frame.
GDB functions to analyze the stack are typically given a pointer to the NEXT frame to determine information about THIS frame. Information about THIS frame includes data on where the registers of the PREVIOUS frame are stored in this stack frame. In this example the frame pointer of the PREVIOUS frame is stored at offset 0 from the stack pointer of THIS frame.
The process whereby a function is given a pointer to the NEXT frame to work out information about THIS frame is referred to as unwinding. The GDB functions involved in this typically include unwind in their name.
The process of analyzing a target to determine the information that should go in struct frame_info is called sniffing. The functions that carry this out are called sniffers and typically include sniffer in their name. More than one sniffer may be required to extract all the information for a particular frame.
Because so many functions work using the NEXT frame, there is an issue about addressing the innermost frame--it has no NEXT frame. To solve this GDB creates a dummy frame #-1, known as the sentinel frame.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
All the frame sniffing functions typically examine the code at the start of the corresponding function, to determine the state of registers. The ABI will save old values and set new values of key registers at the start of each function in what is known as the function prologue.
For any particular stack frame this data does not change, so all the standard unwinding functions, in addition to receiving a pointer to the NEXT frame as their first argument, receive a pointer to a prologue cache as their second argument. This can be used to store values associated with a particular frame, for reuse on subsequent calls involving the same frame.
It is up to the user to define the structure used (it is a
void * pointer) and arrange allocation and deallocation of
storage. However for general use, GDB provides
struct trad_frame_cache, with a set of accessor
routines. This structure holds the stack and code address of
THIS frame, the base address of the frame, a pointer to the
struct frame_info for the NEXT frame and details of
where the registers of the PREVIOUS frame may be found in THIS
frame.
Typically the first time any sniffer function is called with NEXT
frame, the prologue sniffer for THIS frame will be NULL. The
sniffer will analyze the frame, allocate a prologue cache structure
and populate it. Subsequent calls using the same NEXT frame will
pass in this prologue cache, so the data can be returned with no
additional analysis.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
These struct gdbarch functions and variable should be defined
to provide analysis of the stack frame and allow it to be adjusted as
required.
The prologue of a function is the code at the beginning of the function which sets up the stack frame, saves the return address etc. The code representing the behavior of the function starts after the prologue.
This function skips past the prologue of a function if the program counter, pc, is within the prologue of a function. The result is the program counter immediately after the prologue. With modern optimizing compilers, this may be a far from trivial exercise. However the required information may be within the binary as DWARF2 debugging information, making the job much easier.
The default value is NULL (not defined). This function should always
be provided, but can take advantage of DWARF2 debugging information,
if that is available.
Given two frame or stack pointers, return non-zero (true) if the first represents the inner stack frame and 0 (false) otherwise. This is used to determine whether the target has a stack which grows up in memory (rising stack) or grows down in memory (falling stack). See section All About Stack Frames, for an explanation of inner frames.
The default value of this function is NULL and it should always
be defined. However for almost all architectures one of the built-in
functions can be used: core_addr_lessthan (for stacks growing
down in memory) or core_addr_greaterthan (for stacks growing up
in memory).
The architecture may have constraints on how its frames are aligned. For example the OpenRISC 1000 ABI requires stack frames to be double-word aligned, but 32-bit versions of the architecture allocate single-word values to the stack. Thus extra padding may be needed at the end of a stack frame.
Given a proposed address for the stack pointer, this function returns a suitably aligned address (by expanding the stack frame).
The default value is NULL (undefined). This function should be defined
for any architecture where it is possible the stack could become
misaligned. The utility functions align_down (for falling
stacks) and align_up (for rising stacks) will facilitate the
implementation of this function.
Some ABIs reserve space beyond the end of the stack for use by leaf functions without prologue or epilogue or by exception handlers (for example the OpenRISC 1000).
This is known as a red zone (AMD terminology). The AMD64 (nee x86-64) ABI documentation refers to the red zone when describing this scratch area.
The default value is 0. Set this field if the architecture has such a
red zone. The value must be aligned as required by the ABI (see
frame_align above for an explanation of stack frame alignment).
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
These functions provide access to key registers and arguments in the stack frame.
This function is given a pointer to the NEXT stack frame (see section All About Stack Frames, for how frames are represented) and returns the value of the program counter in the PREVIOUS frame (i.e. the frame of the function that called THIS one). This is commonly referred to as the return address.
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, ARCH_PC_REGNUM); return gdbarch_addr_bits_remove (gdbarch, pc); |
This function is given a pointer to the NEXT stack frame (see section All About Stack Frames for how frames are represented) and returns the value of the stack pointer in the PREVIOUS frame (i.e. the frame of the function that called THIS one).
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, ARCH_SP_REGNUM); return gdbarch_addr_bits_remove (gdbarch, sp); |
This function is given a pointer to THIS stack frame (see section All About Stack Frames for how frames are represented), and returns the number of arguments that are being passed, or -1 if not known.
The default value is NULL (undefined), in which case the number of
arguments passed on any stack frame is always unknown. For many
architectures this will be a suitable default.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
When a program stops, GDB needs to construct the chain of
struct frame_info representing the state of the stack using
appropriate sniffers.
Each architecture requires appropriate sniffers, but they do not form
entries in struct gdbarch, since more than one sniffer may
be required and a sniffer may be suitable for more than one
struct gdbarch. Instead sniffers are associated with
architectures using the following functions.
frame_unwind_append_sniffer is used to add a new sniffer to
analyze THIS frame when given a pointer to the NEXT frame.
frame_base_append_sniffer is used to add a new sniffer
which can determine information about the base of a stack frame.
frame_base_set_default is used to specify the default base
sniffer.
These functions all take a reference to struct gdbarch, so
they are associated with a specific architecture. They are usually
called in the gdbarch initialization function, after the
gdbarch struct has been set up. Unless a default has been set, the
most recently appended sniffer will be tried first.
The main frame unwinding sniffer (as set by
frame_unwind_append_sniffer) returns a structure specifying
a set of sniffing functions:
struct frame_unwind
{
enum frame_type type;
frame_this_id_ftype *this_id;
frame_prev_register_ftype *prev_register;
const struct frame_data *unwind_data;
frame_sniffer_ftype *sniffer;
frame_prev_pc_ftype *prev_pc;
frame_dealloc_cache_ftype *dealloc_cache;
};
|
The type field indicates the type of frame this sniffer can
handle: normal, dummy (see section Functions Creating Dummy Frames), signal handler or sentinel. Signal
handlers sometimes have their own simplified stack structure for
efficiency, so may need their own handlers.
The unwind_data field holds additional information which may be
relevant to particular types of frame. For example it may hold
additional information for signal handler frames.
The remaining fields define functions that yield different types of
information when given a pointer to the NEXT stack frame. Not all
functions need be provided. If an entry is NULL, the next sniffer will
be tried instead.
this_id determines the stack pointer and function (code
entry point) for THIS stack frame.
prev_register determines where the values of registers for
the PREVIOUS stack frame are stored in THIS stack frame.
sniffer takes a look at THIS frame's registers to
determine if this is the appropriate unwinder.
prev_pc determines the program counter for THIS
frame. Only needed if the program counter is not an ordinary register
(see section Functions and Variables Specifying the Register Architecture).
dealloc_cache frees any additional memory associated with
the prologue cache for this frame (see section Prologue Caches).
In general it is only the this_id and prev_register
fields that need be defined for custom sniffers.
The frame base sniffer is much simpler. It is a struct
frame_base, which refers to the corresponding frame_unwind
struct and whose fields refer to functions yielding various addresses
within the frame.
struct frame_base
{
const struct frame_unwind *unwind;
frame_this_base_ftype *this_base;
frame_this_locals_ftype *this_locals;
frame_this_args_ftype *this_args;
};
|
All the functions referred to take a pointer to the NEXT frame as
argument. The function referred to by this_base returns the
base address of THIS frame, the function referred to by
this_locals returns the base address of local variables in THIS
frame and the function referred to by this_args returns the
base address of the function arguments in this frame.
As described above, the base address of a frame is the address immediately before the start of the NEXT frame. For a falling stack, this is the lowest address in the frame and for a rising stack it is the highest address in the frame. For most architectures the same address is also the base address for local variables and arguments, in which case the same function can be used for all three entries(6).
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
11.8.1 About Dummy Frames 11.8.2 Functions Creating Dummy Frames
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
GDB can call functions in the target code (for example by using the call or print commands). These functions may be breakpointed, and it is essential that if a function does hit a breakpoint, commands like backtrace work correctly.
This is achieved by making the stack look as though the function had been called from the point where GDB had previously stopped. This requires that GDB can set up stack frames appropriate for such function calls.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The following functions provide the functionality to set up such dummy stack frames.
This function sets up a dummy stack frame for the function about to be
called. push_dummy_call is given the arguments to be passed
and must copy them into registers or push them on to the stack as
appropriate for the ABI.
function is a pointer to the function that will be called and regcache the register cache from which values should be obtained. bp_addr is the address to which the function should return (which is breakpointed, so GDB can regain control, hence the name). nargs is the number of arguments to pass and args an array containing the argument values. struct_return is non-zero (true) if the function returns a structure, and if so struct_addr is the address in which the structure should be returned.
After calling this function, GDB will pass control to the target at the address of the function, which will find the stack and registers set up just as expected.
The default value of this function is NULL (undefined). If the
function is not defined, then GDB will not allow the user to
call functions within the target being debugged.
This is the inverse of push_dummy_call which restores the stack
pointer and program counter after a call to evaluate a function using
a dummy stack frame. The result is a struct frame_id, which
contains the value of the stack pointer and program counter to be
used.
The NEXT frame pointer is provided as argument, next_frame. THIS frame is the frame of the dummy function, which can be unwound, to yield the required stack pointer and program counter from the PREVIOUS frame.
The default value is NULL (undefined). If push_dummy_call is
defined, then this function should also be defined.
If this function is not defined (its default value is NULL), a dummy
call will use the entry point of the currently loaded code on the
target as its return address. A temporary breakpoint will be set
there, so the location must be writable and have room for a
breakpoint.
It is possible that this default is not suitable. It might not be writable (in ROM possibly), or the ABI might require code to be executed on return from a call to unwind the stack before the breakpoint is encountered.
If either of these is the case, then push_dummy_code should be defined to push an instruction sequence onto the end of the stack to which the dummy call should return.
The arguments are essentially the same as those to
push_dummy_call. However the function is provided with the
type of the function result, value_type, bp_addr is used
to return a value (the address at which the breakpoint instruction
should be inserted) and real pc is used to specify the resume
address when starting the call sequence. The function should return
the updated innermost stack address.
Note: This does require that code in the stack can be executed. Some Harvard architectures may not allow this.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The prerequisite for adding core file support in GDB is to have core file support in BFD.
Once BFD support is available, writing the apropriate
regset_from_core_section architecture function should be all
that is needed in order to add support for core files in GDB.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
This section describes other functions and values in gdbarch,
together with some useful macros, that you can use to define the
target architecture.
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. May return NULL to indicate that
software breakpoints are not supported.
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.
Provided breakpoint bytes can be also used by bp_loc_is_permanent to
detect permanent breakpoints. gdbarch_breakpoint_from_pc should return
an unchanged memory copy if it was called for a location with permanent
breakpoint as some architectures use breakpoint instructions containing
arbitrary parameter value.
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)
int gdbarch_cannot_store_register (gdbarch, regnum)
int gdbarch_convert_register_p (gdbarch, regnum, struct type *type)
int gdbarch_fp0_regnum (gdbarch)
CORE_ADDR gdbarch_decr_pc_after_break (gdbarch)
BREAKPOINT, though not always. For most targets this value will be 0.
DISABLE_UNSETTABLE_BREAK (addr)
int gdbarch_dwarf2_reg_to_regnum (gdbarch, dwarf2_regnr)
int gdbarch_ecoff_reg_to_regnum (gdbarch, ecoff_regnr)
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
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, typically by using a manually-determined
offset into the jmp_buf. (While we might like to get the offset
from the target's `jmpbuf.h', that header file cannot be assumed
to be available when building a cross-debugger.)
DEPRECATED_IBM6000_TARGET
I386_USE_GENERIC_WATCHPOINTS
gdbarch_in_function_epilogue_p (gdbarch, addr)
int gdbarch_in_solib_return_trampoline (gdbarch, pc, name)
target_so_ops.in_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_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_stabs_argument_has_addr (gdbarch, type)
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.
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).
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_trampoline_code (gdbarch, frame, pc)
int gdbarch_deprecated_fp_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.
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
gdbarch_deprecated_fp_regnum (or gdbarch_sp_regnum, if
no frame pointer is defined), with an offset of zero.
TARGET_HAS_HARDWARE_WATCHPOINTS
int gdbarch_print_insn (gdbarch, vma, info)
opcodes library
(see section Opcodes). info is a structure (of
type disassemble_info) defined in the header file
`include/dis-asm.h', and used to pass information to the
instruction decoding routine.
frame_id gdbarch_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 by call_function_by_hand.
void gdbarch_value_to_register (gdbarch, frame, type, buf)
Motorola M68K target conditionals.
BPT_VECTOR
0xf.
REMOTE_BPT_VECTOR
1.
| [ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
The following files add a target to GDB:
(Target header files such as `gdb/config/arch/tm-ttt.h', `gdb/config/arch/tm-arch.h', and `config/tm-os.h' are no longer used.)
A GDB description for a new architecture, arch is created by
defining a global function _initialize_arch_tdep, by
convention in the source file `arch-tdep.c'. For
example, in the case of the OpenRISC 1000, this function is called
_initialize_or1k_tdep and is found in the file
`or1k-tdep.c'.
The object file resulting from compiling this source file, which will
contain the implementation of the
_initialize_arch_tdep function is specified in the
GDB `configure.tgt' file, which includes a large case
statement pattern matching against the --target option of the
configure script.
Note: If the architecture requires multiple source files, the corresponding binaries should be included in `configure.tgt'. However if there are header files, the dependencies on these will not be picked up from the entries in `configure.tgt'. The `Makefile.in' file will need extending to show these dependencies.
A new struct gdbarch, defining the new architecture, is created within
the _initialize_arch_tdep function by calling
gdbarch_register:
void gdbarch_register (enum bfd_architecture architecture,
gdbarch_init_ftype *init_func,
gdbarch_dump_tdep_ftype *tdep_dump_func);
|
This function has been described fully in an earlier section. See section How an Architecture is Represented.
The new struct gdbarch should contain implementations of
the necessary functions (described in the previous sections) to
describe the basic layout of the target machine's processor chip
(registers, stack, etc.). It can be shared among many targets that use
the same processor architecture.
| [ << ] | [ >> ] | [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 October, 6 2009 using texi2html