2637 lines
105 KiB
HTML
2637 lines
105 KiB
HTML
<HTML>
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<!-- Created on October, 26 2002 by texi2html 1.64 -->
|
|
<!--
|
|
Written by: Lionel Cons <Lionel.Cons@cern.ch> (original author)
|
|
Karl Berry <karl@freefriends.org>
|
|
Olaf Bachmann <obachman@mathematik.uni-kl.de>
|
|
and many others.
|
|
Maintained by: Olaf Bachmann <obachman@mathematik.uni-kl.de>
|
|
Send bugs and suggestions to <texi2html@mathematik.uni-kl.de>
|
|
|
|
-->
|
|
<HEAD>
|
|
<TITLE>GDB Internals: Target Architecture Definition</TITLE>
|
|
|
|
<META NAME="description" CONTENT="GDB Internals: Target Architecture Definition">
|
|
<META NAME="keywords" CONTENT="GDB Internals: Target Architecture Definition">
|
|
<META NAME="resource-type" CONTENT="document">
|
|
<META NAME="distribution" CONTENT="global">
|
|
<META NAME="Generator" CONTENT="texi2html 1.64">
|
|
|
|
</HEAD>
|
|
|
|
<BODY LANG="" BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#800080" ALINK="#FF0000">
|
|
|
|
<A NAME="SEC67"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_8.html#SEC66"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC68"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[ << ]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint.html#SEC_Top"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_10.html#SEC88"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_19.html#SEC186">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H1> 9. Target Architecture Definition </H1>
|
|
<!--docid::SEC67::-->
|
|
<P>
|
|
|
|
<A NAME="IDX246"></A>
|
|
GDB's target architecture defines what sort of
|
|
machine-language programs GDB can work with, and how it works
|
|
with them.
|
|
</P><P>
|
|
|
|
The target architecture object is implemented as the C structure
|
|
<CODE>struct gdbarch *</CODE>. The structure, and its methods, are generated
|
|
using the Bourne shell script <TT>`gdbarch.sh'</TT>.
|
|
</P><P>
|
|
|
|
<HR SIZE="6">
|
|
<A NAME="SEC68"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC67"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC69"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[ << ]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC67"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_10.html#SEC88"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_19.html#SEC186">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 9.1 Operating System ABI Variant Handling </H2>
|
|
<!--docid::SEC68::-->
|
|
<P>
|
|
|
|
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.
|
|
</P><P>
|
|
|
|
A <EM>sniffer</EM> 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 <EM>generic</EM>, while sniffers for a specific architecture are
|
|
considered to be <EM>specific</EM>. 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 <CODE>EI_OSABI</CODE> field of the ELF header, as well as note
|
|
sections known to be used by several operating systems.
|
|
</P><P>
|
|
|
|
<A NAME="IDX247"></A>
|
|
A <EM>handler</EM> is used to fine-tune the <CODE>gdbarch</CODE> structure for the
|
|
selected OS ABI. There may be only one handler for a given OS ABI
|
|
for each BFD architecture.
|
|
</P><P>
|
|
|
|
The following OS ABI variants are defined in <TT>`osabi.h'</TT>:
|
|
</P><P>
|
|
|
|
<DL COMPACT>
|
|
|
|
<A NAME="IDX248"></A>
|
|
<DT><CODE>GDB_OSABI_UNKNOWN</CODE>
|
|
<DD>The ABI of the inferior is unknown. The default <CODE>gdbarch</CODE>
|
|
settings for the architecture will be used.
|
|
<P>
|
|
|
|
<A NAME="IDX249"></A>
|
|
<DT><CODE>GDB_OSABI_SVR4</CODE>
|
|
<DD>UNIX System V Release 4
|
|
<P>
|
|
|
|
<A NAME="IDX250"></A>
|
|
<DT><CODE>GDB_OSABI_HURD</CODE>
|
|
<DD>GNU using the Hurd kernel
|
|
<P>
|
|
|
|
<A NAME="IDX251"></A>
|
|
<DT><CODE>GDB_OSABI_SOLARIS</CODE>
|
|
<DD>Sun Solaris
|
|
<P>
|
|
|
|
<A NAME="IDX252"></A>
|
|
<DT><CODE>GDB_OSABI_OSF1</CODE>
|
|
<DD>OSF/1, including Digital UNIX and Compaq Tru64 UNIX
|
|
<P>
|
|
|
|
<A NAME="IDX253"></A>
|
|
<DT><CODE>GDB_OSABI_LINUX</CODE>
|
|
<DD>GNU using the Linux kernel
|
|
<P>
|
|
|
|
<A NAME="IDX254"></A>
|
|
<DT><CODE>GDB_OSABI_FREEBSD_AOUT</CODE>
|
|
<DD>FreeBSD using the a.out executable format
|
|
<P>
|
|
|
|
<A NAME="IDX255"></A>
|
|
<DT><CODE>GDB_OSABI_FREEBSD_ELF</CODE>
|
|
<DD>FreeBSD using the ELF executable format
|
|
<P>
|
|
|
|
<A NAME="IDX256"></A>
|
|
<DT><CODE>GDB_OSABI_NETBSD_AOUT</CODE>
|
|
<DD>NetBSD using the a.out executable format
|
|
<P>
|
|
|
|
<A NAME="IDX257"></A>
|
|
<DT><CODE>GDB_OSABI_NETBSD_ELF</CODE>
|
|
<DD>NetBSD using the ELF executable format
|
|
<P>
|
|
|
|
<A NAME="IDX258"></A>
|
|
<DT><CODE>GDB_OSABI_WINCE</CODE>
|
|
<DD>Windows CE
|
|
<P>
|
|
|
|
<A NAME="IDX259"></A>
|
|
<DT><CODE>GDB_OSABI_GO32</CODE>
|
|
<DD>DJGPP
|
|
<P>
|
|
|
|
<A NAME="IDX260"></A>
|
|
<DT><CODE>GDB_OSABI_NETWARE</CODE>
|
|
<DD>Novell NetWare
|
|
<P>
|
|
|
|
<A NAME="IDX261"></A>
|
|
<DT><CODE>GDB_OSABI_ARM_EABI_V1</CODE>
|
|
<DD>ARM Embedded ABI version 1
|
|
<P>
|
|
|
|
<A NAME="IDX262"></A>
|
|
<DT><CODE>GDB_OSABI_ARM_EABI_V2</CODE>
|
|
<DD>ARM Embedded ABI version 2
|
|
<P>
|
|
|
|
<A NAME="IDX263"></A>
|
|
<DT><CODE>GDB_OSABI_ARM_APCS</CODE>
|
|
<DD>Generic ARM Procedure Call Standard
|
|
<P>
|
|
|
|
</DL>
|
|
<P>
|
|
|
|
Here are the functions that make up the OS ABI framework:
|
|
</P><P>
|
|
|
|
<A NAME="IDX264"></A>
|
|
<DL>
|
|
<DT><U>Function:</U> const <B>char</B> <I>*gdbarch_osabi_name (enum gdb_osabi <VAR>osabi</VAR>)</I>
|
|
<DD>Return the name of the OS ABI corresponding to <VAR>osabi</VAR>.
|
|
</DL>
|
|
</P><P>
|
|
|
|
<A NAME="IDX265"></A>
|
|
<DL>
|
|
<DT><U>Function:</U> void <B>gdbarch_register_osabi</B> <I>(enum bfd_architecture <VAR>arch</VAR>, enum gdb_osabi <VAR>osabi</VAR>, void (*<VAR>init_osabi</VAR>)(struct gdbarch_info <VAR>info</VAR>, struct gdbarch *<VAR>gdbarch</VAR>))</I>
|
|
<DD>Register the OS ABI handler specified by <VAR>init_osabi</VAR> for the
|
|
architecture/OS ABI pair specified by <VAR>arch</VAR> and <VAR>osabi</VAR>.
|
|
</DL>
|
|
</P><P>
|
|
|
|
<A NAME="IDX266"></A>
|
|
<DL>
|
|
<DT><U>Function:</U> void <B>gdbarch_register_osabi_sniffer</B> <I>(enum bfd_architecture <VAR>arch</VAR>, enum bfd_flavour <VAR>flavour</VAR>, enum gdb_osabi (*<VAR>sniffer</VAR>)(bfd *<VAR>abfd</VAR>))</I>
|
|
<DD>Register the OS ABI file sniffer specified by <VAR>sniffer</VAR> for the
|
|
BFD architecture/flavour pair specified by <VAR>arch</VAR> and <VAR>flavour</VAR>.
|
|
If <VAR>arch</VAR> is <CODE>bfd_arch_unknown</CODE>, the sniffer is considered to
|
|
be generic, and is allowed to examine <VAR>flavour</VAR>-flavoured files for
|
|
any architecture.
|
|
</DL>
|
|
</P><P>
|
|
|
|
<A NAME="IDX267"></A>
|
|
<DL>
|
|
<DT><U>Function:</U> enum <B>gdb_osabi</B> <I>gdbarch_lookup_osabi (bfd *<VAR>abfd</VAR>)</I>
|
|
<DD>Examine the file described by <VAR>abfd</VAR> to determine its OS ABI.
|
|
The value <CODE>GDB_OSABI_UNKNOWN</CODE> is returned if the OS ABI cannot
|
|
be determined.
|
|
</DL>
|
|
</P><P>
|
|
|
|
<A NAME="IDX268"></A>
|
|
<DL>
|
|
<DT><U>Function:</U> void <B>gdbarch_init_osabi</B> <I>(struct gdbarch info <VAR>info</VAR>, struct gdbarch *<VAR>gdbarch</VAR>, enum gdb_osabi <VAR>osabi</VAR>)</I>
|
|
<DD>Invoke the OS ABI handler corresponding to <VAR>osabi</VAR> to fine-tune the
|
|
<CODE>gdbarch</CODE> structure specified by <VAR>gdbarch</VAR>. If a handler
|
|
corresponding to <VAR>osabi</VAR> has not been registered for <VAR>gdbarch</VAR>'s
|
|
architecture, a warning will be issued and the debugging session will continue
|
|
with the defaults already established for <VAR>gdbarch</VAR>.
|
|
</DL>
|
|
</P><P>
|
|
|
|
<HR SIZE="6">
|
|
<A NAME="SEC69"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC68"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC70"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC70"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC67"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_10.html#SEC88"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_19.html#SEC186">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 9.2 Registers and Memory </H2>
|
|
<!--docid::SEC69::-->
|
|
<P>
|
|
|
|
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.
|
|
</P><P>
|
|
|
|
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 <CODE>REGISTER_NAME</CODE> and related macros.
|
|
</P><P>
|
|
|
|
GDB can handle big-endian, little-endian, and bi-endian architectures.
|
|
</P><P>
|
|
|
|
<HR SIZE="6">
|
|
<A NAME="SEC70"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC69"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC71"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC71"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC67"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_10.html#SEC88"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_19.html#SEC186">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 9.3 Pointers Are Not Always Addresses </H2>
|
|
<!--docid::SEC70::-->
|
|
<P>
|
|
|
|
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.
|
|
</P><P>
|
|
|
|
For example, the Mitsubishi D10V is a 16-bit VLIW processor whose
|
|
instructions are 32 bits long<A NAME="DOCF3" HREF="gdbint_fot.html#FOOT3">(3)</A>.
|
|
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.
|
|
</P><P>
|
|
|
|
However, this means that code pointers and data pointers have different
|
|
forms on the D10V. The 16-bit word <CODE>0xC020</CODE> refers to byte address
|
|
<CODE>0xC020</CODE> when used as a data address, but refers to byte address
|
|
<CODE>0x30080</CODE> when used as a code address.
|
|
</P><P>
|
|
|
|
(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.)
|
|
</P><P>
|
|
|
|
To cope with architectures like this--the D10V is not the only
|
|
one!---GDB tries to distinguish between <EM>addresses</EM>, which are
|
|
byte numbers, and <EM>pointers</EM>, which are the target's representation
|
|
of an address of a particular type of data. In the example above,
|
|
<CODE>0xC020</CODE> is the pointer, which refers to one of the addresses
|
|
<CODE>0xC020</CODE> or <CODE>0x30080</CODE>, 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.
|
|
</P><P>
|
|
|
|
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.
|
|
</P><P>
|
|
|
|
Here are functions which convert between pointers and addresses:
|
|
</P><P>
|
|
|
|
<A NAME="IDX269"></A>
|
|
<DL>
|
|
<DT><U>Function:</U> CORE_ADDR <B>extract_typed_address</B> <I>(void *<VAR>buf</VAR>, struct type *<VAR>type</VAR>)</I>
|
|
<DD>Treat the bytes at <VAR>buf</VAR> as a pointer or reference of type
|
|
<VAR>type</VAR>, and return the address it represents, in a manner
|
|
appropriate for the current architecture. This yields an address
|
|
GDB can use to read target memory, disassemble, etc. Note that
|
|
<VAR>buf</VAR> refers to a buffer in GDB's memory, not the
|
|
inferior's.
|
|
</P><P>
|
|
|
|
For example, if the current architecture is the Intel x86, this function
|
|
extracts a little-endian integer of the appropriate length from
|
|
<VAR>buf</VAR> and returns it. However, if the current architecture is the
|
|
D10V, this function will return a 16-bit integer extracted from
|
|
<VAR>buf</VAR>, multiplied by four if <VAR>type</VAR> is a pointer to a function.
|
|
</P><P>
|
|
|
|
If <VAR>type</VAR> is not a pointer or reference type, then this function
|
|
will signal an internal error.
|
|
</DL>
|
|
</P><P>
|
|
|
|
<A NAME="IDX270"></A>
|
|
<DL>
|
|
<DT><U>Function:</U> CORE_ADDR <B>store_typed_address</B> <I>(void *<VAR>buf</VAR>, struct type *<VAR>type</VAR>, CORE_ADDR <VAR>addr</VAR>)</I>
|
|
<DD>Store the address <VAR>addr</VAR> in <VAR>buf</VAR>, in the proper format for a
|
|
pointer of type <VAR>type</VAR> in the current architecture. Note that
|
|
<VAR>buf</VAR> refers to a buffer in GDB's memory, not the
|
|
inferior's.
|
|
</P><P>
|
|
|
|
For example, if the current architecture is the Intel x86, this function
|
|
stores <VAR>addr</VAR> unmodified as a little-endian integer of the
|
|
appropriate length in <VAR>buf</VAR>. However, if the current architecture
|
|
is the D10V, this function divides <VAR>addr</VAR> by four if <VAR>type</VAR> is
|
|
a pointer to a function, and then stores it in <VAR>buf</VAR>.
|
|
</P><P>
|
|
|
|
If <VAR>type</VAR> is not a pointer or reference type, then this function
|
|
will signal an internal error.
|
|
</DL>
|
|
</P><P>
|
|
|
|
<A NAME="IDX271"></A>
|
|
<DL>
|
|
<DT><U>Function:</U> CORE_ADDR <B>value_as_address</B> <I>(struct value *<VAR>val</VAR>)</I>
|
|
<DD>Assuming that <VAR>val</VAR> is a pointer, return the address it represents,
|
|
as appropriate for the current architecture.
|
|
</P><P>
|
|
|
|
This function actually works on integral values, as well as pointers.
|
|
For pointers, it performs architecture-specific conversions as
|
|
described above for <CODE>extract_typed_address</CODE>.
|
|
</DL>
|
|
</P><P>
|
|
|
|
<A NAME="IDX272"></A>
|
|
<DL>
|
|
<DT><U>Function:</U> CORE_ADDR <B>value_from_pointer</B> <I>(struct type *<VAR>type</VAR>, CORE_ADDR <VAR>addr</VAR>)</I>
|
|
<DD>Create and return a value representing a pointer of type <VAR>type</VAR> to
|
|
the address <VAR>addr</VAR>, as appropriate for the current architecture.
|
|
This function performs architecture-specific conversions as described
|
|
above for <CODE>store_typed_address</CODE>.
|
|
</DL>
|
|
</P><P>
|
|
|
|
GDB also provides functions that do the same tasks, but assume
|
|
that pointers are simply byte addresses; they aren't sensitive to the
|
|
current architecture, beyond knowing the appropriate endianness.
|
|
</P><P>
|
|
|
|
<A NAME="IDX273"></A>
|
|
<DL>
|
|
<DT><U>Function:</U> CORE_ADDR <B>extract_address</B> <I>(void *<VAR>addr</VAR>, int len)</I>
|
|
<DD>Extract a <VAR>len</VAR>-byte number from <VAR>addr</VAR> in the appropriate
|
|
endianness for the current architecture, and return it. Note that
|
|
<VAR>addr</VAR> refers to GDB's memory, not the inferior's.
|
|
</P><P>
|
|
|
|
This function should only be used in architecture-specific code; it
|
|
doesn't have enough information to turn bits into a true address in the
|
|
appropriate way for the current architecture. If you can, use
|
|
<CODE>extract_typed_address</CODE> instead.
|
|
</DL>
|
|
</P><P>
|
|
|
|
<A NAME="IDX274"></A>
|
|
<DL>
|
|
<DT><U>Function:</U> void <B>store_address</B> <I>(void *<VAR>addr</VAR>, int <VAR>len</VAR>, LONGEST <VAR>val</VAR>)</I>
|
|
<DD>Store <VAR>val</VAR> at <VAR>addr</VAR> as a <VAR>len</VAR>-byte integer, in the
|
|
appropriate endianness for the current architecture. Note that
|
|
<VAR>addr</VAR> refers to a buffer in GDB's memory, not the
|
|
inferior's.
|
|
</P><P>
|
|
|
|
This function should only be used in architecture-specific code; it
|
|
doesn't have enough information to turn a true address into bits in the
|
|
appropriate way for the current architecture. If you can, use
|
|
<CODE>store_typed_address</CODE> instead.
|
|
</DL>
|
|
</P><P>
|
|
|
|
Here are some macros which architectures can define to indicate the
|
|
relationship between pointers and addresses. These have default
|
|
definitions, appropriate for architectures on which all pointers are
|
|
simple unsigned byte addresses.
|
|
</P><P>
|
|
|
|
<A NAME="IDX275"></A>
|
|
<DL>
|
|
<DT><U>Target Macro:</U> CORE_ADDR <B>POINTER_TO_ADDRESS</B> <I>(struct type *<VAR>type</VAR>, char *<VAR>buf</VAR>)</I>
|
|
<DD>Assume that <VAR>buf</VAR> holds a pointer of type <VAR>type</VAR>, in the
|
|
appropriate format for the current architecture. Return the byte
|
|
address the pointer refers to.
|
|
</P><P>
|
|
|
|
This function may safely assume that <VAR>type</VAR> is either a pointer or a
|
|
C<TT>++</TT> reference type.
|
|
</DL>
|
|
</P><P>
|
|
|
|
<A NAME="IDX276"></A>
|
|
<DL>
|
|
<DT><U>Target Macro:</U> void <B>ADDRESS_TO_POINTER</B> <I>(struct type *<VAR>type</VAR>, char *<VAR>buf</VAR>, CORE_ADDR <VAR>addr</VAR>)</I>
|
|
<DD>Store in <VAR>buf</VAR> a pointer of type <VAR>type</VAR> representing the address
|
|
<VAR>addr</VAR>, in the appropriate format for the current architecture.
|
|
</P><P>
|
|
|
|
This function may safely assume that <VAR>type</VAR> is either a pointer or a
|
|
C<TT>++</TT> reference type.
|
|
</DL>
|
|
</P><P>
|
|
|
|
<HR SIZE="6">
|
|
<A NAME="SEC71"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC70"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC72"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC72"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC67"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_10.html#SEC88"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_19.html#SEC186">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 9.4 Address Classes </H2>
|
|
<!--docid::SEC71::-->
|
|
<P>
|
|
|
|
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, <CODE>DW_AT_byte_size</CODE> in DWARF 2) or through an explicit
|
|
address class attribute (e.g, <CODE>DW_AT_address_class</CODE> 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.
|
|
</P><P>
|
|
|
|
<A NAME="IDX277"></A>
|
|
<DL>
|
|
<DT><U>Target Macro:</U> int <B>ADDRESS_CLASS_TYPE_FLAGS</B> <I>(int <VAR>byte_size</VAR>, int <VAR>dwarf2_addr_class</VAR>)</I>
|
|
<DD>Returns the type flags needed to construct a pointer type whose size
|
|
is <VAR>byte_size</VAR> and whose address class is <VAR>dwarf2_addr_class</VAR>.
|
|
This function is normally called from within a symbol reader. See
|
|
<TT>`dwarf2read.c'</TT>.
|
|
</DL>
|
|
</P><P>
|
|
|
|
<A NAME="IDX278"></A>
|
|
<DL>
|
|
<DT><U>Target Macro:</U> char <B>*ADDRESS_CLASS_TYPE_FLAGS_TO_NAME</B> <I>(int <VAR>type_flags</VAR>)</I>
|
|
<DD>Given the type flags representing an address class qualifier, return
|
|
its name.
|
|
</DL>
|
|
<A NAME="IDX279"></A>
|
|
<DL>
|
|
<DT><U>Target Macro:</U> int <B>ADDRESS_CLASS_NAME_to_TYPE_FLAGS</B> <I>(int <VAR>name</VAR>, int *var{type_flags_ptr})</I>
|
|
<DD>Given an address qualifier name, set the <CODE>int</CODE> refererenced by <VAR>type_flags_ptr</VAR> to the type flags
|
|
for that address class qualifier.
|
|
</DL>
|
|
</P><P>
|
|
|
|
Since the need for address classes is rather rare, none of
|
|
the address class macros defined by default. Predicate
|
|
macros are provided to detect when they are defined.
|
|
</P><P>
|
|
|
|
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 <CODE>DW_AT_byte_size</CODE> value of 2 to indicate the use of one
|
|
of these "short" pointers. The following functions could be defined
|
|
to implement the address class macros:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=smallexample><FONT SIZE=-1><pre>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;
|
|
}
|
|
</FONT></pre></td></tr></table></P><P>
|
|
|
|
The qualifier <CODE>@short</CODE> 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 <CODE>short_ptr_var</CODE> is one of these
|
|
short pointers, GDB might show the following behavior:
|
|
</P><P>
|
|
|
|
<TABLE><tr><td> </td><td class=smallexample><FONT SIZE=-1><pre>(gdb) ptype short_ptr_var
|
|
type = int * @short
|
|
</FONT></pre></td></tr></table></P><P>
|
|
|
|
<HR SIZE="6">
|
|
<A NAME="SEC72"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC71"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC73"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC73"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC67"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_10.html#SEC88"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_19.html#SEC186">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 9.5 Raw and Virtual Register Representations </H2>
|
|
<!--docid::SEC72::-->
|
|
<P>
|
|
|
|
<EM>Maintainer note: This section is pretty much obsolete. The
|
|
functionality described here has largely been replaced by
|
|
pseudo-registers and the mechanisms described in <A HREF="gdbint_9.html#SEC67">Using Different Register and Memory Data Representations</A>. See also <A HREF="http://www.gnu.org/software/gdb/bugs/">Bug Tracking Database</EM> and
|
|
<A HREF="http://sources.redhat.com/gdb/current/ari/">ARI Index</A> for more
|
|
up-to-date information.</A>
|
|
</P><P>
|
|
|
|
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 <EM>raw</EM> representation is the one used in
|
|
the target registers, and the <EM>virtual</EM> representation is the one
|
|
used in memory, and within GDB <CODE>struct value</CODE> objects.
|
|
</P><P>
|
|
|
|
<EM>Maintainer note: Notice that the same mechanism is being used to
|
|
both convert a register to a <CODE>struct value</CODE> and alternative
|
|
register forms.</EM>
|
|
</P><P>
|
|
|
|
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:
|
|
</P><P>
|
|
|
|
<UL>
|
|
<LI>
|
|
The x86 architecture supports an 80-bit <CODE>long double</CODE> 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.
|
|
<P>
|
|
|
|
<LI>
|
|
Some 64-bit MIPS targets present 32-bit registers to GDB as 64-bit
|
|
registers, with garbage in their upper bits. GDB ignores the top 32
|
|
bits. Thus, the 64-bit form, with garbage in the upper 32 bits, is the
|
|
raw representation, and the trimmed 32-bit representation is the
|
|
virtual representation.
|
|
</UL>
|
|
<P>
|
|
|
|
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,
|
|
<CODE>registers</CODE>, holds the register contents in raw format, and the
|
|
GDB remote protocol transmits register values in raw format.
|
|
</P><P>
|
|
|
|
Your architecture may define the following macros to request
|
|
conversions between the raw and virtual format:
|
|
</P><P>
|
|
|
|
<A NAME="IDX280"></A>
|
|
<DL>
|
|
<DT><U>Target Macro:</U> int <B>REGISTER_CONVERTIBLE</B> <I>(int <VAR>reg</VAR>)</I>
|
|
<DD>Return non-zero if register number <VAR>reg</VAR>'s value needs different raw
|
|
and virtual formats.
|
|
</P><P>
|
|
|
|
You should not use <CODE>REGISTER_CONVERT_TO_VIRTUAL</CODE> for a register
|
|
unless this macro returns a non-zero value for that register.
|
|
</DL>
|
|
</P><P>
|
|
|
|
<A NAME="IDX281"></A>
|
|
<DL>
|
|
<DT><U>Target Macro:</U> int <B>REGISTER_RAW_SIZE</B> <I>(int <VAR>reg</VAR>)</I>
|
|
<DD>The size of register number <VAR>reg</VAR>'s raw value. This is the number
|
|
of bytes the register will occupy in <CODE>registers</CODE>, or in a GDB
|
|
remote protocol packet.
|
|
</DL>
|
|
</P><P>
|
|
|
|
<A NAME="IDX282"></A>
|
|
<DL>
|
|
<DT><U>Target Macro:</U> int <B>REGISTER_VIRTUAL_SIZE</B> <I>(int <VAR>reg</VAR>)</I>
|
|
<DD>The size of register number <VAR>reg</VAR>'s value, in its virtual format.
|
|
This is the size a <CODE>struct value</CODE>'s buffer will have, holding that
|
|
register's value.
|
|
</DL>
|
|
</P><P>
|
|
|
|
<A NAME="IDX283"></A>
|
|
<DL>
|
|
<DT><U>Target Macro:</U> struct <B>type</B> <I>*REGISTER_VIRTUAL_TYPE (int <VAR>reg</VAR>)</I>
|
|
<DD>This is the type of the virtual representation of register number
|
|
<VAR>reg</VAR>. Note that there is no need for a macro giving a type for the
|
|
register's raw form; once the register's value has been obtained, GDB
|
|
always uses the virtual form.
|
|
</DL>
|
|
</P><P>
|
|
|
|
<A NAME="IDX284"></A>
|
|
<DL>
|
|
<DT><U>Target Macro:</U> void <B>REGISTER_CONVERT_TO_VIRTUAL</B> <I>(int <VAR>reg</VAR>, struct type *<VAR>type</VAR>, char *<VAR>from</VAR>, char *<VAR>to</VAR>)</I>
|
|
<DD>Convert the value of register number <VAR>reg</VAR> to <VAR>type</VAR>, which
|
|
should always be <CODE>REGISTER_VIRTUAL_TYPE (<VAR>reg</VAR>)</CODE>. The buffer
|
|
at <VAR>from</VAR> holds the register's value in raw format; the macro should
|
|
convert the value to virtual format, and place it at <VAR>to</VAR>.
|
|
</P><P>
|
|
|
|
Note that <CODE>REGISTER_CONVERT_TO_VIRTUAL</CODE> and
|
|
<CODE>REGISTER_CONVERT_TO_RAW</CODE> take their <VAR>reg</VAR> and <VAR>type</VAR>
|
|
arguments in different orders.
|
|
</P><P>
|
|
|
|
You should only use <CODE>REGISTER_CONVERT_TO_VIRTUAL</CODE> with registers
|
|
for which the <CODE>REGISTER_CONVERTIBLE</CODE> macro returns a non-zero
|
|
value.
|
|
</DL>
|
|
</P><P>
|
|
|
|
<A NAME="IDX285"></A>
|
|
<DL>
|
|
<DT><U>Target Macro:</U> void <B>REGISTER_CONVERT_TO_RAW</B> <I>(struct type *<VAR>type</VAR>, int <VAR>reg</VAR>, char *<VAR>from</VAR>, char *<VAR>to</VAR>)</I>
|
|
<DD>Convert the value of register number <VAR>reg</VAR> to <VAR>type</VAR>, which
|
|
should always be <CODE>REGISTER_VIRTUAL_TYPE (<VAR>reg</VAR>)</CODE>. The buffer
|
|
at <VAR>from</VAR> holds the register's value in raw format; the macro should
|
|
convert the value to virtual format, and place it at <VAR>to</VAR>.
|
|
</P><P>
|
|
|
|
Note that REGISTER_CONVERT_TO_VIRTUAL and REGISTER_CONVERT_TO_RAW take
|
|
their <VAR>reg</VAR> and <VAR>type</VAR> arguments in different orders.
|
|
</DL>
|
|
</P><P>
|
|
|
|
<HR SIZE="6">
|
|
<A NAME="SEC73"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC72"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC74"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC74"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC67"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_10.html#SEC88"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_19.html#SEC186">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 9.6 Using Different Register and Memory Data Representations </H2>
|
|
<!--docid::SEC73::-->
|
|
<P>
|
|
|
|
<EM>Maintainer's note: The way GDB manipulates registers is undergoing
|
|
significant change. Many of the macros and functions refered to in this
|
|
section are likely to be subject to further revision. See
|
|
<A HREF="http://sources.redhat.com/gdb/current/ari/">A.R. Index</A> and
|
|
<A HREF="http://www.gnu.org/software/gdb/bugs">Bug Tracking Database</A> for
|
|
further information. cagney/2002-05-06.</EM>
|
|
</P><P>
|
|
|
|
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:
|
|
</P><P>
|
|
|
|
<UL>
|
|
|
|
<LI>
|
|
The Alpha architecture can represent 32 bit integer values in
|
|
floating-point registers.
|
|
<P>
|
|
|
|
<LI>
|
|
The x86 architecture supports 80-bit floating-point registers. The
|
|
<CODE>long double</CODE> data type occupies 96 bits in memory but only 80 bits
|
|
when stored in a register.
|
|
<P>
|
|
|
|
</UL>
|
|
<P>
|
|
|
|
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.
|
|
</P><P>
|
|
|
|
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:
|
|
</P><P>
|
|
|
|
<A NAME="IDX286"></A>
|
|
<DL>
|
|
<DT><U>Target Macro:</U> int <B>CONVERT_REGISTER_P</B> <I>(int <VAR>reg</VAR>)</I>
|
|
<DD>Return non-zero 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.
|
|
</P><P>
|
|
|
|
When non-zero, the macros <CODE>REGISTER_TO_VALUE</CODE> and
|
|
<CODE>VALUE_TO_REGISTER</CODE> are used to perform any necessary conversion.
|
|
</DL>
|
|
</P><P>
|
|
|
|
<A NAME="IDX287"></A>
|
|
<DL>
|
|
<DT><U>Target Macro:</U> void <B>REGISTER_TO_VALUE</B> <I>(int <VAR>reg</VAR>, struct type *<VAR>type</VAR>, char *<VAR>from</VAR>, char *<VAR>to</VAR>)</I>
|
|
<DD>Convert the value of register number <VAR>reg</VAR> to a data object of type
|
|
<VAR>type</VAR>. The buffer at <VAR>from</VAR> holds the register's value in raw
|
|
format; the converted value should be placed in the buffer at <VAR>to</VAR>.
|
|
</P><P>
|
|
|
|
Note that <CODE>REGISTER_TO_VALUE</CODE> and <CODE>VALUE_TO_REGISTER</CODE> take
|
|
their <VAR>reg</VAR> and <VAR>type</VAR> arguments in different orders.
|
|
</P><P>
|
|
|
|
You should only use <CODE>REGISTER_TO_VALUE</CODE> with registers for which
|
|
the <CODE>CONVERT_REGISTER_P</CODE> macro returns a non-zero value.
|
|
</DL>
|
|
</P><P>
|
|
|
|
<A NAME="IDX288"></A>
|
|
<DL>
|
|
<DT><U>Target Macro:</U> void <B>VALUE_TO_REGISTER</B> <I>(struct type *<VAR>type</VAR>, int <VAR>reg</VAR>, char *<VAR>from</VAR>, char *<VAR>to</VAR>)</I>
|
|
<DD>Convert a data value of type <VAR>type</VAR> to register number <VAR>reg</VAR>'
|
|
raw format.
|
|
</P><P>
|
|
|
|
Note that <CODE>REGISTER_TO_VALUE</CODE> and <CODE>VALUE_TO_REGISTER</CODE> take
|
|
their <VAR>reg</VAR> and <VAR>type</VAR> arguments in different orders.
|
|
</P><P>
|
|
|
|
You should only use <CODE>VALUE_TO_REGISTER</CODE> with registers for which
|
|
the <CODE>CONVERT_REGISTER_P</CODE> macro returns a non-zero value.
|
|
</DL>
|
|
</P><P>
|
|
|
|
<A NAME="IDX289"></A>
|
|
<DL>
|
|
<DT><U>Target Macro:</U> void <B>REGISTER_CONVERT_TO_TYPE</B> <I>(int <VAR>regnum</VAR>, struct type *<VAR>type</VAR>, char *<VAR>buf</VAR>)</I>
|
|
<DD>See <TT>`mips-tdep.c'</TT>. It does not do what you want.
|
|
</DL>
|
|
</P><P>
|
|
|
|
<HR SIZE="6">
|
|
<A NAME="SEC74"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC73"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC75"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC75"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC67"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_10.html#SEC88"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_19.html#SEC186">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 9.7 Frame Interpretation </H2>
|
|
<!--docid::SEC74::-->
|
|
<P>
|
|
|
|
<HR SIZE="6">
|
|
<A NAME="SEC75"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC74"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC76"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC76"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC67"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_10.html#SEC88"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_19.html#SEC186">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 9.8 Inferior Call Setup </H2>
|
|
<!--docid::SEC75::-->
|
|
<P>
|
|
|
|
<HR SIZE="6">
|
|
<A NAME="SEC76"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC75"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC77"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[ << ]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC67"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_10.html#SEC88"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_19.html#SEC186">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 9.9 Compiler Characteristics </H2>
|
|
<!--docid::SEC76::-->
|
|
<P>
|
|
|
|
<HR SIZE="6">
|
|
<A NAME="SEC77"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC76"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC78"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC69"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC67"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_10.html#SEC88"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_19.html#SEC186">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 9.10 Target Conditionals </H2>
|
|
<!--docid::SEC77::-->
|
|
<P>
|
|
|
|
This section describes the macros that you can use to define the target
|
|
machine.
|
|
</P><P>
|
|
|
|
<DL COMPACT>
|
|
|
|
<DT><CODE>ADDITIONAL_OPTIONS</CODE>
|
|
<DD><DT><CODE>ADDITIONAL_OPTION_CASES</CODE>
|
|
<DD><DT><CODE>ADDITIONAL_OPTION_HANDLER</CODE>
|
|
<DD><DT><CODE>ADDITIONAL_OPTION_HELP</CODE>
|
|
<DD><A NAME="IDX290"></A>
|
|
<A NAME="IDX291"></A>
|
|
<A NAME="IDX292"></A>
|
|
<A NAME="IDX293"></A>
|
|
These are a set of macros that allow the addition of additional command
|
|
line options to GDB. They are currently used only for the unsupported
|
|
i960 Nindy target, and should not be used in any other configuration.
|
|
<P>
|
|
|
|
<DT><CODE>ADDR_BITS_REMOVE (addr)</CODE>
|
|
<DD><A NAME="IDX294"></A>
|
|
If a raw machine instruction address includes any bits that are not
|
|
really part of the address, then define this macro to expand into an
|
|
expression that zeroes those bits in <VAR>addr</VAR>. This is only used for
|
|
addresses of instructions, and even then not in all contexts.
|
|
<P>
|
|
|
|
For example, the two low-order bits of the PC on the Hewlett-Packard PA
|
|
2.0 architecture contain the privilege level of the corresponding
|
|
instruction. Since instructions must always be aligned on four-byte
|
|
boundaries, the processor masks out these bits to generate the actual
|
|
address of the instruction. ADDR_BITS_REMOVE should filter out these
|
|
bits with an expression such as <CODE>((addr) & ~3)</CODE>.
|
|
</P><P>
|
|
|
|
<DT><CODE>ADDRESS_CLASS_NAME_TO_TYPE_FLAGS (<VAR>name</VAR>, <VAR>type_flags_ptr</VAR>)</CODE>
|
|
<DD><A NAME="IDX295"></A>
|
|
If <VAR>name</VAR> is a valid address class qualifier name, set the <CODE>int</CODE>
|
|
referenced by <VAR>type_flags_ptr</VAR> to the mask representing the qualifier
|
|
and return 1. If <VAR>name</VAR> is not a valid address class qualifier name,
|
|
return 0.
|
|
<P>
|
|
|
|
The value for <VAR>type_flags_ptr</VAR> should be one of
|
|
<CODE>TYPE_FLAG_ADDRESS_CLASS_1</CODE>, <CODE>TYPE_FLAG_ADDRESS_CLASS_2</CODE>, or
|
|
possibly some combination of these values or'd together.
|
|
See section <A HREF="gdbint_9.html#SEC67">Address Classes</A>.
|
|
</P><P>
|
|
|
|
<DT><CODE>ADDRESS_CLASS_NAME_TO_TYPE_FLAGS_P ()</CODE>
|
|
<DD><A NAME="IDX296"></A>
|
|
Predicate which indicates whether <CODE>ADDRESS_CLASS_NAME_TO_TYPE_FLAGS</CODE>
|
|
has been defined.
|
|
<P>
|
|
|
|
<DT><CODE>ADDRESS_CLASS_TYPE_FLAGS (<VAR>byte_size</VAR>, <VAR>dwarf2_addr_class</VAR>)</CODE>
|
|
<DD><A NAME="IDX297"></A>
|
|
Given a pointers byte size (as described by the debug information) and
|
|
the possible <CODE>DW_AT_address_class</CODE> value, return the type flags
|
|
used by GDB to represent this address class. The value
|
|
returned should be one of <CODE>TYPE_FLAG_ADDRESS_CLASS_1</CODE>,
|
|
<CODE>TYPE_FLAG_ADDRESS_CLASS_2</CODE>, or possibly some combination of these
|
|
values or'd together.
|
|
See section <A HREF="gdbint_9.html#SEC67">Address Classes</A>.
|
|
<P>
|
|
|
|
<DT><CODE>ADDRESS_CLASS_TYPE_FLAGS_P ()</CODE>
|
|
<DD><A NAME="IDX298"></A>
|
|
Predicate which indicates whether <CODE>ADDRESS_CLASS_TYPE_FLAGS</CODE> has
|
|
been defined.
|
|
<P>
|
|
|
|
<DT><CODE>ADDRESS_CLASS_TYPE_FLAGS_TO_NAME (<VAR>type_flags</VAR>)</CODE>
|
|
<DD><A NAME="IDX299"></A>
|
|
Return the name of the address class qualifier associated with the type
|
|
flags given by <VAR>type_flags</VAR>.
|
|
<P>
|
|
|
|
<DT><CODE>ADDRESS_CLASS_TYPE_FLAGS_TO_NAME_P ()</CODE>
|
|
<DD><A NAME="IDX300"></A>
|
|
Predicate which indicates whether <CODE>ADDRESS_CLASS_TYPE_FLAGS_TO_NAME</CODE> has
|
|
been defined.
|
|
See section <A HREF="gdbint_9.html#SEC67">Address Classes</A>.
|
|
<P>
|
|
|
|
<DT><CODE>ADDRESS_TO_POINTER (<VAR>type</VAR>, <VAR>buf</VAR>, <VAR>addr</VAR>)</CODE>
|
|
<DD><A NAME="IDX301"></A>
|
|
Store in <VAR>buf</VAR> a pointer of type <VAR>type</VAR> representing the address
|
|
<VAR>addr</VAR>, in the appropriate format for the current architecture.
|
|
This macro may safely assume that <VAR>type</VAR> is either a pointer or a
|
|
C<TT>++</TT> reference type.
|
|
See section <A HREF="gdbint_9.html#SEC67">Pointers Are Not Always Addresses</A>.
|
|
<P>
|
|
|
|
<DT><CODE>BEFORE_MAIN_LOOP_HOOK</CODE>
|
|
<DD><A NAME="IDX302"></A>
|
|
Define this to expand into any code that you want to execute before the
|
|
main loop starts. Although this is not, strictly speaking, a target
|
|
conditional, that is how it is currently being used. Note that if a
|
|
configuration were to define it one way for a host and a different way
|
|
for the target, GDB will probably not compile, let alone run
|
|
correctly. This macro is currently used only for the unsupported i960 Nindy
|
|
target, and should not be used in any other configuration.
|
|
<P>
|
|
|
|
<DT><CODE>BELIEVE_PCC_PROMOTION</CODE>
|
|
<DD><A NAME="IDX303"></A>
|
|
Define if the compiler promotes a <CODE>short</CODE> or <CODE>char</CODE>
|
|
parameter to an <CODE>int</CODE>, but still reports the parameter as its
|
|
original type, rather than the promoted type.
|
|
<P>
|
|
|
|
<DT><CODE>BELIEVE_PCC_PROMOTION_TYPE</CODE>
|
|
<DD><A NAME="IDX304"></A>
|
|
Define this if GDB should believe the type of a <CODE>short</CODE>
|
|
argument when compiled by <CODE>pcc</CODE>, but look within a full int space to get
|
|
its value. Only defined for Sun-3 at present.
|
|
<P>
|
|
|
|
<DT><CODE>BITS_BIG_ENDIAN</CODE>
|
|
<DD><A NAME="IDX305"></A>
|
|
Define this if the numbering of bits in the targets does <STRONG>not</STRONG> match the
|
|
endianness of the target byte order. A value of 1 means that the bits
|
|
are numbered in a big-endian bit order, 0 means little-endian.
|
|
<P>
|
|
|
|
<DT><CODE>BREAKPOINT</CODE>
|
|
<DD><A NAME="IDX306"></A>
|
|
This is the character array initializer for the bit pattern to put into
|
|
memory where a breakpoint is set. Although it's 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.
|
|
<P>
|
|
|
|
<CODE>BREAKPOINT</CODE> has been deprecated in favor of
|
|
<CODE>BREAKPOINT_FROM_PC</CODE>.
|
|
</P><P>
|
|
|
|
<DT><CODE>BIG_BREAKPOINT</CODE>
|
|
<DD><DT><CODE>LITTLE_BREAKPOINT</CODE>
|
|
<DD><A NAME="IDX307"></A>
|
|
<A NAME="IDX308"></A>
|
|
Similar to BREAKPOINT, but used for bi-endian targets.
|
|
<P>
|
|
|
|
<CODE>BIG_BREAKPOINT</CODE> and <CODE>LITTLE_BREAKPOINT</CODE> have been deprecated in
|
|
favor of <CODE>BREAKPOINT_FROM_PC</CODE>.
|
|
</P><P>
|
|
|
|
<DT><CODE>REMOTE_BREAKPOINT</CODE>
|
|
<DD><DT><CODE>LITTLE_REMOTE_BREAKPOINT</CODE>
|
|
<DD><DT><CODE>BIG_REMOTE_BREAKPOINT</CODE>
|
|
<DD><A NAME="IDX309"></A>
|
|
<A NAME="IDX310"></A>
|
|
<A NAME="IDX311"></A>
|
|
Similar to BREAKPOINT, but used for remote targets.
|
|
<P>
|
|
|
|
<CODE>BIG_REMOTE_BREAKPOINT</CODE> and <CODE>LITTLE_REMOTE_BREAKPOINT</CODE> have been
|
|
deprecated in favor of <CODE>BREAKPOINT_FROM_PC</CODE>.
|
|
</P><P>
|
|
|
|
<DT><CODE>BREAKPOINT_FROM_PC (<VAR>pcptr</VAR>, <VAR>lenptr</VAR>)</CODE>
|
|
<DD><A NAME="IDX312"></A>
|
|
Use the program counter to determine the contents and size of a
|
|
breakpoint instruction. It returns a pointer to a string of bytes
|
|
that encode a breakpoint instruction, stores the length of the string
|
|
to *<VAR>lenptr</VAR>, and adjusts pc (if necessary) to point to the actual
|
|
memory location where the breakpoint should be inserted.
|
|
<P>
|
|
|
|
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.
|
|
</P><P>
|
|
|
|
Replaces all the other <VAR>BREAKPOINT</VAR> macros.
|
|
</P><P>
|
|
|
|
<DT><CODE>MEMORY_INSERT_BREAKPOINT (<VAR>addr</VAR>, <VAR>contents_cache</VAR>)</CODE>
|
|
<DD><DT><CODE>MEMORY_REMOVE_BREAKPOINT (<VAR>addr</VAR>, <VAR>contents_cache</VAR>)</CODE>
|
|
<DD><A NAME="IDX313"></A>
|
|
<A NAME="IDX314"></A>
|
|
Insert or remove memory based breakpoints. Reasonable defaults
|
|
(<CODE>default_memory_insert_breakpoint</CODE> and
|
|
<CODE>default_memory_remove_breakpoint</CODE> respectively) have been
|
|
provided so that it is not necessary to define these for most
|
|
architectures. Architectures which may want to define
|
|
<CODE>MEMORY_INSERT_BREAKPOINT</CODE> and <CODE>MEMORY_REMOVE_BREAKPOINT</CODE> will
|
|
likely have instructions that are oddly sized or are not stored in a
|
|
conventional manner.
|
|
<P>
|
|
|
|
It may also be desirable (from an efficiency standpoint) to define
|
|
custom breakpoint insertion and removal routines if
|
|
<CODE>BREAKPOINT_FROM_PC</CODE> needs to read the target's memory for some
|
|
reason.
|
|
</P><P>
|
|
|
|
<DT><CODE>CALL_DUMMY_P</CODE>
|
|
<DD><A NAME="IDX315"></A>
|
|
A C expression that is non-zero when the target supports inferior function
|
|
calls.
|
|
<P>
|
|
|
|
<DT><CODE>CALL_DUMMY_WORDS</CODE>
|
|
<DD><A NAME="IDX316"></A>
|
|
Pointer to an array of <CODE>LONGEST</CODE> words of data containing
|
|
host-byte-ordered <CODE>REGISTER_BYTES</CODE> sized values that partially
|
|
specify the sequence of instructions needed for an inferior function
|
|
call.
|
|
<P>
|
|
|
|
Should be deprecated in favor of a macro that uses target-byte-ordered
|
|
data.
|
|
</P><P>
|
|
|
|
<DT><CODE>SIZEOF_CALL_DUMMY_WORDS</CODE>
|
|
<DD><A NAME="IDX317"></A>
|
|
The size of <CODE>CALL_DUMMY_WORDS</CODE>. When <CODE>CALL_DUMMY_P</CODE> this must
|
|
return a positive value. See also <CODE>CALL_DUMMY_LENGTH</CODE>.
|
|
<P>
|
|
|
|
<DT><CODE>CALL_DUMMY</CODE>
|
|
<DD><A NAME="IDX318"></A>
|
|
A static initializer for <CODE>CALL_DUMMY_WORDS</CODE>. Deprecated.
|
|
<P>
|
|
|
|
<DT><CODE>CALL_DUMMY_LOCATION</CODE>
|
|
<DD><A NAME="IDX319"></A>
|
|
See the file <TT>`inferior.h'</TT>.
|
|
<P>
|
|
|
|
<DT><CODE>CALL_DUMMY_STACK_ADJUST</CODE>
|
|
<DD><A NAME="IDX320"></A>
|
|
Stack adjustment needed when performing an inferior function call.
|
|
<P>
|
|
|
|
Should be deprecated in favor of something like <CODE>STACK_ALIGN</CODE>.
|
|
</P><P>
|
|
|
|
<DT><CODE>CALL_DUMMY_STACK_ADJUST_P</CODE>
|
|
<DD><A NAME="IDX321"></A>
|
|
Predicate for use of <CODE>CALL_DUMMY_STACK_ADJUST</CODE>.
|
|
<P>
|
|
|
|
Should be deprecated in favor of something like <CODE>STACK_ALIGN</CODE>.
|
|
</P><P>
|
|
|
|
<DT><CODE>CANNOT_FETCH_REGISTER (<VAR>regno</VAR>)</CODE>
|
|
<DD><A NAME="IDX322"></A>
|
|
A C expression that should be nonzero if <VAR>regno</VAR> cannot be fetched
|
|
from an inferior process. This is only relevant if
|
|
<CODE>FETCH_INFERIOR_REGISTERS</CODE> is not defined.
|
|
<P>
|
|
|
|
<DT><CODE>CANNOT_STORE_REGISTER (<VAR>regno</VAR>)</CODE>
|
|
<DD><A NAME="IDX323"></A>
|
|
A C expression that should be nonzero if <VAR>regno</VAR> should not be
|
|
written to the target. This is often the case for program counters,
|
|
status words, and other special registers. If this is not defined,
|
|
GDB will assume that all registers may be written.
|
|
<P>
|
|
|
|
<DT><CODE>DO_DEFERRED_STORES</CODE>
|
|
<DD><DT><CODE>CLEAR_DEFERRED_STORES</CODE>
|
|
<DD><A NAME="IDX324"></A>
|
|
<A NAME="IDX325"></A>
|
|
Define this to execute any deferred stores of registers into the inferior,
|
|
and to cancel any deferred stores.
|
|
<P>
|
|
|
|
Currently only implemented correctly for native Sparc configurations?
|
|
</P><P>
|
|
|
|
<DT><CODE>COERCE_FLOAT_TO_DOUBLE (<VAR>formal</VAR>, <VAR>actual</VAR>)</CODE>
|
|
<DD><A NAME="IDX326"></A>
|
|
<A NAME="IDX327"></A>
|
|
<A NAME="IDX328"></A>
|
|
<A NAME="IDX329"></A>
|
|
<A NAME="IDX330"></A>
|
|
Return non-zero if GDB should promote <CODE>float</CODE> values to
|
|
<CODE>double</CODE> when calling a non-prototyped function. The argument
|
|
<VAR>actual</VAR> is the type of the value we want to pass to the function.
|
|
The argument <VAR>formal</VAR> is the type of this argument, as it appears in
|
|
the function's definition. Note that <VAR>formal</VAR> may be zero if we
|
|
have no debugging information for the function, or if we're passing more
|
|
arguments than are officially declared (for example, varargs). This
|
|
macro is never invoked if the function definitely has a prototype.
|
|
<P>
|
|
|
|
How you should pass arguments to a function depends on whether it was
|
|
defined in K&R style or prototype style. If you define a function using
|
|
the K&R syntax that takes a <CODE>float</CODE> argument, then callers must
|
|
pass that argument as a <CODE>double</CODE>. If you define the function using
|
|
the prototype syntax, then you must pass the argument as a <CODE>float</CODE>,
|
|
with no promotion.
|
|
</P><P>
|
|
|
|
Unfortunately, on certain older platforms, the debug info doesn't
|
|
indicate reliably how each function was defined. A function type's
|
|
<CODE>TYPE_FLAG_PROTOTYPED</CODE> flag may be unset, even if the function was
|
|
defined in prototype style. When calling a function whose
|
|
<CODE>TYPE_FLAG_PROTOTYPED</CODE> flag is unset, GDB consults the
|
|
<CODE>COERCE_FLOAT_TO_DOUBLE</CODE> macro to decide what to do.
|
|
</P><P>
|
|
|
|
<A NAME="IDX331"></A>
|
|
For modern targets, it is proper to assume that, if the prototype flag
|
|
is unset, that can be trusted: <CODE>float</CODE> arguments should be promoted
|
|
to <CODE>double</CODE>. You should use the function
|
|
<CODE>standard_coerce_float_to_double</CODE> to get this behavior.
|
|
</P><P>
|
|
|
|
<A NAME="IDX332"></A>
|
|
For some older targets, if the prototype flag is unset, that doesn't
|
|
tell us anything. So we guess that, if we don't have a type for the
|
|
formal parameter (<I>i.e.</I>, the first argument to
|
|
<CODE>COERCE_FLOAT_TO_DOUBLE</CODE> is null), then we should promote it;
|
|
otherwise, we should leave it alone. The function
|
|
<CODE>default_coerce_float_to_double</CODE> provides this behavior; it is the
|
|
default value, for compatibility with older configurations.
|
|
</P><P>
|
|
|
|
<DT><CODE>int CONVERT_REGISTER_P(<VAR>regnum</VAR>)</CODE>
|
|
<DD><A NAME="IDX333"></A>
|
|
Return non-zero if register <VAR>regnum</VAR> can represent data values in a
|
|
non-standard form.
|
|
See section <A HREF="gdbint_9.html#SEC67">Using Different Register and Memory Data Representations</A>.
|
|
<P>
|
|
|
|
<DT><CODE>DBX_PARM_SYMBOL_CLASS</CODE>
|
|
<DD><A NAME="IDX334"></A>
|
|
Hook for the <CODE>SYMBOL_CLASS</CODE> of a parameter when decoding DBX symbol
|
|
information. In the i960, parameters can be stored as locals or as
|
|
args, depending on the type of the debug record.
|
|
<P>
|
|
|
|
<DT><CODE>DECR_PC_AFTER_BREAK</CODE>
|
|
<DD><A NAME="IDX335"></A>
|
|
Define this to be the amount by which to decrement the PC after the
|
|
program encounters a breakpoint. This is often the number of bytes in
|
|
<CODE>BREAKPOINT</CODE>, though not always. For most targets this value will be 0.
|
|
<P>
|
|
|
|
<DT><CODE>DECR_PC_AFTER_HW_BREAK</CODE>
|
|
<DD><A NAME="IDX336"></A>
|
|
Similarly, for hardware breakpoints.
|
|
<P>
|
|
|
|
<DT><CODE>DISABLE_UNSETTABLE_BREAK (<VAR>addr</VAR>)</CODE>
|
|
<DD><A NAME="IDX337"></A>
|
|
If defined, this should evaluate to 1 if <VAR>addr</VAR> is in a shared
|
|
library in which breakpoints cannot be set and so should be disabled.
|
|
<P>
|
|
|
|
<DT><CODE>PRINT_FLOAT_INFO()</CODE>
|
|
<DD><A NAME="IDX338"></A>
|
|
If defined, then the <SAMP>`info float'</SAMP> command will print information about
|
|
the processor's floating point unit.
|
|
<P>
|
|
|
|
<DT><CODE>print_registers_info (<VAR>gdbarch</VAR>, <VAR>frame</VAR>, <VAR>regnum</VAR>, <VAR>all</VAR>)</CODE>
|
|
<DD><A NAME="IDX339"></A>
|
|
If defined, pretty print the value of the register <VAR>regnum</VAR> for the
|
|
specified <VAR>frame</VAR>. If the value of <VAR>regnum</VAR> is -1, pretty print
|
|
either all registers (<VAR>all</VAR> is non zero) or a select subset of
|
|
registers (<VAR>all</VAR> is zero).
|
|
<P>
|
|
|
|
The default method prints one register per line, and if <VAR>all</VAR> is
|
|
zero omits floating-point registers.
|
|
</P><P>
|
|
|
|
<DT><CODE>PRINT_VECTOR_INFO()</CODE>
|
|
<DD><A NAME="IDX340"></A>
|
|
If defined, then the <SAMP>`info vector'</SAMP> command will call this function
|
|
to print information about the processor's vector unit.
|
|
<P>
|
|
|
|
By default, the <SAMP>`info vector'</SAMP> command will print all vector
|
|
registers (the register's type having the vector attribute).
|
|
</P><P>
|
|
|
|
<DT><CODE>DWARF_REG_TO_REGNUM</CODE>
|
|
<DD><A NAME="IDX341"></A>
|
|
Convert DWARF register number into GDB regnum. If not defined,
|
|
no conversion will be performed.
|
|
<P>
|
|
|
|
<DT><CODE>DWARF2_REG_TO_REGNUM</CODE>
|
|
<DD><A NAME="IDX342"></A>
|
|
Convert DWARF2 register number into GDB regnum. If not
|
|
defined, no conversion will be performed.
|
|
<P>
|
|
|
|
<DT><CODE>ECOFF_REG_TO_REGNUM</CODE>
|
|
<DD><A NAME="IDX343"></A>
|
|
Convert ECOFF register number into GDB regnum. If not defined,
|
|
no conversion will be performed.
|
|
<P>
|
|
|
|
<DT><CODE>END_OF_TEXT_DEFAULT</CODE>
|
|
<DD><A NAME="IDX344"></A>
|
|
This is an expression that should designate the end of the text section.
|
|
<P>
|
|
|
|
<DT><CODE>EXTRACT_RETURN_VALUE(<VAR>type</VAR>, <VAR>regbuf</VAR>, <VAR>valbuf</VAR>)</CODE>
|
|
<DD><A NAME="IDX345"></A>
|
|
Define this to extract a function's return value of type <VAR>type</VAR> from
|
|
the raw register state <VAR>regbuf</VAR> and copy that, in virtual format,
|
|
into <VAR>valbuf</VAR>.
|
|
|
|
<DT><CODE>EXTRACT_STRUCT_VALUE_ADDRESS(<VAR>regbuf</VAR>)</CODE>
|
|
<DD><A NAME="IDX346"></A>
|
|
When defined, extract from the array <VAR>regbuf</VAR> (containing the raw
|
|
register state) the <CODE>CORE_ADDR</CODE> at which a function should return
|
|
its structure value.
|
|
<P>
|
|
|
|
If not defined, <CODE>EXTRACT_RETURN_VALUE</CODE> is used.
|
|
</P><P>
|
|
|
|
<DT><CODE>EXTRACT_STRUCT_VALUE_ADDRESS_P()</CODE>
|
|
<DD><A NAME="IDX347"></A>
|
|
Predicate for <CODE>EXTRACT_STRUCT_VALUE_ADDRESS</CODE>.
|
|
<P>
|
|
|
|
<DT><CODE>FLOAT_INFO</CODE>
|
|
<DD><A NAME="IDX348"></A>
|
|
Deprecated in favor of <CODE>PRINT_FLOAT_INFO</CODE>.
|
|
<P>
|
|
|
|
<DT><CODE>FP_REGNUM</CODE>
|
|
<DD><A NAME="IDX349"></A>
|
|
If the virtual frame pointer is kept in a register, then define this
|
|
macro to be the number (greater than or equal to zero) of that register.
|
|
<P>
|
|
|
|
This should only need to be defined if <CODE>TARGET_READ_FP</CODE> is not
|
|
defined.
|
|
</P><P>
|
|
|
|
<DT><CODE>FRAMELESS_FUNCTION_INVOCATION(<VAR>fi</VAR>)</CODE>
|
|
<DD><A NAME="IDX350"></A>
|
|
Define this to an expression that returns 1 if the function invocation
|
|
represented by <VAR>fi</VAR> does not have a stack frame associated with it.
|
|
Otherwise return 0.
|
|
<P>
|
|
|
|
<DT><CODE>frame_align (<VAR>address</VAR>)</CODE>
|
|
<DD><A NAME="frame_align"></A>
|
|
<A NAME="IDX351"></A>
|
|
Define this to adjust <VAR>address</VAR> so that it meets the alignment
|
|
requirements for the start of a new stack frame. A stack frame's
|
|
alignment requirements are typically stronger than a target processors
|
|
stack alignment requirements (see <A HREF="gdbint_9.html#STACK_ALIGN">STACK_ALIGN</A>).
|
|
<P>
|
|
|
|
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.
|
|
</P><P>
|
|
|
|
Unlike <CODE>STACK_ALIGN</CODE>, this function always adjusts the address in
|
|
the direction of stack growth.
|
|
</P><P>
|
|
|
|
By default, no frame based stack alignment is performed.
|
|
</P><P>
|
|
|
|
<DT><CODE>FRAME_ARGS_ADDRESS_CORRECT</CODE>
|
|
<DD><A NAME="IDX352"></A>
|
|
See <TT>`stack.c'</TT>.
|
|
<P>
|
|
|
|
<DT><CODE>FRAME_CHAIN(<VAR>frame</VAR>)</CODE>
|
|
<DD><A NAME="IDX353"></A>
|
|
Given <VAR>frame</VAR>, return a pointer to the calling frame.
|
|
<P>
|
|
|
|
<DT><CODE>FRAME_CHAIN_VALID(<VAR>chain</VAR>, <VAR>thisframe</VAR>)</CODE>
|
|
<DD><A NAME="IDX354"></A>
|
|
Define this to be an expression that returns zero if the given frame is
|
|
an outermost frame, with no caller, and nonzero otherwise. Several
|
|
common definitions are available:
|
|
<P>
|
|
|
|
<UL>
|
|
<LI>
|
|
<CODE>file_frame_chain_valid</CODE> is nonzero if the chain pointer is nonzero
|
|
and given frame's PC is not inside the startup file (such as
|
|
<TT>`crt0.o'</TT>).
|
|
<P>
|
|
|
|
<LI>
|
|
<CODE>func_frame_chain_valid</CODE> is nonzero if the chain
|
|
pointer is nonzero and the given frame's PC is not in <CODE>main</CODE> or a
|
|
known entry point function (such as <CODE>_start</CODE>).
|
|
<P>
|
|
|
|
<LI>
|
|
<CODE>generic_file_frame_chain_valid</CODE> and
|
|
<CODE>generic_func_frame_chain_valid</CODE> are equivalent implementations for
|
|
targets using generic dummy frames.
|
|
</UL>
|
|
<P>
|
|
|
|
<DT><CODE>FRAME_INIT_SAVED_REGS(<VAR>frame</VAR>)</CODE>
|
|
<DD><A NAME="IDX355"></A>
|
|
See <TT>`frame.h'</TT>. Determines the address of all registers in the
|
|
current stack frame storing each in <CODE>frame->saved_regs</CODE>. Space for
|
|
<CODE>frame->saved_regs</CODE> shall be allocated by
|
|
<CODE>FRAME_INIT_SAVED_REGS</CODE> using either
|
|
<CODE>frame_saved_regs_zalloc</CODE> or <CODE>frame_obstack_alloc</CODE>.
|
|
<P>
|
|
|
|
<CODE>FRAME_FIND_SAVED_REGS</CODE> and <CODE>EXTRA_FRAME_INFO</CODE> are deprecated.
|
|
</P><P>
|
|
|
|
<DT><CODE>FRAME_NUM_ARGS (<VAR>fi</VAR>)</CODE>
|
|
<DD><A NAME="IDX356"></A>
|
|
For the frame described by <VAR>fi</VAR> return the number of arguments that
|
|
are being passed. If the number of arguments is not known, return
|
|
<CODE>-1</CODE>.
|
|
<P>
|
|
|
|
<DT><CODE>FRAME_SAVED_PC(<VAR>frame</VAR>)</CODE>
|
|
<DD><A NAME="IDX357"></A>
|
|
Given <VAR>frame</VAR>, return the pc saved there. This is the return
|
|
address.
|
|
<P>
|
|
|
|
<DT><CODE>FUNCTION_EPILOGUE_SIZE</CODE>
|
|
<DD><A NAME="IDX358"></A>
|
|
For some COFF targets, the <CODE>x_sym.x_misc.x_fsize</CODE> field of the
|
|
function end symbol is 0. For such targets, you must define
|
|
<CODE>FUNCTION_EPILOGUE_SIZE</CODE> to expand into the standard size of a
|
|
function's epilogue.
|
|
<P>
|
|
|
|
<DT><CODE>FUNCTION_START_OFFSET</CODE>
|
|
<DD><A NAME="IDX359"></A>
|
|
An integer, giving the offset in bytes from a function's address (as
|
|
used in the values of symbols, function pointers, etc.), and the
|
|
function's first genuine instruction.
|
|
<P>
|
|
|
|
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 <CODE>call</CODE>
|
|
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, <CODE>FUNCTION_START_OFFSET</CODE> would
|
|
be 2 on the VAX.
|
|
</P><P>
|
|
|
|
<DT><CODE>GCC_COMPILED_FLAG_SYMBOL</CODE>
|
|
<DD><DT><CODE>GCC2_COMPILED_FLAG_SYMBOL</CODE>
|
|
<DD><A NAME="IDX360"></A>
|
|
<A NAME="IDX361"></A>
|
|
If defined, these are the names of the symbols that GDB will
|
|
look for to detect that GCC compiled the file. The default symbols
|
|
are <CODE>gcc_compiled.</CODE> and <CODE>gcc2_compiled.</CODE>,
|
|
respectively. (Currently only defined for the Delta 68.)
|
|
<P>
|
|
|
|
<DT><CODE>GDB_MULTI_ARCH</CODE>
|
|
<DD><A NAME="IDX362"></A>
|
|
If defined and non-zero, enables support for multiple architectures
|
|
within GDB.
|
|
<P>
|
|
|
|
This support can be enabled at two levels. At level one, only
|
|
definitions for previously undefined macros are provided; at level two,
|
|
a multi-arch definition of all architecture dependent macros will be
|
|
defined.
|
|
</P><P>
|
|
|
|
<DT><CODE>GDB_TARGET_IS_HPPA</CODE>
|
|
<DD><A NAME="IDX363"></A>
|
|
This determines whether horrible kludge code in <TT>`dbxread.c'</TT> and
|
|
<TT>`partial-stab.h'</TT> is used to mangle multiple-symbol-table files from
|
|
HPPA's. This should all be ripped out, and a scheme like <TT>`elfread.c'</TT>
|
|
used instead.
|
|
<P>
|
|
|
|
<DT><CODE>GET_LONGJMP_TARGET</CODE>
|
|
<DD><A NAME="IDX364"></A>
|
|
For most machines, this is a target-dependent parameter. On the
|
|
DECstation and the Iris, this is a native-dependent parameter, since
|
|
the header file <TT>`setjmp.h'</TT> is needed to define it.
|
|
<P>
|
|
|
|
This macro determines the target PC address that <CODE>longjmp</CODE> will jump to,
|
|
assuming that we have just stopped at a <CODE>longjmp</CODE> breakpoint. It takes a
|
|
<CODE>CORE_ADDR *</CODE> as argument, and stores the target PC value through this
|
|
pointer. It examines the current state of the machine as needed.
|
|
</P><P>
|
|
|
|
<DT><CODE>GET_SAVED_REGISTER</CODE>
|
|
<DD><A NAME="IDX365"></A>
|
|
<A NAME="IDX366"></A>
|
|
Define this if you need to supply your own definition for the function
|
|
<CODE>get_saved_register</CODE>.
|
|
<P>
|
|
|
|
<DT><CODE>IBM6000_TARGET</CODE>
|
|
<DD><A NAME="IDX367"></A>
|
|
Shows that we are configured for an IBM RS/6000 target. This
|
|
conditional should be eliminated (FIXME) and replaced by
|
|
feature-specific macros. It was introduced in a haste and we are
|
|
repenting at leisure.
|
|
<P>
|
|
|
|
<DT><CODE>I386_USE_GENERIC_WATCHPOINTS</CODE>
|
|
<DD>An x86-based target can define this to use the generic x86 watchpoint
|
|
support; see <A HREF="gdbint_3.html#SEC6">I386_USE_GENERIC_WATCHPOINTS</A>.
|
|
<P>
|
|
|
|
<DT><CODE>SYMBOLS_CAN_START_WITH_DOLLAR</CODE>
|
|
<DD><A NAME="IDX368"></A>
|
|
Some systems have routines whose names start with <SAMP>`$'</SAMP>. Giving this
|
|
macro a non-zero value tells GDB's expression parser to check for such
|
|
routines when parsing tokens that begin with <SAMP>`$'</SAMP>.
|
|
<P>
|
|
|
|
On HP-UX, certain system routines (millicode) have names beginning with
|
|
<SAMP>`$'</SAMP> or <SAMP>`$$'</SAMP>. For example, <CODE>$$dyncall</CODE> is a millicode
|
|
routine that handles inter-space procedure calls on PA-RISC.
|
|
</P><P>
|
|
|
|
<DT><CODE>INIT_EXTRA_FRAME_INFO (<VAR>fromleaf</VAR>, <VAR>frame</VAR>)</CODE>
|
|
<DD><A NAME="IDX369"></A>
|
|
If additional information about the frame is required this should be
|
|
stored in <CODE>frame->extra_info</CODE>. Space for <CODE>frame->extra_info</CODE>
|
|
is allocated using <CODE>frame_obstack_alloc</CODE>.
|
|
<P>
|
|
|
|
<DT><CODE>INIT_FRAME_PC (<VAR>fromleaf</VAR>, <VAR>prev</VAR>)</CODE>
|
|
<DD><A NAME="IDX370"></A>
|
|
This is a C statement that sets the pc of the frame pointed to by
|
|
<VAR>prev</VAR>. [By default...]
|
|
<P>
|
|
|
|
<DT><CODE>INNER_THAN (<VAR>lhs</VAR>, <VAR>rhs</VAR>)</CODE>
|
|
<DD><A NAME="IDX371"></A>
|
|
Returns non-zero if stack address <VAR>lhs</VAR> is inner than (nearer to the
|
|
stack top) stack address <VAR>rhs</VAR>. Define this as <CODE>lhs < rhs</CODE> if
|
|
the target's stack grows downward in memory, or <CODE>lhs > rsh</CODE> if the
|
|
stack grows upward.
|
|
<P>
|
|
|
|
<DT><CODE>gdbarch_in_function_epilogue_p (<VAR>gdbarch</VAR>, <VAR>pc</VAR>)</CODE>
|
|
<DD><A NAME="IDX372"></A>
|
|
Returns non-zero if the given <VAR>pc</VAR> is in the epilogue of a function.
|
|
The epilogue of a function is defined as the part of a function where
|
|
the stack frame of the function already has been destroyed up to the
|
|
final `return from function call' instruction.
|
|
<P>
|
|
|
|
<DT><CODE>SIGTRAMP_START (<VAR>pc</VAR>)</CODE>
|
|
<DD><A NAME="IDX373"></A>
|
|
<DT><CODE>SIGTRAMP_END (<VAR>pc</VAR>)</CODE>
|
|
<DD><A NAME="IDX374"></A>
|
|
Define these to be the start and end address of the <CODE>sigtramp</CODE> for the
|
|
given <VAR>pc</VAR>. On machines where the address is just a compile time
|
|
constant, the macro expansion will typically just ignore the supplied
|
|
<VAR>pc</VAR>.
|
|
<P>
|
|
|
|
<DT><CODE>IN_SOLIB_CALL_TRAMPOLINE (<VAR>pc</VAR>, <VAR>name</VAR>)</CODE>
|
|
<DD><A NAME="IDX375"></A>
|
|
Define this to evaluate to nonzero if the program is stopped in the
|
|
trampoline that connects to a shared library.
|
|
<P>
|
|
|
|
<DT><CODE>IN_SOLIB_RETURN_TRAMPOLINE (<VAR>pc</VAR>, <VAR>name</VAR>)</CODE>
|
|
<DD><A NAME="IDX376"></A>
|
|
Define this to evaluate to nonzero if the program is stopped in the
|
|
trampoline that returns from a shared library.
|
|
<P>
|
|
|
|
<DT><CODE>IN_SOLIB_DYNSYM_RESOLVE_CODE (<VAR>pc</VAR>)</CODE>
|
|
<DD><A NAME="IDX377"></A>
|
|
Define this to evaluate to nonzero if the program is stopped in the
|
|
dynamic linker.
|
|
<P>
|
|
|
|
<DT><CODE>SKIP_SOLIB_RESOLVER (<VAR>pc</VAR>)</CODE>
|
|
<DD><A NAME="IDX378"></A>
|
|
Define this to evaluate to the (nonzero) address at which execution
|
|
should continue to get past the dynamic linker's symbol resolution
|
|
function. A zero value indicates that it is not important or necessary
|
|
to set a breakpoint to get through the dynamic linker and that single
|
|
stepping will suffice.
|
|
<P>
|
|
|
|
<DT><CODE>INTEGER_TO_ADDRESS (<VAR>type</VAR>, <VAR>buf</VAR>)</CODE>
|
|
<DD><A NAME="IDX379"></A>
|
|
<A NAME="IDX380"></A>
|
|
Define this when the architecture needs to handle non-pointer to address
|
|
conversions specially. Converts that value to an address according to
|
|
the current architectures conventions.
|
|
<P>
|
|
|
|
<EM>Pragmatics: When the user copies a well defined expression from
|
|
their source code and passes it, as a parameter, to GDB's
|
|
<CODE>print</CODE> 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 <CODE>x/i</CODE>. Adding an architecture
|
|
method like <CODE>INTEGER_TO_ADDRESS</CODE> certainly makes it possible for
|
|
GDB to "get it right" in all circumstances.</EM>
|
|
</P><P>
|
|
|
|
See section <A HREF="gdbint_9.html#SEC67">Pointers Are Not Always Addresses</A>.
|
|
</P><P>
|
|
|
|
<DT><CODE>IS_TRAPPED_INTERNALVAR (<VAR>name</VAR>)</CODE>
|
|
<DD><A NAME="IDX381"></A>
|
|
This is an ugly hook to allow the specification of special actions that
|
|
should occur as a side-effect of setting the value of a variable
|
|
internal to GDB. Currently only used by the h8500. Note that this
|
|
could be either a host or target conditional.
|
|
<P>
|
|
|
|
<DT><CODE>NEED_TEXT_START_END</CODE>
|
|
<DD><A NAME="IDX382"></A>
|
|
Define this if GDB should determine the start and end addresses of the
|
|
text section. (Seems dubious.)
|
|
<P>
|
|
|
|
<DT><CODE>NO_HIF_SUPPORT</CODE>
|
|
<DD><A NAME="IDX383"></A>
|
|
(Specific to the a29k.)
|
|
<P>
|
|
|
|
<DT><CODE>POINTER_TO_ADDRESS (<VAR>type</VAR>, <VAR>buf</VAR>)</CODE>
|
|
<DD><A NAME="IDX384"></A>
|
|
Assume that <VAR>buf</VAR> holds a pointer of type <VAR>type</VAR>, in the
|
|
appropriate format for the current architecture. Return the byte
|
|
address the pointer refers to.
|
|
See section <A HREF="gdbint_9.html#SEC67">Pointers Are Not Always Addresses</A>.
|
|
<P>
|
|
|
|
<DT><CODE>REGISTER_CONVERTIBLE (<VAR>reg</VAR>)</CODE>
|
|
<DD><A NAME="IDX385"></A>
|
|
Return non-zero if <VAR>reg</VAR> uses different raw and virtual formats.
|
|
See section <A HREF="gdbint_9.html#SEC67">Raw and Virtual Register Representations</A>.
|
|
<P>
|
|
|
|
<DT><CODE>REGISTER_TO_VALUE(<VAR>regnum</VAR>, <VAR>type</VAR>, <VAR>from</VAR>, <VAR>to</VAR>)</CODE>
|
|
<DD><A NAME="IDX386"></A>
|
|
Convert the raw contents of register <VAR>regnum</VAR> into a value of type
|
|
<VAR>type</VAR>.
|
|
See section <A HREF="gdbint_9.html#SEC67">Using Different Register and Memory Data Representations</A>.
|
|
<P>
|
|
|
|
<DT><CODE>REGISTER_RAW_SIZE (<VAR>reg</VAR>)</CODE>
|
|
<DD><A NAME="IDX387"></A>
|
|
Return the raw size of <VAR>reg</VAR>; defaults to the size of the register's
|
|
virtual type.
|
|
See section <A HREF="gdbint_9.html#SEC67">Raw and Virtual Register Representations</A>.
|
|
<P>
|
|
|
|
<DT><CODE>REGISTER_VIRTUAL_SIZE (<VAR>reg</VAR>)</CODE>
|
|
<DD><A NAME="IDX388"></A>
|
|
Return the virtual size of <VAR>reg</VAR>; defaults to the size of the
|
|
register's virtual type.
|
|
Return the virtual size of <VAR>reg</VAR>.
|
|
See section <A HREF="gdbint_9.html#SEC67">Raw and Virtual Register Representations</A>.
|
|
<P>
|
|
|
|
<DT><CODE>REGISTER_VIRTUAL_TYPE (<VAR>reg</VAR>)</CODE>
|
|
<DD><A NAME="IDX389"></A>
|
|
Return the virtual type of <VAR>reg</VAR>.
|
|
See section <A HREF="gdbint_9.html#SEC67">Raw and Virtual Register Representations</A>.
|
|
<P>
|
|
|
|
<DT><CODE>REGISTER_CONVERT_TO_VIRTUAL(<VAR>reg</VAR>, <VAR>type</VAR>, <VAR>from</VAR>, <VAR>to</VAR>)</CODE>
|
|
<DD><A NAME="IDX390"></A>
|
|
Convert the value of register <VAR>reg</VAR> from its raw form to its virtual
|
|
form.
|
|
See section <A HREF="gdbint_9.html#SEC67">Raw and Virtual Register Representations</A>.
|
|
<P>
|
|
|
|
<DT><CODE>REGISTER_CONVERT_TO_RAW(<VAR>type</VAR>, <VAR>reg</VAR>, <VAR>from</VAR>, <VAR>to</VAR>)</CODE>
|
|
<DD><A NAME="IDX391"></A>
|
|
Convert the value of register <VAR>reg</VAR> from its virtual form to its raw
|
|
form.
|
|
See section <A HREF="gdbint_9.html#SEC67">Raw and Virtual Register Representations</A>.
|
|
<P>
|
|
|
|
<DT><CODE>RETURN_VALUE_ON_STACK(<VAR>type</VAR>)</CODE>
|
|
<DD><A NAME="IDX392"></A>
|
|
<A NAME="IDX393"></A>
|
|
<A NAME="IDX394"></A>
|
|
<P>
|
|
|
|
Return non-zero if values of type TYPE are returned on the stack, using
|
|
the "struct convention" (i.e., the caller provides a pointer to a
|
|
buffer in which the callee should store the return value). This
|
|
controls how the <SAMP>`finish'</SAMP> command finds a function's return value,
|
|
and whether an inferior function call reserves space on the stack for
|
|
the return value.
|
|
</P><P>
|
|
|
|
The full logic GDB uses here is kind of odd.
|
|
</P><P>
|
|
|
|
<UL>
|
|
<LI>
|
|
If the type being returned by value is not a structure, union, or array,
|
|
and <CODE>RETURN_VALUE_ON_STACK</CODE> returns zero, then GDB
|
|
concludes the value is not returned using the struct convention.
|
|
<P>
|
|
|
|
<LI>
|
|
Otherwise, GDB calls <CODE>USE_STRUCT_CONVENTION</CODE> (see below).
|
|
If that returns non-zero, GDB assumes the struct convention is
|
|
in use.
|
|
</UL>
|
|
<P>
|
|
|
|
In other words, to indicate that a given type is returned by value using
|
|
the struct convention, that type must be either a struct, union, array,
|
|
or something <CODE>RETURN_VALUE_ON_STACK</CODE> likes, <EM>and</EM> something
|
|
that <CODE>USE_STRUCT_CONVENTION</CODE> likes.
|
|
</P><P>
|
|
|
|
Note that, in C and C<TT>++</TT>, arrays are never returned by value. In those
|
|
languages, these predicates will always see a pointer type, never an
|
|
array type. All the references above to arrays being returned by value
|
|
apply only to other languages.
|
|
</P><P>
|
|
|
|
<DT><CODE>SOFTWARE_SINGLE_STEP_P()</CODE>
|
|
<DD><A NAME="IDX395"></A>
|
|
Define this as 1 if the target does not have a hardware single-step
|
|
mechanism. The macro <CODE>SOFTWARE_SINGLE_STEP</CODE> must also be defined.
|
|
<P>
|
|
|
|
<DT><CODE>SOFTWARE_SINGLE_STEP(<VAR>signal</VAR>, <VAR>insert_breapoints_p</VAR>)</CODE>
|
|
<DD><A NAME="IDX396"></A>
|
|
A function that inserts or removes (depending on
|
|
<VAR>insert_breapoints_p</VAR>) breakpoints at each possible destinations of
|
|
the next instruction. See <TT>`sparc-tdep.c'</TT> and <TT>`rs6000-tdep.c'</TT>
|
|
for examples.
|
|
<P>
|
|
|
|
<DT><CODE>SOFUN_ADDRESS_MAYBE_MISSING</CODE>
|
|
<DD><A NAME="IDX397"></A>
|
|
Somebody clever observed that, the more actual addresses you have in the
|
|
debug information, the more time the linker has to spend relocating
|
|
them. So whenever there's some other way the debugger could find the
|
|
address it needs, you should omit it from the debug info, to make
|
|
linking faster.
|
|
<P>
|
|
|
|
<CODE>SOFUN_ADDRESS_MAYBE_MISSING</CODE> indicates that a particular set of
|
|
hacks of this sort are in use, affecting <CODE>N_SO</CODE> and <CODE>N_FUN</CODE>
|
|
entries in stabs-format debugging information. <CODE>N_SO</CODE> stabs mark
|
|
the beginning and ending addresses of compilation units in the text
|
|
segment. <CODE>N_FUN</CODE> stabs mark the starts and ends of functions.
|
|
</P><P>
|
|
|
|
<CODE>SOFUN_ADDRESS_MAYBE_MISSING</CODE> means two things:
|
|
</P><P>
|
|
|
|
<UL>
|
|
<LI>
|
|
<CODE>N_FUN</CODE> stabs have an address of zero. Instead, you should find the
|
|
addresses where the function starts by taking the function name from
|
|
the stab, and then looking that up in the minsyms (the
|
|
linker/assembler symbol table). In other words, the stab has the
|
|
name, and the linker/assembler symbol table is the only place that carries
|
|
the address.
|
|
<P>
|
|
|
|
<LI>
|
|
<CODE>N_SO</CODE> stabs have an address of zero, too. You just look at the
|
|
<CODE>N_FUN</CODE> stabs that appear before and after the <CODE>N_SO</CODE> stab,
|
|
and guess the starting and ending addresses of the compilation unit from
|
|
them.
|
|
</UL>
|
|
<P>
|
|
|
|
<DT><CODE>PCC_SOL_BROKEN</CODE>
|
|
<DD><A NAME="IDX398"></A>
|
|
(Used only in the Convex target.)
|
|
<P>
|
|
|
|
<DT><CODE>PC_IN_CALL_DUMMY</CODE>
|
|
<DD><A NAME="IDX399"></A>
|
|
See <TT>`inferior.h'</TT>.
|
|
<P>
|
|
|
|
<DT><CODE>PC_IN_SIGTRAMP (<VAR>pc</VAR>, <VAR>name</VAR>)</CODE>
|
|
<DD><A NAME="IDX400"></A>
|
|
<A NAME="IDX401"></A>
|
|
The <EM>sigtramp</EM> is a routine that the kernel calls (which then calls
|
|
the signal handler). On most machines it is a library routine that is
|
|
linked into the executable.
|
|
<P>
|
|
|
|
This function, given a program counter value in <VAR>pc</VAR> and the
|
|
(possibly NULL) name of the function in which that <VAR>pc</VAR> resides,
|
|
returns nonzero if the <VAR>pc</VAR> and/or <VAR>name</VAR> show that we are in
|
|
sigtramp.
|
|
</P><P>
|
|
|
|
<DT><CODE>PC_LOAD_SEGMENT</CODE>
|
|
<DD><A NAME="IDX402"></A>
|
|
If defined, print information about the load segment for the program
|
|
counter. (Defined only for the RS/6000.)
|
|
<P>
|
|
|
|
<DT><CODE>PC_REGNUM</CODE>
|
|
<DD><A NAME="IDX403"></A>
|
|
If the program counter is kept in a register, then define this macro to
|
|
be the number (greater than or equal to zero) of that register.
|
|
<P>
|
|
|
|
This should only need to be defined if <CODE>TARGET_READ_PC</CODE> and
|
|
<CODE>TARGET_WRITE_PC</CODE> are not defined.
|
|
</P><P>
|
|
|
|
<DT><CODE>NPC_REGNUM</CODE>
|
|
<DD><A NAME="IDX404"></A>
|
|
The number of the "next program counter" register, if defined.
|
|
<P>
|
|
|
|
<DT><CODE>PARM_BOUNDARY</CODE>
|
|
<DD><A NAME="IDX405"></A>
|
|
If non-zero, round arguments to a boundary of this many bits before
|
|
pushing them on the stack.
|
|
<P>
|
|
|
|
<DT><CODE>PRINT_REGISTER_HOOK (<VAR>regno</VAR>)</CODE>
|
|
<DD><A NAME="IDX406"></A>
|
|
If defined, this must be a function that prints the contents of the
|
|
given register to standard output.
|
|
<P>
|
|
|
|
<DT><CODE>PRINT_TYPELESS_INTEGER</CODE>
|
|
<DD><A NAME="IDX407"></A>
|
|
This is an obscure substitute for <CODE>print_longest</CODE> that seems to
|
|
have been defined for the Convex target.
|
|
<P>
|
|
|
|
<DT><CODE>PROCESS_LINENUMBER_HOOK</CODE>
|
|
<DD><A NAME="IDX408"></A>
|
|
A hook defined for XCOFF reading.
|
|
<P>
|
|
|
|
<DT><CODE>PROLOGUE_FIRSTLINE_OVERLAP</CODE>
|
|
<DD><A NAME="IDX409"></A>
|
|
(Only used in unsupported Convex configuration.)
|
|
<P>
|
|
|
|
<DT><CODE>PS_REGNUM</CODE>
|
|
<DD><A NAME="IDX410"></A>
|
|
If defined, this is the number of the processor status register. (This
|
|
definition is only used in generic code when parsing "$ps".)
|
|
<P>
|
|
|
|
<DT><CODE>POP_FRAME</CODE>
|
|
<DD><A NAME="IDX411"></A>
|
|
<A NAME="IDX412"></A>
|
|
<A NAME="IDX413"></A>
|
|
Used in <SAMP>`call_function_by_hand'</SAMP> to remove an artificial stack
|
|
frame and in <SAMP>`return_command'</SAMP> to remove a real stack frame.
|
|
<P>
|
|
|
|
<DT><CODE>PUSH_ARGUMENTS (<VAR>nargs</VAR>, <VAR>args</VAR>, <VAR>sp</VAR>, <VAR>struct_return</VAR>, <VAR>struct_addr</VAR>)</CODE>
|
|
<DD><A NAME="IDX414"></A>
|
|
Define this to push arguments onto the stack for inferior function
|
|
call. Returns the updated stack pointer value.
|
|
<P>
|
|
|
|
<DT><CODE>PUSH_DUMMY_FRAME</CODE>
|
|
<DD><A NAME="IDX415"></A>
|
|
Used in <SAMP>`call_function_by_hand'</SAMP> to create an artificial stack frame.
|
|
<P>
|
|
|
|
<DT><CODE>REGISTER_BYTES</CODE>
|
|
<DD><A NAME="IDX416"></A>
|
|
The total amount of space needed to store GDB's copy of the machine's
|
|
register state.
|
|
<P>
|
|
|
|
<DT><CODE>REGISTER_NAME(<VAR>i</VAR>)</CODE>
|
|
<DD><A NAME="IDX417"></A>
|
|
Return the name of register <VAR>i</VAR> as a string. May return <CODE>NULL</CODE>
|
|
or <CODE>NUL</CODE> to indicate that register <VAR>i</VAR> is not valid.
|
|
<P>
|
|
|
|
<DT><CODE>REGISTER_NAMES</CODE>
|
|
<DD><A NAME="IDX418"></A>
|
|
Deprecated in favor of <CODE>REGISTER_NAME</CODE>.
|
|
<P>
|
|
|
|
<DT><CODE>REG_STRUCT_HAS_ADDR (<VAR>gcc_p</VAR>, <VAR>type</VAR>)</CODE>
|
|
<DD><A NAME="IDX419"></A>
|
|
Define this to return 1 if the given type will be passed by pointer
|
|
rather than directly.
|
|
<P>
|
|
|
|
<DT><CODE>SAVE_DUMMY_FRAME_TOS (<VAR>sp</VAR>)</CODE>
|
|
<DD><A NAME="IDX420"></A>
|
|
Used in <SAMP>`call_function_by_hand'</SAMP> to notify the target dependent code
|
|
of the top-of-stack value that will be passed to the the inferior code.
|
|
This is the value of the <CODE>SP</CODE> after both the dummy frame and space
|
|
for parameters/results have been allocated on the stack.
|
|
<P>
|
|
|
|
<DT><CODE>SDB_REG_TO_REGNUM</CODE>
|
|
<DD><A NAME="IDX421"></A>
|
|
Define this to convert sdb register numbers into GDB regnums. If not
|
|
defined, no conversion will be done.
|
|
<P>
|
|
|
|
<DT><CODE>SKIP_PERMANENT_BREAKPOINT</CODE>
|
|
<DD><A NAME="IDX422"></A>
|
|
Advance the inferior's PC past a permanent breakpoint. GDB normally
|
|
steps over a breakpoint by removing it, stepping one instruction, and
|
|
re-inserting the breakpoint. However, permanent breakpoints are
|
|
hardwired into the inferior, and can't be removed, so this strategy
|
|
doesn't work. Calling <CODE>SKIP_PERMANENT_BREAKPOINT</CODE> adjusts the processor's
|
|
state so that execution will resume just after the breakpoint. This
|
|
macro does the right thing even when the breakpoint is in the delay slot
|
|
of a branch or jump.
|
|
<P>
|
|
|
|
<DT><CODE>SKIP_PROLOGUE (<VAR>pc</VAR>)</CODE>
|
|
<DD><A NAME="IDX423"></A>
|
|
A C expression that returns the address of the "real" code beyond the
|
|
function entry prologue found at <VAR>pc</VAR>.
|
|
<P>
|
|
|
|
<DT><CODE>SKIP_TRAMPOLINE_CODE (<VAR>pc</VAR>)</CODE>
|
|
<DD><A NAME="IDX424"></A>
|
|
If the target machine has trampoline code that sits between callers and
|
|
the functions being called, then define this macro to return a new PC
|
|
that is at the start of the real function.
|
|
<P>
|
|
|
|
<DT><CODE>SP_REGNUM</CODE>
|
|
<DD><A NAME="IDX425"></A>
|
|
If the stack-pointer is kept in a register, then define this macro to be
|
|
the number (greater than or equal to zero) of that register.
|
|
<P>
|
|
|
|
This should only need to be defined if <CODE>TARGET_WRITE_SP</CODE> and
|
|
<CODE>TARGET_WRITE_SP</CODE> are not defined.
|
|
</P><P>
|
|
|
|
<DT><CODE>STAB_REG_TO_REGNUM</CODE>
|
|
<DD><A NAME="IDX426"></A>
|
|
Define this to convert stab register numbers (as gotten from `r'
|
|
declarations) into GDB regnums. If not defined, no conversion will be
|
|
done.
|
|
<P>
|
|
|
|
<DT><CODE>STACK_ALIGN (<VAR>addr</VAR>)</CODE>
|
|
<DD><A NAME="STACK_ALIGN"></A>
|
|
<A NAME="IDX427"></A>
|
|
Define this to increase <VAR>addr</VAR> so that it meets the alignment
|
|
requirements for the processor's stack.
|
|
<P>
|
|
|
|
Unlike <A HREF="gdbint_9.html#frame_align">frame_align</A>, this function always adjusts <VAR>addr</VAR>
|
|
upwards.
|
|
</P><P>
|
|
|
|
By default, no stack alignment is performed.
|
|
</P><P>
|
|
|
|
<DT><CODE>STEP_SKIPS_DELAY (<VAR>addr</VAR>)</CODE>
|
|
<DD><A NAME="IDX428"></A>
|
|
Define this to return true if the address is of an instruction with a
|
|
delay slot. If a breakpoint has been placed in the instruction's delay
|
|
slot, GDB will single-step over that instruction before resuming
|
|
normally. Currently only defined for the Mips.
|
|
<P>
|
|
|
|
<DT><CODE>STORE_RETURN_VALUE (<VAR>type</VAR>, <VAR>regcache</VAR>, <VAR>valbuf</VAR>)</CODE>
|
|
<DD><A NAME="IDX429"></A>
|
|
A C expression that writes the function return value, found in
|
|
<VAR>valbuf</VAR>, into the <VAR>regcache</VAR>. <VAR>type</VAR> is the type of the
|
|
value that is to be returned.
|
|
<P>
|
|
|
|
<DT><CODE>SUN_FIXED_LBRAC_BUG</CODE>
|
|
<DD><A NAME="IDX430"></A>
|
|
(Used only for Sun-3 and Sun-4 targets.)
|
|
<P>
|
|
|
|
<DT><CODE>SYMBOL_RELOADING_DEFAULT</CODE>
|
|
<DD><A NAME="IDX431"></A>
|
|
The default value of the "symbol-reloading" variable. (Never defined in
|
|
current sources.)
|
|
<P>
|
|
|
|
<DT><CODE>TARGET_CHAR_BIT</CODE>
|
|
<DD><A NAME="IDX432"></A>
|
|
Number of bits in a char; defaults to 8.
|
|
<P>
|
|
|
|
<DT><CODE>TARGET_CHAR_SIGNED</CODE>
|
|
<DD><A NAME="IDX433"></A>
|
|
Non-zero if <CODE>char</CODE> is normally signed on this architecture; zero if
|
|
it should be unsigned.
|
|
<P>
|
|
|
|
The ISO C standard requires the compiler to treat <CODE>char</CODE> as
|
|
equivalent to either <CODE>signed char</CODE> or <CODE>unsigned char</CODE>; any
|
|
character in the standard execution set is supposed to be positive.
|
|
Most compilers treat <CODE>char</CODE> as signed, but <CODE>char</CODE> is unsigned
|
|
on the IBM S/390, RS6000, and PowerPC targets.
|
|
</P><P>
|
|
|
|
<DT><CODE>TARGET_COMPLEX_BIT</CODE>
|
|
<DD><A NAME="IDX434"></A>
|
|
Number of bits in a complex number; defaults to <CODE>2 * TARGET_FLOAT_BIT</CODE>.
|
|
<P>
|
|
|
|
At present this macro is not used.
|
|
</P><P>
|
|
|
|
<DT><CODE>TARGET_DOUBLE_BIT</CODE>
|
|
<DD><A NAME="IDX435"></A>
|
|
Number of bits in a double float; defaults to <CODE>8 * TARGET_CHAR_BIT</CODE>.
|
|
<P>
|
|
|
|
<DT><CODE>TARGET_DOUBLE_COMPLEX_BIT</CODE>
|
|
<DD><A NAME="IDX436"></A>
|
|
Number of bits in a double complex; defaults to <CODE>2 * TARGET_DOUBLE_BIT</CODE>.
|
|
<P>
|
|
|
|
At present this macro is not used.
|
|
</P><P>
|
|
|
|
<DT><CODE>TARGET_FLOAT_BIT</CODE>
|
|
<DD><A NAME="IDX437"></A>
|
|
Number of bits in a float; defaults to <CODE>4 * TARGET_CHAR_BIT</CODE>.
|
|
<P>
|
|
|
|
<DT><CODE>TARGET_INT_BIT</CODE>
|
|
<DD><A NAME="IDX438"></A>
|
|
Number of bits in an integer; defaults to <CODE>4 * TARGET_CHAR_BIT</CODE>.
|
|
<P>
|
|
|
|
<DT><CODE>TARGET_LONG_BIT</CODE>
|
|
<DD><A NAME="IDX439"></A>
|
|
Number of bits in a long integer; defaults to <CODE>4 * TARGET_CHAR_BIT</CODE>.
|
|
<P>
|
|
|
|
<DT><CODE>TARGET_LONG_DOUBLE_BIT</CODE>
|
|
<DD><A NAME="IDX440"></A>
|
|
Number of bits in a long double float;
|
|
defaults to <CODE>2 * TARGET_DOUBLE_BIT</CODE>.
|
|
<P>
|
|
|
|
<DT><CODE>TARGET_LONG_LONG_BIT</CODE>
|
|
<DD><A NAME="IDX441"></A>
|
|
Number of bits in a long long integer; defaults to <CODE>2 * TARGET_LONG_BIT</CODE>.
|
|
<P>
|
|
|
|
<DT><CODE>TARGET_PTR_BIT</CODE>
|
|
<DD><A NAME="IDX442"></A>
|
|
Number of bits in a pointer; defaults to <CODE>TARGET_INT_BIT</CODE>.
|
|
<P>
|
|
|
|
<DT><CODE>TARGET_SHORT_BIT</CODE>
|
|
<DD><A NAME="IDX443"></A>
|
|
Number of bits in a short integer; defaults to <CODE>2 * TARGET_CHAR_BIT</CODE>.
|
|
<P>
|
|
|
|
<DT><CODE>TARGET_READ_PC</CODE>
|
|
<DD><A NAME="IDX444"></A>
|
|
<DT><CODE>TARGET_WRITE_PC (<VAR>val</VAR>, <VAR>pid</VAR>)</CODE>
|
|
<DD><A NAME="IDX445"></A>
|
|
<DT><CODE>TARGET_READ_SP</CODE>
|
|
<DD><A NAME="IDX446"></A>
|
|
<DT><CODE>TARGET_WRITE_SP</CODE>
|
|
<DD><A NAME="IDX447"></A>
|
|
<DT><CODE>TARGET_READ_FP</CODE>
|
|
<DD><A NAME="IDX448"></A>
|
|
<A NAME="IDX449"></A>
|
|
<A NAME="IDX450"></A>
|
|
<A NAME="IDX451"></A>
|
|
<A NAME="IDX452"></A>
|
|
<A NAME="IDX453"></A>
|
|
These change the behavior of <CODE>read_pc</CODE>, <CODE>write_pc</CODE>,
|
|
<CODE>read_sp</CODE>, <CODE>write_sp</CODE> and <CODE>read_fp</CODE>. For most targets,
|
|
these may be left undefined. GDB will call the read and write
|
|
register functions with the relevant <CODE>_REGNUM</CODE> argument.
|
|
<P>
|
|
|
|
These macros are useful when a target keeps one of these registers in a
|
|
hard to get at place; for example, part in a segment register and part
|
|
in an ordinary register.
|
|
</P><P>
|
|
|
|
<DT><CODE>TARGET_VIRTUAL_FRAME_POINTER(<VAR>pc</VAR>, <VAR>regp</VAR>, <VAR>offsetp</VAR>)</CODE>
|
|
<DD><A NAME="IDX454"></A>
|
|
Returns a <CODE>(register, offset)</CODE> pair representing the virtual
|
|
frame pointer in use at the code address <VAR>pc</VAR>. If virtual
|
|
frame pointers are not used, a default definition simply returns
|
|
<CODE>FP_REGNUM</CODE>, with an offset of zero.
|
|
<P>
|
|
|
|
<DT><CODE>TARGET_HAS_HARDWARE_WATCHPOINTS</CODE>
|
|
<DD>If non-zero, the target has support for hardware-assisted
|
|
watchpoints. See section <A HREF="gdbint_3.html#SEC6">watchpoints</A>, for more details and
|
|
other related macros.
|
|
<P>
|
|
|
|
<DT><CODE>TARGET_PRINT_INSN (<VAR>addr</VAR>, <VAR>info</VAR>)</CODE>
|
|
<DD><A NAME="IDX455"></A>
|
|
This is the function used by GDB to print an assembly
|
|
instruction. It prints the instruction at address <VAR>addr</VAR> in
|
|
debugged memory and returns the length of the instruction, in bytes. If
|
|
a target doesn't define its own printing routine, it defaults to an
|
|
accessor function for the global pointer <CODE>tm_print_insn</CODE>. This
|
|
usually points to a function in the <CODE>opcodes</CODE> library (see section <A HREF="gdbint_12.html#SEC102">Opcodes</A>). <VAR>info</VAR> is a structure (of type
|
|
<CODE>disassemble_info</CODE>) defined in <TT>`include/dis-asm.h'</TT> used to
|
|
pass information to the instruction decoding routine.
|
|
<P>
|
|
|
|
<DT><CODE>USE_STRUCT_CONVENTION (<VAR>gcc_p</VAR>, <VAR>type</VAR>)</CODE>
|
|
<DD><A NAME="IDX456"></A>
|
|
If defined, this must be an expression that is nonzero if a value of the
|
|
given <VAR>type</VAR> being returned from a function must have space
|
|
allocated for it on the stack. <VAR>gcc_p</VAR> is true if the function
|
|
being considered is known to have been compiled by GCC; this is helpful
|
|
for systems where GCC is known to use different calling convention than
|
|
other compilers.
|
|
<P>
|
|
|
|
<DT><CODE>VALUE_TO_REGISTER(<VAR>type</VAR>, <VAR>regnum</VAR>, <VAR>from</VAR>, <VAR>to</VAR>)</CODE>
|
|
<DD><A NAME="IDX457"></A>
|
|
Convert a value of type <VAR>type</VAR> into the raw contents of register
|
|
<VAR>regnum</VAR>'s.
|
|
See section <A HREF="gdbint_9.html#SEC67">Using Different Register and Memory Data Representations</A>.
|
|
<P>
|
|
|
|
<DT><CODE>VARIABLES_INSIDE_BLOCK (<VAR>desc</VAR>, <VAR>gcc_p</VAR>)</CODE>
|
|
<DD><A NAME="IDX458"></A>
|
|
For dbx-style debugging information, if the compiler puts variable
|
|
declarations inside LBRAC/RBRAC blocks, this should be defined to be
|
|
nonzero. <VAR>desc</VAR> is the value of <CODE>n_desc</CODE> from the
|
|
<CODE>N_RBRAC</CODE> symbol, and <VAR>gcc_p</VAR> is true if GDB has noticed the
|
|
presence of either the <CODE>GCC_COMPILED_SYMBOL</CODE> or the
|
|
<CODE>GCC2_COMPILED_SYMBOL</CODE>. By default, this is 0.
|
|
<P>
|
|
|
|
<DT><CODE>OS9K_VARIABLES_INSIDE_BLOCK (<VAR>desc</VAR>, <VAR>gcc_p</VAR>)</CODE>
|
|
<DD><A NAME="IDX459"></A>
|
|
Similarly, for OS/9000. Defaults to 1.
|
|
</DL>
|
|
<P>
|
|
|
|
Motorola M68K target conditionals.
|
|
</P><P>
|
|
|
|
<DL COMPACT>
|
|
<A NAME="IDX460"></A>
|
|
<DT><CODE>BPT_VECTOR</CODE>
|
|
<DD><A NAME="IDX461"></A>
|
|
Define this to be the 4-bit location of the breakpoint trap vector. If
|
|
not defined, it will default to <CODE>0xf</CODE>.
|
|
<P>
|
|
|
|
<A NAME="IDX462"></A>
|
|
<DT><CODE>REMOTE_BPT_VECTOR</CODE>
|
|
<DD><A NAME="IDX463"></A>
|
|
Defaults to <CODE>1</CODE>.
|
|
<P>
|
|
|
|
<A NAME="IDX464"></A>
|
|
<DT><CODE>NAME_OF_MALLOC</CODE>
|
|
<DD><A NAME="IDX465"></A>
|
|
<A NAME="IDX466"></A>
|
|
A string containing the name of the function to call in order to
|
|
allocate some memory in the inferior. The default value is "malloc".
|
|
<P>
|
|
|
|
</DL>
|
|
<P>
|
|
|
|
<HR SIZE="6">
|
|
<A NAME="SEC78"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC77"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC79"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC69"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC67"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_10.html#SEC88"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_19.html#SEC186">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 9.11 Adding a New Target </H2>
|
|
<!--docid::SEC78::-->
|
|
<P>
|
|
|
|
<A NAME="IDX467"></A>
|
|
The following files add a target to GDB:
|
|
</P><P>
|
|
|
|
<DL COMPACT>
|
|
<A NAME="IDX468"></A>
|
|
<DT><TT>`gdb/config/<VAR>arch</VAR>/<VAR>ttt</VAR>.mt'</TT>
|
|
<DD>Contains a Makefile fragment specific to this target. Specifies what
|
|
object files are needed for target <VAR>ttt</VAR>, by defining
|
|
<SAMP>`TDEPFILES=<small>...</small>'</SAMP> and <SAMP>`TDEPLIBS=<small>...</small>'</SAMP>. Also specifies
|
|
the header file which describes <VAR>ttt</VAR>, by defining <SAMP>`TM_FILE=
|
|
tm-<VAR>ttt</VAR>.h'</SAMP>.
|
|
<P>
|
|
|
|
You can also define <SAMP>`TM_CFLAGS'</SAMP>, <SAMP>`TM_CLIBS'</SAMP>, <SAMP>`TM_CDEPS'</SAMP>,
|
|
but these are now deprecated, replaced by autoconf, and may go away in
|
|
future versions of GDB.
|
|
</P><P>
|
|
|
|
<DT><TT>`gdb/<VAR>ttt</VAR>-tdep.c'</TT>
|
|
<DD>Contains any miscellaneous code required for this target machine. On
|
|
some machines it doesn't exist at all. Sometimes the macros in
|
|
<TT>`tm-<VAR>ttt</VAR>.h'</TT> become very complicated, so they are implemented
|
|
as functions here instead, and the macro is simply defined to call the
|
|
function. This is vastly preferable, since it is easier to understand
|
|
and debug.
|
|
<P>
|
|
|
|
<DT><TT>`gdb/<VAR>arch</VAR>-tdep.c'</TT>
|
|
<DD><DT><TT>`gdb/<VAR>arch</VAR>-tdep.h'</TT>
|
|
<DD>This often exists to describe the basic layout of the target machine's
|
|
processor chip (registers, stack, etc.). If used, it is included by
|
|
<TT>`<VAR>ttt</VAR>-tdep.h'</TT>. It can be shared among many targets that use
|
|
the same processor.
|
|
<P>
|
|
|
|
<DT><TT>`gdb/config/<VAR>arch</VAR>/tm-<VAR>ttt</VAR>.h'</TT>
|
|
<DD>(<TT>`tm.h'</TT> is a link to this file, created by <CODE>configure</CODE>). Contains
|
|
macro definitions about the target machine's registers, stack frame
|
|
format and instructions.
|
|
<P>
|
|
|
|
New targets do not need this file and should not create it.
|
|
</P><P>
|
|
|
|
<DT><TT>`gdb/config/<VAR>arch</VAR>/tm-<VAR>arch</VAR>.h'</TT>
|
|
<DD>This often exists to describe the basic layout of the target machine's
|
|
processor chip (registers, stack, etc.). If used, it is included by
|
|
<TT>`tm-<VAR>ttt</VAR>.h'</TT>. It can be shared among many targets that use the
|
|
same processor.
|
|
<P>
|
|
|
|
New targets do not need this file and should not create it.
|
|
</P><P>
|
|
|
|
</DL>
|
|
<P>
|
|
|
|
If you are adding a new operating system for an existing CPU chip, add a
|
|
<TT>`config/tm-<VAR>os</VAR>.h'</TT> file that describes the operating system
|
|
facilities that are unusual (extra symbol table info; the breakpoint
|
|
instruction needed; etc.). Then write a <TT>`<VAR>arch</VAR>/tm-<VAR>os</VAR>.h'</TT>
|
|
that just <CODE>#include</CODE>s <TT>`tm-<VAR>arch</VAR>.h'</TT> and
|
|
<TT>`config/tm-<VAR>os</VAR>.h'</TT>.
|
|
</P><P>
|
|
|
|
<HR SIZE="6">
|
|
<A NAME="SEC79"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC78"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC80"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC69"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC67"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_10.html#SEC88"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_19.html#SEC186">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H2> 9.12 Converting an existing Target Architecture to Multi-arch </H2>
|
|
<!--docid::SEC79::-->
|
|
<P>
|
|
|
|
This section describes the current accepted best practice for converting
|
|
an existing target architecture to the multi-arch framework.
|
|
</P><P>
|
|
|
|
The process consists of generating, testing, posting and committing a
|
|
sequence of patches. Each patch must contain a single change, for
|
|
instance:
|
|
</P><P>
|
|
|
|
<UL>
|
|
|
|
<LI>
|
|
Directly convert a group of functions into macros (the conversion does
|
|
not change the behavior of any of the functions).
|
|
<P>
|
|
|
|
<LI>
|
|
Replace a non-multi-arch with a multi-arch mechanism (e.g.,
|
|
<CODE>FRAME_INFO</CODE>).
|
|
<P>
|
|
|
|
<LI>
|
|
Enable multi-arch level one.
|
|
<P>
|
|
|
|
<LI>
|
|
Delete one or more files.
|
|
<P>
|
|
|
|
</UL>
|
|
<P>
|
|
|
|
There isn't a size limit on a patch, however, a developer is strongly
|
|
encouraged to keep the patch size down.
|
|
</P><P>
|
|
|
|
Since each patch is well defined, and since each change has been tested
|
|
and shows no regressions, the patches are considered <EM>fairly</EM>
|
|
obvious. Such patches, when submitted by developers listed in the
|
|
<TT>`MAINTAINERS'</TT> file, do not need approval. Occasional steps in the
|
|
process may be more complicated and less clear. The developer is
|
|
expected to use their judgment and is encouraged to seek advice as
|
|
needed.
|
|
</P><P>
|
|
|
|
<HR SIZE="6">
|
|
<A NAME="SEC80"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC79"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC81"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC69"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC79"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_10.html#SEC88"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_19.html#SEC186">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H3> 9.12.1 Preparation </H3>
|
|
<!--docid::SEC80::-->
|
|
<P>
|
|
|
|
The first step is to establish control. Build (with <SAMP>`-Werror'</SAMP>
|
|
enabled) and test the target so that there is a baseline against which
|
|
the debugger can be compared.
|
|
</P><P>
|
|
|
|
At no stage can the test results regress or GDB stop compiling
|
|
with <SAMP>`-Werror'</SAMP>.
|
|
</P><P>
|
|
|
|
<HR SIZE="6">
|
|
<A NAME="SEC81"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC80"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC82"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC82"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC79"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_10.html#SEC88"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_19.html#SEC186">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H3> 9.12.2 Add the multi-arch initialization code </H3>
|
|
<!--docid::SEC81::-->
|
|
<P>
|
|
|
|
The objective of this step is to establish the basic multi-arch
|
|
framework. It involves
|
|
</P><P>
|
|
|
|
<UL>
|
|
|
|
<LI>
|
|
The addition of a <CODE><VAR>arch</VAR>_gdbarch_init</CODE> function<A NAME="DOCF4" HREF="gdbint_fot.html#FOOT4">(4)</A> that creates
|
|
the architecture:
|
|
<TABLE><tr><td> </td><td class=smallexample><FONT SIZE=-1><pre>static struct gdbarch *
|
|
d10v_gdbarch_init (info, arches)
|
|
struct gdbarch_info info;
|
|
struct gdbarch_list *arches;
|
|
{
|
|
struct gdbarch *gdbarch;
|
|
/* there is only one d10v architecture */
|
|
if (arches != NULL)
|
|
return arches->gdbarch;
|
|
gdbarch = gdbarch_alloc (&info, NULL);
|
|
return gdbarch;
|
|
}
|
|
</FONT></pre></td></tr></table><EM></EM>
|
|
<P>
|
|
|
|
<LI>
|
|
A per-architecture dump function to print any architecture specific
|
|
information:
|
|
<TABLE><tr><td> </td><td class=smallexample><FONT SIZE=-1><pre>static void
|
|
mips_dump_tdep (struct gdbarch *current_gdbarch,
|
|
struct ui_file *file)
|
|
{
|
|
<small>...</small> code to print architecture specific info <small>...</small>
|
|
}
|
|
</FONT></pre></td></tr></table><P>
|
|
|
|
<LI>
|
|
A change to <CODE>_initialize_<VAR>arch</VAR>_tdep</CODE> to register this new
|
|
architecture:
|
|
<TABLE><tr><td> </td><td class=smallexample><FONT SIZE=-1><pre>void
|
|
_initialize_mips_tdep (void)
|
|
{
|
|
gdbarch_register (bfd_arch_mips, mips_gdbarch_init,
|
|
mips_dump_tdep);
|
|
</FONT></pre></td></tr></table><P>
|
|
|
|
<LI>
|
|
Add the macro <CODE>GDB_MULTI_ARCH</CODE>, defined as 0 (zero), to the file<BR>
|
|
<TT>`config/<VAR>arch</VAR>/tm-<VAR>arch</VAR>.h'</TT>.
|
|
<P>
|
|
|
|
</UL>
|
|
<P>
|
|
|
|
<HR SIZE="6">
|
|
<A NAME="SEC82"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC81"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC83"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC83"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC79"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_10.html#SEC88"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_19.html#SEC186">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H3> 9.12.3 Update multi-arch incompatible mechanisms </H3>
|
|
<!--docid::SEC82::-->
|
|
<P>
|
|
|
|
Some mechanisms do not work with multi-arch. They include:
|
|
</P><P>
|
|
|
|
<DL COMPACT>
|
|
<DT><CODE>EXTRA_FRAME_INFO</CODE>
|
|
<DD>Delete.
|
|
<DT><CODE>FRAME_FIND_SAVED_REGS</CODE>
|
|
<DD>Replaced with <CODE>FRAME_INIT_SAVED_REGS</CODE>
|
|
</DL>
|
|
<P>
|
|
|
|
At this stage you could also consider converting the macros into
|
|
functions.
|
|
</P><P>
|
|
|
|
<HR SIZE="6">
|
|
<A NAME="SEC83"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC82"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC84"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC84"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC79"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_10.html#SEC88"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_19.html#SEC186">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H3> 9.12.4 Prepare for multi-arch level to one </H3>
|
|
<!--docid::SEC83::-->
|
|
<P>
|
|
|
|
Temporally set <CODE>GDB_MULTI_ARCH</CODE> to <CODE>GDB_MULTI_ARCH_PARTIAL</CODE>
|
|
and then build and start GDB (the change should not be
|
|
committed). GDB may not build, and once built, it may die with
|
|
an internal error listing the architecture methods that must be
|
|
provided.
|
|
</P><P>
|
|
|
|
Fix any build problems (patch(es)).
|
|
</P><P>
|
|
|
|
Convert all the architecture methods listed, which are only macros, into
|
|
functions (patch(es)).
|
|
</P><P>
|
|
|
|
Update <CODE><VAR>arch</VAR>_gdbarch_init</CODE> to set all the missing
|
|
architecture methods and wrap the corresponding macros in <CODE>#if
|
|
!GDB_MULTI_ARCH</CODE> (patch(es)).
|
|
</P><P>
|
|
|
|
<HR SIZE="6">
|
|
<A NAME="SEC84"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC83"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC85"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC85"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC79"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_10.html#SEC88"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_19.html#SEC186">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H3> 9.12.5 Set multi-arch level one </H3>
|
|
<!--docid::SEC84::-->
|
|
<P>
|
|
|
|
Change the value of <CODE>GDB_MULTI_ARCH</CODE> to GDB_MULTI_ARCH_PARTIAL (a
|
|
single patch).
|
|
</P><P>
|
|
|
|
Any problems with throwing "the switch" should have been fixed
|
|
already.
|
|
</P><P>
|
|
|
|
<HR SIZE="6">
|
|
<A NAME="SEC85"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC84"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC86"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC86"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC79"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_10.html#SEC88"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_19.html#SEC186">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H3> 9.12.6 Convert remaining macros </H3>
|
|
<!--docid::SEC85::-->
|
|
<P>
|
|
|
|
Suggest converting macros into functions (and setting the corresponding
|
|
architecture method) in small batches.
|
|
</P><P>
|
|
|
|
<HR SIZE="6">
|
|
<A NAME="SEC86"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC85"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC87"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC87"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC79"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_10.html#SEC88"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_19.html#SEC186">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H3> 9.12.7 Set multi-arch level to two </H3>
|
|
<!--docid::SEC86::-->
|
|
<P>
|
|
|
|
This should go smoothly.
|
|
</P><P>
|
|
|
|
<HR SIZE="6">
|
|
<A NAME="SEC87"></A>
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC86"> < </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_10.html#SEC88"> > </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC69"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC79"> Up </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_10.html#SEC88"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_19.html#SEC186">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<H3> 9.12.8 Delete the TM file </H3>
|
|
<!--docid::SEC87::-->
|
|
<P>
|
|
|
|
The <TT>`tm-<VAR>arch</VAR>.h'</TT> can be deleted. <TT>`<VAR>arch</VAR>.mt'</TT> and
|
|
<TT>`configure.in'</TT> updated.
|
|
</P><P>
|
|
|
|
<A NAME="Target Vector Definition"></A>
|
|
</P><P>
|
|
|
|
<HR SIZE="6">
|
|
<TABLE CELLPADDING=1 CELLSPACING=1 BORDER=0>
|
|
<TR><TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_9.html#SEC69"> << </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_10.html#SEC88"> >> </A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT"> <TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint.html#SEC_Top">Top</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_toc.html#SEC_Contents">Contents</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_19.html#SEC186">Index</A>]</TD>
|
|
<TD VALIGN="MIDDLE" ALIGN="LEFT">[<A HREF="gdbint_abt.html#SEC_About"> ? </A>]</TD>
|
|
</TR></TABLE>
|
|
<BR>
|
|
<FONT SIZE="-1">
|
|
|
|
<address>
|
|
|
|
<p>Please send FSF & GNU inquiries & questions to <a
|
|
href="mailto:gnu@gnu.org">gnu@gnu.org</a>. There are also <a
|
|
href="http://www.gnu.org/home.html#ContactInfo">other ways to
|
|
contact</a> the FSF.</p>
|
|
|
|
<p>These pages are maintained by <a
|
|
href="http://www.gnu.org/software/gdb/">the GDB developers</a>.</p>
|
|
|
|
<p>Copyright Free Software Foundation, Inc., 59 Temple Place - Suite
|
|
330, Boston, MA 02111, USA.</p>
|
|
|
|
<p>Verbatim copying and distribution of this entire article is
|
|
permitted in any medium, provided this notice is preserved.</p>
|
|
|
|
</address>
|
|
|
|
This document was generated
|
|
by <I>GDB Administrator</I> on <I>October, 26 2002</I>
|
|
using <A HREF="http://www.mathematik.uni-kl.de/~obachman/Texi2html
|
|
"><I>texi2html</I></A>
|
|
|
|
</BODY>
|
|
</HTML>
|