mirror of
https://github.com/rtlduino/RTL8710AF_GCC.git
synced 2026-07-15 15:55:41 +00:00
motify compile link error
motify compile link error
This commit is contained in:
parent
923914edae
commit
03e74a8e50
5418 changed files with 1367914 additions and 206149 deletions
|
|
@ -0,0 +1,58 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>About Dummy Frames - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="up" href="Inferior-Call-Setup.html#Inferior-Call-Setup" title="Inferior Call Setup">
|
||||
<link rel="next" href="Functions-Creating-Dummy-Frames.html#Functions-Creating-Dummy-Frames" title="Functions Creating Dummy Frames">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="About-Dummy-Frames"></a>
|
||||
Next: <a rel="next" accesskey="n" href="Functions-Creating-Dummy-Frames.html#Functions-Creating-Dummy-Frames">Functions Creating Dummy Frames</a>,
|
||||
Up: <a rel="up" accesskey="u" href="Inferior-Call-Setup.html#Inferior-Call-Setup">Inferior Call Setup</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h4 class="subsection">11.8.1 About Dummy Frames</h4>
|
||||
|
||||
<p><a name="index-dummy-frames-354"></a>
|
||||
<span class="sc">gdb</span> can call functions in the target code (for example by
|
||||
using the <kbd>call</kbd> or <kbd>print</kbd> commands). These functions may be
|
||||
breakpointed, and it is essential that if a function does hit a
|
||||
breakpoint, commands like <kbd>backtrace</kbd> work correctly.
|
||||
|
||||
<p>This is achieved by making the stack look as though the function had
|
||||
been called from the point where <span class="sc">gdb</span> had previously stopped.
|
||||
This requires that <span class="sc">gdb</span> can set up stack frames appropriate for
|
||||
such function calls.
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,114 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>Adding Target Described Register Support - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="up" href="Target-Descriptions.html#Target-Descriptions" title="Target Descriptions">
|
||||
<link rel="prev" href="Target-Descriptions-Implementation.html#Target-Descriptions-Implementation" title="Target Descriptions Implementation">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Adding-Target-Described-Register-Support"></a>
|
||||
Previous: <a rel="previous" accesskey="p" href="Target-Descriptions-Implementation.html#Target-Descriptions-Implementation">Target Descriptions Implementation</a>,
|
||||
Up: <a rel="up" accesskey="u" href="Target-Descriptions.html#Target-Descriptions">Target Descriptions</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h3 class="section">12.2 Adding Target Described Register Support</h3>
|
||||
|
||||
<p><a name="index-target-descriptions_002c-adding-register-support-436"></a>
|
||||
Target descriptions can report additional registers specific to an
|
||||
instance of the target. But it takes a little work in the architecture
|
||||
specific routines to support this.
|
||||
|
||||
<p>A target description must either have no registers or a complete
|
||||
set—this avoids complexity in trying to merge standard registers
|
||||
with the target defined registers. It is the architecture's
|
||||
responsibility to validate that a description with registers has
|
||||
everything it needs. To keep architecture code simple, the same
|
||||
mechanism is used to assign fixed internal register numbers to
|
||||
standard registers.
|
||||
|
||||
<p>If <code>tdesc_has_registers</code> returns 1, the description contains
|
||||
registers. The architecture's <code>gdbarch_init</code> routine should:
|
||||
|
||||
<ul>
|
||||
<li>Call <code>tdesc_data_alloc</code> to allocate storage, early, before
|
||||
searching for a matching gdbarch or allocating a new one.
|
||||
|
||||
<li>Use <code>tdesc_find_feature</code> to locate standard features by name.
|
||||
|
||||
<li>Use <code>tdesc_numbered_register</code> and <code>tdesc_numbered_register_choices</code>
|
||||
to locate the expected registers in the standard features.
|
||||
|
||||
<li>Return <code>NULL</code> if a required feature is missing, or if any standard
|
||||
feature is missing expected registers. This will produce a warning that
|
||||
the description was incomplete.
|
||||
|
||||
<li>Free the allocated data before returning, unless <code>tdesc_use_registers</code>
|
||||
is called.
|
||||
|
||||
<li>Call <code>set_gdbarch_num_regs</code> as usual, with a number higher than any
|
||||
fixed number passed to <code>tdesc_numbered_register</code>.
|
||||
|
||||
<li>Call <code>tdesc_use_registers</code> after creating a new gdbarch, before
|
||||
returning it.
|
||||
|
||||
</ul>
|
||||
|
||||
<p>After <code>tdesc_use_registers</code> has been called, the architecture's
|
||||
<code>register_name</code>, <code>register_type</code>, and <code>register_reggroup_p</code>
|
||||
routines will not be called; that information will be taken from
|
||||
the target description. <code>num_regs</code> may be increased to account
|
||||
for any additional registers in the description.
|
||||
|
||||
<p>Pseudo-registers require some extra care:
|
||||
|
||||
<ul>
|
||||
<li>Using <code>tdesc_numbered_register</code> allows the architecture to give
|
||||
constant register numbers to standard architectural registers, e.g.
|
||||
as an <code>enum</code> in <samp><var>arch</var><span class="file">-tdep.h</span></samp>. But because
|
||||
pseudo-registers are always numbered above <code>num_regs</code>,
|
||||
which may be increased by the description, constant numbers
|
||||
can not be used for pseudos. They must be numbered relative to
|
||||
<code>num_regs</code> instead.
|
||||
|
||||
<li>The description will not describe pseudo-registers, so the
|
||||
architecture must call <code>set_tdesc_pseudo_register_name</code>,
|
||||
<code>set_tdesc_pseudo_register_type</code>, and
|
||||
<code>set_tdesc_pseudo_register_reggroup_p</code> to supply routines
|
||||
describing pseudo registers. These routines will be passed
|
||||
internal register numbers, so the same routines used for the
|
||||
gdbarch equivalents are usually suitable.
|
||||
|
||||
</ul>
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,106 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>Adding a New Target - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="up" href="Target-Architecture-Definition.html#Target-Architecture-Definition" title="Target Architecture Definition">
|
||||
<link rel="prev" href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features" title="Defining Other Architecture Features">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Adding-a-New-Target"></a>
|
||||
Previous: <a rel="previous" accesskey="p" href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a>,
|
||||
Up: <a rel="up" accesskey="u" href="Target-Architecture-Definition.html#Target-Architecture-Definition">Target Architecture Definition</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h3 class="section">11.11 Adding a New Target</h3>
|
||||
|
||||
<p><a name="index-adding-a-target-430"></a>The following files add a target to <span class="sc">gdb</span>:
|
||||
|
||||
|
||||
<a name="index-target-dependent-files-431"></a>
|
||||
<dl>
|
||||
<dt><samp><span class="file">gdb/</span><var>ttt</var><span class="file">-tdep.c</span></samp><dd>Contains any miscellaneous code required for this target machine. On
|
||||
some machines it doesn't exist at all.
|
||||
|
||||
<br><dt><samp><span class="file">gdb/</span><var>arch</var><span class="file">-tdep.c</span></samp><dt><samp><span class="file">gdb/</span><var>arch</var><span class="file">-tdep.h</span></samp><dd>This is required to describe the basic layout of the target machine's
|
||||
processor chip (registers, stack, etc.). It can be shared among many
|
||||
targets that use the same processor architecture.
|
||||
|
||||
</dl>
|
||||
|
||||
<p>(Target header files such as
|
||||
<samp><span class="file">gdb/config/</span><var>arch</var><span class="file">/tm-</span><var>ttt</var><span class="file">.h</span></samp>,
|
||||
<samp><span class="file">gdb/config/</span><var>arch</var><span class="file">/tm-</span><var>arch</var><span class="file">.h</span></samp>, and
|
||||
<samp><span class="file">config/tm-</span><var>os</var><span class="file">.h</span></samp> are no longer used.)
|
||||
|
||||
<p><a name="index-g_t_005finitialize_005f_0040var_007barch_007d_005ftdep-432"></a>A <span class="sc">gdb</span> description for a new architecture, arch is created by
|
||||
defining a global function <code>_initialize_</code><var>arch</var><code>_tdep</code>, by
|
||||
convention in the source file <samp><var>arch</var><span class="file">-tdep.c</span></samp>. For
|
||||
example, in the case of the OpenRISC 1000, this function is called
|
||||
<code>_initialize_or1k_tdep</code> and is found in the file
|
||||
<samp><span class="file">or1k-tdep.c</span></samp>.
|
||||
|
||||
<p>The object file resulting from compiling this source file, which will
|
||||
contain the implementation of the
|
||||
<code>_initialize_</code><var>arch</var><code>_tdep</code> function is specified in the
|
||||
<span class="sc">gdb</span> <samp><span class="file">configure.tgt</span></samp> file, which includes a large case
|
||||
statement pattern matching against the <code>--target</code> option of the
|
||||
<kbd>configure</kbd> script.
|
||||
|
||||
<blockquote>
|
||||
<em>Note:</em> If the architecture requires multiple source files, the
|
||||
corresponding binaries should be included in
|
||||
<samp><span class="file">configure.tgt</span></samp>. However if there are header files, the
|
||||
dependencies on these will not be picked up from the entries in
|
||||
<samp><span class="file">configure.tgt</span></samp>. The <samp><span class="file">Makefile.in</span></samp> file will need extending to
|
||||
show these dependencies.
|
||||
</blockquote>
|
||||
|
||||
<p><a name="index-gdbarch_005fregister-433"></a>A new struct gdbarch, defining the new architecture, is created within
|
||||
the <code>_initialize_</code><var>arch</var><code>_tdep</code> function by calling
|
||||
<code>gdbarch_register</code>:
|
||||
|
||||
<pre class="smallexample"> void gdbarch_register (enum bfd_architecture architecture,
|
||||
gdbarch_init_ftype *init_func,
|
||||
gdbarch_dump_tdep_ftype *tdep_dump_func);
|
||||
</pre>
|
||||
<p>This function has been described fully in an earlier
|
||||
section. See <a href="How-an-Architecture-is-Represented.html#How-an-Architecture-is-Represented">How an Architecture is Represented</a>.
|
||||
|
||||
<p>The new <code>struct gdbarch<!-- /@w --></code> should contain implementations of
|
||||
the necessary functions (described in the previous sections) to
|
||||
describe the basic layout of the target machine's processor chip
|
||||
(registers, stack, etc.). It can be shared among many targets that use
|
||||
the same processor architecture.
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,57 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>Adding support for debugging core files - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="up" href="Target-Architecture-Definition.html#Target-Architecture-Definition" title="Target Architecture Definition">
|
||||
<link rel="prev" href="Inferior-Call-Setup.html#Inferior-Call-Setup" title="Inferior Call Setup">
|
||||
<link rel="next" href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features" title="Defining Other Architecture Features">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Adding-support-for-debugging-core-files"></a>
|
||||
Next: <a rel="next" accesskey="n" href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a>,
|
||||
Previous: <a rel="previous" accesskey="p" href="Inferior-Call-Setup.html#Inferior-Call-Setup">Inferior Call Setup</a>,
|
||||
Up: <a rel="up" accesskey="u" href="Target-Architecture-Definition.html#Target-Architecture-Definition">Target Architecture Definition</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h3 class="section">11.9 Adding support for debugging core files</h3>
|
||||
|
||||
<p><a name="index-core-files-358"></a>
|
||||
The prerequisite for adding core file support in <span class="sc">gdb</span> is to have
|
||||
core file support in BFD.
|
||||
|
||||
<p>Once BFD support is available, writing the apropriate
|
||||
<code>regset_from_core_section</code> architecture function should be all
|
||||
that is needed in order to add support for core files in <span class="sc">gdb</span>.
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,131 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>Address Classes - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="up" href="Target-Architecture-Definition.html#Target-Architecture-Definition" title="Target Architecture Definition">
|
||||
<link rel="prev" href="Pointers-and-Addresses.html#Pointers-and-Addresses" title="Pointers and Addresses">
|
||||
<link rel="next" href="Register-Representation.html#Register-Representation" title="Register Representation">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Address-Classes"></a>
|
||||
Next: <a rel="next" accesskey="n" href="Register-Representation.html#Register-Representation">Register Representation</a>,
|
||||
Previous: <a rel="previous" accesskey="p" href="Pointers-and-Addresses.html#Pointers-and-Addresses">Pointers and Addresses</a>,
|
||||
Up: <a rel="up" accesskey="u" href="Target-Architecture-Definition.html#Target-Architecture-Definition">Target Architecture Definition</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h3 class="section">11.5 Address Classes</h3>
|
||||
|
||||
<p><a name="index-address-classes-254"></a><a name="index-DW_005fAT_005fbyte_005fsize-255"></a><a name="index-DW_005fAT_005faddress_005fclass-256"></a>
|
||||
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<!-- /@w -->) or through an explicit
|
||||
address class attribute (e.g, <code>DW_AT_address_class</code> in DWARF 2<!-- /@w -->), the
|
||||
following macros should be defined in order to disambiguate these
|
||||
types within <span class="sc">gdb</span> as well as provide the added information to
|
||||
a <span class="sc">gdb</span> user when printing type expressions.
|
||||
|
||||
<div class="defun">
|
||||
— Function: int <b>gdbarch_address_class_type_flags</b> (<var>struct gdbarch *gdbarch, int byte_size, int dwarf2_addr_class</var>)<var><a name="index-gdbarch_005faddress_005fclass_005ftype_005fflags-257"></a></var><br>
|
||||
<blockquote><p>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
|
||||
<samp><span class="file">dwarf2read.c</span></samp>.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: char * <b>gdbarch_address_class_type_flags_to_name</b> (<var>struct gdbarch *gdbarch, int type_flags</var>)<var><a name="index-gdbarch_005faddress_005fclass_005ftype_005fflags_005fto_005fname-258"></a></var><br>
|
||||
<blockquote><p>Given the type flags representing an address class qualifier, return
|
||||
its name.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: int <b>gdbarch_address_class_name_to_type_flags</b> (<var>struct gdbarch *gdbarch, int name, int *type_flags_ptr</var>)<var><a name="index-gdbarch_005faddress_005fclass_005fname_005fto_005ftype_005fflags-259"></a></var><br>
|
||||
<blockquote><p>Given an address qualifier name, set the <code>int</code> referenced by <var>type_flags_ptr</var> to the type flags
|
||||
for that address class qualifier.
|
||||
</p></blockquote></div>
|
||||
|
||||
<p>Since the need for address classes is rather rare, none of
|
||||
the address class functions are defined by default. Predicate
|
||||
functions are provided to detect when they are defined.
|
||||
|
||||
<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<!-- /@w --> 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 functions:
|
||||
|
||||
<pre class="smallexample"> 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;
|
||||
}
|
||||
</pre>
|
||||
<p>The qualifier <code>@short</code> is used in <span class="sc">gdb</span>'s type expressions
|
||||
to indicate the presence of one of these “short” pointers. For
|
||||
example if the debug information indicates that <code>short_ptr_var</code> is
|
||||
one of these short pointers, <span class="sc">gdb</span> might show the following
|
||||
behavior:
|
||||
|
||||
<pre class="smallexample"> (gdb) ptype short_ptr_var
|
||||
type = int * @short
|
||||
</pre>
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,703 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>Algorithms - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="prev" href="Overall-Structure.html#Overall-Structure" title="Overall Structure">
|
||||
<link rel="next" href="User-Interface.html#User-Interface" title="User Interface">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Algorithms"></a>
|
||||
Next: <a rel="next" accesskey="n" href="User-Interface.html#User-Interface">User Interface</a>,
|
||||
Previous: <a rel="previous" accesskey="p" href="Overall-Structure.html#Overall-Structure">Overall Structure</a>,
|
||||
Up: <a rel="up" accesskey="u" href="index.html#Top">Top</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h2 class="chapter">3 Algorithms</h2>
|
||||
|
||||
<p><a name="index-algorithms-5"></a>
|
||||
<span class="sc">gdb</span> uses a number of debugging-specific algorithms. They are
|
||||
often not very complicated, but get lost in the thicket of special
|
||||
cases and real-world issues. This chapter describes the basic
|
||||
algorithms and mentions some of the specific target definitions that
|
||||
they use.
|
||||
|
||||
<h3 class="section">3.1 Prologue Analysis</h3>
|
||||
|
||||
<p><a name="index-prologue-analysis-6"></a><a name="index-call-frame-information-7"></a><a name="index-CFI-_0028call-frame-information_0029-8"></a>To produce a backtrace and allow the user to manipulate older frames'
|
||||
variables and arguments, <span class="sc">gdb</span> needs to find the base addresses
|
||||
of older frames, and discover where those frames' registers have been
|
||||
saved. Since a frame's “callee-saves” registers get saved by
|
||||
younger frames if and when they're reused, a frame's registers may be
|
||||
scattered unpredictably across younger frames. This means that
|
||||
changing the value of a register-allocated variable in an older frame
|
||||
may actually entail writing to a save slot in some younger frame.
|
||||
|
||||
<p>Modern versions of GCC emit Dwarf call frame information (“CFI”),
|
||||
which describes how to find frame base addresses and saved registers.
|
||||
But CFI is not always available, so as a fallback <span class="sc">gdb</span> uses a
|
||||
technique called <dfn>prologue analysis</dfn> to find frame sizes and saved
|
||||
registers. A prologue analyzer disassembles the function's machine
|
||||
code starting from its entry point, and looks for instructions that
|
||||
allocate frame space, save the stack pointer in a frame pointer
|
||||
register, save registers, and so on. Obviously, this can't be done
|
||||
accurately in general, but it's tractable to do well enough to be very
|
||||
helpful. Prologue analysis predates the GNU toolchain's support for
|
||||
CFI; at one time, prologue analysis was the only mechanism
|
||||
<span class="sc">gdb</span> used for stack unwinding at all, when the function
|
||||
calling conventions didn't specify a fixed frame layout.
|
||||
|
||||
<p>In the olden days, function prologues were generated by hand-written,
|
||||
target-specific code in GCC, and treated as opaque and untouchable by
|
||||
optimizers. Looking at this code, it was usually straightforward to
|
||||
write a prologue analyzer for <span class="sc">gdb</span> that would accurately
|
||||
understand all the prologues GCC would generate. However, over time
|
||||
GCC became more aggressive about instruction scheduling, and began to
|
||||
understand more about the semantics of the prologue instructions
|
||||
themselves; in response, <span class="sc">gdb</span>'s analyzers became more complex
|
||||
and fragile. Keeping the prologue analyzers working as GCC (and the
|
||||
instruction sets themselves) evolved became a substantial task.
|
||||
|
||||
<p><a name="index-g_t_0040file_007bprologue_002dvalue_002ec_007d-9"></a><a name="index-abstract-interpretation-of-function-prologues-10"></a><a name="index-pseudo_002devaluation-of-function-prologues-11"></a>To try to address this problem, the code in <samp><span class="file">prologue-value.h</span></samp>
|
||||
and <samp><span class="file">prologue-value.c</span></samp> provides a general framework for writing
|
||||
prologue analyzers that are simpler and more robust than ad-hoc
|
||||
analyzers. When we analyze a prologue using the prologue-value
|
||||
framework, we're really doing “abstract interpretation” or
|
||||
“pseudo-evaluation”: running the function's code in simulation, but
|
||||
using conservative approximations of the values registers and memory
|
||||
would hold when the code actually runs. For example, if our function
|
||||
starts with the instruction:
|
||||
|
||||
<pre class="example"> addi r1, 42 # add 42 to r1
|
||||
</pre>
|
||||
<p class="noindent">we don't know exactly what value will be in <code>r1</code> after executing
|
||||
this instruction, but we do know it'll be 42 greater than its original
|
||||
value.
|
||||
|
||||
<p>If we then see an instruction like:
|
||||
|
||||
<pre class="example"> addi r1, 22 # add 22 to r1
|
||||
</pre>
|
||||
<p class="noindent">we still don't know what <code>r1's</code> value is, but again, we can say
|
||||
it is now 64 greater than its original value.
|
||||
|
||||
<p>If the next instruction were:
|
||||
|
||||
<pre class="example"> mov r2, r1 # set r2 to r1's value
|
||||
</pre>
|
||||
<p class="noindent">then we can say that <code>r2's</code> value is now the original value of
|
||||
<code>r1</code> plus 64.
|
||||
|
||||
<p>It's common for prologues to save registers on the stack, so we'll
|
||||
need to track the values of stack frame slots, as well as the
|
||||
registers. So after an instruction like this:
|
||||
|
||||
<pre class="example"> mov (fp+4), r2
|
||||
</pre>
|
||||
<p class="noindent">then we'd know that the stack slot four bytes above the frame pointer
|
||||
holds the original value of <code>r1</code> plus 64.
|
||||
|
||||
<p>And so on.
|
||||
|
||||
<p>Of course, this can only go so far before it gets unreasonable. If we
|
||||
wanted to be able to say anything about the value of <code>r1</code> after
|
||||
the instruction:
|
||||
|
||||
<pre class="example"> xor r1, r3 # exclusive-or r1 and r3, place result in r1
|
||||
</pre>
|
||||
<p class="noindent">then things would get pretty complex. But remember, we're just doing
|
||||
a conservative approximation; if exclusive-or instructions aren't
|
||||
relevant to prologues, we can just say <code>r1</code>'s value is now
|
||||
“unknown”. We can ignore things that are too complex, if that loss of
|
||||
information is acceptable for our application.
|
||||
|
||||
<p>So when we say “conservative approximation” here, what we mean is an
|
||||
approximation that is either accurate, or marked “unknown”, but
|
||||
never inaccurate.
|
||||
|
||||
<p>Using this framework, a prologue analyzer is simply an interpreter for
|
||||
machine code, but one that uses conservative approximations for the
|
||||
contents of registers and memory instead of actual values. Starting
|
||||
from the function's entry point, you simulate instructions up to the
|
||||
current PC, or an instruction that you don't know how to simulate.
|
||||
Now you can examine the state of the registers and stack slots you've
|
||||
kept track of.
|
||||
|
||||
<ul>
|
||||
<li>To see how large your stack frame is, just check the value of the
|
||||
stack pointer register; if it's the original value of the SP
|
||||
minus a constant, then that constant is the stack frame's size.
|
||||
If the SP's value has been marked as “unknown”, then that means
|
||||
the prologue has done something too complex for us to track, and
|
||||
we don't know the frame size.
|
||||
|
||||
<li>To see where we've saved the previous frame's registers, we just
|
||||
search the values we've tracked — stack slots, usually, but
|
||||
registers, too, if you want — for something equal to the register's
|
||||
original value. If the calling conventions suggest a standard place
|
||||
to save a given register, then we can check there first, but really,
|
||||
anything that will get us back the original value will probably work.
|
||||
</ul>
|
||||
|
||||
<p>This does take some work. But prologue analyzers aren't
|
||||
quick-and-simple pattern patching to recognize a few fixed prologue
|
||||
forms any more; they're big, hairy functions. Along with inferior
|
||||
function calls, prologue analysis accounts for a substantial portion
|
||||
of the time needed to stabilize a <span class="sc">gdb</span> port. So it's
|
||||
worthwhile to look for an approach that will be easier to understand
|
||||
and maintain. In the approach described above:
|
||||
|
||||
<ul>
|
||||
<li>It's easier to see that the analyzer is correct: you just see
|
||||
whether the analyzer properly (albeit conservatively) simulates
|
||||
the effect of each instruction.
|
||||
|
||||
<li>It's easier to extend the analyzer: you can add support for new
|
||||
instructions, and know that you haven't broken anything that
|
||||
wasn't already broken before.
|
||||
|
||||
<li>It's orthogonal: to gather new information, you don't need to
|
||||
complicate the code for each instruction. As long as your domain
|
||||
of conservative values is already detailed enough to tell you
|
||||
what you need, then all the existing instruction simulations are
|
||||
already gathering the right data for you.
|
||||
|
||||
</ul>
|
||||
|
||||
<p>The file <samp><span class="file">prologue-value.h</span></samp> contains detailed comments explaining
|
||||
the framework and how to use it.
|
||||
|
||||
<h3 class="section">3.2 Breakpoint Handling</h3>
|
||||
|
||||
<p><a name="index-breakpoints-12"></a>In general, a breakpoint is a user-designated location in the program
|
||||
where the user wants to regain control if program execution ever reaches
|
||||
that location.
|
||||
|
||||
<p>There are two main ways to implement breakpoints; either as “hardware”
|
||||
breakpoints or as “software” breakpoints.
|
||||
|
||||
<p><a name="index-hardware-breakpoints-13"></a><a name="index-program-counter-14"></a>Hardware breakpoints are sometimes available as a builtin debugging
|
||||
features with some chips. Typically these work by having dedicated
|
||||
register into which the breakpoint address may be stored. If the PC
|
||||
(shorthand for <dfn>program counter</dfn>)
|
||||
ever matches a value in a breakpoint registers, the CPU raises an
|
||||
exception and reports it to <span class="sc">gdb</span>.
|
||||
|
||||
<p>Another possibility is when an emulator is in use; many emulators
|
||||
include circuitry that watches the address lines coming out from the
|
||||
processor, and force it to stop if the address matches a breakpoint's
|
||||
address.
|
||||
|
||||
<p>A third possibility is that the target already has the ability to do
|
||||
breakpoints somehow; for instance, a ROM monitor may do its own
|
||||
software breakpoints. So although these are not literally “hardware
|
||||
breakpoints”, from <span class="sc">gdb</span>'s point of view they work the same;
|
||||
<span class="sc">gdb</span> need not do anything more than set the breakpoint and wait
|
||||
for something to happen.
|
||||
|
||||
<p>Since they depend on hardware resources, hardware breakpoints may be
|
||||
limited in number; when the user asks for more, <span class="sc">gdb</span> will
|
||||
start trying to set software breakpoints. (On some architectures,
|
||||
notably the 32-bit x86 platforms, <span class="sc">gdb</span> cannot always know
|
||||
whether there's enough hardware resources to insert all the hardware
|
||||
breakpoints and watchpoints. On those platforms, <span class="sc">gdb</span> prints
|
||||
an error message only when the program being debugged is continued.)
|
||||
|
||||
<p><a name="index-software-breakpoints-15"></a>Software breakpoints require <span class="sc">gdb</span> to do somewhat more work.
|
||||
The basic theory is that <span class="sc">gdb</span> will replace a program
|
||||
instruction with a trap, illegal divide, or some other instruction
|
||||
that will cause an exception, and then when it's encountered,
|
||||
<span class="sc">gdb</span> will take the exception and stop the program. When the
|
||||
user says to continue, <span class="sc">gdb</span> will restore the original
|
||||
instruction, single-step, re-insert the trap, and continue on.
|
||||
|
||||
<p>Since it literally overwrites the program being tested, the program area
|
||||
must be writable, so this technique won't work on programs in ROM. It
|
||||
can also distort the behavior of programs that examine themselves,
|
||||
although such a situation would be highly unusual.
|
||||
|
||||
<p>Also, the software breakpoint instruction should be the smallest size of
|
||||
instruction, so it doesn't overwrite an instruction that might be a jump
|
||||
target, and cause disaster when the program jumps into the middle of the
|
||||
breakpoint instruction. (Strictly speaking, the breakpoint must be no
|
||||
larger than the smallest interval between instructions that may be jump
|
||||
targets; perhaps there is an architecture where only even-numbered
|
||||
instructions may jumped to.) Note that it's possible for an instruction
|
||||
set not to have any instructions usable for a software breakpoint,
|
||||
although in practice only the ARC has failed to define such an
|
||||
instruction.
|
||||
|
||||
<p>Basic breakpoint object handling is in <samp><span class="file">breakpoint.c</span></samp>. However,
|
||||
much of the interesting breakpoint action is in <samp><span class="file">infrun.c</span></samp>.
|
||||
|
||||
|
||||
<a name="index-insert-or-remove-software-breakpoint-16"></a>
|
||||
<a name="index-target_005fremove_005fbreakpoint-17"></a>
|
||||
<a name="index-target_005finsert_005fbreakpoint-18"></a>
|
||||
<dl><dt><code>target_remove_breakpoint (</code><var>bp_tgt</var><code>)</code><dt><code>target_insert_breakpoint (</code><var>bp_tgt</var><code>)</code><dd>Insert or remove a software breakpoint at address
|
||||
<var>bp_tgt</var><code>->placed_address</code>. Returns zero for success,
|
||||
non-zero for failure. On input, <var>bp_tgt</var> contains the address of the
|
||||
breakpoint, and is otherwise initialized to zero. The fields of the
|
||||
<code>struct bp_target_info</code> pointed to by <var>bp_tgt</var> are updated
|
||||
to contain other information about the breakpoint on output. The field
|
||||
<code>placed_address</code> may be updated if the breakpoint was placed at a
|
||||
related address; the field <code>shadow_contents</code> contains the real
|
||||
contents of the bytes where the breakpoint has been inserted,
|
||||
if reading memory would return the breakpoint instead of the
|
||||
underlying memory; the field <code>shadow_len</code> is the length of
|
||||
memory cached in <code>shadow_contents</code>, if any; and the field
|
||||
<code>placed_size</code> is optionally set and used by the target, if
|
||||
it could differ from <code>shadow_len</code>.
|
||||
|
||||
<p>For example, the remote target ‘<samp><span class="samp">Z0</span></samp>’ packet does not require
|
||||
shadowing memory, so <code>shadow_len</code> is left at zero. However,
|
||||
the length reported by <code>gdbarch_breakpoint_from_pc</code> is cached in
|
||||
<code>placed_size</code>, so that a matching ‘<samp><span class="samp">z0</span></samp>’ packet can be
|
||||
used to remove the breakpoint.
|
||||
|
||||
<p><a name="index-insert-or-remove-hardware-breakpoint-19"></a><a name="index-target_005fremove_005fhw_005fbreakpoint-20"></a><a name="index-target_005finsert_005fhw_005fbreakpoint-21"></a><br><dt><code>target_remove_hw_breakpoint (</code><var>bp_tgt</var><code>)</code><dt><code>target_insert_hw_breakpoint (</code><var>bp_tgt</var><code>)</code><dd>Insert or remove a hardware-assisted breakpoint at address
|
||||
<var>bp_tgt</var><code>->placed_address</code>. Returns zero for success,
|
||||
non-zero for failure. See <code>target_insert_breakpoint</code> for
|
||||
a description of the <code>struct bp_target_info</code> pointed to by
|
||||
<var>bp_tgt</var>; the <code>shadow_contents</code> and
|
||||
<code>shadow_len</code> members are not used for hardware breakpoints,
|
||||
but <code>placed_size</code> may be.
|
||||
</dl>
|
||||
|
||||
<h3 class="section">3.3 Single Stepping</h3>
|
||||
|
||||
<h3 class="section">3.4 Signal Handling</h3>
|
||||
|
||||
<h3 class="section">3.5 Thread Handling</h3>
|
||||
|
||||
<h3 class="section">3.6 Inferior Function Calls</h3>
|
||||
|
||||
<h3 class="section">3.7 Longjmp Support</h3>
|
||||
|
||||
<p><a name="index-g_t_0040code_007blongjmp_007d-debugging-22"></a><span class="sc">gdb</span> has support for figuring out that the target is doing a
|
||||
<code>longjmp</code> and for stopping at the target of the jump, if we are
|
||||
stepping. This is done with a few specialized internal breakpoints,
|
||||
which are visible in the output of the ‘<samp><span class="samp">maint info breakpoint</span></samp>’
|
||||
command.
|
||||
|
||||
<p><a name="index-gdbarch_005fget_005flongjmp_005ftarget-23"></a>To make this work, you need to define a function called
|
||||
<code>gdbarch_get_longjmp_target</code>, which will examine the
|
||||
<code>jmp_buf</code> structure and extract the <code>longjmp</code> target address.
|
||||
Since <code>jmp_buf</code> is target specific and typically defined in a
|
||||
target header not available to <span class="sc">gdb</span>, you will need to
|
||||
determine the offset of the PC manually and return that; many targets
|
||||
define a <code>jb_pc_offset</code> field in the tdep structure to save the
|
||||
value once calculated.
|
||||
|
||||
<h3 class="section">3.8 Watchpoints</h3>
|
||||
|
||||
<p><a name="index-watchpoints-24"></a>
|
||||
Watchpoints are a special kind of breakpoints (see <a href="Algorithms.html#Algorithms">breakpoints</a>) which break when data is accessed rather than when some
|
||||
instruction is executed. When you have data which changes without
|
||||
your knowing what code does that, watchpoints are the silver bullet to
|
||||
hunt down and kill such bugs.
|
||||
|
||||
<p><a name="index-hardware-watchpoints-25"></a><a name="index-software-watchpoints-26"></a>Watchpoints can be either hardware-assisted or not; the latter type is
|
||||
known as “software watchpoints.” <span class="sc">gdb</span> always uses
|
||||
hardware-assisted watchpoints if they are available, and falls back on
|
||||
software watchpoints otherwise. Typical situations where <span class="sc">gdb</span>
|
||||
will use software watchpoints are:
|
||||
|
||||
<ul>
|
||||
<li>The watched memory region is too large for the underlying hardware
|
||||
watchpoint support. For example, each x86 debug register can watch up
|
||||
to 4 bytes of memory, so trying to watch data structures whose size is
|
||||
more than 16 bytes will cause <span class="sc">gdb</span> to use software
|
||||
watchpoints.
|
||||
|
||||
<li>The value of the expression to be watched depends on data held in
|
||||
registers (as opposed to memory).
|
||||
|
||||
<li>Too many different watchpoints requested. (On some architectures,
|
||||
this situation is impossible to detect until the debugged program is
|
||||
resumed.) Note that x86 debug registers are used both for hardware
|
||||
breakpoints and for watchpoints, so setting too many hardware
|
||||
breakpoints might cause watchpoint insertion to fail.
|
||||
|
||||
<li>No hardware-assisted watchpoints provided by the target
|
||||
implementation.
|
||||
</ul>
|
||||
|
||||
<p>Software watchpoints are very slow, since <span class="sc">gdb</span> needs to
|
||||
single-step the program being debugged and test the value of the
|
||||
watched expression(s) after each instruction. The rest of this
|
||||
section is mostly irrelevant for software watchpoints.
|
||||
|
||||
<p>When the inferior stops, <span class="sc">gdb</span> tries to establish, among other
|
||||
possible reasons, whether it stopped due to a watchpoint being hit.
|
||||
It first uses <code>STOPPED_BY_WATCHPOINT</code> to see if any watchpoint
|
||||
was hit. If not, all watchpoint checking is skipped.
|
||||
|
||||
<p>Then <span class="sc">gdb</span> calls <code>target_stopped_data_address</code> exactly
|
||||
once. This method returns the address of the watchpoint which
|
||||
triggered, if the target can determine it. If the triggered address
|
||||
is available, <span class="sc">gdb</span> compares the address returned by this
|
||||
method with each watched memory address in each active watchpoint.
|
||||
For data-read and data-access watchpoints, <span class="sc">gdb</span> announces
|
||||
every watchpoint that watches the triggered address as being hit.
|
||||
For this reason, data-read and data-access watchpoints
|
||||
<em>require</em> that the triggered address be available; if not, read
|
||||
and access watchpoints will never be considered hit. For data-write
|
||||
watchpoints, if the triggered address is available, <span class="sc">gdb</span>
|
||||
considers only those watchpoints which match that address;
|
||||
otherwise, <span class="sc">gdb</span> considers all data-write watchpoints. For
|
||||
each data-write watchpoint that <span class="sc">gdb</span> considers, it evaluates
|
||||
the expression whose value is being watched, and tests whether the
|
||||
watched value has changed. Watchpoints whose watched values have
|
||||
changed are announced as hit.
|
||||
|
||||
<!-- FIXME move these to the main lists of target/native defns -->
|
||||
<p><span class="sc">gdb</span> uses several macros and primitives to support hardware
|
||||
watchpoints:
|
||||
|
||||
|
||||
<a name="index-TARGET_005fCAN_005fUSE_005fHARDWARE_005fWATCHPOINT-27"></a>
|
||||
<dl><dt><code>TARGET_CAN_USE_HARDWARE_WATCHPOINT (</code><var>type</var><code>, </code><var>count</var><code>, </code><var>other</var><code>)</code><dd>Return the number of hardware watchpoints of type <var>type</var> that are
|
||||
possible to be set. The value is positive if <var>count</var> watchpoints
|
||||
of this type can be set, zero if setting watchpoints of this type is
|
||||
not supported, and negative if <var>count</var> is more than the maximum
|
||||
number of watchpoints of type <var>type</var> that can be set. <var>other</var>
|
||||
is non-zero if other types of watchpoints are currently enabled (there
|
||||
are architectures which cannot set watchpoints of different types at
|
||||
the same time).
|
||||
|
||||
<p><a name="index-TARGET_005fREGION_005fOK_005fFOR_005fHW_005fWATCHPOINT-28"></a><br><dt><code>TARGET_REGION_OK_FOR_HW_WATCHPOINT (</code><var>addr</var><code>, </code><var>len</var><code>)</code><dd>Return non-zero if hardware watchpoints can be used to watch a region
|
||||
whose address is <var>addr</var> and whose length in bytes is <var>len</var>.
|
||||
|
||||
<p><a name="index-insert-or-remove-hardware-watchpoint-29"></a><a name="index-target_005finsert_005fwatchpoint-30"></a><a name="index-target_005fremove_005fwatchpoint-31"></a><br><dt><code>target_insert_watchpoint (</code><var>addr</var><code>, </code><var>len</var><code>, </code><var>type</var><code>)</code><dt><code>target_remove_watchpoint (</code><var>addr</var><code>, </code><var>len</var><code>, </code><var>type</var><code>)</code><dd>Insert or remove a hardware watchpoint starting at <var>addr</var>, for
|
||||
<var>len</var> bytes. <var>type</var> is the watchpoint type, one of the
|
||||
possible values of the enumerated data type <code>target_hw_bp_type</code>,
|
||||
defined by <samp><span class="file">breakpoint.h</span></samp> as follows:
|
||||
|
||||
<pre class="smallexample"> enum target_hw_bp_type
|
||||
{
|
||||
hw_write = 0, /* Common (write) HW watchpoint */
|
||||
hw_read = 1, /* Read HW watchpoint */
|
||||
hw_access = 2, /* Access (read or write) HW watchpoint */
|
||||
hw_execute = 3 /* Execute HW breakpoint */
|
||||
};
|
||||
</pre>
|
||||
<p class="noindent">These two macros should return 0 for success, non-zero for failure.
|
||||
|
||||
<p><a name="index-target_005fstopped_005fdata_005faddress-32"></a><br><dt><code>target_stopped_data_address (</code><var>addr_p</var><code>)</code><dd>If the inferior has some watchpoint that triggered, place the address
|
||||
associated with the watchpoint at the location pointed to by
|
||||
<var>addr_p</var> and return non-zero. Otherwise, return zero. This
|
||||
is required for data-read and data-access watchpoints. It is
|
||||
not required for data-write watchpoints, but <span class="sc">gdb</span> uses
|
||||
it to improve handling of those also.
|
||||
|
||||
<p><span class="sc">gdb</span> will only call this method once per watchpoint stop,
|
||||
immediately after calling <code>STOPPED_BY_WATCHPOINT</code>. If the
|
||||
target's watchpoint indication is sticky, i.e., stays set after
|
||||
resuming, this method should clear it. For instance, the x86 debug
|
||||
control register has sticky triggered flags.
|
||||
|
||||
<p><a name="index-target_005fwatchpoint_005faddr_005fwithin_005frange-33"></a><br><dt><code>target_watchpoint_addr_within_range (</code><var>target</var><code>, </code><var>addr</var><code>, </code><var>start</var><code>, </code><var>length</var><code>)</code><dd>Check whether <var>addr</var> (as returned by <code>target_stopped_data_address</code>)
|
||||
lies within the hardware-defined watchpoint region described by
|
||||
<var>start</var> and <var>length</var>. This only needs to be provided if the
|
||||
granularity of a watchpoint is greater than one byte, i.e., if the
|
||||
watchpoint can also trigger on nearby addresses outside of the watched
|
||||
region.
|
||||
|
||||
<p><a name="index-HAVE_005fSTEPPABLE_005fWATCHPOINT-34"></a><br><dt><code>HAVE_STEPPABLE_WATCHPOINT</code><dd>If defined to a non-zero value, it is not necessary to disable a
|
||||
watchpoint to step over it. Like <code>gdbarch_have_nonsteppable_watchpoint</code>,
|
||||
this is usually set when watchpoints trigger at the instruction
|
||||
which will perform an interesting read or write. It should be
|
||||
set if there is a temporary disable bit which allows the processor
|
||||
to step over the interesting instruction without raising the
|
||||
watchpoint exception again.
|
||||
|
||||
<p><a name="index-gdbarch_005fhave_005fnonsteppable_005fwatchpoint-35"></a><br><dt><code>int gdbarch_have_nonsteppable_watchpoint (</code><var>gdbarch</var><code>)</code><dd>If it returns a non-zero value, <span class="sc">gdb</span> should disable a
|
||||
watchpoint to step the inferior over it. This is usually set when
|
||||
watchpoints trigger at the instruction which will perform an
|
||||
interesting read or write.
|
||||
|
||||
<p><a name="index-HAVE_005fCONTINUABLE_005fWATCHPOINT-36"></a><br><dt><code>HAVE_CONTINUABLE_WATCHPOINT</code><dd>If defined to a non-zero value, it is possible to continue the
|
||||
inferior after a watchpoint has been hit. This is usually set
|
||||
when watchpoints trigger at the instruction following an interesting
|
||||
read or write.
|
||||
|
||||
<p><a name="index-STOPPED_005fBY_005fWATCHPOINT-37"></a><br><dt><code>STOPPED_BY_WATCHPOINT (</code><var>wait_status</var><code>)</code><dd>Return non-zero if stopped by a watchpoint. <var>wait_status</var> is of
|
||||
the type <code>struct target_waitstatus</code>, defined by <samp><span class="file">target.h</span></samp>.
|
||||
Normally, this macro is defined to invoke the function pointed to by
|
||||
the <code>to_stopped_by_watchpoint</code> member of the structure (of the
|
||||
type <code>target_ops</code>, defined on <samp><span class="file">target.h</span></samp>) that describes the
|
||||
target-specific operations; <code>to_stopped_by_watchpoint</code> ignores
|
||||
the <var>wait_status</var> argument.
|
||||
|
||||
<p><span class="sc">gdb</span> does not require the non-zero value returned by
|
||||
<code>STOPPED_BY_WATCHPOINT</code> to be 100% correct, so if a target cannot
|
||||
determine for sure whether the inferior stopped due to a watchpoint,
|
||||
it could return non-zero “just in case”.
|
||||
</dl>
|
||||
|
||||
<h4 class="subsection">3.8.1 Watchpoints and Threads</h4>
|
||||
|
||||
<p><a name="index-watchpoints_002c-with-threads-38"></a>
|
||||
<span class="sc">gdb</span> only supports process-wide watchpoints, which trigger
|
||||
in all threads. <span class="sc">gdb</span> uses the thread ID to make watchpoints
|
||||
act as if they were thread-specific, but it cannot set hardware
|
||||
watchpoints that only trigger in a specific thread. Therefore, even
|
||||
if the target supports threads, per-thread debug registers, and
|
||||
watchpoints which only affect a single thread, it should set the
|
||||
per-thread debug registers for all threads to the same value. On
|
||||
<span class="sc">gnu</span>/Linux native targets, this is accomplished by using
|
||||
<code>ALL_LWPS</code> in <code>target_insert_watchpoint</code> and
|
||||
<code>target_remove_watchpoint</code> and by using
|
||||
<code>linux_set_new_thread</code> to register a handler for newly created
|
||||
threads.
|
||||
|
||||
<p><span class="sc">gdb</span>'s <span class="sc">gnu</span>/Linux support only reports a single event
|
||||
at a time, although multiple events can trigger simultaneously for
|
||||
multi-threaded programs. When multiple events occur, <samp><span class="file">linux-nat.c</span></samp>
|
||||
queues subsequent events and returns them the next time the program
|
||||
is resumed. This means that <code>STOPPED_BY_WATCHPOINT</code> and
|
||||
<code>target_stopped_data_address</code> only need to consult the current
|
||||
thread's state—the thread indicated by <code>inferior_ptid</code>. If
|
||||
two threads have hit watchpoints simultaneously, those routines
|
||||
will be called a second time for the second thread.
|
||||
|
||||
<h4 class="subsection">3.8.2 x86 Watchpoints</h4>
|
||||
|
||||
<p><a name="index-x86-debug-registers-39"></a><a name="index-watchpoints_002c-on-x86-40"></a>
|
||||
The 32-bit Intel x86 (a.k.a. ia32) processors feature special debug
|
||||
registers designed to facilitate debugging. <span class="sc">gdb</span> provides a
|
||||
generic library of functions that x86-based ports can use to implement
|
||||
support for watchpoints and hardware-assisted breakpoints. This
|
||||
subsection documents the x86 watchpoint facilities in <span class="sc">gdb</span>.
|
||||
|
||||
<p>(At present, the library functions read and write debug registers directly, and are
|
||||
thus only available for native configurations.)
|
||||
|
||||
<p>To use the generic x86 watchpoint support, a port should do the
|
||||
following:
|
||||
|
||||
|
||||
<a name="index-I386_005fUSE_005fGENERIC_005fWATCHPOINTS-41"></a>
|
||||
<ul><li>Define the macro <code>I386_USE_GENERIC_WATCHPOINTS</code> somewhere in the
|
||||
target-dependent headers.
|
||||
|
||||
<li>Include the <samp><span class="file">config/i386/nm-i386.h</span></samp> header file <em>after</em>
|
||||
defining <code>I386_USE_GENERIC_WATCHPOINTS</code>.
|
||||
|
||||
<li>Add <samp><span class="file">i386-nat.o</span></samp> to the value of the Make variable
|
||||
<code>NATDEPFILES</code> (see <a href="Native-Debugging.html#Native-Debugging">NATDEPFILES</a>).
|
||||
|
||||
<li>Provide implementations for the <code>I386_DR_LOW_*</code> macros described
|
||||
below. Typically, each macro should call a target-specific function
|
||||
which does the real work.
|
||||
</ul>
|
||||
|
||||
<p>The x86 watchpoint support works by maintaining mirror images of the
|
||||
debug registers. Values are copied between the mirror images and the
|
||||
real debug registers via a set of macros which each target needs to
|
||||
provide:
|
||||
|
||||
|
||||
<a name="index-I386_005fDR_005fLOW_005fSET_005fCONTROL-42"></a>
|
||||
<dl><dt><code>I386_DR_LOW_SET_CONTROL (</code><var>val</var><code>)</code><dd>Set the Debug Control (DR7) register to the value <var>val</var>.
|
||||
|
||||
<p><a name="index-I386_005fDR_005fLOW_005fSET_005fADDR-43"></a><br><dt><code>I386_DR_LOW_SET_ADDR (</code><var>idx</var><code>, </code><var>addr</var><code>)</code><dd>Put the address <var>addr</var> into the debug register number <var>idx</var>.
|
||||
|
||||
<p><a name="index-I386_005fDR_005fLOW_005fRESET_005fADDR-44"></a><br><dt><code>I386_DR_LOW_RESET_ADDR (</code><var>idx</var><code>)</code><dd>Reset (i.e. zero out) the address stored in the debug register
|
||||
number <var>idx</var>.
|
||||
|
||||
<p><a name="index-I386_005fDR_005fLOW_005fGET_005fSTATUS-45"></a><br><dt><code>I386_DR_LOW_GET_STATUS</code><dd>Return the value of the Debug Status (DR6) register. This value is
|
||||
used immediately after it is returned by
|
||||
<code>I386_DR_LOW_GET_STATUS</code>, so as to support per-thread status
|
||||
register values.
|
||||
</dl>
|
||||
|
||||
<p>For each one of the 4 debug registers (whose indices are from 0 to 3)
|
||||
that store addresses, a reference count is maintained by <span class="sc">gdb</span>,
|
||||
to allow sharing of debug registers by several watchpoints. This
|
||||
allows users to define several watchpoints that watch the same
|
||||
expression, but with different conditions and/or commands, without
|
||||
wasting debug registers which are in short supply. <span class="sc">gdb</span>
|
||||
maintains the reference counts internally, targets don't have to do
|
||||
anything to use this feature.
|
||||
|
||||
<p>The x86 debug registers can each watch a region that is 1, 2, or 4
|
||||
bytes long. The ia32 architecture requires that each watched region
|
||||
be appropriately aligned: 2-byte region on 2-byte boundary, 4-byte
|
||||
region on 4-byte boundary. However, the x86 watchpoint support in
|
||||
<span class="sc">gdb</span> can watch unaligned regions and regions larger than 4
|
||||
bytes (up to 16 bytes) by allocating several debug registers to watch
|
||||
a single region. This allocation of several registers per a watched
|
||||
region is also done automatically without target code intervention.
|
||||
|
||||
<p>The generic x86 watchpoint support provides the following API for the
|
||||
<span class="sc">gdb</span>'s application code:
|
||||
|
||||
|
||||
<a name="index-i386_005fregion_005fok_005ffor_005fwatchpoint-46"></a>
|
||||
<dl><dt><code>i386_region_ok_for_watchpoint (</code><var>addr</var><code>, </code><var>len</var><code>)</code><dd>The macro <code>TARGET_REGION_OK_FOR_HW_WATCHPOINT</code> is set to call
|
||||
this function. It counts the number of debug registers required to
|
||||
watch a given region, and returns a non-zero value if that number is
|
||||
less than 4, the number of debug registers available to x86
|
||||
processors.
|
||||
|
||||
<p><a name="index-i386_005fstopped_005fdata_005faddress-47"></a><br><dt><code>i386_stopped_data_address (</code><var>addr_p</var><code>)</code><dd>The target function
|
||||
<code>target_stopped_data_address</code> is set to call this function.
|
||||
This
|
||||
function examines the breakpoint condition bits in the DR6 Debug
|
||||
Status register, as returned by the <code>I386_DR_LOW_GET_STATUS</code>
|
||||
macro, and returns the address associated with the first bit that is
|
||||
set in DR6.
|
||||
|
||||
<p><a name="index-i386_005fstopped_005fby_005fwatchpoint-48"></a><br><dt><code>i386_stopped_by_watchpoint (void)</code><dd>The macro <code>STOPPED_BY_WATCHPOINT</code>
|
||||
is set to call this function. The
|
||||
argument passed to <code>STOPPED_BY_WATCHPOINT</code> is ignored. This
|
||||
function examines the breakpoint condition bits in the DR6 Debug
|
||||
Status register, as returned by the <code>I386_DR_LOW_GET_STATUS</code>
|
||||
macro, and returns true if any bit is set. Otherwise, false is
|
||||
returned.
|
||||
|
||||
<p><a name="index-i386_005finsert_005fwatchpoint-49"></a><a name="index-i386_005fremove_005fwatchpoint-50"></a><br><dt><code>i386_insert_watchpoint (</code><var>addr</var><code>, </code><var>len</var><code>, </code><var>type</var><code>)</code><dt><code>i386_remove_watchpoint (</code><var>addr</var><code>, </code><var>len</var><code>, </code><var>type</var><code>)</code><dd>Insert or remove a watchpoint. The macros
|
||||
<code>target_insert_watchpoint</code> and <code>target_remove_watchpoint</code>
|
||||
are set to call these functions. <code>i386_insert_watchpoint</code> first
|
||||
looks for a debug register which is already set to watch the same
|
||||
region for the same access types; if found, it just increments the
|
||||
reference count of that debug register, thus implementing debug
|
||||
register sharing between watchpoints. If no such register is found,
|
||||
the function looks for a vacant debug register, sets its mirrored
|
||||
value to <var>addr</var>, sets the mirrored value of DR7 Debug Control
|
||||
register as appropriate for the <var>len</var> and <var>type</var> parameters,
|
||||
and then passes the new values of the debug register and DR7 to the
|
||||
inferior by calling <code>I386_DR_LOW_SET_ADDR</code> and
|
||||
<code>I386_DR_LOW_SET_CONTROL</code>. If more than one debug register is
|
||||
required to cover the given region, the above process is repeated for
|
||||
each debug register.
|
||||
|
||||
<p><code>i386_remove_watchpoint</code> does the opposite: it resets the address
|
||||
in the mirrored value of the debug register and its read/write and
|
||||
length bits in the mirrored value of DR7, then passes these new
|
||||
values to the inferior via <code>I386_DR_LOW_RESET_ADDR</code> and
|
||||
<code>I386_DR_LOW_SET_CONTROL</code>. If a register is shared by several
|
||||
watchpoints, each time a <code>i386_remove_watchpoint</code> is called, it
|
||||
decrements the reference count, and only calls
|
||||
<code>I386_DR_LOW_RESET_ADDR</code> and <code>I386_DR_LOW_SET_CONTROL</code> when
|
||||
the count goes to zero.
|
||||
|
||||
<p><a name="index-i386_005finsert_005fhw_005fbreakpoint-51"></a><a name="index-i386_005fremove_005fhw_005fbreakpoint-52"></a><br><dt><code>i386_insert_hw_breakpoint (</code><var>bp_tgt</var><code>)</code><dt><code>i386_remove_hw_breakpoint (</code><var>bp_tgt</var><code>)</code><dd>These functions insert and remove hardware-assisted breakpoints. The
|
||||
macros <code>target_insert_hw_breakpoint</code> and
|
||||
<code>target_remove_hw_breakpoint</code> are set to call these functions.
|
||||
The argument is a <code>struct bp_target_info *</code>, as described in
|
||||
the documentation for <code>target_insert_breakpoint</code>.
|
||||
These functions work like <code>i386_insert_watchpoint</code> and
|
||||
<code>i386_remove_watchpoint</code>, respectively, except that they set up
|
||||
the debug registers to watch instruction execution, and each
|
||||
hardware-assisted breakpoint always requires exactly one debug
|
||||
register.
|
||||
|
||||
<p><a name="index-i386_005fcleanup_005fdregs-53"></a><br><dt><code>i386_cleanup_dregs (void)</code><dd>This function clears all the reference counts, addresses, and control
|
||||
bits in the mirror images of the debug registers. It doesn't affect
|
||||
the actual debug registers in the inferior process.
|
||||
</dl>
|
||||
|
||||
<p class="noindent"><strong>Notes:</strong>
|
||||
<ol type=1 start=1>
|
||||
<li>x86 processors support setting watchpoints on I/O reads or writes.
|
||||
However, since no target supports this (as of March 2001), and since
|
||||
<code>enum target_hw_bp_type</code> doesn't even have an enumeration for I/O
|
||||
watchpoints, this feature is not yet available to <span class="sc">gdb</span> running
|
||||
on x86.
|
||||
|
||||
<li>x86 processors can enable watchpoints locally, for the current task
|
||||
only, or globally, for all the tasks. For each debug register,
|
||||
there's a bit in the DR7 Debug Control register that determines
|
||||
whether the associated address is watched locally or globally. The
|
||||
current implementation of x86 watchpoint support in <span class="sc">gdb</span>
|
||||
always sets watchpoints to be locally enabled, since global
|
||||
watchpoints might interfere with the underlying OS and are probably
|
||||
unavailable in many platforms.
|
||||
</ol>
|
||||
|
||||
<h3 class="section">3.9 Checkpoints</h3>
|
||||
|
||||
<p><a name="index-checkpoints-54"></a><a name="index-restart-55"></a>In the abstract, a checkpoint is a point in the execution history of
|
||||
the program, which the user may wish to return to at some later time.
|
||||
|
||||
<p>Internally, a checkpoint is a saved copy of the program state, including
|
||||
whatever information is required in order to restore the program to that
|
||||
state at a later time. This can be expected to include the state of
|
||||
registers and memory, and may include external state such as the state
|
||||
of open files and devices.
|
||||
|
||||
<p>There are a number of ways in which checkpoints may be implemented
|
||||
in gdb, e.g. as corefiles, as forked processes, and as some opaque
|
||||
method implemented on the target side.
|
||||
|
||||
<p>A corefile can be used to save an image of target memory and register
|
||||
state, which can in principle be restored later — but corefiles do
|
||||
not typically include information about external entities such as
|
||||
open files. Currently this method is not implemented in gdb.
|
||||
|
||||
<p>A forked process can save the state of user memory and registers,
|
||||
as well as some subset of external (kernel) state. This method
|
||||
is used to implement checkpoints on Linux, and in principle might
|
||||
be used on other systems.
|
||||
|
||||
<p>Some targets, e.g. simulators, might have their own built-in
|
||||
method for saving checkpoints, and gdb might be able to take
|
||||
advantage of that capability without necessarily knowing any
|
||||
details of how it is done.
|
||||
|
||||
<h3 class="section">3.10 Observing changes in <span class="sc">gdb</span> internals</h3>
|
||||
|
||||
<p><a name="index-observer-pattern-interface-56"></a><a name="index-notifications-about-changes-in-internals-57"></a>
|
||||
In order to function properly, several modules need to be notified when
|
||||
some changes occur in the <span class="sc">gdb</span> internals. Traditionally, these
|
||||
modules have relied on several paradigms, the most common ones being
|
||||
hooks and gdb-events. Unfortunately, none of these paradigms was
|
||||
versatile enough to become the standard notification mechanism in
|
||||
<span class="sc">gdb</span>. The fact that they only supported one “client” was also
|
||||
a strong limitation.
|
||||
|
||||
<p>A new paradigm, based on the Observer pattern of the <cite>Design
|
||||
Patterns</cite> book, has therefore been implemented. The goal was to provide
|
||||
a new interface overcoming the issues with the notification mechanisms
|
||||
previously available. This new interface needed to be strongly typed,
|
||||
easy to extend, and versatile enough to be used as the standard
|
||||
interface when adding new notifications.
|
||||
|
||||
<p>See <a href="GDB-Observers.html#GDB-Observers">GDB Observers</a> for a brief description of the observers
|
||||
currently implemented in GDB. The rationale for the current
|
||||
implementation is also briefly discussed.
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,133 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>All About Stack Frames - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="up" href="Frame-Interpretation.html#Frame-Interpretation" title="Frame Interpretation">
|
||||
<link rel="next" href="Frame-Handling-Terminology.html#Frame-Handling-Terminology" title="Frame Handling Terminology">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="All-About-Stack-Frames"></a>
|
||||
Next: <a rel="next" accesskey="n" href="Frame-Handling-Terminology.html#Frame-Handling-Terminology">Frame Handling Terminology</a>,
|
||||
Up: <a rel="up" accesskey="u" href="Frame-Interpretation.html#Frame-Interpretation">Frame Interpretation</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h4 class="subsection">11.7.1 All About Stack Frames</h4>
|
||||
|
||||
<p><span class="sc">gdb</span> needs to understand the stack on which local (automatic)
|
||||
variables are stored. The area of the stack containing all the local
|
||||
variables for a function invocation is known as the <dfn>stack frame</dfn>
|
||||
for that function (or colloquially just as the <dfn>frame</dfn>). In turn the
|
||||
function that called the function will have its stack frame, and so on
|
||||
back through the chain of functions that have been called.
|
||||
|
||||
<p>Almost all architectures have one register dedicated to point to the
|
||||
end of the stack (the <dfn>stack pointer</dfn>). Many have a second register
|
||||
which points to the start of the currently active stack frame (the
|
||||
<dfn>frame pointer</dfn>). The specific arrangements for an architecture are
|
||||
a key part of the ABI.
|
||||
|
||||
<p>A diagram helps to explain this. Here is a simple program to compute
|
||||
factorials:
|
||||
|
||||
<pre class="smallexample"> #include <stdio.h>
|
||||
int fact (int n)
|
||||
{
|
||||
if (0 == n)
|
||||
{
|
||||
return 1;
|
||||
}
|
||||
else
|
||||
{
|
||||
return n * fact (n - 1);
|
||||
}
|
||||
}
|
||||
|
||||
main ()
|
||||
{
|
||||
int i;
|
||||
|
||||
for (i = 0; i < 10; i++)
|
||||
{
|
||||
int f = fact (i);
|
||||
printf ("%d! = %d\n", i, f);
|
||||
}
|
||||
}
|
||||
</pre>
|
||||
<p>Consider the state of the stack when the code reaches line 6 after the
|
||||
main program has called <code>fact <!-- /@w -->(3)</code>. The chain of function
|
||||
calls will be <code>main ()</code>, <code>fact <!-- /@w -->(3)</code>, <code>fact <!-- /@w -->(2)</code>, <code>fact (1)<!-- /@w --></code> and <code>fact <!-- /@w -->(0)</code>.
|
||||
|
||||
<p>In this illustration the stack is falling (as used for example by the
|
||||
OpenRISC 1000 ABI). The stack pointer (SP) is at the end of the stack
|
||||
(lowest address) and the frame pointer (FP) is at the highest address
|
||||
in the current stack frame. The following diagram shows how the stack
|
||||
looks.
|
||||
|
||||
<div align="center"><img src="stack_frame.png" alt="stack_frame.png"></div>
|
||||
|
||||
<p>In each stack frame, offset 0 from the stack pointer is the frame
|
||||
pointer of the previous frame and offset 4 (this is illustrating a
|
||||
32-bit architecture) from the stack pointer is the return address.
|
||||
Local variables are indexed from the frame pointer, with negative
|
||||
indexes. In the function <code>fact</code>, offset -4 from the frame
|
||||
pointer is the argument <var>n</var>. In the <code>main</code> function, offset
|
||||
-4 from the frame pointer is the local variable <var>i</var> and offset -8
|
||||
from the frame pointer is the local variable <var>f</var><a rel="footnote" href="#fn-1" name="fnd-1"><sup>1</sup></a>.
|
||||
|
||||
<p>It is very easy to get confused when examining stacks. <span class="sc">gdb</span>
|
||||
has terminology it uses rigorously throughout. The stack frame of the
|
||||
function currently executing, or where execution stopped is numbered
|
||||
zero. In this example frame #0 is the stack frame of the call to
|
||||
<code>fact <!-- /@w -->(0)</code>. The stack frame of its calling function
|
||||
(<code>fact <!-- /@w -->(1)</code> in this case) is numbered #1 and so on back
|
||||
through the chain of calls.
|
||||
|
||||
<p>The main <span class="sc">gdb</span> data structure describing frames is
|
||||
<code>struct frame_info<!-- /@w --></code>. It is not used directly, but only via
|
||||
its accessor functions. <code>frame_info</code> includes information about
|
||||
the registers in the frame and a pointer to the code of the function
|
||||
with which the frame is associated. The entire stack is represented as
|
||||
a linked list of <code>frame_info</code> structs.
|
||||
|
||||
<div class="footnote">
|
||||
<hr>
|
||||
<h4>Footnotes</h4><p class="footnote"><small>[<a name="fn-1" href="#fnd-1">1</a>]</small> This is
|
||||
a simplified example for illustrative purposes only. Good optimizing
|
||||
compilers would not put anything on the stack for such simple
|
||||
functions. Indeed they might eliminate the recursion and use of the
|
||||
stack entirely!</p>
|
||||
|
||||
<hr></div>
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,169 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>Analyzing Stacks---Frame Sniffers - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="up" href="Frame-Interpretation.html#Frame-Interpretation" title="Frame Interpretation">
|
||||
<link rel="prev" href="Functions-to-Access-Frame-Data.html#Functions-to-Access-Frame-Data" title="Functions to Access Frame Data">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Analyzing-Stacks---Frame-Sniffers"></a>
|
||||
<a name="Analyzing-Stacks_002d_002d_002dFrame-Sniffers"></a>
|
||||
Previous: <a rel="previous" accesskey="p" href="Functions-to-Access-Frame-Data.html#Functions-to-Access-Frame-Data">Functions to Access Frame Data</a>,
|
||||
Up: <a rel="up" accesskey="u" href="Frame-Interpretation.html#Frame-Interpretation">Frame Interpretation</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h4 class="subsection">11.7.6 Analyzing Stacks—Frame Sniffers</h4>
|
||||
|
||||
<p>When a program stops, <span class="sc">gdb</span> needs to construct the chain of
|
||||
struct <code>frame_info</code> representing the state of the stack using
|
||||
appropriate <dfn>sniffers</dfn>.
|
||||
|
||||
<p>Each architecture requires appropriate sniffers, but they do not form
|
||||
entries in <code>struct gdbarch<!-- /@w --></code>, since more than one sniffer may
|
||||
be required and a sniffer may be suitable for more than one
|
||||
<code>struct gdbarch<!-- /@w --></code>. Instead sniffers are associated with
|
||||
architectures using the following functions.
|
||||
|
||||
<ul>
|
||||
<li><a name="index-frame_005funwind_005fappend_005fsniffer-348"></a><code>frame_unwind_append_sniffer</code> is used to add a new sniffer to
|
||||
analyze THIS frame when given a pointer to the NEXT frame.
|
||||
|
||||
<li><a name="index-frame_005fbase_005fappend_005fsniffer-349"></a><code>frame_base_append_sniffer</code> is used to add a new sniffer
|
||||
which can determine information about the base of a stack frame.
|
||||
|
||||
<li><a name="index-frame_005fbase_005fset_005fdefault-350"></a><code>frame_base_set_default</code> is used to specify the default base
|
||||
sniffer.
|
||||
|
||||
</ul>
|
||||
|
||||
<p>These functions all take a reference to <code>struct gdbarch<!-- /@w --></code>, so
|
||||
they are associated with a specific architecture. They are usually
|
||||
called in the <code>gdbarch</code> initialization function, after the
|
||||
<code>gdbarch</code> struct has been set up. Unless a default has been set, the
|
||||
most recently appended sniffer will be tried first.
|
||||
|
||||
<p>The main frame unwinding sniffer (as set by
|
||||
<code>frame_unwind_append_sniffer)</code> returns a structure specifying
|
||||
a set of sniffing functions:
|
||||
|
||||
<p><a name="index-g_t_0040code_007bframe_005funwind_007d-351"></a>
|
||||
<pre class="smallexample"> struct frame_unwind
|
||||
{
|
||||
enum frame_type type;
|
||||
frame_this_id_ftype *this_id;
|
||||
frame_prev_register_ftype *prev_register;
|
||||
const struct frame_data *unwind_data;
|
||||
frame_sniffer_ftype *sniffer;
|
||||
frame_prev_pc_ftype *prev_pc;
|
||||
frame_dealloc_cache_ftype *dealloc_cache;
|
||||
};
|
||||
</pre>
|
||||
<p>The <code>type</code> field indicates the type of frame this sniffer can
|
||||
handle: normal, dummy (see <a href="Functions-Creating-Dummy-Frames.html#Functions-Creating-Dummy-Frames">Functions Creating Dummy Frames</a>), signal handler or sentinel. Signal
|
||||
handlers sometimes have their own simplified stack structure for
|
||||
efficiency, so may need their own handlers.
|
||||
|
||||
<p>The <code>unwind_data</code> field holds additional information which may be
|
||||
relevant to particular types of frame. For example it may hold
|
||||
additional information for signal handler frames.
|
||||
|
||||
<p>The remaining fields define functions that yield different types of
|
||||
information when given a pointer to the NEXT stack frame. Not all
|
||||
functions need be provided. If an entry is <code>NULL</code>, the next sniffer will
|
||||
be tried instead.
|
||||
|
||||
<ul>
|
||||
<li><code>this_id</code> determines the stack pointer and function (code
|
||||
entry point) for THIS stack frame.
|
||||
|
||||
<li><code>prev_register</code> determines where the values of registers for
|
||||
the PREVIOUS stack frame are stored in THIS stack frame.
|
||||
|
||||
<li><code>sniffer</code> takes a look at THIS frame's registers to
|
||||
determine if this is the appropriate unwinder.
|
||||
|
||||
<li><code>prev_pc</code> determines the program counter for THIS
|
||||
frame. Only needed if the program counter is not an ordinary register
|
||||
(see <a href="Register-Architecture-Functions-_0026-Variables.html#Register-Architecture-Functions-_0026-Variables">Functions and Variables Specifying the Register Architecture</a>).
|
||||
|
||||
<li><code>dealloc_cache</code> frees any additional memory associated with
|
||||
the prologue cache for this frame (see <a href="Prologue-Caches.html#Prologue-Caches">Prologue Caches</a>).
|
||||
|
||||
</ul>
|
||||
|
||||
<p>In general it is only the <code>this_id</code> and <code>prev_register</code>
|
||||
fields that need be defined for custom sniffers.
|
||||
|
||||
<p>The frame base sniffer is much simpler. It is a <code>struct frame_base<!-- /@w --></code>, which refers to the corresponding <code>frame_unwind</code>
|
||||
struct and whose fields refer to functions yielding various addresses
|
||||
within the frame.
|
||||
|
||||
<p><a name="index-g_t_0040code_007bframe_005fbase_007d-352"></a>
|
||||
<pre class="smallexample"> struct frame_base
|
||||
{
|
||||
const struct frame_unwind *unwind;
|
||||
frame_this_base_ftype *this_base;
|
||||
frame_this_locals_ftype *this_locals;
|
||||
frame_this_args_ftype *this_args;
|
||||
};
|
||||
</pre>
|
||||
<p>All the functions referred to take a pointer to the NEXT frame as
|
||||
argument. The function referred to by <code>this_base</code> returns the
|
||||
base address of THIS frame, the function referred to by
|
||||
<code>this_locals</code> returns the base address of local variables in THIS
|
||||
frame and the function referred to by <code>this_args</code> returns the
|
||||
base address of the function arguments in this frame.
|
||||
|
||||
<p>As described above, the base address of a frame is the address
|
||||
immediately before the start of the NEXT frame. For a falling
|
||||
stack, this is the lowest address in the frame and for a rising stack
|
||||
it is the highest address in the frame. For most architectures the
|
||||
same address is also the base address for local variables and
|
||||
arguments, in which case the same function can be used for all three
|
||||
entries<a rel="footnote" href="#fn-1" name="fnd-1"><sup>1</sup></a>.
|
||||
|
||||
<div class="footnote">
|
||||
<hr>
|
||||
<h4>Footnotes</h4><p class="footnote"><small>[<a name="fn-1" href="#fnd-1">1</a>]</small> It is worth noting that if it cannot be determined in any
|
||||
other way (for example by there being a register with the name
|
||||
<code>"fp"</code>), then the result of the <code>this_base</code> function will be
|
||||
used as the value of the frame pointer variable <kbd>$fp</kbd> in
|
||||
<span class="sc">gdb</span>. This is very often not correct (for example with the
|
||||
OpenRISC 1000, this value is the stack pointer, <kbd>$sp</kbd>). In this
|
||||
case a register (raw or pseudo) with the name <code>"fp"</code> should be
|
||||
defined. It will be used in preference as the value of <kbd>$fp</kbd>.</p>
|
||||
|
||||
<hr></div>
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,306 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>Coding Standards - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="prev" href="Support-Libraries.html#Support-Libraries" title="Support Libraries">
|
||||
<link rel="next" href="Misc-Guidelines.html#Misc-Guidelines" title="Misc Guidelines">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Coding-Standards"></a>
|
||||
Next: <a rel="next" accesskey="n" href="Misc-Guidelines.html#Misc-Guidelines">Misc Guidelines</a>,
|
||||
Previous: <a rel="previous" accesskey="p" href="Support-Libraries.html#Support-Libraries">Support Libraries</a>,
|
||||
Up: <a rel="up" accesskey="u" href="index.html#Top">Top</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h2 class="chapter">16 Coding Standards</h2>
|
||||
|
||||
<p><a name="index-coding-standards-454"></a>
|
||||
|
||||
<h3 class="section">16.1 <span class="sc">gdb</span> C Coding Standards</h3>
|
||||
|
||||
<p><span class="sc">gdb</span> follows the GNU coding standards, as described in
|
||||
<samp><span class="file">etc/standards.texi</span></samp>. This file is also available for anonymous
|
||||
FTP from GNU archive sites. <span class="sc">gdb</span> takes a strict interpretation
|
||||
of the standard; in general, when the GNU standard recommends a practice
|
||||
but does not require it, <span class="sc">gdb</span> requires it.
|
||||
|
||||
<p><span class="sc">gdb</span> follows an additional set of coding standards specific to
|
||||
<span class="sc">gdb</span>, as described in the following sections.
|
||||
|
||||
<h4 class="subsection">16.1.1 ISO C</h4>
|
||||
|
||||
<p><span class="sc">gdb</span> assumes an ISO/IEC 9899:1990 (a.k.a. ISO C90) compliant
|
||||
compiler.
|
||||
|
||||
<p><span class="sc">gdb</span> does not assume an ISO C or POSIX compliant C library.
|
||||
|
||||
<h4 class="subsection">16.1.2 Formatting</h4>
|
||||
|
||||
<p><a name="index-source-code-formatting-455"></a>The standard GNU recommendations for formatting must be followed
|
||||
strictly. Any <span class="sc">gdb</span>-specific deviation from GNU
|
||||
recomendations is described below.
|
||||
|
||||
<p>A function declaration should not have its name in column zero. A
|
||||
function definition should have its name in column zero.
|
||||
|
||||
<pre class="smallexample"> /* Declaration */
|
||||
static void foo (void);
|
||||
/* Definition */
|
||||
void
|
||||
foo (void)
|
||||
{
|
||||
}
|
||||
</pre>
|
||||
<p><em>Pragmatics: This simplifies scripting. Function definitions can
|
||||
be found using ‘</em><samp><span class="samp">^function-name</span></samp><em>’.</em>
|
||||
|
||||
<p>There must be a space between a function or macro name and the opening
|
||||
parenthesis of its argument list (except for macro definitions, as
|
||||
required by C). There must not be a space after an open paren/bracket
|
||||
or before a close paren/bracket.
|
||||
|
||||
<p>While additional whitespace is generally helpful for reading, do not use
|
||||
more than one blank line to separate blocks, and avoid adding whitespace
|
||||
after the end of a program line (as of 1/99, some 600 lines had
|
||||
whitespace after the semicolon). Excess whitespace causes difficulties
|
||||
for <code>diff</code> and <code>patch</code> utilities.
|
||||
|
||||
<p>Pointers are declared using the traditional K&R C style:
|
||||
|
||||
<pre class="smallexample"> void *foo;
|
||||
</pre>
|
||||
<p class="noindent">and not:
|
||||
|
||||
<pre class="smallexample"> void * foo;
|
||||
void* foo;
|
||||
</pre>
|
||||
<p>In addition, whitespace around casts and unary operators should follow
|
||||
the following guidelines:
|
||||
|
||||
<p><table summary=""><tr align="left"><td valign="top" width="20%">Use... </td><td valign="top" width="20%">...instead of </td><td valign="top" width="80%">
|
||||
|
||||
<p><br></td></tr><tr align="left"><td valign="top" width="20%"><code>!x</code>
|
||||
</td><td valign="top" width="20%"><code>! x</code>
|
||||
<br></td></tr><tr align="left"><td valign="top" width="20%"><code>~x</code>
|
||||
</td><td valign="top" width="20%"><code>~ x</code>
|
||||
<br></td></tr><tr align="left"><td valign="top" width="20%"><code>-x</code>
|
||||
</td><td valign="top" width="20%"><code>- x</code>
|
||||
</td><td valign="top" width="80%">(unary minus)
|
||||
<br></td></tr><tr align="left"><td valign="top" width="20%"><code>(foo) x</code>
|
||||
</td><td valign="top" width="20%"><code>(foo)x</code>
|
||||
</td><td valign="top" width="80%">(cast)
|
||||
<br></td></tr><tr align="left"><td valign="top" width="20%"><code>*x</code>
|
||||
</td><td valign="top" width="20%"><code>* x</code>
|
||||
</td><td valign="top" width="80%">(pointer dereference)
|
||||
<br></td></tr></table>
|
||||
|
||||
<p>Any two or more lines in code should be wrapped in braces, even if
|
||||
they are comments, as they look like separate statements:
|
||||
|
||||
<pre class="smallexample"> if (i)
|
||||
{
|
||||
/* Return success. */
|
||||
return 0;
|
||||
}
|
||||
</pre>
|
||||
<p class="noindent">and not:
|
||||
|
||||
<pre class="smallexample"> if (i)
|
||||
/* Return success. */
|
||||
return 0;
|
||||
</pre>
|
||||
<h4 class="subsection">16.1.3 Comments</h4>
|
||||
|
||||
<p><a name="index-comment-formatting-456"></a>The standard GNU requirements on comments must be followed strictly.
|
||||
|
||||
<p>Block comments must appear in the following form, with no <code>/*</code>- or
|
||||
<code>*/</code>-only lines, and no leading <code>*</code>:
|
||||
|
||||
<pre class="smallexample"> /* Wait for control to return from inferior to debugger. If inferior
|
||||
gets a signal, we may decide to start it up again instead of
|
||||
returning. That is why there is a loop in this function. When
|
||||
this function actually returns it means the inferior should be left
|
||||
stopped and <span class="sc">gdb</span> should read more commands. */
|
||||
</pre>
|
||||
<p>(Note that this format is encouraged by Emacs; tabbing for a multi-line
|
||||
comment works correctly, and <kbd>M-q</kbd> fills the block consistently.)
|
||||
|
||||
<p>Put a blank line between the block comments preceding function or
|
||||
variable definitions, and the definition itself.
|
||||
|
||||
<p>In general, put function-body comments on lines by themselves, rather
|
||||
than trying to fit them into the 20 characters left at the end of a
|
||||
line, since either the comment or the code will inevitably get longer
|
||||
than will fit, and then somebody will have to move it anyhow.
|
||||
|
||||
<h4 class="subsection">16.1.4 C Usage</h4>
|
||||
|
||||
<p><a name="index-C-data-types-457"></a>Code must not depend on the sizes of C data types, the format of the
|
||||
host's floating point numbers, the alignment of anything, or the order
|
||||
of evaluation of expressions.
|
||||
|
||||
<p><a name="index-function-usage-458"></a>Use functions freely. There are only a handful of compute-bound areas
|
||||
in <span class="sc">gdb</span> that might be affected by the overhead of a function
|
||||
call, mainly in symbol reading. Most of <span class="sc">gdb</span>'s performance is
|
||||
limited by the target interface (whether serial line or system call).
|
||||
|
||||
<p>However, use functions with moderation. A thousand one-line functions
|
||||
are just as hard to understand as a single thousand-line function.
|
||||
|
||||
<p><em>Macros are bad, M'kay.</em>
|
||||
(But if you have to use a macro, make sure that the macro arguments are
|
||||
protected with parentheses.)
|
||||
|
||||
<p><a name="index-types-459"></a>
|
||||
Declarations like ‘<samp><span class="samp">struct foo *</span></samp>’ should be used in preference to
|
||||
declarations like ‘<samp><span class="samp">typedef struct foo { ... } *foo_ptr</span></samp>’.
|
||||
|
||||
<p>Zero constant (<code>0</code>) is not interchangeable with a null pointer
|
||||
constant (<code>NULL</code>) anywhere. <span class="sc">gcc</span> does not give a warning for
|
||||
such interchange. Specifically:
|
||||
|
||||
<p><table summary=""><tr align="left"><td valign="top" width="20%">incorrect
|
||||
</td><td valign="top" width="50%"><code>if (pointervar) {}</code>
|
||||
<br></td></tr><tr align="left"><td valign="top" width="20%">incorrect
|
||||
</td><td valign="top" width="50%"><code>if (!pointervar) {}</code>
|
||||
<br></td></tr><tr align="left"><td valign="top" width="20%">incorrect
|
||||
</td><td valign="top" width="50%"><code>if (pointervar != 0) {}</code>
|
||||
<br></td></tr><tr align="left"><td valign="top" width="20%">incorrect
|
||||
</td><td valign="top" width="50%"><code>if (pointervar == 0) {}</code>
|
||||
<br></td></tr><tr align="left"><td valign="top" width="20%">correct
|
||||
</td><td valign="top" width="50%"><code>if (pointervar != NULL) {}</code>
|
||||
<br></td></tr><tr align="left"><td valign="top" width="20%">correct
|
||||
</td><td valign="top" width="50%"><code>if (pointervar == NULL) {}</code>
|
||||
<br></td></tr></table>
|
||||
|
||||
<h4 class="subsection">16.1.5 Function Prototypes</h4>
|
||||
|
||||
<p><a name="index-function-prototypes-460"></a>
|
||||
Prototypes must be used when both <em>declaring</em> and <em>defining</em>
|
||||
a function. Prototypes for <span class="sc">gdb</span> functions must include both the
|
||||
argument type and name, with the name matching that used in the actual
|
||||
function definition.
|
||||
|
||||
<p>All external functions should have a declaration in a header file that
|
||||
callers include, that declaration should use the <code>extern</code> modifier.
|
||||
The only exception concerns <code>_initialize_*</code> functions, which must
|
||||
be external so that <samp><span class="file">init.c</span></samp> construction works, but shouldn't be
|
||||
visible to random source files.
|
||||
|
||||
<p>Where a source file needs a forward declaration of a static function,
|
||||
that declaration must appear in a block near the top of the source file.
|
||||
|
||||
<h4 class="subsection">16.1.6 File Names</h4>
|
||||
|
||||
<p>Any file used when building the core of <span class="sc">gdb</span> must be in lower
|
||||
case. Any file used when building the core of <span class="sc">gdb</span> must be 8.3
|
||||
unique. These requirements apply to both source and generated files.
|
||||
|
||||
<p><em>Pragmatics: The core of </em><span class="sc">gdb</span><em> must be buildable on many
|
||||
platforms including DJGPP and MacOS/HFS. Every time an unfriendly file
|
||||
is introduced to the build process both </em><samp><span class="file">Makefile.in</span></samp><em> and
|
||||
</em><samp><span class="file">configure.in</span></samp><em> need to be modified accordingly. Compare the
|
||||
convoluted conversion process needed to transform </em><samp><span class="file">COPYING</span></samp><em> into
|
||||
</em><samp><span class="file">copying.c</span></samp><em> with the conversion needed to transform
|
||||
</em><samp><span class="file">version.in</span></samp><em> into </em><samp><span class="file">version.c</span></samp><em>.</em>
|
||||
|
||||
<p>Any file non 8.3 compliant file (that is not used when building the core
|
||||
of <span class="sc">gdb</span>) must be added to <samp><span class="file">gdb/config/djgpp/fnchange.lst</span></samp>.
|
||||
|
||||
<p><em>Pragmatics: This is clearly a compromise.</em>
|
||||
|
||||
<p>When <span class="sc">gdb</span> has a local version of a system header file (ex
|
||||
<samp><span class="file">string.h</span></samp>) the file name based on the POSIX header prefixed with
|
||||
<samp><span class="file">gdb_</span></samp> (<samp><span class="file">gdb_string.h</span></samp>). These headers should be relatively
|
||||
independent: they should use only macros defined by <samp><span class="file">configure</span></samp>,
|
||||
the compiler, or the host; they should include only system headers; they
|
||||
should refer only to system types. They may be shared between multiple
|
||||
programs, e.g. <span class="sc">gdb</span> and <span class="sc">gdbserver</span>.
|
||||
|
||||
<p>For other files ‘<samp><span class="samp">-</span></samp>’ is used as the separator.
|
||||
|
||||
<h4 class="subsection">16.1.7 Include Files</h4>
|
||||
|
||||
<p>A <samp><span class="file">.c</span></samp> file should include <samp><span class="file">defs.h</span></samp> first.
|
||||
|
||||
<p>A <samp><span class="file">.c</span></samp> file should directly include the <code>.h</code> file of every
|
||||
declaration and/or definition it directly refers to. It cannot rely on
|
||||
indirect inclusion.
|
||||
|
||||
<p>A <samp><span class="file">.h</span></samp> file should directly include the <code>.h</code> file of every
|
||||
declaration and/or definition it directly refers to. It cannot rely on
|
||||
indirect inclusion. Exception: The file <samp><span class="file">defs.h</span></samp> does not need to
|
||||
be directly included.
|
||||
|
||||
<p>An external declaration should only appear in one include file.
|
||||
|
||||
<p>An external declaration should never appear in a <code>.c</code> file.
|
||||
Exception: a declaration for the <code>_initialize</code> function that
|
||||
pacifies <samp><span class="option">-Wmissing-declaration</span></samp>.
|
||||
|
||||
<p>A <code>typedef</code> definition should only appear in one include file.
|
||||
|
||||
<p>An opaque <code>struct</code> declaration can appear in multiple <samp><span class="file">.h</span></samp>
|
||||
files. Where possible, a <samp><span class="file">.h</span></samp> file should use an opaque
|
||||
<code>struct</code> declaration instead of an include.
|
||||
|
||||
<p>All <samp><span class="file">.h</span></samp> files should be wrapped in:
|
||||
|
||||
<pre class="smallexample"> #ifndef INCLUDE_FILE_NAME_H
|
||||
#define INCLUDE_FILE_NAME_H
|
||||
header body
|
||||
#endif
|
||||
</pre>
|
||||
<h3 class="section">16.2 <span class="sc">gdb</span> Python Coding Standards</h3>
|
||||
|
||||
<p><span class="sc">gdb</span> follows the published <code>Python</code> coding standards in
|
||||
<a href="http://www.python.org/dev/peps/pep-0008/"><code>PEP008</code></a>.
|
||||
|
||||
<p>In addition, the guidelines in the
|
||||
<a href="http://google-styleguide.googlecode.com/svn/trunk/pyguide.html">Google Python Style Guide</a> are also followed where they do not
|
||||
conflict with <code>PEP008</code>.
|
||||
|
||||
<h4 class="subsection">16.2.1 <span class="sc">gdb</span>-specific exceptions</h4>
|
||||
|
||||
<p>There are a few exceptions to the published standards.
|
||||
They exist mainly for consistency with the <code>C</code> standards.
|
||||
|
||||
<!-- It is expected that there are a few more exceptions, -->
|
||||
<!-- so we use itemize here. -->
|
||||
<ul>
|
||||
<li>Use <code>FIXME</code> instead of <code>TODO</code>.
|
||||
|
||||
</ul>
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,289 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>Concept Index - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="prev" href="GNU-Free-Documentation-License.html#GNU-Free-Documentation-License" title="GNU Free Documentation License">
|
||||
<link rel="next" href="Function-and-Variable-Index.html#Function-and-Variable-Index" title="Function and Variable Index">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Concept-Index"></a>
|
||||
Next: <a rel="next" accesskey="n" href="Function-and-Variable-Index.html#Function-and-Variable-Index">Function and Variable Index</a>,
|
||||
Previous: <a rel="previous" accesskey="p" href="GNU-Free-Documentation-License.html#GNU-Free-Documentation-License">GNU Free Documentation License</a>,
|
||||
Up: <a rel="up" accesskey="u" href="index.html#Top">Top</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h2 class="unnumbered">Concept Index</h2>
|
||||
|
||||
<ul class="index-cp" compact>
|
||||
<li><a href="Register-Information-Functions.html#index-g_t_0040kbd_007b_0024fp_007d-292"><kbd>$fp</kbd></a>: <a href="Register-Information-Functions.html#Register-Information-Functions">Register Information Functions</a></li>
|
||||
<li><a href="Register-Architecture-Functions-_0026-Variables.html#index-g_t_0040kbd_007b_0024pc_007d-275"><kbd>$pc</kbd></a>: <a href="Register-Architecture-Functions-_0026-Variables.html#Register-Architecture-Functions-_0026-Variables">Register Architecture Functions & Variables</a></li>
|
||||
<li><a href="Register-Architecture-Functions-_0026-Variables.html#index-g_t_0040kbd_007b_0024ps_007d-280"><kbd>$ps</kbd></a>: <a href="Register-Architecture-Functions-_0026-Variables.html#Register-Architecture-Functions-_0026-Variables">Register Architecture Functions & Variables</a></li>
|
||||
<li><a href="Register-Architecture-Functions-_0026-Variables.html#index-g_t_0040kbd_007b_0024sp_007d-271"><kbd>$sp</kbd></a>: <a href="Register-Architecture-Functions-_0026-Variables.html#Register-Architecture-Functions-_0026-Variables">Register Architecture Functions & Variables</a></li>
|
||||
<li><a href="Symbol-Handling.html#index-g_t_0040code_007ba_002eout_007d-format-144"><code>a.out</code> format</a>: <a href="Symbol-Handling.html#Symbol-Handling">Symbol Handling</a></li>
|
||||
<li><a href="Algorithms.html#index-abstract-interpretation-of-function-prologues-10">abstract interpretation of function prologues</a>: <a href="Algorithms.html#Algorithms">Algorithms</a></li>
|
||||
<li><a href="Host-Definition.html#index-adding-a-new-host-173">adding a new host</a>: <a href="Host-Definition.html#Host-Definition">Host Definition</a></li>
|
||||
<li><a href="Symbol-Handling.html#index-adding-a-symbol_002dreading-module-128">adding a symbol-reading module</a>: <a href="Symbol-Handling.html#Symbol-Handling">Symbol Handling</a></li>
|
||||
<li><a href="Adding-a-New-Target.html#index-adding-a-target-430">adding a target</a>: <a href="Adding-a-New-Target.html#Adding-a-New-Target">Adding a New Target</a></li>
|
||||
<li><a href="Symbol-Handling.html#index-adding-debugging-info-reader-158">adding debugging info reader</a>: <a href="Symbol-Handling.html#Symbol-Handling">Symbol Handling</a></li>
|
||||
<li><a href="Language-Support.html#index-adding-source-language-160">adding source language</a>: <a href="Language-Support.html#Language-Support">Language Support</a></li>
|
||||
<li><a href="Address-Classes.html#index-address-classes-254">address classes</a>: <a href="Address-Classes.html#Address-Classes">Address Classes</a></li>
|
||||
<li><a href="Pointers-and-Addresses.html#index-address-representation-240">address representation</a>: <a href="Pointers-and-Addresses.html#Pointers-and-Addresses">Pointers and Addresses</a></li>
|
||||
<li><a href="Pointers-and-Addresses.html#index-address-spaces_002c-separate-data-and-code-244">address spaces, separate data and code</a>: <a href="Pointers-and-Addresses.html#Pointers-and-Addresses">Pointers and Addresses</a></li>
|
||||
<li><a href="Algorithms.html#index-algorithms-5">algorithms</a>: <a href="Algorithms.html#Algorithms">Algorithms</a></li>
|
||||
<li><a href="How-an-Architecture-is-Represented.html#index-g_t_0040file_007b_0040var_007barch_007d_002dtdep_002ec_007d-225"><samp><var>arch</var><span class="file">-tdep.c</span></samp></a>: <a href="How-an-Architecture-is-Represented.html#How-an-Architecture-is-Represented">How an Architecture is Represented</a></li>
|
||||
<li><a href="How-an-Architecture-is-Represented.html#index-architecture-representation-222">architecture representation</a>: <a href="How-an-Architecture-is-Represented.html#How-an-Architecture-is-Represented">How an Architecture is Represented</a></li>
|
||||
<li><a href="Support-Libraries.html#index-Array-Containers-452">Array Containers</a>: <a href="Support-Libraries.html#Support-Libraries">Support Libraries</a></li>
|
||||
<li><a href="Misc-Guidelines.html#index-assumptions-about-targets-475">assumptions about targets</a>: <a href="Misc-Guidelines.html#Misc-Guidelines">Misc Guidelines</a></li>
|
||||
<li><a href="Frame-Handling-Terminology.html#index-base-of-a-frame-322">base of a frame</a>: <a href="Frame-Handling-Terminology.html#Frame-Handling-Terminology">Frame Handling Terminology</a></li>
|
||||
<li><a href="Support-Libraries.html#index-BFD-library-446">BFD library</a>: <a href="Support-Libraries.html#Support-Libraries">Support Libraries</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-breakpoint-address-adjusted-377">breakpoint address adjusted</a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Algorithms.html#index-breakpoints-12">breakpoints</a>: <a href="Algorithms.html#Algorithms">Algorithms</a></li>
|
||||
<li><a href="Getting-Started.html#index-g_t_0040code_007bbug_002dgdb_007d-mailing-list-498"><code>bug-gdb</code> mailing list</a>: <a href="Getting-Started.html#Getting-Started">Getting Started</a></li>
|
||||
<li><a href="Debugging-GDB.html#index-build-script-502">build script</a>: <a href="Debugging-GDB.html#Debugging-GDB">Debugging GDB</a></li>
|
||||
<li><a href="Coding-Standards.html#index-C-data-types-457">C data types</a>: <a href="Coding-Standards.html#Coding-Standards">Coding Standards</a></li>
|
||||
<li><a href="Algorithms.html#index-call-frame-information-7">call frame information</a>: <a href="Algorithms.html#Algorithms">Algorithms</a></li>
|
||||
<li><a href="Stack-Frames.html#index-call-stack-frame-107">call stack frame</a>: <a href="Stack-Frames.html#Stack-Frames">Stack Frames</a></li>
|
||||
<li><a href="Inferior-Call-Setup.html#index-calls-to-the-inferior-353">calls to the inferior</a>: <a href="Inferior-Call-Setup.html#Inferior-Call-Setup">Inferior Call Setup</a></li>
|
||||
<li><a href="Algorithms.html#index-CFI-_0028call-frame-information_0029-8">CFI (call frame information)</a>: <a href="Algorithms.html#Algorithms">Algorithms</a></li>
|
||||
<li><a href="Algorithms.html#index-checkpoints-54">checkpoints</a>: <a href="Algorithms.html#Algorithms">Algorithms</a></li>
|
||||
<li><a href="Misc-Guidelines.html#index-cleanups-461">cleanups</a>: <a href="Misc-Guidelines.html#Misc-Guidelines">Misc Guidelines</a></li>
|
||||
<li><a href="User-Interface.html#index-CLI-59">CLI</a>: <a href="User-Interface.html#User-Interface">User Interface</a></li>
|
||||
<li><a href="Pointers-and-Addresses.html#index-code-pointers_002c-word_002daddressed-245">code pointers, word-addressed</a>: <a href="Pointers-and-Addresses.html#Pointers-and-Addresses">Pointers and Addresses</a></li>
|
||||
<li><a href="Coding-Standards.html#index-coding-standards-454">coding standards</a>: <a href="Coding-Standards.html#Coding-Standards">Coding Standards</a></li>
|
||||
<li><a href="Symbol-Handling.html#index-COFF-debugging-info-152">COFF debugging info</a>: <a href="Symbol-Handling.html#Symbol-Handling">Symbol Handling</a></li>
|
||||
<li><a href="Symbol-Handling.html#index-COFF-format-145">COFF format</a>: <a href="Symbol-Handling.html#Symbol-Handling">Symbol Handling</a></li>
|
||||
<li><a href="Getting-Started.html#index-command-implementation-497">command implementation</a>: <a href="Getting-Started.html#Getting-Started">Getting Started</a></li>
|
||||
<li><a href="User-Interface.html#index-command-interpreter-58">command interpreter</a>: <a href="User-Interface.html#User-Interface">User Interface</a></li>
|
||||
<li><a href="Coding-Standards.html#index-comment-formatting-456">comment formatting</a>: <a href="Coding-Standards.html#Coding-Standards">Coding Standards</a></li>
|
||||
<li><a href="Misc-Guidelines.html#index-compiler-warnings-473">compiler warnings</a>: <a href="Misc-Guidelines.html#Misc-Guidelines">Misc Guidelines</a></li>
|
||||
<li><a href="Symbol-Handling.html#index-Compressed-DWARF-2-debugging-info-155">Compressed DWARF 2 debugging info</a>: <a href="Symbol-Handling.html#Symbol-Handling">Symbol Handling</a></li>
|
||||
<li><a href="Values.html#index-computed-values-105">computed values</a>: <a href="Values.html#Values">Values</a></li>
|
||||
<li><a href="How-an-Architecture-is-Represented.html#index-g_t_0040file_007bconfigure_002etgt_007d-226"><samp><span class="file">configure.tgt</span></samp></a>: <a href="How-an-Architecture-is-Represented.html#How-an-Architecture-is-Represented">How an Architecture is Represented</a></li>
|
||||
<li><a href="Pointers-and-Addresses.html#index-converting-between-pointers-and-addresses-246">converting between pointers and addresses</a>: <a href="Pointers-and-Addresses.html#Pointers-and-Addresses">Pointers and Addresses</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-converting-integers-to-addresses-396">converting integers to addresses</a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Raw-and-Cooked-Registers.html#index-cooked-register-representation-261">cooked register representation</a>: <a href="Raw-and-Cooked-Registers.html#Raw-and-Cooked-Registers">Raw and Cooked Registers</a></li>
|
||||
<li><a href="Adding-support-for-debugging-core-files.html#index-core-files-358">core files</a>: <a href="Adding-support-for-debugging-core-files.html#Adding-support-for-debugging-core-files">Adding support for debugging core files</a></li>
|
||||
<li><a href="Pointers-and-Addresses.html#index-D10V-addresses-247">D10V addresses</a>: <a href="Pointers-and-Addresses.html#Pointers-and-Addresses">Pointers and Addresses</a></li>
|
||||
<li><a href="User-Interface.html#index-data-output-83">data output</a>: <a href="User-Interface.html#User-Interface">User Interface</a></li>
|
||||
<li><a href="Misc-Guidelines.html#index-data_002dpointer_002c-per_002darchitecture_002fper_002dmodule-467">data-pointer, per-architecture/per-module</a>: <a href="Misc-Guidelines.html#Misc-Guidelines">Misc Guidelines</a></li>
|
||||
<li><a href="Debugging-GDB.html#index-debugging-_0040value_007bGDBN_007d-499">debugging <span class="sc">gdb</span></a>: <a href="Debugging-GDB.html#Debugging-GDB">Debugging GDB</a></li>
|
||||
<li><a href="User-Interface.html#index-deprecating-commands-64">deprecating commands</a>: <a href="User-Interface.html#User-Interface">User Interface</a></li>
|
||||
<li><a href="Misc-Guidelines.html#index-design-474">design</a>: <a href="Misc-Guidelines.html#Misc-Guidelines">Misc Guidelines</a></li>
|
||||
<li><a href="Host-Definition.html#index-DOS-text-files-181">DOS text files</a>: <a href="Host-Definition.html#Host-Definition">Host Definition</a></li>
|
||||
<li><a href="About-Dummy-Frames.html#index-dummy-frames-354">dummy frames</a>: <a href="About-Dummy-Frames.html#About-Dummy-Frames">About Dummy Frames</a></li>
|
||||
<li><a href="Address-Classes.html#index-DW_005fAT_005faddress_005fclass-256">DW_AT_address_class</a>: <a href="Address-Classes.html#Address-Classes">Address Classes</a></li>
|
||||
<li><a href="Address-Classes.html#index-DW_005fAT_005fbyte_005fsize-255">DW_AT_byte_size</a>: <a href="Address-Classes.html#Address-Classes">Address Classes</a></li>
|
||||
<li><a href="Symbol-Handling.html#index-DWARF-2-debugging-info-154">DWARF 2 debugging info</a>: <a href="Symbol-Handling.html#Symbol-Handling">Symbol Handling</a></li>
|
||||
<li><a href="Symbol-Handling.html#index-DWARF-3-debugging-info-156">DWARF 3 debugging info</a>: <a href="Symbol-Handling.html#Symbol-Handling">Symbol Handling</a></li>
|
||||
<li><a href="Symbol-Handling.html#index-ECOFF-debugging-info-153">ECOFF debugging info</a>: <a href="Symbol-Handling.html#Symbol-Handling">Symbol Handling</a></li>
|
||||
<li><a href="Symbol-Handling.html#index-ECOFF-format-146">ECOFF format</a>: <a href="Symbol-Handling.html#Symbol-Handling">Symbol Handling</a></li>
|
||||
<li><a href="Symbol-Handling.html#index-ELF-format-149">ELF format</a>: <a href="Symbol-Handling.html#Symbol-Handling">Symbol Handling</a></li>
|
||||
<li><a href="Managing-Execution-State.html#index-execution-state-438">execution state</a>: <a href="Managing-Execution-State.html#Managing-Execution-State">Managing Execution State</a></li>
|
||||
<li><a href="Versions-and-Branches.html#index-experimental-branches-489">experimental branches</a>: <a href="Versions-and-Branches.html#Versions-and-Branches">Versions and Branches</a></li>
|
||||
<li><a href="Language-Support.html#index-expression-evaluation-routines-163">expression evaluation routines</a>: <a href="Language-Support.html#Language-Support">Language Support</a></li>
|
||||
<li><a href="Language-Support.html#index-expression-parser-161">expression parser</a>: <a href="Language-Support.html#Language-Support">Language Support</a></li>
|
||||
<li><a href="User-Interface.html#index-field-output-functions-82">field output functions</a>: <a href="User-Interface.html#User-Interface">User Interface</a></li>
|
||||
<li><a href="Misc-Guidelines.html#index-file-names_002c-portability-479">file names, portability</a>: <a href="Misc-Guidelines.html#Misc-Guidelines">Misc Guidelines</a></li>
|
||||
<li><a href="Symbol-Handling.html#index-finding-a-symbol-136">finding a symbol</a>: <a href="Symbol-Handling.html#Symbol-Handling">Symbol Handling</a></li>
|
||||
<li><a href="OS-ABI-Variant-Handling.html#index-fine_002dtuning-_0040code_007bgdbarch_007d-structure-194">fine-tuning <code>gdbarch</code> structure</a>: <a href="OS-ABI-Variant-Handling.html#OS-ABI-Variant-Handling">OS ABI Variant Handling</a></li>
|
||||
<li><a href="Register-Architecture-Functions-_0026-Variables.html#index-first-floating-point-register-283">first floating point register</a>: <a href="Register-Architecture-Functions-_0026-Variables.html#Register-Architecture-Functions-_0026-Variables">Register Architecture Functions & Variables</a></li>
|
||||
<li><a href="Stack-Frames.html#index-frame-106">frame</a>: <a href="Stack-Frames.html#Stack-Frames">Stack Frames</a></li>
|
||||
<li><a href="Stack-Frames.html#index-frame-ID-116">frame ID</a>: <a href="Stack-Frames.html#Stack-Frames">Stack Frames</a></li>
|
||||
<li><a href="Register-Information-Functions.html#index-frame-pointer-291">frame pointer</a>: <a href="Register-Information-Functions.html#Register-Information-Functions">Register Information Functions</a></li>
|
||||
<li><a href="Frame-Handling-Terminology.html#index-frame_002c-definition-of-base-of-a-frame-324">frame, definition of base of a frame</a>: <a href="Frame-Handling-Terminology.html#Frame-Handling-Terminology">Frame Handling Terminology</a></li>
|
||||
<li><a href="Frame-Handling-Terminology.html#index-frame_002c-definition-of-innermost-frame-321">frame, definition of innermost frame</a>: <a href="Frame-Handling-Terminology.html#Frame-Handling-Terminology">Frame Handling Terminology</a></li>
|
||||
<li><a href="Frame-Handling-Terminology.html#index-frame_002c-definition-of-NEXT-frame-315">frame, definition of NEXT frame</a>: <a href="Frame-Handling-Terminology.html#Frame-Handling-Terminology">Frame Handling Terminology</a></li>
|
||||
<li><a href="Frame-Handling-Terminology.html#index-frame_002c-definition-of-PREVIOUS-frame-318">frame, definition of PREVIOUS frame</a>: <a href="Frame-Handling-Terminology.html#Frame-Handling-Terminology">Frame Handling Terminology</a></li>
|
||||
<li><a href="Frame-Handling-Terminology.html#index-frame_002c-definition-of-sentinel-frame-333">frame, definition of sentinel frame</a>: <a href="Frame-Handling-Terminology.html#Frame-Handling-Terminology">Frame Handling Terminology</a></li>
|
||||
<li><a href="Frame-Handling-Terminology.html#index-frame_002c-definition-of-sniffing-330">frame, definition of sniffing</a>: <a href="Frame-Handling-Terminology.html#Frame-Handling-Terminology">Frame Handling Terminology</a></li>
|
||||
<li><a href="Frame-Handling-Terminology.html#index-frame_002c-definition-of-THIS-frame-312">frame, definition of THIS frame</a>: <a href="Frame-Handling-Terminology.html#Frame-Handling-Terminology">Frame Handling Terminology</a></li>
|
||||
<li><a href="Frame-Handling-Terminology.html#index-frame_002c-definition-of-unwinding-327">frame, definition of unwinding</a>: <a href="Frame-Handling-Terminology.html#Frame-Handling-Terminology">Frame Handling Terminology</a></li>
|
||||
<li><a href="Analyzing-Stacks_002d_002d_002dFrame-Sniffers.html#index-g_t_0040code_007bframe_005fbase_007d-352"><code>frame_base</code></a>: <a href="Analyzing-Stacks_002d_002d_002dFrame-Sniffers.html#Analyzing-Stacks_002d_002d_002dFrame-Sniffers">Analyzing Stacks---Frame Sniffers</a></li>
|
||||
<li><a href="Analyzing-Stacks_002d_002d_002dFrame-Sniffers.html#index-g_t_0040code_007bframe_005funwind_007d-351"><code>frame_unwind</code></a>: <a href="Analyzing-Stacks_002d_002d_002dFrame-Sniffers.html#Analyzing-Stacks_002d_002d_002dFrame-Sniffers">Analyzing Stacks---Frame Sniffers</a></li>
|
||||
<li><a href="Symbol-Handling.html#index-full-symbol-table-130">full symbol table</a>: <a href="Symbol-Handling.html#Symbol-Handling">Symbol Handling</a></li>
|
||||
<li><a href="Prologue-Caches.html#index-function-prologue-334">function prologue</a>: <a href="Prologue-Caches.html#Prologue-Caches">Prologue Caches</a></li>
|
||||
<li><a href="Coding-Standards.html#index-function-prototypes-460">function prototypes</a>: <a href="Coding-Standards.html#Coding-Standards">Coding Standards</a></li>
|
||||
<li><a href="Coding-Standards.html#index-function-usage-458">function usage</a>: <a href="Coding-Standards.html#Coding-Standards">Coding Standards</a></li>
|
||||
<li><a href="Symbol-Handling.html#index-fundamental-types-141">fundamental types</a>: <a href="Symbol-Handling.html#Symbol-Handling">Symbol Handling</a></li>
|
||||
<li><a href="Overall-Structure.html#index-g_t_0040value_007bGDBN_007d-source-tree-structure-4"><span class="sc">gdb</span> source tree structure</a>: <a href="Overall-Structure.html#Overall-Structure">Overall Structure</a></li>
|
||||
<li><a href="Register-Caching.html#index-g_t_0040code_007bgdb_005fbyte_007d-305"><code>gdb_byte</code></a>: <a href="Register-Caching.html#Register-Caching">Register Caching</a></li>
|
||||
<li><a href="How-an-Architecture-is-Represented.html#index-g_t_0040code_007bgdbarch_007d-227"><code>gdbarch</code></a>: <a href="How-an-Architecture-is-Represented.html#How-an-Architecture-is-Represented">How an Architecture is Represented</a></li>
|
||||
<li><a href="Creating-a-New-Architecture.html#index-g_t_0040code_007bgdbarch_007d-accessor-functions-237"><code>gdbarch</code> accessor functions</a>: <a href="Creating-a-New-Architecture.html#Creating-a-New-Architecture">Creating a New Architecture</a></li>
|
||||
<li><a href="Looking-Up-an-Existing-Architecture.html#index-g_t_0040code_007bgdbarch_007d-lookup-229"><code>gdbarch</code> lookup</a>: <a href="Looking-Up-an-Existing-Architecture.html#Looking-Up-an-Existing-Architecture">Looking Up an Existing Architecture</a></li>
|
||||
<li><a href="Register-Architecture-Functions-_0026-Variables.html#index-g_t_0040code_007bgdbarch_007d-register-architecture-functions-263"><code>gdbarch</code> register architecture functions</a>: <a href="Register-Architecture-Functions-_0026-Variables.html#Register-Architecture-Functions-_0026-Variables">Register Architecture Functions & Variables</a></li>
|
||||
<li><a href="Register-Information-Functions.html#index-g_t_0040code_007bgdbarch_007d-register-information-functions-284"><code>gdbarch</code> register information functions</a>: <a href="Register-Information-Functions.html#Register-Information-Functions">Register Information Functions</a></li>
|
||||
<li><a href="Looking-Up-an-Existing-Architecture.html#index-g_t_0040code_007bgdbarch_005finfo_007d-231"><code>gdbarch_info</code></a>: <a href="Looking-Up-an-Existing-Architecture.html#Looking-Up-an-Existing-Architecture">Looking Up an Existing Architecture</a></li>
|
||||
<li><a href="Creating-a-New-Architecture.html#index-g_t_0040code_007bgdbarch_005ftdep_007d-definition-238"><code>gdbarch_tdep</code> definition</a>: <a href="Creating-a-New-Architecture.html#Creating-a-New-Architecture">Creating a New Architecture</a></li>
|
||||
<li><a href="Creating-a-New-Architecture.html#index-g_t_0040code_007bgdbarch_005ftdep_007d-when-allocating-new-_0040code_007bgdbarch_007d-235"><code>gdbarch_tdep</code> when allocating new <code>gdbarch</code></a>: <a href="Creating-a-New-Architecture.html#Creating-a-New-Architecture">Creating a New Architecture</a></li>
|
||||
<li><a href="Host-Definition.html#index-generic-host-support-175">generic host support</a>: <a href="Host-Definition.html#Host-Definition">Host Definition</a></li>
|
||||
<li><a href="Algorithms.html#index-hardware-breakpoints-13">hardware breakpoints</a>: <a href="Algorithms.html#Algorithms">Algorithms</a></li>
|
||||
<li><a href="Algorithms.html#index-hardware-watchpoints-25">hardware watchpoints</a>: <a href="Algorithms.html#Algorithms">Algorithms</a></li>
|
||||
<li><a href="Overall-Structure.html#index-host-2">host</a>: <a href="Overall-Structure.html#Overall-Structure">Overall Structure</a></li>
|
||||
<li><a href="Host-Definition.html#index-host_002c-adding-174">host, adding</a>: <a href="Host-Definition.html#Host-Definition">Host Definition</a></li>
|
||||
<li><a href="Frame-Handling-Terminology.html#index-innermost-frame-319">innermost frame</a>: <a href="Frame-Handling-Terminology.html#Frame-Handling-Terminology">Frame Handling Terminology</a></li>
|
||||
<li><a href="Algorithms.html#index-insert-or-remove-hardware-breakpoint-19">insert or remove hardware breakpoint</a>: <a href="Algorithms.html#Algorithms">Algorithms</a></li>
|
||||
<li><a href="Algorithms.html#index-insert-or-remove-hardware-watchpoint-29">insert or remove hardware watchpoint</a>: <a href="Algorithms.html#Algorithms">Algorithms</a></li>
|
||||
<li><a href="Algorithms.html#index-insert-or-remove-software-breakpoint-16">insert or remove software breakpoint</a>: <a href="Algorithms.html#Algorithms">Algorithms</a></li>
|
||||
<li><a href="User-Interface.html#index-item-output-functions-81">item output functions</a>: <a href="User-Interface.html#User-Interface">User Interface</a></li>
|
||||
<li><a href="Language-Support.html#index-language-parser-162">language parser</a>: <a href="Language-Support.html#Language-Support">Language Support</a></li>
|
||||
<li><a href="Language-Support.html#index-language-support-159">language support</a>: <a href="Language-Support.html#Language-Support">Language Support</a></li>
|
||||
<li><a href="Debugging-GDB.html#index-legal-papers-for-code-contributions-501">legal papers for code contributions</a>: <a href="Debugging-GDB.html#Debugging-GDB">Debugging GDB</a></li>
|
||||
<li><a href="libgdb.html#index-g_t_0040code_007blibgdb_007d-100"><code>libgdb</code></a>: <a href="libgdb.html#libgdb">libgdb</a></li>
|
||||
<li><a href="Support-Libraries.html#index-g_t_0040code_007blibiberty_007d-library-449"><code>libiberty</code> library</a>: <a href="Support-Libraries.html#Support-Libraries">Support Libraries</a></li>
|
||||
<li><a href="Misc-Guidelines.html#index-line-wrap-in-output-471">line wrap in output</a>: <a href="Misc-Guidelines.html#Misc-Guidelines">Misc Guidelines</a></li>
|
||||
<li><a href="User-Interface.html#index-list-output-functions-67">list output functions</a>: <a href="User-Interface.html#User-Interface">User Interface</a></li>
|
||||
<li><a href="Algorithms.html#index-g_t_0040code_007blongjmp_007d-debugging-22"><code>longjmp</code> debugging</a>: <a href="Algorithms.html#Algorithms">Algorithms</a></li>
|
||||
<li><a href="Symbol-Handling.html#index-lookup_005fsymbol-140">lookup_symbol</a>: <a href="Symbol-Handling.html#Symbol-Handling">Symbol Handling</a></li>
|
||||
<li><a href="Values.html#index-g_t_0040code_007blval_005ftype_007d-enumeration_002c-for-values_002e-104"><code>lval_type</code> enumeration, for values.</a>: <a href="Values.html#Values">Values</a></li>
|
||||
<li><a href="Releasing-GDB.html#index-making-a-new-release-of-gdb-491">making a new release of gdb</a>: <a href="Releasing-GDB.html#Releasing-GDB">Releasing GDB</a></li>
|
||||
<li><a href="Register-and-Memory-Data.html#index-memory-representation-294">memory representation</a>: <a href="Register-and-Memory-Data.html#Register-and-Memory-Data">Register and Memory Data</a></li>
|
||||
<li><a href="Symbol-Handling.html#index-minimal-symbol-table-133">minimal symbol table</a>: <a href="Symbol-Handling.html#Symbol-Handling">Symbol Handling</a></li>
|
||||
<li><a href="Symbol-Handling.html#index-minsymtabs-134">minsymtabs</a>: <a href="Symbol-Handling.html#Symbol-Handling">Symbol Handling</a></li>
|
||||
<li><a href="Misc-Guidelines.html#index-multi_002darch-data-466">multi-arch data</a>: <a href="Misc-Guidelines.html#Misc-Guidelines">Misc Guidelines</a></li>
|
||||
<li><a href="Native-Debugging.html#index-native-conditionals-442">native conditionals</a>: <a href="Native-Debugging.html#Native-Debugging">Native Debugging</a></li>
|
||||
<li><a href="Native-Debugging.html#index-native-debugging-440">native debugging</a>: <a href="Native-Debugging.html#Native-Debugging">Native Debugging</a></li>
|
||||
<li><a href="User-Interface.html#index-nesting-level-in-_0040code_007bui_005fout_007d-functions-70">nesting level in <code>ui_out</code> functions</a>: <a href="User-Interface.html#User-Interface">User Interface</a></li>
|
||||
<li><a href="Start-of-New-Year-Procedure.html#index-new-year-procedure-490">new year procedure</a>: <a href="Start-of-New-Year-Procedure.html#Start-of-New-Year-Procedure">Start of New Year Procedure</a></li>
|
||||
<li><a href="Frame-Handling-Terminology.html#index-NEXT-frame-313">NEXT frame</a>: <a href="Frame-Handling-Terminology.html#Frame-Handling-Terminology">Frame Handling Terminology</a></li>
|
||||
<li><a href="GDB-Observers.html#index-g_t_0040code_007bnormal_005fstop_007d-observer-504"><code>normal_stop</code> observer</a>: <a href="GDB-Observers.html#GDB-Observers">GDB Observers</a></li>
|
||||
<li><a href="GDB-Observers.html#index-notification-about-inferior-execution-stop-505">notification about inferior execution stop</a>: <a href="GDB-Observers.html#GDB-Observers">GDB Observers</a></li>
|
||||
<li><a href="Algorithms.html#index-notifications-about-changes-in-internals-57">notifications about changes in internals</a>: <a href="Algorithms.html#Algorithms">Algorithms</a></li>
|
||||
<li><a href="Symbol-Handling.html#index-object-file-formats-143">object file formats</a>: <a href="Symbol-Handling.html#Symbol-Handling">Symbol Handling</a></li>
|
||||
<li><a href="Algorithms.html#index-observer-pattern-interface-56">observer pattern interface</a>: <a href="Algorithms.html#Algorithms">Algorithms</a></li>
|
||||
<li><a href="GDB-Observers.html#index-observers-implementation-rationale-503">observers implementation rationale</a>: <a href="GDB-Observers.html#GDB-Observers">GDB Observers</a></li>
|
||||
<li><a href="Support-Libraries.html#index-g_t_0040code_007bobstacks_007d-450"><code>obstacks</code></a>: <a href="Support-Libraries.html#Support-Libraries">Support Libraries</a></li>
|
||||
<li><a href="Support-Libraries.html#index-opcodes-library-447">opcodes library</a>: <a href="Support-Libraries.html#Support-Libraries">Support Libraries</a></li>
|
||||
<li><a href="OS-ABI-Variant-Handling.html#index-OS-ABI-variants-193">OS ABI variants</a>: <a href="OS-ABI-Variant-Handling.html#OS-ABI-Variant-Handling">OS ABI Variant Handling</a></li>
|
||||
<li><a href="Symbol-Handling.html#index-partial-symbol-table-135">partial symbol table</a>: <a href="Symbol-Handling.html#Symbol-Handling">Symbol Handling</a></li>
|
||||
<li><a href="Symbol-Handling.html#index-PE_002dCOFF-format-148">PE-COFF format</a>: <a href="Symbol-Handling.html#Symbol-Handling">Symbol Handling</a></li>
|
||||
<li><a href="Misc-Guidelines.html#index-per_002darchitecture-module-data-465">per-architecture module data</a>: <a href="Misc-Guidelines.html#Misc-Guidelines">Misc Guidelines</a></li>
|
||||
<li><a href="Pointers-and-Addresses.html#index-pointer-representation-239">pointer representation</a>: <a href="Pointers-and-Addresses.html#Pointers-and-Addresses">Pointers and Addresses</a></li>
|
||||
<li><a href="Misc-Guidelines.html#index-portability-476">portability</a>: <a href="Misc-Guidelines.html#Misc-Guidelines">Misc Guidelines</a></li>
|
||||
<li><a href="Misc-Guidelines.html#index-portable-file-name-handling-478">portable file name handling</a>: <a href="Misc-Guidelines.html#Misc-Guidelines">Misc Guidelines</a></li>
|
||||
<li><a href="Porting-GDB.html#index-porting-to-new-machines-486">porting to new machines</a>: <a href="Porting-GDB.html#Porting-GDB">Porting GDB</a></li>
|
||||
<li><a href="Frame-Handling-Terminology.html#index-PREVIOUS-frame-316">PREVIOUS frame</a>: <a href="Frame-Handling-Terminology.html#Frame-Handling-Terminology">Frame Handling Terminology</a></li>
|
||||
<li><a href="Register-Architecture-Functions-_0026-Variables.html#index-processor-status-register-278">processor status register</a>: <a href="Register-Architecture-Functions-_0026-Variables.html#Register-Architecture-Functions-_0026-Variables">Register Architecture Functions & Variables</a></li>
|
||||
<li><a href="Register-Architecture-Functions-_0026-Variables.html#index-program-counter-274">program counter</a>: <a href="Register-Architecture-Functions-_0026-Variables.html#Register-Architecture-Functions-_0026-Variables">Register Architecture Functions & Variables</a></li>
|
||||
<li><a href="Algorithms.html#index-program-counter-14">program counter</a>: <a href="Algorithms.html#Algorithms">Algorithms</a></li>
|
||||
<li><a href="Algorithms.html#index-prologue-analysis-6">prologue analysis</a>: <a href="Algorithms.html#Algorithms">Algorithms</a></li>
|
||||
<li><a href="Prologue-Caches.html#index-prologue-cache-336">prologue cache</a>: <a href="Prologue-Caches.html#Prologue-Caches">Prologue Caches</a></li>
|
||||
<li><a href="Prologue-Caches.html#index-prologue-of-a-function-335">prologue of a function</a>: <a href="Prologue-Caches.html#Prologue-Caches">Prologue Caches</a></li>
|
||||
<li><a href="Algorithms.html#index-g_t_0040file_007bprologue_002dvalue_002ec_007d-9"><samp><span class="file">prologue-value.c</span></samp></a>: <a href="Algorithms.html#Algorithms">Algorithms</a></li>
|
||||
<li><a href="Host-Definition.html#index-prompt-183">prompt</a>: <a href="Host-Definition.html#Host-Definition">Host Definition</a></li>
|
||||
<li><a href="Algorithms.html#index-pseudo_002devaluation-of-function-prologues-11">pseudo-evaluation of function prologues</a>: <a href="Algorithms.html#Algorithms">Algorithms</a></li>
|
||||
<li><a href="Symbol-Handling.html#index-psymtabs-132">psymtabs</a>: <a href="Symbol-Handling.html#Symbol-Handling">Symbol Handling</a></li>
|
||||
<li><a href="Raw-and-Cooked-Registers.html#index-raw-register-representation-260">raw register representation</a>: <a href="Raw-and-Cooked-Registers.html#Raw-and-Cooked-Registers">Raw and Cooked Registers</a></li>
|
||||
<li><a href="Symbol-Handling.html#index-reading-of-symbols-123">reading of symbols</a>: <a href="Symbol-Handling.html#Symbol-Handling">Symbol Handling</a></li>
|
||||
<li><a href="Support-Libraries.html#index-readline-library-448">readline library</a>: <a href="Support-Libraries.html#Support-Libraries">Support Libraries</a></li>
|
||||
<li><a href="Register-Caching.html#index-register-caching-301">register caching</a>: <a href="Register-Caching.html#Register-Caching">Register Caching</a></li>
|
||||
<li><a href="Register-and-Memory-Data.html#index-register-data-formats_002c-converting-296">register data formats, converting</a>: <a href="Register-and-Memory-Data.html#Register-and-Memory-Data">Register and Memory Data</a></li>
|
||||
<li><a href="Register-and-Memory-Data.html#index-register-representation-293">register representation</a>: <a href="Register-and-Memory-Data.html#Register-and-Memory-Data">Register and Memory Data</a></li>
|
||||
<li><a href="Support-Libraries.html#index-regular-expressions-library-451">regular expressions library</a>: <a href="Support-Libraries.html#Support-Libraries">Support Libraries</a></li>
|
||||
<li><a href="Versions-and-Branches.html#index-Release-Branches-487">Release Branches</a>: <a href="Versions-and-Branches.html#Versions-and-Branches">Versions and Branches</a></li>
|
||||
<li><a href="Host-Definition.html#index-remote-debugging-support-176">remote debugging support</a>: <a href="Host-Definition.html#Host-Definition">Host Definition</a></li>
|
||||
<li><a href="How-an-Architecture-is-Represented.html#index-representation-of-architecture-223">representation of architecture</a>: <a href="How-an-Architecture-is-Represented.html#How-an-Architecture-is-Represented">How an Architecture is Represented</a></li>
|
||||
<li><a href="Raw-and-Cooked-Registers.html#index-representations_002c-raw-and-cooked-registers-262">representations, raw and cooked registers</a>: <a href="Raw-and-Cooked-Registers.html#Raw-and-Cooked-Registers">Raw and Cooked Registers</a></li>
|
||||
<li><a href="Register-and-Memory-Data.html#index-representations_002c-register-and-memory-295">representations, register and memory</a>: <a href="Register-and-Memory-Data.html#Register-and-Memory-Data">Register and Memory Data</a></li>
|
||||
<li><a href="Requirements.html#index-requirements-for-_0040value_007bGDBN_007d-1">requirements for <span class="sc">gdb</span></a>: <a href="Requirements.html#Requirements">Requirements</a></li>
|
||||
<li><a href="Algorithms.html#index-restart-55">restart</a>: <a href="Algorithms.html#Algorithms">Algorithms</a></li>
|
||||
<li><a href="Testsuite.html#index-running-the-test-suite-493">running the test suite</a>: <a href="Testsuite.html#Testsuite">Testsuite</a></li>
|
||||
<li><a href="Symbol-Handling.html#index-secondary-symbol-file-129">secondary symbol file</a>: <a href="Symbol-Handling.html#Symbol-Handling">Symbol Handling</a></li>
|
||||
<li><a href="Frame-Handling-Terminology.html#index-sentinel-frame-331">sentinel frame</a>: <a href="Frame-Handling-Terminology.html#Frame-Handling-Terminology">Frame Handling Terminology</a></li>
|
||||
<li><a href="Stack-Frames.html#index-sentinel-frame-111">sentinel frame</a>: <a href="Stack-Frames.html#Stack-Frames">Stack Frames</a></li>
|
||||
<li><a href="Pointers-and-Addresses.html#index-separate-data-and-code-address-spaces-242">separate data and code address spaces</a>: <a href="Pointers-and-Addresses.html#Pointers-and-Addresses">Pointers and Addresses</a></li>
|
||||
<li><a href="Host-Definition.html#index-serial-line-support-177">serial line support</a>: <a href="Host-Definition.html#Host-Definition">Host Definition</a></li>
|
||||
<li><a href="Creating-a-New-Architecture.html#index-g_t_0040code_007bset_005fgdbarch_007d-functions-236"><code>set_gdbarch</code> functions</a>: <a href="Creating-a-New-Architecture.html#Creating-a-New-Architecture">Creating a New Architecture</a></li>
|
||||
<li><a href="Frame-Handling-Terminology.html#index-sniffing-328">sniffing</a>: <a href="Frame-Handling-Terminology.html#Frame-Handling-Terminology">Frame Handling Terminology</a></li>
|
||||
<li><a href="Algorithms.html#index-software-breakpoints-15">software breakpoints</a>: <a href="Algorithms.html#Algorithms">Algorithms</a></li>
|
||||
<li><a href="Algorithms.html#index-software-watchpoints-26">software watchpoints</a>: <a href="Algorithms.html#Algorithms">Algorithms</a></li>
|
||||
<li><a href="Symbol-Handling.html#index-SOM-debugging-info-157">SOM debugging info</a>: <a href="Symbol-Handling.html#Symbol-Handling">Symbol Handling</a></li>
|
||||
<li><a href="Symbol-Handling.html#index-SOM-format-150">SOM format</a>: <a href="Symbol-Handling.html#Symbol-Handling">Symbol Handling</a></li>
|
||||
<li><a href="Coding-Standards.html#index-source-code-formatting-455">source code formatting</a>: <a href="Coding-Standards.html#Coding-Standards">Coding Standards</a></li>
|
||||
<li><a href="Pointers-and-Addresses.html#index-spaces_002c-separate-data-and-code-address-243">spaces, separate data and code address</a>: <a href="Pointers-and-Addresses.html#Pointers-and-Addresses">Pointers and Addresses</a></li>
|
||||
<li><a href="Symbol-Handling.html#index-stabs-debugging-info-151">stabs debugging info</a>: <a href="Symbol-Handling.html#Symbol-Handling">Symbol Handling</a></li>
|
||||
<li><a href="Frame-Handling-Terminology.html#index-stack-frame_002c-definition-of-base-of-a-frame-323">stack frame, definition of base of a frame</a>: <a href="Frame-Handling-Terminology.html#Frame-Handling-Terminology">Frame Handling Terminology</a></li>
|
||||
<li><a href="Frame-Handling-Terminology.html#index-stack-frame_002c-definition-of-innermost-frame-320">stack frame, definition of innermost frame</a>: <a href="Frame-Handling-Terminology.html#Frame-Handling-Terminology">Frame Handling Terminology</a></li>
|
||||
<li><a href="Frame-Handling-Terminology.html#index-stack-frame_002c-definition-of-NEXT-frame-314">stack frame, definition of NEXT frame</a>: <a href="Frame-Handling-Terminology.html#Frame-Handling-Terminology">Frame Handling Terminology</a></li>
|
||||
<li><a href="Frame-Handling-Terminology.html#index-stack-frame_002c-definition-of-PREVIOUS-frame-317">stack frame, definition of PREVIOUS frame</a>: <a href="Frame-Handling-Terminology.html#Frame-Handling-Terminology">Frame Handling Terminology</a></li>
|
||||
<li><a href="Frame-Handling-Terminology.html#index-stack-frame_002c-definition-of-sentinel-frame-332">stack frame, definition of sentinel frame</a>: <a href="Frame-Handling-Terminology.html#Frame-Handling-Terminology">Frame Handling Terminology</a></li>
|
||||
<li><a href="Frame-Handling-Terminology.html#index-stack-frame_002c-definition-of-sniffing-329">stack frame, definition of sniffing</a>: <a href="Frame-Handling-Terminology.html#Frame-Handling-Terminology">Frame Handling Terminology</a></li>
|
||||
<li><a href="Frame-Handling-Terminology.html#index-stack-frame_002c-definition-of-THIS-frame-311">stack frame, definition of THIS frame</a>: <a href="Frame-Handling-Terminology.html#Frame-Handling-Terminology">Frame Handling Terminology</a></li>
|
||||
<li><a href="Frame-Handling-Terminology.html#index-stack-frame_002c-definition-of-unwinding-326">stack frame, definition of unwinding</a>: <a href="Frame-Handling-Terminology.html#Frame-Handling-Terminology">Frame Handling Terminology</a></li>
|
||||
<li><a href="Register-Architecture-Functions-_0026-Variables.html#index-stack-pointer-270">stack pointer</a>: <a href="Register-Architecture-Functions-_0026-Variables.html#Register-Architecture-Functions-_0026-Variables">Register Architecture Functions & Variables</a></li>
|
||||
<li><a href="Register-Architecture-Functions-_0026-Variables.html#index-status-register-279">status register</a>: <a href="Register-Architecture-Functions-_0026-Variables.html#Register-Architecture-Functions-_0026-Variables">Register Architecture Functions & Variables</a></li>
|
||||
<li><a href="Creating-a-New-Architecture.html#index-g_t_0040code_007bstruct-gdbarch_007d-creation-233"><code>struct gdbarch</code> creation</a>: <a href="Creating-a-New-Architecture.html#Creating-a-New-Architecture">Creating a New Architecture</a></li>
|
||||
<li><a href="Register-Caching.html#index-g_t_0040code_007bstruct-regcache_007d-302"><code>struct regcache</code></a>: <a href="Register-Caching.html#Register-Caching">Register Caching</a></li>
|
||||
<li><a href="Register-and-Memory-Data.html#index-g_t_0040code_007bstruct-value_007d_002c-converting-register-contents-to-297"><code>struct value</code>, converting register contents to</a>: <a href="Register-and-Memory-Data.html#Register-and-Memory-Data">Register and Memory Data</a></li>
|
||||
<li><a href="Debugging-GDB.html#index-submitting-patches-500">submitting patches</a>: <a href="Debugging-GDB.html#Debugging-GDB">Debugging GDB</a></li>
|
||||
<li><a href="Symbol-Handling.html#index-g_t_0040code_007bsym_005ffns_007d-structure-127"><code>sym_fns</code> structure</a>: <a href="Symbol-Handling.html#Symbol-Handling">Symbol Handling</a></li>
|
||||
<li><a href="Symbol-Handling.html#index-symbol-files-124">symbol files</a>: <a href="Symbol-Handling.html#Symbol-Handling">Symbol Handling</a></li>
|
||||
<li><a href="Symbol-Handling.html#index-symbol-lookup-137">symbol lookup</a>: <a href="Symbol-Handling.html#Symbol-Handling">Symbol Handling</a></li>
|
||||
<li><a href="Symbol-Handling.html#index-symbol-reading-122">symbol reading</a>: <a href="Symbol-Handling.html#Symbol-Handling">Symbol Handling</a></li>
|
||||
<li><a href="Symbol-Handling.html#index-symtabs-131">symtabs</a>: <a href="Symbol-Handling.html#Symbol-Handling">Symbol Handling</a></li>
|
||||
<li><a href="Misc-Guidelines.html#index-system-dependencies-477">system dependencies</a>: <a href="Misc-Guidelines.html#Misc-Guidelines">Misc Guidelines</a></li>
|
||||
<li><a href="User-Interface.html#index-table-output-functions-68">table output functions</a>: <a href="User-Interface.html#User-Interface">User Interface</a></li>
|
||||
<li><a href="Overall-Structure.html#index-target-3">target</a>: <a href="Overall-Structure.html#Overall-Structure">Overall Structure</a></li>
|
||||
<li><a href="Target-Architecture-Definition.html#index-target-architecture-definition-192">target architecture definition</a>: <a href="Target-Architecture-Definition.html#Target-Architecture-Definition">Target Architecture Definition</a></li>
|
||||
<li><a href="Adding-a-New-Target.html#index-target-dependent-files-431">target dependent files</a>: <a href="Adding-a-New-Target.html#Adding-a-New-Target">Adding a New Target</a></li>
|
||||
<li><a href="Target-Descriptions.html#index-target-descriptions-434">target descriptions</a>: <a href="Target-Descriptions.html#Target-Descriptions">Target Descriptions</a></li>
|
||||
<li><a href="Adding-Target-Described-Register-Support.html#index-target-descriptions_002c-adding-register-support-436">target descriptions, adding register support</a>: <a href="Adding-Target-Described-Register-Support.html#Adding-Target-Described-Register-Support">Adding Target Described Register Support</a></li>
|
||||
<li><a href="Target-Descriptions-Implementation.html#index-target-descriptions_002c-implementation-435">target descriptions, implementation</a>: <a href="Target-Descriptions-Implementation.html#Target-Descriptions-Implementation">Target Descriptions Implementation</a></li>
|
||||
<li><a href="Target-Vector-Definition.html#index-target-vector-437">target vector</a>: <a href="Target-Vector-Definition.html#Target-Vector-Definition">Target Vector Definition</a></li>
|
||||
<li><a href="Existing-Targets.html#index-targets-439">targets</a>: <a href="Existing-Targets.html#Existing-Targets">Existing Targets</a></li>
|
||||
<li><a href="Host-Definition.html#index-TCP-remote-support-178">TCP remote support</a>: <a href="Host-Definition.html#Host-Definition">Host Definition</a></li>
|
||||
<li><a href="Host-Definition.html#index-terminal-device-185">terminal device</a>: <a href="Host-Definition.html#Host-Definition">Host Definition</a></li>
|
||||
<li><a href="Testsuite.html#index-test-suite-492">test suite</a>: <a href="Testsuite.html#Testsuite">Testsuite</a></li>
|
||||
<li><a href="Testsuite.html#index-test-suite-organization-495">test suite organization</a>: <a href="Testsuite.html#Testsuite">Testsuite</a></li>
|
||||
<li><a href="Testsuite.html#index-Testsuite-Configuration-494">Testsuite Configuration</a>: <a href="Testsuite.html#Testsuite">Testsuite</a></li>
|
||||
<li><a href="Frame-Handling-Terminology.html#index-THIS-frame-310">THIS frame</a>: <a href="Frame-Handling-Terminology.html#Frame-Handling-Terminology">Frame Handling Terminology</a></li>
|
||||
<li><a href="User-Interface.html#index-tuple-output-functions-69">tuple output functions</a>: <a href="User-Interface.html#User-Interface">User Interface</a></li>
|
||||
<li><a href="Symbol-Handling.html#index-type-codes-142">type codes</a>: <a href="Symbol-Handling.html#Symbol-Handling">Symbol Handling</a></li>
|
||||
<li><a href="Coding-Standards.html#index-types-459">types</a>: <a href="Coding-Standards.html#Coding-Standards">Coding Standards</a></li>
|
||||
<li><a href="User-Interface.html#index-g_t_0040code_007bui_005fout_007d-functions-66"><code>ui_out</code> functions</a>: <a href="User-Interface.html#User-Interface">User Interface</a></li>
|
||||
<li><a href="User-Interface.html#index-g_t_0040code_007bui_005fout_007d-functions_002c-usage-examples-99"><code>ui_out</code> functions, usage examples</a>: <a href="User-Interface.html#User-Interface">User Interface</a></li>
|
||||
<li><a href="Stack-Frames.html#index-unwind-frame-108">unwind frame</a>: <a href="Stack-Frames.html#Stack-Frames">Stack Frames</a></li>
|
||||
<li><a href="Frame-Handling-Terminology.html#index-unwinding-325">unwinding</a>: <a href="Frame-Handling-Terminology.html#Frame-Handling-Terminology">Frame Handling Terminology</a></li>
|
||||
<li><a href="User-Interface.html#index-using-_0040code_007bui_005fout_007d-functions-98">using <code>ui_out</code> functions</a>: <a href="User-Interface.html#User-Interface">User Interface</a></li>
|
||||
<li><a href="Values.html#index-g_t_0040code_007bvalue_007d-structure-103"><code>value</code> structure</a>: <a href="Values.html#Values">Values</a></li>
|
||||
<li><a href="Values.html#index-values-102">values</a>: <a href="Values.html#Values">Values</a></li>
|
||||
<li><a href="Support-Libraries.html#index-VEC-453">VEC</a>: <a href="Support-Libraries.html#Support-Libraries">Support Libraries</a></li>
|
||||
<li><a href="Versions-and-Branches.html#index-vendor-branches-488">vendor branches</a>: <a href="Versions-and-Branches.html#Versions-and-Branches">Versions and Branches</a></li>
|
||||
<li><a href="Algorithms.html#index-watchpoints-24">watchpoints</a>: <a href="Algorithms.html#Algorithms">Algorithms</a></li>
|
||||
<li><a href="Algorithms.html#index-watchpoints_002c-on-x86-40">watchpoints, on x86</a>: <a href="Algorithms.html#Algorithms">Algorithms</a></li>
|
||||
<li><a href="Algorithms.html#index-watchpoints_002c-with-threads-38">watchpoints, with threads</a>: <a href="Algorithms.html#Algorithms">Algorithms</a></li>
|
||||
<li><a href="Pointers-and-Addresses.html#index-word_002daddressed-machines-241">word-addressed machines</a>: <a href="Pointers-and-Addresses.html#Pointers-and-Addresses">Pointers and Addresses</a></li>
|
||||
<li><a href="Testsuite.html#index-writing-tests-496">writing tests</a>: <a href="Testsuite.html#Testsuite">Testsuite</a></li>
|
||||
<li><a href="Algorithms.html#index-x86-debug-registers-39">x86 debug registers</a>: <a href="Algorithms.html#Algorithms">Algorithms</a></li>
|
||||
<li><a href="Symbol-Handling.html#index-XCOFF-format-147">XCOFF format</a>: <a href="Symbol-Handling.html#Symbol-Handling">Symbol Handling</a></li>
|
||||
</ul></body></html>
|
||||
|
||||
|
|
@ -0,0 +1,79 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>Contributors - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="up" href="Summary.html#Summary" title="Summary">
|
||||
<link rel="prev" href="Requirements.html#Requirements" title="Requirements">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Contributors"></a>
|
||||
Previous: <a rel="previous" accesskey="p" href="Requirements.html#Requirements">Requirements</a>,
|
||||
Up: <a rel="up" accesskey="u" href="Summary.html#Summary">Summary</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h3 class="section">1.2 Contributors</h3>
|
||||
|
||||
<p>The first edition of this document was written by John Gilmore of
|
||||
Cygnus Solutions. The current second edition was written by Stan Shebs
|
||||
of Cygnus Solutions, who continues to update the manual.
|
||||
|
||||
<p>Over the years, many others have made additions and changes to this
|
||||
document. This section attempts to record the significant contributors
|
||||
to that effort. One of the virtues of free software is that everyone
|
||||
is free to contribute to it; with regret, we cannot actually
|
||||
acknowledge everyone here.
|
||||
|
||||
<blockquote>
|
||||
<em>Plea:</em> This section has only been added relatively recently (four
|
||||
years after publication of the second edition). Additions to this
|
||||
section are particularly welcome. If you or your friends (or enemies,
|
||||
to be evenhanded) have been unfairly omitted from this list, we would
|
||||
like to add your names!
|
||||
</blockquote>
|
||||
|
||||
<p>A document such as this relies on being kept up to date by numerous
|
||||
small updates by contributing engineers as they make changes to the
|
||||
code base. The file <samp><span class="file">ChangeLog</span></samp> in the <span class="sc">gdb</span> distribution
|
||||
approximates a blow-by-blow account. The most prolific contributors to
|
||||
this important, but low profile task are Andrew Cagney (responsible
|
||||
for over half the entries), Daniel Jacobowitz, Mark Kettenis, Jim
|
||||
Blandy and Eli Zaretskii.
|
||||
|
||||
<p>Eli Zaretskii and Daniel Jacobowitz wrote the sections documenting
|
||||
watchpoints.
|
||||
|
||||
<p>Jeremy Bennett updated the sections on initializing a new architecture
|
||||
and register representation, and added the section on Frame Interpretation.
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,87 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>Creating a New Architecture - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="up" href="Initialize-New-Architecture.html#Initialize-New-Architecture" title="Initialize New Architecture">
|
||||
<link rel="prev" href="Looking-Up-an-Existing-Architecture.html#Looking-Up-an-Existing-Architecture" title="Looking Up an Existing Architecture">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Creating-a-New-Architecture"></a>
|
||||
Previous: <a rel="previous" accesskey="p" href="Looking-Up-an-Existing-Architecture.html#Looking-Up-an-Existing-Architecture">Looking Up an Existing Architecture</a>,
|
||||
Up: <a rel="up" accesskey="u" href="Initialize-New-Architecture.html#Initialize-New-Architecture">Initialize New Architecture</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h4 class="subsection">11.2.3 Creating a New Architecture</h4>
|
||||
|
||||
<p><a name="index-g_t_0040code_007bstruct-gdbarch_007d-creation-233"></a>
|
||||
<a name="index-gdbarch_005falloc-234"></a><a name="index-g_t_0040code_007bgdbarch_005ftdep_007d-when-allocating-new-_0040code_007bgdbarch_007d-235"></a>If no architecture is found, then a new architecture must be created,
|
||||
by calling <code>gdbarch_alloc</code> using the supplied <code>struct gdbarch_info<!-- /@w --></code> and any additional custom target specific
|
||||
information in a <code>struct gdbarch_tdep</code>. The prototype for
|
||||
<code>gdbarch_alloc</code> is:
|
||||
|
||||
<pre class="smallexample"> struct gdbarch *gdbarch_alloc (const struct gdbarch_info *<var>info</var>,
|
||||
struct gdbarch_tdep *<var>tdep</var>);
|
||||
</pre>
|
||||
<p><a name="index-g_t_0040code_007bset_005fgdbarch_007d-functions-236"></a><a name="index-g_t_0040code_007bgdbarch_007d-accessor-functions-237"></a>The newly created struct gdbarch must then be populated. Although
|
||||
there are default values, in most cases they are not what is
|
||||
required.
|
||||
|
||||
<p>For each element, <var>X</var>, there is are a pair of corresponding accessor
|
||||
functions, one to set the value of that element,
|
||||
<code>set_gdbarch_</code><var>X</var>, the second to either get the value of an
|
||||
element (if it is a variable) or to apply the element (if it is a
|
||||
function), <code>gdbarch_</code><var>X</var>. Note that both accessor functions
|
||||
take a pointer to the <code>struct gdbarch<!-- /@w --></code> as first
|
||||
argument. Populating the new <code>gdbarch</code> should use the
|
||||
<code>set_gdbarch</code> functions.
|
||||
|
||||
<p>The following sections identify the main elements that should be set
|
||||
in this way. This is not the complete list, but represents the
|
||||
functions and elements that must commonly be specified for a new
|
||||
architecture. Many of the functions and variables are described in the
|
||||
header file <samp><span class="file">gdbarch.h</span></samp>.
|
||||
|
||||
<p>This is the main work in defining a new architecture. Implementing the
|
||||
set of functions to populate the <code>struct gdbarch</code>.
|
||||
|
||||
<p><a name="index-g_t_0040code_007bgdbarch_005ftdep_007d-definition-238"></a><code>struct gdbarch_tdep</code> is not defined within <span class="sc">gdb</span>—it is up
|
||||
to the user to define this struct if it is needed to hold custom target
|
||||
information that is not covered by the standard <code>struct gdbarch<!-- /@w --></code>. For example with the OpenRISC 1000 architecture it is used to
|
||||
hold the number of matchpoints available in the target (along with other
|
||||
information).
|
||||
|
||||
<p>If there is no additional target specific information, it can be set to
|
||||
<code>NULL</code>.
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,156 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>Debugging GDB - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="up" href="Hints.html#Hints" title="Hints">
|
||||
<link rel="prev" href="Getting-Started.html#Getting-Started" title="Getting Started">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Debugging-GDB"></a>
|
||||
Previous: <a rel="previous" accesskey="p" href="Getting-Started.html#Getting-Started">Getting Started</a>,
|
||||
Up: <a rel="up" accesskey="u" href="Hints.html#Hints">Hints</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h3 class="section">23.2 Debugging <span class="sc">gdb</span> with itself</h3>
|
||||
|
||||
<p><a name="index-debugging-_0040value_007bGDBN_007d-499"></a>
|
||||
If <span class="sc">gdb</span> is limping on your machine, this is the preferred way to get it
|
||||
fully functional. Be warned that in some ancient Unix systems, like
|
||||
Ultrix 4.2, a program can't be running in one process while it is being
|
||||
debugged in another. Rather than typing the command <kbd>./gdb ./gdb<!-- /@w --></kbd>, which works on Suns and such, you can copy <samp><span class="file">gdb</span></samp> to
|
||||
<samp><span class="file">gdb2</span></samp> and then type <kbd>./gdb ./gdb2<!-- /@w --></kbd>.
|
||||
|
||||
<p>When you run <span class="sc">gdb</span> in the <span class="sc">gdb</span> source directory, it will read
|
||||
<samp><span class="file">gdb-gdb.gdb</span></samp> file (plus possibly <samp><span class="file">gdb-gdb.py</span></samp> file) that sets up
|
||||
some simple things to make debugging gdb easier. The <code>info</code> command, when
|
||||
executed without a subcommand in a <span class="sc">gdb</span> being debugged by gdb, will pop
|
||||
you back up to the top level gdb. See <samp><span class="file">gdb-gdb.gdb</span></samp> for details.
|
||||
|
||||
<p>If you use emacs, you will probably want to do a <code>make TAGS</code> after
|
||||
you configure your distribution; this will put the machine dependent
|
||||
routines for your local machine where they will be accessed first by
|
||||
<kbd>M-.</kbd>
|
||||
|
||||
<p>Also, make sure that you've either compiled <span class="sc">gdb</span> with your local cc, or
|
||||
have run <code>fixincludes</code> if you are compiling with gcc.
|
||||
|
||||
<h3 class="section">23.3 Submitting Patches</h3>
|
||||
|
||||
<p><a name="index-submitting-patches-500"></a>Thanks for thinking of offering your changes back to the community of
|
||||
<span class="sc">gdb</span> users. In general we like to get well designed enhancements.
|
||||
Thanks also for checking in advance about the best way to transfer the
|
||||
changes.
|
||||
|
||||
<p>The <span class="sc">gdb</span> maintainers will only install “cleanly designed” patches.
|
||||
This manual summarizes what we believe to be clean design for <span class="sc">gdb</span>.
|
||||
|
||||
<p>If the maintainers don't have time to put the patch in when it arrives,
|
||||
or if there is any question about a patch, it goes into a large queue
|
||||
with everyone else's patches and bug reports.
|
||||
|
||||
<p><a name="index-legal-papers-for-code-contributions-501"></a>The legal issue is that to incorporate substantial changes requires a
|
||||
copyright assignment from you and/or your employer, granting ownership
|
||||
of the changes to the Free Software Foundation. You can get the
|
||||
standard documents for doing this by sending mail to <code>gnu@gnu.org</code>
|
||||
and asking for it. We recommend that people write in "All programs
|
||||
owned by the Free Software Foundation" as "NAME OF PROGRAM", so that
|
||||
changes in many programs (not just <span class="sc">gdb</span>, but GAS, Emacs, GCC,
|
||||
etc) can be
|
||||
contributed with only one piece of legalese pushed through the
|
||||
bureaucracy and filed with the FSF. We can't start merging changes until
|
||||
this paperwork is received by the FSF (their rules, which we follow
|
||||
since we maintain it for them).
|
||||
|
||||
<p>Technically, the easiest way to receive changes is to receive each
|
||||
feature as a small context diff or unidiff, suitable for <code>patch</code>.
|
||||
Each message sent to me should include the changes to C code and
|
||||
header files for a single feature, plus <samp><span class="file">ChangeLog</span></samp> entries for
|
||||
each directory where files were modified, and diffs for any changes
|
||||
needed to the manuals (<samp><span class="file">gdb/doc/gdb.texinfo</span></samp> or
|
||||
<samp><span class="file">gdb/doc/gdbint.texinfo</span></samp>). If there are a lot of changes for a
|
||||
single feature, they can be split down into multiple messages.
|
||||
|
||||
<p>In this way, if we read and like the feature, we can add it to the
|
||||
sources with a single patch command, do some testing, and check it in.
|
||||
If you leave out the <samp><span class="file">ChangeLog</span></samp>, we have to write one. If you leave
|
||||
out the doc, we have to puzzle out what needs documenting. Etc., etc.
|
||||
|
||||
<p>The reason to send each change in a separate message is that we will not
|
||||
install some of the changes. They'll be returned to you with questions
|
||||
or comments. If we're doing our job correctly, the message back to you
|
||||
will say what you have to fix in order to make the change acceptable.
|
||||
The reason to have separate messages for separate features is so that
|
||||
the acceptable changes can be installed while one or more changes are
|
||||
being reworked. If multiple features are sent in a single message, we
|
||||
tend to not put in the effort to sort out the acceptable changes from
|
||||
the unacceptable, so none of the features get installed until all are
|
||||
acceptable.
|
||||
|
||||
<p>If this sounds painful or authoritarian, well, it is. But we get a lot
|
||||
of bug reports and a lot of patches, and many of them don't get
|
||||
installed because we don't have the time to finish the job that the bug
|
||||
reporter or the contributor could have done. Patches that arrive
|
||||
complete, working, and well designed, tend to get installed on the day
|
||||
they arrive. The others go into a queue and get installed as time
|
||||
permits, which, since the maintainers have many demands to meet, may not
|
||||
be for quite some time.
|
||||
|
||||
<p>Please send patches directly to
|
||||
<a href="mailto:gdb-patches@sourceware.org">the <span class="sc">gdb</span> maintainers</a>.
|
||||
|
||||
<h3 class="section">23.4 Build Script</h3>
|
||||
|
||||
<p><a name="index-build-script-502"></a>
|
||||
The script <samp><span class="file">gdb_buildall.sh</span></samp> builds <span class="sc">gdb</span> with flag
|
||||
<samp><span class="option">--enable-targets=all</span></samp> set. This builds <span class="sc">gdb</span> with all supported
|
||||
targets activated. This helps testing <span class="sc">gdb</span> when doing changes that
|
||||
affect more than one architecture and is much faster than using
|
||||
<samp><span class="file">gdb_mbuild.sh</span></samp>.
|
||||
|
||||
<p>After building <span class="sc">gdb</span> the script checks which architectures are
|
||||
supported and then switches the current architecture to each of those to get
|
||||
information about the architecture. The test results are stored in log files
|
||||
in the directory the script was called from.
|
||||
|
||||
<!-- *-texinfo-*- -->
|
||||
<!-- This file is part of the GDB manual. -->
|
||||
<!-- Copyright (C) 2003-2013 Free Software Foundation, Inc. -->
|
||||
<!-- See the file gdbint.texinfo for copying conditions. -->
|
||||
<!-- Also, the @deftypefun lines from this file are processed into a -->
|
||||
<!-- header file during the GDB build process. Permission is granted -->
|
||||
<!-- to redistribute and/or modify those lines under the terms of the -->
|
||||
<!-- GNU General Public License as published by the Free Software -->
|
||||
<!-- Foundation; either version 3 of the License, or (at your option) -->
|
||||
<!-- any later version. -->
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,505 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>Defining Other Architecture Features - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="up" href="Target-Architecture-Definition.html#Target-Architecture-Definition" title="Target Architecture Definition">
|
||||
<link rel="prev" href="Adding-support-for-debugging-core-files.html#Adding-support-for-debugging-core-files" title="Adding support for debugging core files">
|
||||
<link rel="next" href="Adding-a-New-Target.html#Adding-a-New-Target" title="Adding a New Target">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Defining-Other-Architecture-Features"></a>
|
||||
Next: <a rel="next" accesskey="n" href="Adding-a-New-Target.html#Adding-a-New-Target">Adding a New Target</a>,
|
||||
Previous: <a rel="previous" accesskey="p" href="Adding-support-for-debugging-core-files.html#Adding-support-for-debugging-core-files">Adding support for debugging core files</a>,
|
||||
Up: <a rel="up" accesskey="u" href="Target-Architecture-Definition.html#Target-Architecture-Definition">Target Architecture Definition</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h3 class="section">11.10 Defining Other Architecture Features</h3>
|
||||
|
||||
<p>This section describes other functions and values in <code>gdbarch</code>,
|
||||
together with some useful macros, that you can use to define the
|
||||
target architecture.
|
||||
|
||||
<dl>
|
||||
<dt><code>CORE_ADDR gdbarch_addr_bits_remove (</code><var>gdbarch</var><code>, </code><var>addr</var><code>)</code><dd><a name="index-gdbarch_005faddr_005fbits_005fremove-359"></a>If a raw machine instruction address includes any bits that are not
|
||||
really part of the address, then this function is used to zero 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. <code>gdbarch_addr_bits_remove</code> would then for
|
||||
example look like that:
|
||||
<pre class="smallexample"> arch_addr_bits_remove (CORE_ADDR addr)
|
||||
{
|
||||
return (addr &= ~0x3);
|
||||
}
|
||||
</pre>
|
||||
<br><dt><code>int address_class_name_to_type_flags (</code><var>gdbarch</var><code>, </code><var>name</var><code>, </code><var>type_flags_ptr</var><code>)</code><dd><a name="index-address_005fclass_005fname_005fto_005ftype_005fflags-360"></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 <a href="Target-Architecture-Definition.html#Target-Architecture-Definition">Address Classes</a>.
|
||||
|
||||
<br><dt><code>int address_class_name_to_type_flags_p (</code><var>gdbarch</var><code>)</code><dd><a name="index-address_005fclass_005fname_005fto_005ftype_005fflags_005fp-361"></a>Predicate which indicates whether <code>address_class_name_to_type_flags</code>
|
||||
has been defined.
|
||||
|
||||
<br><dt><code>int gdbarch_address_class_type_flags (</code><var>gdbarch</var><code>, </code><var>byte_size</var><code>, </code><var>dwarf2_addr_class</var><code>)</code><dd><a name="index-gdbarch_005faddress_005fclass_005ftype_005fflags-362"></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 <span class="sc">gdb</span> 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 <a href="Target-Architecture-Definition.html#Target-Architecture-Definition">Address Classes</a>.
|
||||
|
||||
<br><dt><code>int gdbarch_address_class_type_flags_p (</code><var>gdbarch</var><code>)</code><dd><a name="index-gdbarch_005faddress_005fclass_005ftype_005fflags_005fp-363"></a>Predicate which indicates whether <code>gdbarch_address_class_type_flags_p</code> has
|
||||
been defined.
|
||||
|
||||
<br><dt><code>const char *gdbarch_address_class_type_flags_to_name (</code><var>gdbarch</var><code>, </code><var>type_flags</var><code>)</code><dd><a name="index-gdbarch_005faddress_005fclass_005ftype_005fflags_005fto_005fname-364"></a>Return the name of the address class qualifier associated with the type
|
||||
flags given by <var>type_flags</var>.
|
||||
|
||||
<br><dt><code>int gdbarch_address_class_type_flags_to_name_p (</code><var>gdbarch</var><code>)</code><dd><a name="index-gdbarch_005faddress_005fclass_005ftype_005fflags_005fto_005fname_005fp-365"></a>Predicate which indicates whether <code>gdbarch_address_class_type_flags_to_name</code> has been defined.
|
||||
See <a href="Target-Architecture-Definition.html#Target-Architecture-Definition">Address Classes</a>.
|
||||
|
||||
<br><dt><code>void gdbarch_address_to_pointer (</code><var>gdbarch</var><code>, </code><var>type</var><code>, </code><var>buf</var><code>, </code><var>addr</var><code>)</code><dd><a name="index-gdbarch_005faddress_005fto_005fpointer-366"></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 function may safely assume that <var>type</var> is either a pointer or a
|
||||
C<tt>++</tt> reference type.
|
||||
See <a href="Target-Architecture-Definition.html#Target-Architecture-Definition">Pointers Are Not Always Addresses</a>.
|
||||
|
||||
<br><dt><code>int gdbarch_believe_pcc_promotion (</code><var>gdbarch</var><code>)</code><dd><a name="index-gdbarch_005fbelieve_005fpcc_005fpromotion-367"></a>Used to notify 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.
|
||||
|
||||
<br><dt><code>gdbarch_bits_big_endian (</code><var>gdbarch</var><code>)</code><dd><a name="index-gdbarch_005fbits_005fbig_005fendian-368"></a>This is used if the numbering of bits in the targets does <strong>not</strong> match
|
||||
the endianism 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.
|
||||
|
||||
<br><dt><code>set_gdbarch_bits_big_endian (</code><var>gdbarch</var><code>, </code><var>bits_big_endian</var><code>)</code><dd><a name="index-set_005fgdbarch_005fbits_005fbig_005fendian-369"></a>Calling set_gdbarch_bits_big_endian with a value of 1 indicates that the
|
||||
bits in the target are numbered in a big-endian bit order, 0 indicates
|
||||
little-endian.
|
||||
|
||||
<br><dt><code>BREAKPOINT</code><dd><a name="index-BREAKPOINT-370"></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>gdbarch_breakpoint_from_pc</code>.
|
||||
|
||||
<br><dt><code>BIG_BREAKPOINT</code><dt><code>LITTLE_BREAKPOINT</code><dd><a name="index-LITTLE_005fBREAKPOINT-371"></a><a name="index-BIG_005fBREAKPOINT-372"></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>gdbarch_breakpoint_from_pc</code>.
|
||||
|
||||
<br><dt><code>const gdb_byte *gdbarch_breakpoint_from_pc (</code><var>gdbarch</var><code>, </code><var>pcptr</var><code>, </code><var>lenptr</var><code>)</code><dd><a name="index-gdbarch_005fbreakpoint_005ffrom_005fpc-373"></a><a name="gdbarch_005fbreakpoint_005ffrom_005fpc"></a>Use the program counter to determine the
|
||||
contents and size of a breakpoint instruction. It returns a pointer to
|
||||
a static string of bytes that encode a breakpoint instruction, stores the
|
||||
length of the string to <code>*</code><var>lenptr</var>, and adjusts the program
|
||||
counter (if necessary) to point to the actual memory location where the
|
||||
breakpoint should be inserted. On input, the program counter
|
||||
(<code>*</code><var>pcptr</var> is the encoded inferior's PC register. If software
|
||||
breakpoints are supported, the function sets this argument to the PC's
|
||||
plain address. If software breakpoints are not supported, the function
|
||||
returns NULL instead of the encoded breakpoint instruction.
|
||||
|
||||
<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>Provided breakpoint bytes can be also used by <code>bp_loc_is_permanent</code> to
|
||||
detect permanent breakpoints. <code>gdbarch_breakpoint_from_pc</code> should return
|
||||
an unchanged memory copy if it was called for a location with permanent
|
||||
breakpoint as some architectures use breakpoint instructions containing
|
||||
arbitrary parameter value.
|
||||
|
||||
<p>Replaces all the other <var>BREAKPOINT</var> macros.
|
||||
|
||||
<br><dt><code>int gdbarch_memory_insert_breakpoint (</code><var>gdbarch</var><code>, </code><var>bp_tgt</var><code>)</code><dt><code>gdbarch_memory_remove_breakpoint (</code><var>gdbarch</var><code>, </code><var>bp_tgt</var><code>)</code><dd><a name="index-gdbarch_005fmemory_005fremove_005fbreakpoint-374"></a><a name="index-gdbarch_005fmemory_005finsert_005fbreakpoint-375"></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 set these for most
|
||||
architectures. Architectures which may want to set
|
||||
<code>gdbarch_memory_insert_breakpoint</code> and <code>gdbarch_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>gdbarch_breakpoint_from_pc</code> needs to read the target's memory for some
|
||||
reason.
|
||||
|
||||
<br><dt><code>CORE_ADDR gdbarch_adjust_breakpoint_address (</code><var>gdbarch</var><code>, </code><var>bpaddr</var><code>)</code><dd><a name="index-gdbarch_005fadjust_005fbreakpoint_005faddress-376"></a><a name="index-breakpoint-address-adjusted-377"></a>Given an address at which a breakpoint is desired, return a breakpoint
|
||||
address adjusted to account for architectural constraints on
|
||||
breakpoint placement. This method is not needed by most targets.
|
||||
|
||||
<p>The FR-V target (see <samp><span class="file">frv-tdep.c</span></samp>) requires this method.
|
||||
The FR-V is a VLIW architecture in which a number of RISC-like
|
||||
instructions are grouped (packed) together into an aggregate
|
||||
instruction or instruction bundle. When the processor executes
|
||||
one of these bundles, the component instructions are executed
|
||||
in parallel.
|
||||
|
||||
<p>In the course of optimization, the compiler may group instructions
|
||||
from distinct source statements into the same bundle. The line number
|
||||
information associated with one of the latter statements will likely
|
||||
refer to some instruction other than the first one in the bundle. So,
|
||||
if the user attempts to place a breakpoint on one of these latter
|
||||
statements, <span class="sc">gdb</span> must be careful to <em>not</em> place the break
|
||||
instruction on any instruction other than the first one in the bundle.
|
||||
(Remember though that the instructions within a bundle execute
|
||||
in parallel, so the <em>first</em> instruction is the instruction
|
||||
at the lowest address and has nothing to do with execution order.)
|
||||
|
||||
<p>The FR-V's <code>gdbarch_adjust_breakpoint_address</code> method will adjust a
|
||||
breakpoint's address by scanning backwards for the beginning of
|
||||
the bundle, returning the address of the bundle.
|
||||
|
||||
<p>Since the adjustment of a breakpoint may significantly alter a user's
|
||||
expectation, <span class="sc">gdb</span> prints a warning when an adjusted breakpoint
|
||||
is initially set and each time that that breakpoint is hit.
|
||||
|
||||
<br><dt><code>int gdbarch_call_dummy_location (</code><var>gdbarch</var><code>)</code><dd><a name="index-gdbarch_005fcall_005fdummy_005flocation-378"></a>See the file <samp><span class="file">inferior.h</span></samp>.
|
||||
|
||||
<p>This method has been replaced by <code>gdbarch_push_dummy_code</code>
|
||||
(see <a href="gdbarch_005fpush_005fdummy_005fcode.html#gdbarch_005fpush_005fdummy_005fcode">gdbarch_push_dummy_code</a>).
|
||||
|
||||
<br><dt><code>int gdbarch_cannot_fetch_register (</code><var>gdbarch</var><code>, </code><var>regum</var><code>)</code><dd><a name="index-gdbarch_005fcannot_005ffetch_005fregister-379"></a>This function should return nonzero if <var>regno</var> cannot be fetched
|
||||
from an inferior process.
|
||||
|
||||
<br><dt><code>int gdbarch_cannot_store_register (</code><var>gdbarch</var><code>, </code><var>regnum</var><code>)</code><dd><a name="index-gdbarch_005fcannot_005fstore_005fregister-380"></a>This function should return 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. This function returns 0 as
|
||||
default so that <span class="sc">gdb</span> will assume that all registers may be written.
|
||||
|
||||
<br><dt><code>int gdbarch_convert_register_p (</code><var>gdbarch</var><code>, </code><var>regnum</var><code>, struct type *</code><var>type</var><code>)</code><dd><a name="index-gdbarch_005fconvert_005fregister_005fp-381"></a>Return non-zero if register <var>regnum</var> represents data values of type
|
||||
<var>type</var> in a non-standard form.
|
||||
See <a href="Target-Architecture-Definition.html#Target-Architecture-Definition">Using Different Register and Memory Data Representations</a>.
|
||||
|
||||
<br><dt><code>int gdbarch_fp0_regnum (</code><var>gdbarch</var><code>)</code><dd><a name="index-gdbarch_005ffp0_005fregnum-382"></a>This function returns the number of the first floating point register,
|
||||
if the machine has such registers. Otherwise, it returns -1.
|
||||
|
||||
<br><dt><code>CORE_ADDR gdbarch_decr_pc_after_break (</code><var>gdbarch</var><code>)</code><dd><a name="index-gdbarch_005fdecr_005fpc_005fafter_005fbreak-383"></a>This function shall return 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.
|
||||
|
||||
<br><dt><code>DISABLE_UNSETTABLE_BREAK (</code><var>addr</var><code>)</code><dd><a name="index-DISABLE_005fUNSETTABLE_005fBREAK-384"></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.
|
||||
|
||||
<br><dt><code>int gdbarch_dwarf2_reg_to_regnum (</code><var>gdbarch</var><code>, </code><var>dwarf2_regnr</var><code>)</code><dd><a name="index-gdbarch_005fdwarf2_005freg_005fto_005fregnum-385"></a>Convert DWARF2 register number <var>dwarf2_regnr</var> into <span class="sc">gdb</span> regnum.
|
||||
If not defined, no conversion will be performed.
|
||||
|
||||
<br><dt><code>int gdbarch_ecoff_reg_to_regnum (</code><var>gdbarch</var><code>, </code><var>ecoff_regnr</var><code>)</code><dd><a name="index-gdbarch_005fecoff_005freg_005fto_005fregnum-386"></a>Convert ECOFF register number <var>ecoff_regnr</var> into <span class="sc">gdb</span> regnum. If
|
||||
not defined, no conversion will be performed.
|
||||
|
||||
<br><dt><code>GCC_COMPILED_FLAG_SYMBOL</code><dt><code>GCC2_COMPILED_FLAG_SYMBOL</code><dd><a name="index-GCC2_005fCOMPILED_005fFLAG_005fSYMBOL-387"></a><a name="index-GCC_005fCOMPILED_005fFLAG_005fSYMBOL-388"></a>If defined, these are the names of the symbols that <span class="sc">gdb</span> 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.)
|
||||
|
||||
<br><dt><code>gdbarch_get_longjmp_target</code><dd><a name="index-gdbarch_005fget_005flongjmp_005ftarget-389"></a>This function 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, typically by using a manually-determined
|
||||
offset into the <code>jmp_buf</code>. (While we might like to get the offset
|
||||
from the target's <samp><span class="file">jmpbuf.h</span></samp>, that header file cannot be assumed
|
||||
to be available when building a cross-debugger.)
|
||||
|
||||
<br><dt><code>DEPRECATED_IBM6000_TARGET</code><dd><a name="index-DEPRECATED_005fIBM6000_005fTARGET-390"></a>Shows that we are configured for an IBM RS/6000 system. This
|
||||
conditional should be eliminated (FIXME) and replaced by
|
||||
feature-specific macros. It was introduced in haste and we are
|
||||
repenting at leisure.
|
||||
|
||||
<br><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="Algorithms.html#Algorithms">I386_USE_GENERIC_WATCHPOINTS</a>.
|
||||
|
||||
<br><dt><code>gdbarch_in_function_epilogue_p (</code><var>gdbarch</var><code>, </code><var>addr</var><code>)</code><dd><a name="index-gdbarch_005fin_005ffunction_005fepilogue_005fp-391"></a>Returns non-zero if the given <var>addr</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.
|
||||
|
||||
<br><dt><code>int gdbarch_in_solib_return_trampoline (</code><var>gdbarch</var><code>, </code><var>pc</var><code>, </code><var>name</var><code>)</code><dd><a name="index-gdbarch_005fin_005fsolib_005freturn_005ftrampoline-392"></a>Define this function to return nonzero if the program is stopped in the
|
||||
trampoline that returns from a shared library.
|
||||
|
||||
<br><dt><code>target_so_ops.in_dynsym_resolve_code (</code><var>pc</var><code>)</code><dd><a name="index-in_005fdynsym_005fresolve_005fcode-393"></a>Define this to return nonzero if the program is stopped in the
|
||||
dynamic linker.
|
||||
|
||||
<br><dt><code>SKIP_SOLIB_RESOLVER (</code><var>pc</var><code>)</code><dd><a name="index-SKIP_005fSOLIB_005fRESOLVER-394"></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.
|
||||
|
||||
<br><dt><code>CORE_ADDR gdbarch_integer_to_address (</code><var>gdbarch</var><code>, </code><var>type</var><code>, </code><var>buf</var><code>)</code><dd><a name="index-gdbarch_005finteger_005fto_005faddress-395"></a><a name="index-converting-integers-to-addresses-396"></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 </em><span class="sc">gdb</span><em>'s
|
||||
</em><code>print</code><em> 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, </em><span class="sc">gdb</span><em> 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 </em><span class="sc">gdb</span><em> casts integers
|
||||
to pointers; they are complaining that they can't take an address from a
|
||||
disassembly listing and give it to </em><code>x/i</code><em>. Adding an architecture
|
||||
method like </em><code>gdbarch_integer_to_address</code><em> certainly makes it possible for
|
||||
</em><span class="sc">gdb</span><em> to “get it right” in all circumstances.</em>
|
||||
|
||||
<p>See <a href="Target-Architecture-Definition.html#Target-Architecture-Definition">Pointers Are Not Always Addresses</a>.
|
||||
|
||||
<br><dt><code>CORE_ADDR gdbarch_pointer_to_address (</code><var>gdbarch</var><code>, </code><var>type</var><code>, </code><var>buf</var><code>)</code><dd><a name="index-gdbarch_005fpointer_005fto_005faddress-397"></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 <a href="Target-Architecture-Definition.html#Target-Architecture-Definition">Pointers Are Not Always Addresses</a>.
|
||||
|
||||
<br><dt><code>void gdbarch_register_to_value(</code><var>gdbarch</var><code>, </code><var>frame</var><code>, </code><var>regnum</var><code>, </code><var>type</var><code>, </code><var>fur</var><code>)</code><dd><a name="index-gdbarch_005fregister_005fto_005fvalue-398"></a>Convert the raw contents of register <var>regnum</var> into a value of type
|
||||
<var>type</var>.
|
||||
See <a href="Target-Architecture-Definition.html#Target-Architecture-Definition">Using Different Register and Memory Data Representations</a>.
|
||||
|
||||
<br><dt><code>REGISTER_CONVERT_TO_VIRTUAL(</code><var>reg</var><code>, </code><var>type</var><code>, </code><var>from</var><code>, </code><var>to</var><code>)</code><dd><a name="index-REGISTER_005fCONVERT_005fTO_005fVIRTUAL-399"></a>Convert the value of register <var>reg</var> from its raw form to its virtual
|
||||
form.
|
||||
See <a href="Target-Architecture-Definition.html#Target-Architecture-Definition">Raw and Virtual Register Representations</a>.
|
||||
|
||||
<br><dt><code>REGISTER_CONVERT_TO_RAW(</code><var>type</var><code>, </code><var>reg</var><code>, </code><var>from</var><code>, </code><var>to</var><code>)</code><dd><a name="index-REGISTER_005fCONVERT_005fTO_005fRAW-400"></a>Convert the value of register <var>reg</var> from its virtual form to its raw
|
||||
form.
|
||||
See <a href="Target-Architecture-Definition.html#Target-Architecture-Definition">Raw and Virtual Register Representations</a>.
|
||||
|
||||
<br><dt><code>const struct regset *regset_from_core_section (struct gdbarch * </code><var>gdbarch</var><code>, const char * </code><var>sect_name</var><code>, size_t </code><var>sect_size</var><code>)</code><dd><a name="index-regset_005ffrom_005fcore_005fsection-401"></a>Return the appropriate register set for a core file section with name
|
||||
<var>sect_name</var> and size <var>sect_size</var>.
|
||||
|
||||
<br><dt><code>SOFTWARE_SINGLE_STEP_P()</code><dd><a name="index-SOFTWARE_005fSINGLE_005fSTEP_005fP-402"></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.
|
||||
|
||||
<br><dt><code>SOFTWARE_SINGLE_STEP(</code><var>signal</var><code>, </code><var>insert_breakpoints_p</var><code>)</code><dd><a name="index-SOFTWARE_005fSINGLE_005fSTEP-403"></a>A function that inserts or removes (depending on
|
||||
<var>insert_breakpoints_p</var>) breakpoints at each possible destinations of
|
||||
the next instruction. See <samp><span class="file">sparc-tdep.c</span></samp> and <samp><span class="file">rs6000-tdep.c</span></samp>
|
||||
for examples.
|
||||
|
||||
<br><dt><code>set_gdbarch_sofun_address_maybe_missing (</code><var>gdbarch</var><code>, </code><var>set</var><code>)</code><dd><a name="index-set_005fgdbarch_005fsofun_005faddress_005fmaybe_005fmissing-404"></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>Calling <code>set_gdbarch_sofun_address_maybe_missing</code> with a non-zero
|
||||
argument <var>set</var> 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>In this case, <span class="sc">gdb</span> assumes two things:
|
||||
|
||||
<ul>
|
||||
<li><code>N_FUN</code> stabs have an address of zero. Instead of using those
|
||||
addresses, you should find the address where the function starts by
|
||||
taking the function name from the stab, and then looking that up in the
|
||||
minsyms (the linker/assembler symbol table). In other words, the stab
|
||||
has the name, and the linker/assembler symbol table is the only place
|
||||
that carries the address.
|
||||
|
||||
<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>
|
||||
|
||||
<br><dt><code>int gdbarch_stabs_argument_has_addr (</code><var>gdbarch</var><code>, </code><var>type</var><code>)</code><dd><a name="index-gdbarch_005fstabs_005fargument_005fhas_005faddr-405"></a><a name="gdbarch_005fstabs_005fargument_005fhas_005faddr"></a>Define this function to return
|
||||
nonzero if a function argument of type <var>type</var> is passed by reference
|
||||
instead of value.
|
||||
|
||||
<br><dt><code>CORE_ADDR gdbarch_push_dummy_call (</code><var>gdbarch</var><code>, </code><var>function</var><code>, </code><var>regcache</var><code>, </code><var>bp_addr</var><code>, </code><var>nargs</var><code>, </code><var>args</var><code>, </code><var>sp</var><code>, </code><var>struct_return</var><code>, </code><var>struct_addr</var><code>)</code><dd><a name="index-gdbarch_005fpush_005fdummy_005fcall-406"></a><a name="gdbarch_005fpush_005fdummy_005fcall"></a>Define this to push the dummy frame's call to
|
||||
the inferior function onto the stack. In addition to pushing <var>nargs</var>, the
|
||||
code should push <var>struct_addr</var> (when <var>struct_return</var> is non-zero), and
|
||||
the return address (<var>bp_addr</var>, in inferior's PC register encoding).
|
||||
|
||||
<p><var>function</var> is a pointer to a <code>struct value</code>; on architectures that use
|
||||
function descriptors, this contains the function descriptor value.
|
||||
|
||||
<p>Returns the updated top-of-stack pointer.
|
||||
|
||||
<br><dt><code>CORE_ADDR gdbarch_push_dummy_code (</code><var>gdbarch</var><code>, </code><var>sp</var><code>, </code><var>funaddr</var><code>, </code><var>using_gcc</var><code>, </code><var>args</var><code>, </code><var>nargs</var><code>, </code><var>value_type</var><code>, </code><var>real_pc</var><code>, </code><var>bp_addr</var><code>, </code><var>regcache</var><code>)</code><dd><a name="index-gdbarch_005fpush_005fdummy_005fcode-407"></a><a name="gdbarch_005fpush_005fdummy_005fcode"></a>Given a stack based call dummy, push the
|
||||
instruction sequence (including space for a breakpoint) to which the
|
||||
called function should return.
|
||||
|
||||
<p>Set <var>bp_addr</var> to the address at which the breakpoint instruction
|
||||
should be inserted (in inferior's PC register encoding), <var>real_pc</var> to the
|
||||
resume address when starting the call sequence, and return the updated
|
||||
inner-most stack address.
|
||||
|
||||
<p>By default, the stack is grown sufficient to hold a frame-aligned
|
||||
(see <a href="frame_005falign.html#frame_005falign">frame_align</a>) breakpoint, <var>bp_addr</var> is set to the address
|
||||
reserved for that breakpoint (in inferior's PC register encoding), and
|
||||
<var>real_pc</var> set to <var>funaddr</var>.
|
||||
|
||||
<p>This method replaces <code>gdbarch_call_dummy_location (</code><var>gdbarch</var><code>)</code><!-- /@w -->.
|
||||
|
||||
<br><dt><code>int gdbarch_sdb_reg_to_regnum (</code><var>gdbarch</var><code>, </code><var>sdb_regnr</var><code>)</code><dd><a name="index-gdbarch_005fsdb_005freg_005fto_005fregnum-408"></a>Use this function to convert sdb register <var>sdb_regnr</var> into <span class="sc">gdb</span>
|
||||
regnum. If not defined, no conversion will be done.
|
||||
|
||||
<br><dt><code>enum return_value_convention gdbarch_return_value (struct gdbarch *</code><var>gdbarch</var><code>, struct type *</code><var>valtype</var><code>, struct regcache *</code><var>regcache</var><code>, void *</code><var>readbuf</var><code>, const void *</code><var>writebuf</var><code>)</code><dd><a name="index-gdbarch_005freturn_005fvalue-409"></a><a name="gdbarch_005freturn_005fvalue"></a>Given a function with a return-value of
|
||||
type <var>rettype</var>, return which return-value convention that function
|
||||
would use.
|
||||
|
||||
<p><span class="sc">gdb</span> currently recognizes two function return-value conventions:
|
||||
<code>RETURN_VALUE_REGISTER_CONVENTION</code> where the return value is found
|
||||
in registers; and <code>RETURN_VALUE_STRUCT_CONVENTION</code> where the return
|
||||
value is found in memory and the address of that memory location is
|
||||
passed in as the function's first parameter.
|
||||
|
||||
<p>If the register convention is being used, and <var>writebuf</var> is
|
||||
non-<code>NULL</code>, also copy the return-value in <var>writebuf</var> into
|
||||
<var>regcache</var>.
|
||||
|
||||
<p>If the register convention is being used, and <var>readbuf</var> is
|
||||
non-<code>NULL</code>, also copy the return value from <var>regcache</var> into
|
||||
<var>readbuf</var> (<var>regcache</var> contains a copy of the registers from the
|
||||
just returned function).
|
||||
|
||||
<p><em>Maintainer note: This method replaces separate predicate, extract,
|
||||
store methods. By having only one method, the logic needed to determine
|
||||
the return-value convention need only be implemented in one place. If
|
||||
</em><span class="sc">gdb</span><em> were written in an </em><span class="sc">oo</span><em> language, this method would
|
||||
instead return an object that knew how to perform the register
|
||||
return-value extract and store.</em>
|
||||
|
||||
<p><em>Maintainer note: This method does not take a </em><var>gcc_p</var><em>
|
||||
parameter, and such a parameter should not be added. If an architecture
|
||||
that requires per-compiler or per-function information be identified,
|
||||
then the replacement of </em><var>rettype</var><em> with </em><code>struct value</code>
|
||||
<var>function</var><em> should be pursued.</em>
|
||||
|
||||
<p><em>Maintainer note: The </em><var>regcache</var><em> parameter limits this methods
|
||||
to the inner most frame. While replacing </em><var>regcache</var><em> with a
|
||||
</em><code>struct frame_info</code> <var>frame</var><em> parameter would remove that
|
||||
limitation there has yet to be a demonstrated need for such a change.</em>
|
||||
|
||||
<br><dt><code>void gdbarch_skip_permanent_breakpoint (</code><var>gdbarch</var><code>, </code><var>regcache</var><code>)</code><dd><a name="index-gdbarch_005fskip_005fpermanent_005fbreakpoint-410"></a>Advance the inferior's PC past a permanent breakpoint. <span class="sc">gdb</span> 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>gdbarch_skip_permanent_breakpoint</code> adjusts the
|
||||
processor's state so that execution will resume just after the breakpoint.
|
||||
This function does the right thing even when the breakpoint is in the delay slot
|
||||
of a branch or jump.
|
||||
|
||||
<br><dt><code>CORE_ADDR gdbarch_skip_trampoline_code (</code><var>gdbarch</var><code>, </code><var>frame</var><code>, </code><var>pc</var><code>)</code><dd><a name="index-gdbarch_005fskip_005ftrampoline_005fcode-411"></a>If the target machine has trampoline code that sits between callers and
|
||||
the functions being called, then define this function to return a new PC
|
||||
that is at the start of the real function.
|
||||
|
||||
<br><dt><code>int gdbarch_deprecated_fp_regnum (</code><var>gdbarch</var><code>)</code><dd><a name="index-gdbarch_005fdeprecated_005ffp_005fregnum-412"></a>If the frame pointer is in a register, use this function to return the
|
||||
number of that register.
|
||||
|
||||
<br><dt><code>int gdbarch_stab_reg_to_regnum (</code><var>gdbarch</var><code>, </code><var>stab_regnr</var><code>)</code><dd><a name="index-gdbarch_005fstab_005freg_005fto_005fregnum-413"></a>Use this function to convert stab register <var>stab_regnr</var> into <span class="sc">gdb</span>
|
||||
regnum. If not defined, no conversion will be done.
|
||||
|
||||
<br><dt><code>TARGET_CHAR_BIT</code><dd><a name="index-TARGET_005fCHAR_005fBIT-414"></a>Number of bits in a char; defaults to 8.
|
||||
|
||||
<br><dt><code>int gdbarch_char_signed (</code><var>gdbarch</var><code>)</code><dd><a name="index-gdbarch_005fchar_005fsigned-415"></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.
|
||||
|
||||
<br><dt><code>int gdbarch_double_bit (</code><var>gdbarch</var><code>)</code><dd><a name="index-gdbarch_005fdouble_005fbit-416"></a>Number of bits in a double float; defaults to <code>8 * TARGET_CHAR_BIT</code><!-- /@w -->.
|
||||
|
||||
<br><dt><code>int gdbarch_float_bit (</code><var>gdbarch</var><code>)</code><dd><a name="index-gdbarch_005ffloat_005fbit-417"></a>Number of bits in a float; defaults to <code>4 * TARGET_CHAR_BIT</code><!-- /@w -->.
|
||||
|
||||
<br><dt><code>int gdbarch_int_bit (</code><var>gdbarch</var><code>)</code><dd><a name="index-gdbarch_005fint_005fbit-418"></a>Number of bits in an integer; defaults to <code>4 * TARGET_CHAR_BIT</code><!-- /@w -->.
|
||||
|
||||
<br><dt><code>int gdbarch_long_bit (</code><var>gdbarch</var><code>)</code><dd><a name="index-gdbarch_005flong_005fbit-419"></a>Number of bits in a long integer; defaults to <code>4 * TARGET_CHAR_BIT</code><!-- /@w -->.
|
||||
|
||||
<br><dt><code>int gdbarch_long_double_bit (</code><var>gdbarch</var><code>)</code><dd><a name="index-gdbarch_005flong_005fdouble_005fbit-420"></a>Number of bits in a long double float;
|
||||
defaults to <code>2 * gdbarch_double_bit (</code><var>gdbarch</var><code>)</code><!-- /@w -->.
|
||||
|
||||
<br><dt><code>int gdbarch_long_long_bit (</code><var>gdbarch</var><code>)</code><dd><a name="index-gdbarch_005flong_005flong_005fbit-421"></a>Number of bits in a long long integer; defaults to
|
||||
<code>2 * gdbarch_long_bit (</code><var>gdbarch</var><code>)</code><!-- /@w -->.
|
||||
|
||||
<br><dt><code>int gdbarch_ptr_bit (</code><var>gdbarch</var><code>)</code><dd><a name="index-gdbarch_005fptr_005fbit-422"></a>Number of bits in a pointer; defaults to
|
||||
<code>gdbarch_int_bit (</code><var>gdbarch</var><code>)</code><!-- /@w -->.
|
||||
|
||||
<br><dt><code>int gdbarch_short_bit (</code><var>gdbarch</var><code>)</code><dd><a name="index-gdbarch_005fshort_005fbit-423"></a>Number of bits in a short integer; defaults to <code>2 * TARGET_CHAR_BIT</code><!-- /@w -->.
|
||||
|
||||
<br><dt><code>void gdbarch_virtual_frame_pointer (</code><var>gdbarch</var><code>, </code><var>pc</var><code>, </code><var>frame_regnum</var><code>, </code><var>frame_offset</var><code>)</code><dd><a name="index-gdbarch_005fvirtual_005fframe_005fpointer-424"></a>Returns a <code>(</code><var>register</var><code>, </code><var>offset</var><code>)</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>gdbarch_deprecated_fp_regnum</code> (or <code>gdbarch_sp_regnum</code>, if
|
||||
no frame pointer is defined), with an offset of zero.
|
||||
|
||||
<!-- need to explain virtual frame pointers, they are recorded in agent -->
|
||||
<!-- expressions for tracepoints -->
|
||||
<br><dt><code>TARGET_HAS_HARDWARE_WATCHPOINTS</code><dd>If non-zero, the target has support for hardware-assisted
|
||||
watchpoints. See <a href="Algorithms.html#Algorithms">watchpoints</a>, for more details and
|
||||
other related macros.
|
||||
|
||||
<br><dt><code>int gdbarch_print_insn (</code><var>gdbarch</var><code>, </code><var>vma</var><code>, </code><var>info</var><code>)</code><dd><a name="index-gdbarch_005fprint_005finsn-425"></a>This is the function used by <span class="sc">gdb</span> to print an assembly
|
||||
instruction. It prints the instruction at address <var>vma</var> in
|
||||
debugged memory and returns the length of the instruction, in bytes.
|
||||
This usually points to a function in the <code>opcodes</code> library
|
||||
(see <a href="Support-Libraries.html#Support-Libraries">Opcodes</a>). <var>info</var> is a structure (of
|
||||
type <code>disassemble_info</code>) defined in the header file
|
||||
<samp><span class="file">include/dis-asm.h</span></samp>, and used to pass information to the
|
||||
instruction decoding routine.
|
||||
|
||||
<br><dt><code>frame_id gdbarch_dummy_id (</code><var>gdbarch</var><code>, </code><var>frame</var><code>)</code><dd><a name="index-gdbarch_005fdummy_005fid-426"></a><a name="gdbarch_005fdummy_005fid"></a>Given <var>frame</var> return a <code>struct frame_id</code><!-- /@w --> that uniquely identifies an inferior function call's dummy
|
||||
frame. The value returned must match the dummy frame stack value
|
||||
previously saved by <code>call_function_by_hand</code>.
|
||||
|
||||
<br><dt><code>void gdbarch_value_to_register (</code><var>gdbarch</var><code>, </code><var>frame</var><code>, </code><var>type</var><code>, </code><var>buf</var><code>)</code><dd><a name="index-gdbarch_005fvalue_005fto_005fregister-427"></a>Convert a value of type <var>type</var> into the raw contents of a register.
|
||||
See <a href="Target-Architecture-Definition.html#Target-Architecture-Definition">Using Different Register and Memory Data Representations</a>.
|
||||
|
||||
</dl>
|
||||
|
||||
<p>Motorola M68K target conditionals.
|
||||
|
||||
<dl>
|
||||
<dt><code>BPT_VECTOR</code><a name="index-BPT_005fVECTOR-428"></a><dd>Define this to be the 4-bit location of the breakpoint trap vector. If
|
||||
not defined, it will default to <code>0xf</code>.
|
||||
|
||||
<br><dt><code>REMOTE_BPT_VECTOR</code><a name="index-REMOTE_005fBPT_005fVECTOR-429"></a><dd>Defaults to <code>1</code>.
|
||||
|
||||
</dl>
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,106 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>Existing Targets - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="up" href="Target-Vector-Definition.html#Target-Vector-Definition" title="Target Vector Definition">
|
||||
<link rel="prev" href="Managing-Execution-State.html#Managing-Execution-State" title="Managing Execution State">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Existing-Targets"></a>
|
||||
Previous: <a rel="previous" accesskey="p" href="Managing-Execution-State.html#Managing-Execution-State">Managing Execution State</a>,
|
||||
Up: <a rel="up" accesskey="u" href="Target-Vector-Definition.html#Target-Vector-Definition">Target Vector Definition</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h3 class="section">13.2 Existing Targets</h3>
|
||||
|
||||
<p><a name="index-targets-439"></a>
|
||||
|
||||
<h4 class="subsection">13.2.1 File Targets</h4>
|
||||
|
||||
<p>Both executables and core files have target vectors.
|
||||
|
||||
<h4 class="subsection">13.2.2 Standard Protocol and Remote Stubs</h4>
|
||||
|
||||
<p><span class="sc">gdb</span>'s file <samp><span class="file">remote.c</span></samp> talks a serial protocol to code that
|
||||
runs in the target system. <span class="sc">gdb</span> provides several sample
|
||||
<dfn>stubs</dfn> that can be integrated into target programs or operating
|
||||
systems for this purpose; they are named <samp><var>cpu</var><span class="file">-stub.c</span></samp>. Many
|
||||
operating systems, embedded targets, emulators, and simulators already
|
||||
have a <span class="sc">gdb</span> stub built into them, and maintenance of the remote
|
||||
protocol must be careful to preserve compatibility.
|
||||
|
||||
<p>The <span class="sc">gdb</span> user's manual describes how to put such a stub into
|
||||
your target code. What follows is a discussion of integrating the
|
||||
SPARC stub into a complicated operating system (rather than a simple
|
||||
program), by Stu Grossman, the author of this stub.
|
||||
|
||||
<p>The trap handling code in the stub assumes the following upon entry to
|
||||
<code>trap_low</code>:
|
||||
|
||||
<ol type=1 start=1>
|
||||
<li>%l1 and %l2 contain pc and npc respectively at the time of the trap;
|
||||
|
||||
<li>traps are disabled;
|
||||
|
||||
<li>you are in the correct trap window.
|
||||
</ol>
|
||||
|
||||
<p>As long as your trap handler can guarantee those conditions, then there
|
||||
is no reason why you shouldn't be able to “share” traps with the stub.
|
||||
The stub has no requirement that it be jumped to directly from the
|
||||
hardware trap vector. That is why it calls <code>exceptionHandler()</code>,
|
||||
which is provided by the external environment. For instance, this could
|
||||
set up the hardware traps to actually execute code which calls the stub
|
||||
first, and then transfers to its own trap handler.
|
||||
|
||||
<p>For the most point, there probably won't be much of an issue with
|
||||
“sharing” traps, as the traps we use are usually not used by the kernel,
|
||||
and often indicate unrecoverable error conditions. Anyway, this is all
|
||||
controlled by a table, and is trivial to modify. The most important
|
||||
trap for us is for <code>ta 1</code>. Without that, we can't single step or
|
||||
do breakpoints. Everything else is unnecessary for the proper operation
|
||||
of the debugger/stub.
|
||||
|
||||
<p>From reading the stub, it's probably not obvious how breakpoints work.
|
||||
They are simply done by deposit/examine operations from <span class="sc">gdb</span>.
|
||||
|
||||
<h4 class="subsection">13.2.3 ROM Monitor Interface</h4>
|
||||
|
||||
<h4 class="subsection">13.2.4 Custom Protocols</h4>
|
||||
|
||||
<h4 class="subsection">13.2.5 Transport Layer</h4>
|
||||
|
||||
<h4 class="subsection">13.2.6 Builtin Simulator</h4>
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,101 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>Frame Handling Terminology - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="up" href="Frame-Interpretation.html#Frame-Interpretation" title="Frame Interpretation">
|
||||
<link rel="prev" href="All-About-Stack-Frames.html#All-About-Stack-Frames" title="All About Stack Frames">
|
||||
<link rel="next" href="Prologue-Caches.html#Prologue-Caches" title="Prologue Caches">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Frame-Handling-Terminology"></a>
|
||||
Next: <a rel="next" accesskey="n" href="Prologue-Caches.html#Prologue-Caches">Prologue Caches</a>,
|
||||
Previous: <a rel="previous" accesskey="p" href="All-About-Stack-Frames.html#All-About-Stack-Frames">All About Stack Frames</a>,
|
||||
Up: <a rel="up" accesskey="u" href="Frame-Interpretation.html#Frame-Interpretation">Frame Interpretation</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h4 class="subsection">11.7.2 Frame Handling Terminology</h4>
|
||||
|
||||
<p>It is easy to get confused when referencing stack frames. <span class="sc">gdb</span>
|
||||
uses some precise terminology.
|
||||
|
||||
<ul>
|
||||
<li><a name="index-THIS-frame-310"></a><a name="index-stack-frame_002c-definition-of-THIS-frame-311"></a><a name="index-frame_002c-definition-of-THIS-frame-312"></a><dfn>THIS</dfn> frame is the frame currently under consideration.
|
||||
|
||||
<li><a name="index-NEXT-frame-313"></a><a name="index-stack-frame_002c-definition-of-NEXT-frame-314"></a><a name="index-frame_002c-definition-of-NEXT-frame-315"></a>The <dfn>NEXT</dfn> frame, also sometimes called the inner or newer frame is the
|
||||
frame of the function called by the function of THIS frame.
|
||||
|
||||
<li><a name="index-PREVIOUS-frame-316"></a><a name="index-stack-frame_002c-definition-of-PREVIOUS-frame-317"></a><a name="index-frame_002c-definition-of-PREVIOUS-frame-318"></a>The <dfn>PREVIOUS</dfn> frame, also sometimes called the outer or older frame is
|
||||
the frame of the function which called the function of THIS frame.
|
||||
|
||||
</ul>
|
||||
|
||||
<p>So in the example in the previous section (see <a href="All-About-Stack-Frames.html#All-About-Stack-Frames">All About Stack Frames</a>), if THIS frame is #3 (the call to
|
||||
<code>fact <!-- /@w -->(3)</code>), the NEXT frame is frame #2 (the call to
|
||||
<code>fact <!-- /@w -->(2)</code>) and the PREVIOUS frame is frame #4 (the call to
|
||||
<code>main <!-- /@w -->()</code>).
|
||||
|
||||
<p><a name="index-innermost-frame-319"></a><a name="index-stack-frame_002c-definition-of-innermost-frame-320"></a><a name="index-frame_002c-definition-of-innermost-frame-321"></a>The <dfn>innermost</dfn> frame is the frame of the current executing
|
||||
function, or where the program stopped, in this example, in the middle
|
||||
of the call to <code>fact (0))<!-- /@w --></code>. It is always numbered frame #0.
|
||||
|
||||
<p><a name="index-base-of-a-frame-322"></a><a name="index-stack-frame_002c-definition-of-base-of-a-frame-323"></a><a name="index-frame_002c-definition-of-base-of-a-frame-324"></a>The <dfn>base</dfn> of a frame is the address immediately before the start
|
||||
of the NEXT frame. For a stack which grows down in memory (a
|
||||
<dfn>falling</dfn> stack) this will be the lowest address and for a stack
|
||||
which grows up in memory (a <dfn>rising</dfn> stack) this will be the
|
||||
highest address in the frame.
|
||||
|
||||
<p><span class="sc">gdb</span> functions to analyze the stack are typically given a
|
||||
pointer to the NEXT frame to determine information about THIS
|
||||
frame. Information about THIS frame includes data on where the
|
||||
registers of the PREVIOUS frame are stored in this stack frame. In
|
||||
this example the frame pointer of the PREVIOUS frame is stored at
|
||||
offset 0 from the stack pointer of THIS frame.
|
||||
|
||||
<p><a name="index-unwinding-325"></a><a name="index-stack-frame_002c-definition-of-unwinding-326"></a><a name="index-frame_002c-definition-of-unwinding-327"></a>The process whereby a function is given a pointer to the NEXT
|
||||
frame to work out information about THIS frame is referred to as
|
||||
<dfn>unwinding</dfn>. The <span class="sc">gdb</span> functions involved in this typically
|
||||
include unwind in their name.
|
||||
|
||||
<p><a name="index-sniffing-328"></a><a name="index-stack-frame_002c-definition-of-sniffing-329"></a><a name="index-frame_002c-definition-of-sniffing-330"></a>The process of analyzing a target to determine the information that
|
||||
should go in struct frame_info is called <dfn>sniffing</dfn>. The functions
|
||||
that carry this out are called sniffers and typically include sniffer
|
||||
in their name. More than one sniffer may be required to extract all
|
||||
the information for a particular frame.
|
||||
|
||||
<p><a name="index-sentinel-frame-331"></a><a name="index-stack-frame_002c-definition-of-sentinel-frame-332"></a><a name="index-frame_002c-definition-of-sentinel-frame-333"></a>Because so many functions work using the NEXT frame, there is an issue
|
||||
about addressing the innermost frame—it has no NEXT frame. To solve
|
||||
this <span class="sc">gdb</span> creates a dummy frame #-1, known as the
|
||||
<dfn>sentinel</dfn> frame.
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,58 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>Frame Interpretation - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="up" href="Target-Architecture-Definition.html#Target-Architecture-Definition" title="Target Architecture Definition">
|
||||
<link rel="prev" href="Register-Representation.html#Register-Representation" title="Register Representation">
|
||||
<link rel="next" href="Inferior-Call-Setup.html#Inferior-Call-Setup" title="Inferior Call Setup">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Frame-Interpretation"></a>
|
||||
Next: <a rel="next" accesskey="n" href="Inferior-Call-Setup.html#Inferior-Call-Setup">Inferior Call Setup</a>,
|
||||
Previous: <a rel="previous" accesskey="p" href="Register-Representation.html#Register-Representation">Register Representation</a>,
|
||||
Up: <a rel="up" accesskey="u" href="Target-Architecture-Definition.html#Target-Architecture-Definition">Target Architecture Definition</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h3 class="section">11.7 Frame Interpretation</h3>
|
||||
|
||||
<ul class="menu">
|
||||
<li><a accesskey="1" href="All-About-Stack-Frames.html#All-About-Stack-Frames">All About Stack Frames</a>
|
||||
<li><a accesskey="2" href="Frame-Handling-Terminology.html#Frame-Handling-Terminology">Frame Handling Terminology</a>
|
||||
<li><a accesskey="3" href="Prologue-Caches.html#Prologue-Caches">Prologue Caches</a>
|
||||
<li><a accesskey="4" href="Functions-and-Variable-to-Analyze-Frames.html#Functions-and-Variable-to-Analyze-Frames">Functions and Variable to Analyze Frames</a>
|
||||
<li><a accesskey="5" href="Functions-to-Access-Frame-Data.html#Functions-to-Access-Frame-Data">Functions to Access Frame Data</a>
|
||||
<li><a accesskey="6" href="Analyzing-Stacks_002d_002d_002dFrame-Sniffers.html#Analyzing-Stacks_002d_002d_002dFrame-Sniffers">Analyzing Stacks---Frame Sniffers</a>
|
||||
</ul>
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,342 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>Function and Variable Index - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="prev" href="Concept-Index.html#Concept-Index" title="Concept Index">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Function-and-Variable-Index"></a>
|
||||
Previous: <a rel="previous" accesskey="p" href="Concept-Index.html#Concept-Index">Concept Index</a>,
|
||||
Up: <a rel="up" accesskey="u" href="index.html#Top">Top</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h2 class="unnumbered">Function and Variable Index</h2>
|
||||
|
||||
|
||||
|
||||
<ul class="index-fn" compact>
|
||||
<li><a href="Adding-a-New-Target.html#index-g_t_005finitialize_005f_0040var_007barch_007d_005ftdep-432"><code>_initialize_</code><var>arch</var><code>_tdep</code></a>: <a href="Adding-a-New-Target.html#Adding-a-New-Target">Adding a New Target</a></li>
|
||||
<li><a href="How-an-Architecture-is-Represented.html#index-g_t_005finitialize_005f_0040var_007barch_007d_005ftdep-224"><code>_initialize_</code><var>arch</var><code>_tdep</code></a>: <a href="How-an-Architecture-is-Represented.html#How-an-Architecture-is-Represented">How an Architecture is Represented</a></li>
|
||||
<li><a href="Language-Support.html#index-g_t_005finitialize_005flanguage-168"><code>_initialize_language</code></a>: <a href="Language-Support.html#Language-Support">Language Support</a></li>
|
||||
<li><a href="GDB-Observers.html#index-about_005fto_005fproceed-521"><code>about_to_proceed</code></a>: <a href="GDB-Observers.html#GDB-Observers">GDB Observers</a></li>
|
||||
<li><a href="User-Interface.html#index-add_005fcmd-60"><code>add_cmd</code></a>: <a href="User-Interface.html#User-Interface">User Interface</a></li>
|
||||
<li><a href="User-Interface.html#index-add_005fcom-61"><code>add_com</code></a>: <a href="User-Interface.html#User-Interface">User Interface</a></li>
|
||||
<li><a href="User-Interface.html#index-add_005fsetshow_005fcmd-62"><code>add_setshow_cmd</code></a>: <a href="User-Interface.html#User-Interface">User Interface</a></li>
|
||||
<li><a href="User-Interface.html#index-add_005fsetshow_005fcmd_005ffull-63"><code>add_setshow_cmd_full</code></a>: <a href="User-Interface.html#User-Interface">User Interface</a></li>
|
||||
<li><a href="Symbol-Handling.html#index-add_005fsymtab_005ffns-126"><code>add_symtab_fns</code></a>: <a href="Symbol-Handling.html#Symbol-Handling">Symbol Handling</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-address_005fclass_005fname_005fto_005ftype_005fflags-360"><code>address_class_name_to_type_flags</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-address_005fclass_005fname_005fto_005ftype_005fflags_005fp-361"><code>address_class_name_to_type_flags_p</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Functions-and-Variable-to-Analyze-Frames.html#index-align_005fdown-342"><code>align_down</code></a>: <a href="Functions-and-Variable-to-Analyze-Frames.html#Functions-and-Variable-to-Analyze-Frames">Functions and Variable to Analyze Frames</a></li>
|
||||
<li><a href="Functions-and-Variable-to-Analyze-Frames.html#index-align_005fup-343"><code>align_up</code></a>: <a href="Functions-and-Variable-to-Analyze-Frames.html#Functions-and-Variable-to-Analyze-Frames">Functions and Variable to Analyze Frames</a></li>
|
||||
<li><a href="Language-Support.html#index-allocate_005fsymtab-169"><code>allocate_symtab</code></a>: <a href="Language-Support.html#Language-Support">Language Support</a></li>
|
||||
<li><a href="GDB-Observers.html#index-architecture_005fchanged-526"><code>architecture_changed</code></a>: <a href="GDB-Observers.html#GDB-Observers">GDB Observers</a></li>
|
||||
<li><a href="GDB-Observers.html#index-before_005fprompt-533"><code>before_prompt</code></a>: <a href="GDB-Observers.html#GDB-Observers">GDB Observers</a></li>
|
||||
<li><a href="Looking-Up-an-Existing-Architecture.html#index-bfd_005farch_005finfo-232"><code>bfd_arch_info</code></a>: <a href="Looking-Up-an-Existing-Architecture.html#Looking-Up-an-Existing-Architecture">Looking Up an Existing Architecture</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-BIG_005fBREAKPOINT-372"><code>BIG_BREAKPOINT</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-BPT_005fVECTOR-428"><code>BPT_VECTOR</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-BREAKPOINT-370"><code>BREAKPOINT</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="GDB-Observers.html#index-breakpoint_005fcreated-522"><code>breakpoint_created</code></a>: <a href="GDB-Observers.html#GDB-Observers">GDB Observers</a></li>
|
||||
<li><a href="GDB-Observers.html#index-breakpoint_005fdeleted-523"><code>breakpoint_deleted</code></a>: <a href="GDB-Observers.html#GDB-Observers">GDB Observers</a></li>
|
||||
<li><a href="GDB-Observers.html#index-breakpoint_005fmodified-524"><code>breakpoint_modified</code></a>: <a href="GDB-Observers.html#GDB-Observers">GDB Observers</a></li>
|
||||
<li><a href="GDB-Observers.html#index-command_005fparam_005fchanged-535"><code>command_param_changed</code></a>: <a href="GDB-Observers.html#GDB-Observers">GDB Observers</a></li>
|
||||
<li><a href="Functions-and-Variable-to-Analyze-Frames.html#index-core_005faddr_005fgreaterthan-340"><code>core_addr_greaterthan</code></a>: <a href="Functions-and-Variable-to-Analyze-Frames.html#Functions-and-Variable-to-Analyze-Frames">Functions and Variable to Analyze Frames</a></li>
|
||||
<li><a href="Functions-and-Variable-to-Analyze-Frames.html#index-core_005faddr_005flessthan-339"><code>core_addr_lessthan</code></a>: <a href="Functions-and-Variable-to-Analyze-Frames.html#Functions-and-Variable-to-Analyze-Frames">Functions and Variable to Analyze Frames</a></li>
|
||||
<li><a href="Host-Definition.html#index-CRLF_005fSOURCE_005fFILES-180"><code>CRLF_SOURCE_FILES</code></a>: <a href="Host-Definition.html#Host-Definition">Host Definition</a></li>
|
||||
<li><a href="Language-Support.html#index-current_005flanguage-167"><code>current_language</code></a>: <a href="Language-Support.html#Language-Support">Language Support</a></li>
|
||||
<li><a href="Host-Definition.html#index-DEFAULT_005fPROMPT-182"><code>DEFAULT_PROMPT</code></a>: <a href="Host-Definition.html#Host-Definition">Host Definition</a></li>
|
||||
<li><a href="User-Interface.html#index-deprecate_005fcmd-65"><code>deprecate_cmd</code></a>: <a href="User-Interface.html#User-Interface">User Interface</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-DEPRECATED_005fIBM6000_005fTARGET-390"><code>DEPRECATED_IBM6000_TARGET</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Host-Definition.html#index-DEV_005fTTY-184"><code>DEV_TTY</code></a>: <a href="Host-Definition.html#Host-Definition">Host Definition</a></li>
|
||||
<li><a href="Misc-Guidelines.html#index-DIRNAME_005fSEPARATOR-484"><code>DIRNAME_SEPARATOR</code></a>: <a href="Misc-Guidelines.html#Misc-Guidelines">Misc Guidelines</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-DISABLE_005fUNSETTABLE_005fBREAK-384"><code>DISABLE_UNSETTABLE_BREAK</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Misc-Guidelines.html#index-discard_005fcleanups-464"><code>discard_cleanups</code></a>: <a href="Misc-Guidelines.html#Misc-Guidelines">Misc Guidelines</a></li>
|
||||
<li><a href="Misc-Guidelines.html#index-do_005fcleanups-463"><code>do_cleanups</code></a>: <a href="Misc-Guidelines.html#Misc-Guidelines">Misc Guidelines</a></li>
|
||||
<li><a href="Language-Support.html#index-evaluate_005fsubexp-164"><code>evaluate_subexp</code></a>: <a href="Language-Support.html#Language-Support">Language Support</a></li>
|
||||
<li><a href="GDB-Observers.html#index-executable_005fchanged-511"><code>executable_changed</code></a>: <a href="GDB-Observers.html#GDB-Observers">GDB Observers</a></li>
|
||||
<li><a href="Pointers-and-Addresses.html#index-extract_005ftyped_005faddress-248"><code>extract_typed_address</code></a>: <a href="Pointers-and-Addresses.html#Pointers-and-Addresses">Pointers and Addresses</a></li>
|
||||
<li><a href="Misc-Guidelines.html#index-FILENAME_005fCMP-483"><code>FILENAME_CMP</code></a>: <a href="Misc-Guidelines.html#Misc-Guidelines">Misc Guidelines</a></li>
|
||||
<li><a href="Symbol-Handling.html#index-find_005fpc_005ffunction-138"><code>find_pc_function</code></a>: <a href="Symbol-Handling.html#Symbol-Handling">Symbol Handling</a></li>
|
||||
<li><a href="Symbol-Handling.html#index-find_005fpc_005fline-139"><code>find_pc_line</code></a>: <a href="Symbol-Handling.html#Symbol-Handling">Symbol Handling</a></li>
|
||||
<li><a href="Symbol-Handling.html#index-find_005fsym_005ffns-125"><code>find_sym_fns</code></a>: <a href="Symbol-Handling.html#Symbol-Handling">Symbol Handling</a></li>
|
||||
<li><a href="Host-Definition.html#index-FOPEN_005fRB-187"><code>FOPEN_RB</code></a>: <a href="Host-Definition.html#Host-Definition">Host Definition</a></li>
|
||||
<li><a href="Register-Architecture-Functions-_0026-Variables.html#index-fp0_005fregnum-281"><code>fp0_regnum</code></a>: <a href="Register-Architecture-Functions-_0026-Variables.html#Register-Architecture-Functions-_0026-Variables">Register Architecture Functions & Variables</a></li>
|
||||
<li><a href="Functions-and-Variable-to-Analyze-Frames.html#index-frame_005falign-341"><code>frame_align</code></a>: <a href="Functions-and-Variable-to-Analyze-Frames.html#Functions-and-Variable-to-Analyze-Frames">Functions and Variable to Analyze Frames</a></li>
|
||||
<li><a href="Analyzing-Stacks_002d_002d_002dFrame-Sniffers.html#index-frame_005fbase_005fappend_005fsniffer-349"><code>frame_base_append_sniffer</code></a>: <a href="Analyzing-Stacks_002d_002d_002dFrame-Sniffers.html#Analyzing-Stacks_002d_002d_002dFrame-Sniffers">Analyzing Stacks---Frame Sniffers</a></li>
|
||||
<li><a href="Analyzing-Stacks_002d_002d_002dFrame-Sniffers.html#index-frame_005fbase_005fset_005fdefault-350"><code>frame_base_set_default</code></a>: <a href="Analyzing-Stacks_002d_002d_002dFrame-Sniffers.html#Analyzing-Stacks_002d_002d_002dFrame-Sniffers">Analyzing Stacks---Frame Sniffers</a></li>
|
||||
<li><a href="Functions-to-Access-Frame-Data.html#index-frame_005fnum_005fargs-347"><code>frame_num_args</code></a>: <a href="Functions-to-Access-Frame-Data.html#Functions-to-Access-Frame-Data">Functions to Access Frame Data</a></li>
|
||||
<li><a href="Functions-and-Variable-to-Analyze-Frames.html#index-frame_005fred_005fzone_005fsize-344"><code>frame_red_zone_size</code></a>: <a href="Functions-and-Variable-to-Analyze-Frames.html#Functions-and-Variable-to-Analyze-Frames">Functions and Variable to Analyze Frames</a></li>
|
||||
<li><a href="Stack-Frames.html#index-frame_005fregister_005funwind-109"><code>frame_register_unwind</code></a>: <a href="Stack-Frames.html#Stack-Frames">Stack Frames</a></li>
|
||||
<li><a href="Analyzing-Stacks_002d_002d_002dFrame-Sniffers.html#index-frame_005funwind_005fappend_005fsniffer-348"><code>frame_unwind_append_sniffer</code></a>: <a href="Analyzing-Stacks_002d_002d_002dFrame-Sniffers.html#Analyzing-Stacks_002d_002d_002dFrame-Sniffers">Analyzing Stacks---Frame Sniffers</a></li>
|
||||
<li><a href="Stack-Frames.html#index-frame_005funwind_005fappend_005funwinder-115"><code>frame_unwind_append_unwinder</code></a>: <a href="Stack-Frames.html#Stack-Frames">Stack Frames</a></li>
|
||||
<li><a href="Stack-Frames.html#index-frame_005funwind_005fgot_005faddress-121"><code>frame_unwind_got_address</code></a>: <a href="Stack-Frames.html#Stack-Frames">Stack Frames</a></li>
|
||||
<li><a href="Stack-Frames.html#index-frame_005funwind_005fgot_005fconstant-120"><code>frame_unwind_got_constant</code></a>: <a href="Stack-Frames.html#Stack-Frames">Stack Frames</a></li>
|
||||
<li><a href="Stack-Frames.html#index-frame_005funwind_005fgot_005fmemory-119"><code>frame_unwind_got_memory</code></a>: <a href="Stack-Frames.html#Stack-Frames">Stack Frames</a></li>
|
||||
<li><a href="Stack-Frames.html#index-frame_005funwind_005fgot_005foptimized-117"><code>frame_unwind_got_optimized</code></a>: <a href="Stack-Frames.html#Stack-Frames">Stack Frames</a></li>
|
||||
<li><a href="Stack-Frames.html#index-frame_005funwind_005fgot_005fregister-118"><code>frame_unwind_got_register</code></a>: <a href="Stack-Frames.html#Stack-Frames">Stack Frames</a></li>
|
||||
<li><a href="Stack-Frames.html#index-frame_005funwind_005fprepend_005funwinder-114"><code>frame_unwind_prepend_unwinder</code></a>: <a href="Stack-Frames.html#Stack-Frames">Stack Frames</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-GCC2_005fCOMPILED_005fFLAG_005fSYMBOL-387"><code>GCC2_COMPILED_FLAG_SYMBOL</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-GCC_005fCOMPILED_005fFLAG_005fSYMBOL-388"><code>GCC_COMPILED_FLAG_SYMBOL</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="GDB-Observers.html#index-gdb_005fdatadir_005fchanged-534"><code>gdb_datadir_changed</code></a>: <a href="GDB-Observers.html#GDB-Observers">GDB Observers</a></li>
|
||||
<li><a href="OS-ABI-Variant-Handling.html#index-GDB_005fOSABI_005fAIX-215"><code>GDB_OSABI_AIX</code></a>: <a href="OS-ABI-Variant-Handling.html#OS-ABI-Variant-Handling">OS ABI Variant Handling</a></li>
|
||||
<li><a href="OS-ABI-Variant-Handling.html#index-GDB_005fOSABI_005fCYGWIN-214"><code>GDB_OSABI_CYGWIN</code></a>: <a href="OS-ABI-Variant-Handling.html#OS-ABI-Variant-Handling">OS ABI Variant Handling</a></li>
|
||||
<li><a href="OS-ABI-Variant-Handling.html#index-GDB_005fOSABI_005fFREEBSD_005fAOUT-202"><code>GDB_OSABI_FREEBSD_AOUT</code></a>: <a href="OS-ABI-Variant-Handling.html#OS-ABI-Variant-Handling">OS ABI Variant Handling</a></li>
|
||||
<li><a href="OS-ABI-Variant-Handling.html#index-GDB_005fOSABI_005fFREEBSD_005fELF-203"><code>GDB_OSABI_FREEBSD_ELF</code></a>: <a href="OS-ABI-Variant-Handling.html#OS-ABI-Variant-Handling">OS ABI Variant Handling</a></li>
|
||||
<li><a href="OS-ABI-Variant-Handling.html#index-GDB_005fOSABI_005fGO32-208"><code>GDB_OSABI_GO32</code></a>: <a href="OS-ABI-Variant-Handling.html#OS-ABI-Variant-Handling">OS ABI Variant Handling</a></li>
|
||||
<li><a href="OS-ABI-Variant-Handling.html#index-GDB_005fOSABI_005fHPUX_005fELF-211"><code>GDB_OSABI_HPUX_ELF</code></a>: <a href="OS-ABI-Variant-Handling.html#OS-ABI-Variant-Handling">OS ABI Variant Handling</a></li>
|
||||
<li><a href="OS-ABI-Variant-Handling.html#index-GDB_005fOSABI_005fHPUX_005fSOM-212"><code>GDB_OSABI_HPUX_SOM</code></a>: <a href="OS-ABI-Variant-Handling.html#OS-ABI-Variant-Handling">OS ABI Variant Handling</a></li>
|
||||
<li><a href="OS-ABI-Variant-Handling.html#index-GDB_005fOSABI_005fHURD-198"><code>GDB_OSABI_HURD</code></a>: <a href="OS-ABI-Variant-Handling.html#OS-ABI-Variant-Handling">OS ABI Variant Handling</a></li>
|
||||
<li><a href="OS-ABI-Variant-Handling.html#index-GDB_005fOSABI_005fINTERIX-210"><code>GDB_OSABI_INTERIX</code></a>: <a href="OS-ABI-Variant-Handling.html#OS-ABI-Variant-Handling">OS ABI Variant Handling</a></li>
|
||||
<li><a href="OS-ABI-Variant-Handling.html#index-GDB_005fOSABI_005fIRIX-209"><code>GDB_OSABI_IRIX</code></a>: <a href="OS-ABI-Variant-Handling.html#OS-ABI-Variant-Handling">OS ABI Variant Handling</a></li>
|
||||
<li><a href="OS-ABI-Variant-Handling.html#index-GDB_005fOSABI_005fLINUX-201"><code>GDB_OSABI_LINUX</code></a>: <a href="OS-ABI-Variant-Handling.html#OS-ABI-Variant-Handling">OS ABI Variant Handling</a></li>
|
||||
<li><a href="OS-ABI-Variant-Handling.html#index-GDB_005fOSABI_005fNETBSD_005fAOUT-204"><code>GDB_OSABI_NETBSD_AOUT</code></a>: <a href="OS-ABI-Variant-Handling.html#OS-ABI-Variant-Handling">OS ABI Variant Handling</a></li>
|
||||
<li><a href="OS-ABI-Variant-Handling.html#index-GDB_005fOSABI_005fNETBSD_005fELF-205"><code>GDB_OSABI_NETBSD_ELF</code></a>: <a href="OS-ABI-Variant-Handling.html#OS-ABI-Variant-Handling">OS ABI Variant Handling</a></li>
|
||||
<li><a href="OS-ABI-Variant-Handling.html#index-GDB_005fOSABI_005fOPENBSD_005fELF-206"><code>GDB_OSABI_OPENBSD_ELF</code></a>: <a href="OS-ABI-Variant-Handling.html#OS-ABI-Variant-Handling">OS ABI Variant Handling</a></li>
|
||||
<li><a href="OS-ABI-Variant-Handling.html#index-GDB_005fOSABI_005fOSF1-200"><code>GDB_OSABI_OSF1</code></a>: <a href="OS-ABI-Variant-Handling.html#OS-ABI-Variant-Handling">OS ABI Variant Handling</a></li>
|
||||
<li><a href="OS-ABI-Variant-Handling.html#index-GDB_005fOSABI_005fQNXNTO-213"><code>GDB_OSABI_QNXNTO</code></a>: <a href="OS-ABI-Variant-Handling.html#OS-ABI-Variant-Handling">OS ABI Variant Handling</a></li>
|
||||
<li><a href="OS-ABI-Variant-Handling.html#index-GDB_005fOSABI_005fSOLARIS-199"><code>GDB_OSABI_SOLARIS</code></a>: <a href="OS-ABI-Variant-Handling.html#OS-ABI-Variant-Handling">OS ABI Variant Handling</a></li>
|
||||
<li><a href="OS-ABI-Variant-Handling.html#index-GDB_005fOSABI_005fSVR4-197"><code>GDB_OSABI_SVR4</code></a>: <a href="OS-ABI-Variant-Handling.html#OS-ABI-Variant-Handling">OS ABI Variant Handling</a></li>
|
||||
<li><a href="OS-ABI-Variant-Handling.html#index-GDB_005fOSABI_005fUNINITIALIZED-195"><code>GDB_OSABI_UNINITIALIZED</code></a>: <a href="OS-ABI-Variant-Handling.html#OS-ABI-Variant-Handling">OS ABI Variant Handling</a></li>
|
||||
<li><a href="OS-ABI-Variant-Handling.html#index-GDB_005fOSABI_005fUNKNOWN-196"><code>GDB_OSABI_UNKNOWN</code></a>: <a href="OS-ABI-Variant-Handling.html#OS-ABI-Variant-Handling">OS ABI Variant Handling</a></li>
|
||||
<li><a href="OS-ABI-Variant-Handling.html#index-GDB_005fOSABI_005fWINCE-207"><code>GDB_OSABI_WINCE</code></a>: <a href="OS-ABI-Variant-Handling.html#OS-ABI-Variant-Handling">OS ABI Variant Handling</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-gdbarch_005faddr_005fbits_005fremove-359"><code>gdbarch_addr_bits_remove</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Address-Classes.html#index-gdbarch_005faddress_005fclass_005fname_005fto_005ftype_005fflags-259"><code>gdbarch_address_class_name_to_type_flags</code></a>: <a href="Address-Classes.html#Address-Classes">Address Classes</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-gdbarch_005faddress_005fclass_005ftype_005fflags-362"><code>gdbarch_address_class_type_flags</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Address-Classes.html#index-gdbarch_005faddress_005fclass_005ftype_005fflags-257"><code>gdbarch_address_class_type_flags</code></a>: <a href="Address-Classes.html#Address-Classes">Address Classes</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-gdbarch_005faddress_005fclass_005ftype_005fflags_005fp-363"><code>gdbarch_address_class_type_flags_p</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-gdbarch_005faddress_005fclass_005ftype_005fflags_005fto_005fname-364"><code>gdbarch_address_class_type_flags_to_name</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Address-Classes.html#index-gdbarch_005faddress_005fclass_005ftype_005fflags_005fto_005fname-258"><code>gdbarch_address_class_type_flags_to_name</code></a>: <a href="Address-Classes.html#Address-Classes">Address Classes</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-gdbarch_005faddress_005fclass_005ftype_005fflags_005fto_005fname_005fp-365"><code>gdbarch_address_class_type_flags_to_name_p</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-gdbarch_005faddress_005fto_005fpointer-366"><code>gdbarch_address_to_pointer</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Pointers-and-Addresses.html#index-gdbarch_005faddress_005fto_005fpointer-253"><code>gdbarch_address_to_pointer</code></a>: <a href="Pointers-and-Addresses.html#Pointers-and-Addresses">Pointers and Addresses</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-gdbarch_005fadjust_005fbreakpoint_005faddress-376"><code>gdbarch_adjust_breakpoint_address</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Creating-a-New-Architecture.html#index-gdbarch_005falloc-234"><code>gdbarch_alloc</code></a>: <a href="Creating-a-New-Architecture.html#Creating-a-New-Architecture">Creating a New Architecture</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-gdbarch_005fbelieve_005fpcc_005fpromotion-367"><code>gdbarch_believe_pcc_promotion</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-gdbarch_005fbits_005fbig_005fendian-368"><code>gdbarch_bits_big_endian</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-gdbarch_005fbreakpoint_005ffrom_005fpc-373"><code>gdbarch_breakpoint_from_pc</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-gdbarch_005fcall_005fdummy_005flocation-378"><code>gdbarch_call_dummy_location</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-gdbarch_005fcannot_005ffetch_005fregister-379"><code>gdbarch_cannot_fetch_register</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-gdbarch_005fcannot_005fstore_005fregister-380"><code>gdbarch_cannot_store_register</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-gdbarch_005fchar_005fsigned-415"><code>gdbarch_char_signed</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-gdbarch_005fconvert_005fregister_005fp-381"><code>gdbarch_convert_register_p</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Register-and-Memory-Data.html#index-gdbarch_005fconvert_005fregister_005fp-298"><code>gdbarch_convert_register_p</code></a>: <a href="Register-and-Memory-Data.html#Register-and-Memory-Data">Register and Memory Data</a></li>
|
||||
<li><a href="Misc-Guidelines.html#index-gdbarch_005fdata-470"><code>gdbarch_data</code></a>: <a href="Misc-Guidelines.html#Misc-Guidelines">Misc Guidelines</a></li>
|
||||
<li><a href="Misc-Guidelines.html#index-gdbarch_005fdata_005fregister_005fpost_005finit-469"><code>gdbarch_data_register_post_init</code></a>: <a href="Misc-Guidelines.html#Misc-Guidelines">Misc Guidelines</a></li>
|
||||
<li><a href="Misc-Guidelines.html#index-gdbarch_005fdata_005fregister_005fpre_005finit-468"><code>gdbarch_data_register_pre_init</code></a>: <a href="Misc-Guidelines.html#Misc-Guidelines">Misc Guidelines</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-gdbarch_005fdecr_005fpc_005fafter_005fbreak-383"><code>gdbarch_decr_pc_after_break</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-gdbarch_005fdeprecated_005ffp_005fregnum-412"><code>gdbarch_deprecated_fp_regnum</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-gdbarch_005fdouble_005fbit-416"><code>gdbarch_double_bit</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-gdbarch_005fdummy_005fid-426"><code>gdbarch_dummy_id</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-gdbarch_005fdwarf2_005freg_005fto_005fregnum-385"><code>gdbarch_dwarf2_reg_to_regnum</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-gdbarch_005fecoff_005freg_005fto_005fregnum-386"><code>gdbarch_ecoff_reg_to_regnum</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-gdbarch_005ffloat_005fbit-417"><code>gdbarch_float_bit</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-gdbarch_005ffp0_005fregnum-382"><code>gdbarch_fp0_regnum</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-gdbarch_005fget_005flongjmp_005ftarget-389"><code>gdbarch_get_longjmp_target</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Algorithms.html#index-gdbarch_005fget_005flongjmp_005ftarget-23"><code>gdbarch_get_longjmp_target</code></a>: <a href="Algorithms.html#Algorithms">Algorithms</a></li>
|
||||
<li><a href="Algorithms.html#index-gdbarch_005fhave_005fnonsteppable_005fwatchpoint-35"><code>gdbarch_have_nonsteppable_watchpoint</code></a>: <a href="Algorithms.html#Algorithms">Algorithms</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-gdbarch_005fin_005ffunction_005fepilogue_005fp-391"><code>gdbarch_in_function_epilogue_p</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-gdbarch_005fin_005fsolib_005freturn_005ftrampoline-392"><code>gdbarch_in_solib_return_trampoline</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="OS-ABI-Variant-Handling.html#index-gdbarch_005finit_005fosabi-220"><code>gdbarch_init_osabi</code></a>: <a href="OS-ABI-Variant-Handling.html#OS-ABI-Variant-Handling">OS ABI Variant Handling</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-gdbarch_005fint_005fbit-418"><code>gdbarch_int_bit</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-gdbarch_005finteger_005fto_005faddress-395"><code>gdbarch_integer_to_address</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Looking-Up-an-Existing-Architecture.html#index-gdbarch_005flist_005flookup_005fby_005finfo-230"><code>gdbarch_list_lookup_by_info</code></a>: <a href="Looking-Up-an-Existing-Architecture.html#Looking-Up-an-Existing-Architecture">Looking Up an Existing Architecture</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-gdbarch_005flong_005fbit-419"><code>gdbarch_long_bit</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-gdbarch_005flong_005fdouble_005fbit-420"><code>gdbarch_long_double_bit</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-gdbarch_005flong_005flong_005fbit-421"><code>gdbarch_long_long_bit</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="OS-ABI-Variant-Handling.html#index-gdbarch_005flookup_005fosabi-219"><code>gdbarch_lookup_osabi</code></a>: <a href="OS-ABI-Variant-Handling.html#OS-ABI-Variant-Handling">OS ABI Variant Handling</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-gdbarch_005fmemory_005finsert_005fbreakpoint-375"><code>gdbarch_memory_insert_breakpoint</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-gdbarch_005fmemory_005fremove_005fbreakpoint-374"><code>gdbarch_memory_remove_breakpoint</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="OS-ABI-Variant-Handling.html#index-gdbarch_005fosabi_005fname-216"><code>gdbarch_osabi_name</code></a>: <a href="OS-ABI-Variant-Handling.html#OS-ABI-Variant-Handling">OS ABI Variant Handling</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-gdbarch_005fpointer_005fto_005faddress-397"><code>gdbarch_pointer_to_address</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Pointers-and-Addresses.html#index-gdbarch_005fpointer_005fto_005faddress-252"><code>gdbarch_pointer_to_address</code></a>: <a href="Pointers-and-Addresses.html#Pointers-and-Addresses">Pointers and Addresses</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-gdbarch_005fprint_005finsn-425"><code>gdbarch_print_insn</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-gdbarch_005fptr_005fbit-422"><code>gdbarch_ptr_bit</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-gdbarch_005fpush_005fdummy_005fcall-406"><code>gdbarch_push_dummy_call</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-gdbarch_005fpush_005fdummy_005fcode-407"><code>gdbarch_push_dummy_code</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Adding-a-New-Target.html#index-gdbarch_005fregister-433"><code>gdbarch_register</code></a>: <a href="Adding-a-New-Target.html#Adding-a-New-Target">Adding a New Target</a></li>
|
||||
<li><a href="How-an-Architecture-is-Represented.html#index-gdbarch_005fregister-228"><code>gdbarch_register</code></a>: <a href="How-an-Architecture-is-Represented.html#How-an-Architecture-is-Represented">How an Architecture is Represented</a></li>
|
||||
<li><a href="OS-ABI-Variant-Handling.html#index-gdbarch_005fregister_005fosabi-217"><code>gdbarch_register_osabi</code></a>: <a href="OS-ABI-Variant-Handling.html#OS-ABI-Variant-Handling">OS ABI Variant Handling</a></li>
|
||||
<li><a href="OS-ABI-Variant-Handling.html#index-gdbarch_005fregister_005fosabi_005fsniffer-218"><code>gdbarch_register_osabi_sniffer</code></a>: <a href="OS-ABI-Variant-Handling.html#OS-ABI-Variant-Handling">OS ABI Variant Handling</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-gdbarch_005fregister_005fto_005fvalue-398"><code>gdbarch_register_to_value</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Register-and-Memory-Data.html#index-gdbarch_005fregister_005fto_005fvalue-299"><code>gdbarch_register_to_value</code></a>: <a href="Register-and-Memory-Data.html#Register-and-Memory-Data">Register and Memory Data</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-gdbarch_005freturn_005fvalue-409"><code>gdbarch_return_value</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-gdbarch_005fsdb_005freg_005fto_005fregnum-408"><code>gdbarch_sdb_reg_to_regnum</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-gdbarch_005fshort_005fbit-423"><code>gdbarch_short_bit</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-gdbarch_005fskip_005fpermanent_005fbreakpoint-410"><code>gdbarch_skip_permanent_breakpoint</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-gdbarch_005fskip_005ftrampoline_005fcode-411"><code>gdbarch_skip_trampoline_code</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-gdbarch_005fstab_005freg_005fto_005fregnum-413"><code>gdbarch_stab_reg_to_regnum</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-gdbarch_005fstabs_005fargument_005fhas_005faddr-405"><code>gdbarch_stabs_argument_has_addr</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-gdbarch_005fvalue_005fto_005fregister-427"><code>gdbarch_value_to_register</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Register-and-Memory-Data.html#index-gdbarch_005fvalue_005fto_005fregister-300"><code>gdbarch_value_to_register</code></a>: <a href="Register-and-Memory-Data.html#Register-and-Memory-Data">Register and Memory Data</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-gdbarch_005fvirtual_005fframe_005fpointer-424"><code>gdbarch_virtual_frame_pointer</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Host-Definition.html#index-g_t_0040value_007bGDBN_007dINIT_005fFILENAME-179"><span class="sc">gdb</span><code>INIT_FILENAME</code></a>: <a href="Host-Definition.html#Host-Definition">Host Definition</a></li>
|
||||
<li><a href="OS-ABI-Variant-Handling.html#index-generic_005felf_005fosabi_005fsniff_005fabi_005ftag_005fsections-221"><code>generic_elf_osabi_sniff_abi_tag_sections</code></a>: <a href="OS-ABI-Variant-Handling.html#OS-ABI-Variant-Handling">OS ABI Variant Handling</a></li>
|
||||
<li><a href="Stack-Frames.html#index-get_005fframe_005fregister-110"><code>get_frame_register</code></a>: <a href="Stack-Frames.html#Stack-Frames">Stack Frames</a></li>
|
||||
<li><a href="Stack-Frames.html#index-get_005fframe_005ftype-112"><code>get_frame_type</code></a>: <a href="Stack-Frames.html#Stack-Frames">Stack Frames</a></li>
|
||||
<li><a href="Algorithms.html#index-HAVE_005fCONTINUABLE_005fWATCHPOINT-36"><code>HAVE_CONTINUABLE_WATCHPOINT</code></a>: <a href="Algorithms.html#Algorithms">Algorithms</a></li>
|
||||
<li><a href="Misc-Guidelines.html#index-HAVE_005fDOS_005fBASED_005fFILE_005fSYSTEM-480"><code>HAVE_DOS_BASED_FILE_SYSTEM</code></a>: <a href="Misc-Guidelines.html#Misc-Guidelines">Misc Guidelines</a></li>
|
||||
<li><a href="Algorithms.html#index-HAVE_005fSTEPPABLE_005fWATCHPOINT-34"><code>HAVE_STEPPABLE_WATCHPOINT</code></a>: <a href="Algorithms.html#Algorithms">Algorithms</a></li>
|
||||
<li><a href="Algorithms.html#index-i386_005fcleanup_005fdregs-53"><code>i386_cleanup_dregs</code></a>: <a href="Algorithms.html#Algorithms">Algorithms</a></li>
|
||||
<li><a href="Algorithms.html#index-I386_005fDR_005fLOW_005fGET_005fSTATUS-45"><code>I386_DR_LOW_GET_STATUS</code></a>: <a href="Algorithms.html#Algorithms">Algorithms</a></li>
|
||||
<li><a href="Algorithms.html#index-I386_005fDR_005fLOW_005fRESET_005fADDR-44"><code>I386_DR_LOW_RESET_ADDR</code></a>: <a href="Algorithms.html#Algorithms">Algorithms</a></li>
|
||||
<li><a href="Algorithms.html#index-I386_005fDR_005fLOW_005fSET_005fADDR-43"><code>I386_DR_LOW_SET_ADDR</code></a>: <a href="Algorithms.html#Algorithms">Algorithms</a></li>
|
||||
<li><a href="Algorithms.html#index-I386_005fDR_005fLOW_005fSET_005fCONTROL-42"><code>I386_DR_LOW_SET_CONTROL</code></a>: <a href="Algorithms.html#Algorithms">Algorithms</a></li>
|
||||
<li><a href="Algorithms.html#index-i386_005finsert_005fhw_005fbreakpoint-51"><code>i386_insert_hw_breakpoint</code></a>: <a href="Algorithms.html#Algorithms">Algorithms</a></li>
|
||||
<li><a href="Algorithms.html#index-i386_005finsert_005fwatchpoint-49"><code>i386_insert_watchpoint</code></a>: <a href="Algorithms.html#Algorithms">Algorithms</a></li>
|
||||
<li><a href="Algorithms.html#index-i386_005fregion_005fok_005ffor_005fwatchpoint-46"><code>i386_region_ok_for_watchpoint</code></a>: <a href="Algorithms.html#Algorithms">Algorithms</a></li>
|
||||
<li><a href="Algorithms.html#index-i386_005fremove_005fhw_005fbreakpoint-52"><code>i386_remove_hw_breakpoint</code></a>: <a href="Algorithms.html#Algorithms">Algorithms</a></li>
|
||||
<li><a href="Algorithms.html#index-i386_005fremove_005fwatchpoint-50"><code>i386_remove_watchpoint</code></a>: <a href="Algorithms.html#Algorithms">Algorithms</a></li>
|
||||
<li><a href="Algorithms.html#index-i386_005fstopped_005fby_005fwatchpoint-48"><code>i386_stopped_by_watchpoint</code></a>: <a href="Algorithms.html#Algorithms">Algorithms</a></li>
|
||||
<li><a href="Algorithms.html#index-i386_005fstopped_005fdata_005faddress-47"><code>i386_stopped_data_address</code></a>: <a href="Algorithms.html#Algorithms">Algorithms</a></li>
|
||||
<li><a href="Algorithms.html#index-I386_005fUSE_005fGENERIC_005fWATCHPOINTS-41"><code>I386_USE_GENERIC_WATCHPOINTS</code></a>: <a href="Algorithms.html#Algorithms">Algorithms</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-in_005fdynsym_005fresolve_005fcode-393"><code>in_dynsym_resolve_code</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="GDB-Observers.html#index-inferior_005fadded-528"><code>inferior_added</code></a>: <a href="GDB-Observers.html#GDB-Observers">GDB Observers</a></li>
|
||||
<li><a href="GDB-Observers.html#index-inferior_005fappeared-529"><code>inferior_appeared</code></a>: <a href="GDB-Observers.html#GDB-Observers">GDB Observers</a></li>
|
||||
<li><a href="GDB-Observers.html#index-inferior_005fcreated-512"><code>inferior_created</code></a>: <a href="GDB-Observers.html#GDB-Observers">GDB Observers</a></li>
|
||||
<li><a href="GDB-Observers.html#index-inferior_005fexit-530"><code>inferior_exit</code></a>: <a href="GDB-Observers.html#GDB-Observers">GDB Observers</a></li>
|
||||
<li><a href="GDB-Observers.html#index-inferior_005fremoved-531"><code>inferior_removed</code></a>: <a href="GDB-Observers.html#GDB-Observers">GDB Observers</a></li>
|
||||
<li><a href="Functions-and-Variable-to-Analyze-Frames.html#index-inner_005fthan-338"><code>inner_than</code></a>: <a href="Functions-and-Variable-to-Analyze-Frames.html#Functions-and-Variable-to-Analyze-Frames">Functions and Variable to Analyze Frames</a></li>
|
||||
<li><a href="Misc-Guidelines.html#index-IS_005fABSOLUTE_005fPATH-482"><code>IS_ABSOLUTE_PATH</code></a>: <a href="Misc-Guidelines.html#Misc-Guidelines">Misc Guidelines</a></li>
|
||||
<li><a href="Misc-Guidelines.html#index-IS_005fDIR_005fSEPARATOR-481"><code>IS_DIR_SEPARATOR</code></a>: <a href="Misc-Guidelines.html#Misc-Guidelines">Misc Guidelines</a></li>
|
||||
<li><a href="Host-Definition.html#index-ISATTY-186"><code>ISATTY</code></a>: <a href="Host-Definition.html#Host-Definition">Host Definition</a></li>
|
||||
<li><a href="Language-Support.html#index-length_005fof_005fsubexp-166"><code>length_of_subexp</code></a>: <a href="Language-Support.html#Language-Support">Language Support</a></li>
|
||||
<li><a href="Host-Definition.html#index-lint-190"><code>lint</code></a>: <a href="Host-Definition.html#Host-Definition">Host Definition</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-LITTLE_005fBREAKPOINT-371"><code>LITTLE_BREAKPOINT</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Host-Definition.html#index-LSEEK_005fNOT_005fLINEAR-189"><code>LSEEK_NOT_LINEAR</code></a>: <a href="Host-Definition.html#Host-Definition">Host Definition</a></li>
|
||||
<li><a href="Misc-Guidelines.html#index-make_005fcleanup-462"><code>make_cleanup</code></a>: <a href="Misc-Guidelines.html#Misc-Guidelines">Misc Guidelines</a></li>
|
||||
<li><a href="User-Interface.html#index-make_005fcleanup_005fui_005fout_005flist_005fbegin_005fend-80"><code>make_cleanup_ui_out_list_begin_end</code></a>: <a href="User-Interface.html#User-Interface">User Interface</a></li>
|
||||
<li><a href="User-Interface.html#index-make_005fcleanup_005fui_005fout_005ftuple_005fbegin_005fend-77"><code>make_cleanup_ui_out_tuple_begin_end</code></a>: <a href="User-Interface.html#User-Interface">User Interface</a></li>
|
||||
<li><a href="GDB-Observers.html#index-memory_005fchanged-532"><code>memory_changed</code></a>: <a href="GDB-Observers.html#GDB-Observers">GDB Observers</a></li>
|
||||
<li><a href="Native-Debugging.html#index-NATDEPFILES-441"><code>NATDEPFILES</code></a>: <a href="Native-Debugging.html#Native-Debugging">Native Debugging</a></li>
|
||||
<li><a href="GDB-Observers.html#index-new_005fobjfile-516"><code>new_objfile</code></a>: <a href="GDB-Observers.html#GDB-Observers">GDB Observers</a></li>
|
||||
<li><a href="GDB-Observers.html#index-new_005fthread-517"><code>new_thread</code></a>: <a href="GDB-Observers.html#GDB-Observers">GDB Observers</a></li>
|
||||
<li><a href="GDB-Observers.html#index-normal_005fstop-509"><code>normal_stop</code></a>: <a href="GDB-Observers.html#GDB-Observers">GDB Observers</a></li>
|
||||
<li><a href="Language-Support.html#index-op_005fprint_005ftab-171"><code>op_print_tab</code></a>: <a href="Language-Support.html#Language-Support">Language Support</a></li>
|
||||
<li><a href="Language-Support.html#index-parse_005fexp_005f1-172"><code>parse_exp_1</code></a>: <a href="Language-Support.html#Language-Support">Language Support</a></li>
|
||||
<li><a href="Register-Architecture-Functions-_0026-Variables.html#index-pc_005fregnum-272"><code>pc_regnum</code></a>: <a href="Register-Architecture-Functions-_0026-Variables.html#Register-Architecture-Functions-_0026-Variables">Register Architecture Functions & Variables</a></li>
|
||||
<li><a href="Language-Support.html#index-prefixify_005fsubexp-165"><code>prefixify_subexp</code></a>: <a href="Language-Support.html#Language-Support">Language Support</a></li>
|
||||
<li><a href="Register-Information-Functions.html#index-print_005ffloat_005finfo-288"><code>print_float_info</code></a>: <a href="Register-Information-Functions.html#Register-Information-Functions">Register Information Functions</a></li>
|
||||
<li><a href="Register-Information-Functions.html#index-print_005fregisters_005finfo-287"><code>print_registers_info</code></a>: <a href="Register-Information-Functions.html#Register-Information-Functions">Register Information Functions</a></li>
|
||||
<li><a href="Language-Support.html#index-print_005fsubexp-170"><code>print_subexp</code></a>: <a href="Language-Support.html#Language-Support">Language Support</a></li>
|
||||
<li><a href="Register-Information-Functions.html#index-print_005fvector_005finfo-289"><code>print_vector_info</code></a>: <a href="Register-Information-Functions.html#Register-Information-Functions">Register Information Functions</a></li>
|
||||
<li><a href="Host-Definition.html#index-PRINTF_005fHAS_005fLONG_005fLONG-188"><code>PRINTF_HAS_LONG_LONG</code></a>: <a href="Host-Definition.html#Host-Definition">Host Definition</a></li>
|
||||
<li><a href="Register-Architecture-Functions-_0026-Variables.html#index-ps_005fregnum-276"><code>ps_regnum</code></a>: <a href="Register-Architecture-Functions-_0026-Variables.html#Register-Architecture-Functions-_0026-Variables">Register Architecture Functions & Variables</a></li>
|
||||
<li><a href="Register-Architecture-Functions-_0026-Variables.html#index-pseudo_005fregister_005fread-266"><code>pseudo_register_read</code></a>: <a href="Register-Architecture-Functions-_0026-Variables.html#Register-Architecture-Functions-_0026-Variables">Register Architecture Functions & Variables</a></li>
|
||||
<li><a href="Register-Architecture-Functions-_0026-Variables.html#index-pseudo_005fregister_005fwrite-267"><code>pseudo_register_write</code></a>: <a href="Register-Architecture-Functions-_0026-Variables.html#Register-Architecture-Functions-_0026-Variables">Register Architecture Functions & Variables</a></li>
|
||||
<li><a href="Functions-Creating-Dummy-Frames.html#index-push_005fdummy_005fcall-355"><code>push_dummy_call</code></a>: <a href="Functions-Creating-Dummy-Frames.html#Functions-Creating-Dummy-Frames">Functions Creating Dummy Frames</a></li>
|
||||
<li><a href="Functions-Creating-Dummy-Frames.html#index-push_005fdummy_005fcode-357"><code>push_dummy_code</code></a>: <a href="Functions-Creating-Dummy-Frames.html#Functions-Creating-Dummy-Frames">Functions Creating Dummy Frames</a></li>
|
||||
<li><a href="Register-Architecture-Functions-_0026-Variables.html#index-read_005fpc-264"><code>read_pc</code></a>: <a href="Register-Architecture-Functions-_0026-Variables.html#Register-Architecture-Functions-_0026-Variables">Register Architecture Functions & Variables</a></li>
|
||||
<li><a href="GDB-Observers.html#index-record_005fchanged-513"><code>record_changed</code></a>: <a href="GDB-Observers.html#GDB-Observers">GDB Observers</a></li>
|
||||
<li><a href="Register-Caching.html#index-regcache_005fcooked_005fread-303"><code>regcache_cooked_read</code></a>: <a href="Register-Caching.html#Register-Caching">Register Caching</a></li>
|
||||
<li><a href="Register-Caching.html#index-regcache_005fcooked_005fread_005fsigned-306"><code>regcache_cooked_read_signed</code></a>: <a href="Register-Caching.html#Register-Caching">Register Caching</a></li>
|
||||
<li><a href="Register-Caching.html#index-regcache_005fcooked_005fread_005funsigned-307"><code>regcache_cooked_read_unsigned</code></a>: <a href="Register-Caching.html#Register-Caching">Register Caching</a></li>
|
||||
<li><a href="Register-Caching.html#index-regcache_005fcooked_005fwrite-304"><code>regcache_cooked_write</code></a>: <a href="Register-Caching.html#Register-Caching">Register Caching</a></li>
|
||||
<li><a href="Register-Caching.html#index-regcache_005fcooked_005fwrite_005fsigned-308"><code>regcache_cooked_write_signed</code></a>: <a href="Register-Caching.html#Register-Caching">Register Caching</a></li>
|
||||
<li><a href="Register-Caching.html#index-regcache_005fcooked_005fwrite_005funsigned-309"><code>regcache_cooked_write_unsigned</code></a>: <a href="Register-Caching.html#Register-Caching">Register Caching</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-REGISTER_005fCONVERT_005fTO_005fRAW-400"><code>REGISTER_CONVERT_TO_RAW</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-REGISTER_005fCONVERT_005fTO_005fVIRTUAL-399"><code>REGISTER_CONVERT_TO_VIRTUAL</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Register-Information-Functions.html#index-register_005fname-285"><code>register_name</code></a>: <a href="Register-Information-Functions.html#Register-Information-Functions">Register Information Functions</a></li>
|
||||
<li><a href="Register-Information-Functions.html#index-register_005freggroup_005fp-290"><code>register_reggroup_p</code></a>: <a href="Register-Information-Functions.html#Register-Information-Functions">Register Information Functions</a></li>
|
||||
<li><a href="Register-Information-Functions.html#index-register_005ftype-286"><code>register_type</code></a>: <a href="Register-Information-Functions.html#Register-Information-Functions">Register Information Functions</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-regset_005ffrom_005fcore_005fsection-401"><code>regset_from_core_section</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-REMOTE_005fBPT_005fVECTOR-429"><code>REMOTE_BPT_VECTOR</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Stack-Frames.html#index-SENTINEL_005fFRAME-113"><code>SENTINEL_FRAME</code></a>: <a href="Stack-Frames.html#Stack-Frames">Stack Frames</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-set_005fgdbarch_005fbits_005fbig_005fendian-369"><code>set_gdbarch_bits_big_endian</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-set_005fgdbarch_005fsofun_005faddress_005fmaybe_005fmissing-404"><code>set_gdbarch_sofun_address_maybe_missing</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Functions-and-Variable-to-Analyze-Frames.html#index-skip_005fprologue-337"><code>skip_prologue</code></a>: <a href="Functions-and-Variable-to-Analyze-Frames.html#Functions-and-Variable-to-Analyze-Frames">Functions and Variable to Analyze Frames</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-SKIP_005fSOLIB_005fRESOLVER-394"><code>SKIP_SOLIB_RESOLVER</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Misc-Guidelines.html#index-SLASH_005fSTRING-485"><code>SLASH_STRING</code></a>: <a href="Misc-Guidelines.html#Misc-Guidelines">Misc Guidelines</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-SOFTWARE_005fSINGLE_005fSTEP-403"><code>SOFTWARE_SINGLE_STEP</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-SOFTWARE_005fSINGLE_005fSTEP_005fP-402"><code>SOFTWARE_SINGLE_STEP_P</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Native-Debugging.html#index-SOLIB_005fADD-443"><code>SOLIB_ADD</code></a>: <a href="Native-Debugging.html#Native-Debugging">Native Debugging</a></li>
|
||||
<li><a href="Native-Debugging.html#index-SOLIB_005fCREATE_005fINFERIOR_005fHOOK-444"><code>SOLIB_CREATE_INFERIOR_HOOK</code></a>: <a href="Native-Debugging.html#Native-Debugging">Native Debugging</a></li>
|
||||
<li><a href="GDB-Observers.html#index-solib_005floaded-514"><code>solib_loaded</code></a>: <a href="GDB-Observers.html#GDB-Observers">GDB Observers</a></li>
|
||||
<li><a href="GDB-Observers.html#index-solib_005funloaded-515"><code>solib_unloaded</code></a>: <a href="GDB-Observers.html#GDB-Observers">GDB Observers</a></li>
|
||||
<li><a href="Register-Architecture-Functions-_0026-Variables.html#index-sp_005fregnum-268"><code>sp_regnum</code></a>: <a href="Register-Architecture-Functions-_0026-Variables.html#Register-Architecture-Functions-_0026-Variables">Register Architecture Functions & Variables</a></li>
|
||||
<li><a href="Native-Debugging.html#index-START_005fINFERIOR_005fTRAPS_005fEXPECTED-445"><code>START_INFERIOR_TRAPS_EXPECTED</code></a>: <a href="Native-Debugging.html#Native-Debugging">Native Debugging</a></li>
|
||||
<li><a href="Algorithms.html#index-STOPPED_005fBY_005fWATCHPOINT-37"><code>STOPPED_BY_WATCHPOINT</code></a>: <a href="Algorithms.html#Algorithms">Algorithms</a></li>
|
||||
<li><a href="Pointers-and-Addresses.html#index-store_005ftyped_005faddress-249"><code>store_typed_address</code></a>: <a href="Pointers-and-Addresses.html#Pointers-and-Addresses">Pointers and Addresses</a></li>
|
||||
<li><a href="GDB-Observers.html#index-struct-506"><code>struct</code></a>: <a href="GDB-Observers.html#GDB-Observers">GDB Observers</a></li>
|
||||
<li><a href="Algorithms.html#index-TARGET_005fCAN_005fUSE_005fHARDWARE_005fWATCHPOINT-27"><code>TARGET_CAN_USE_HARDWARE_WATCHPOINT</code></a>: <a href="Algorithms.html#Algorithms">Algorithms</a></li>
|
||||
<li><a href="GDB-Observers.html#index-target_005fchanged-510"><code>target_changed</code></a>: <a href="GDB-Observers.html#GDB-Observers">GDB Observers</a></li>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#index-TARGET_005fCHAR_005fBIT-414"><code>TARGET_CHAR_BIT</code></a>: <a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a></li>
|
||||
<li><a href="Algorithms.html#index-target_005finsert_005fbreakpoint-18"><code>target_insert_breakpoint</code></a>: <a href="Algorithms.html#Algorithms">Algorithms</a></li>
|
||||
<li><a href="Algorithms.html#index-target_005finsert_005fhw_005fbreakpoint-21"><code>target_insert_hw_breakpoint</code></a>: <a href="Algorithms.html#Algorithms">Algorithms</a></li>
|
||||
<li><a href="Algorithms.html#index-target_005finsert_005fwatchpoint-30"><code>target_insert_watchpoint</code></a>: <a href="Algorithms.html#Algorithms">Algorithms</a></li>
|
||||
<li><a href="Algorithms.html#index-TARGET_005fREGION_005fOK_005fFOR_005fHW_005fWATCHPOINT-28"><code>TARGET_REGION_OK_FOR_HW_WATCHPOINT</code></a>: <a href="Algorithms.html#Algorithms">Algorithms</a></li>
|
||||
<li><a href="Algorithms.html#index-target_005fremove_005fbreakpoint-17"><code>target_remove_breakpoint</code></a>: <a href="Algorithms.html#Algorithms">Algorithms</a></li>
|
||||
<li><a href="Algorithms.html#index-target_005fremove_005fhw_005fbreakpoint-20"><code>target_remove_hw_breakpoint</code></a>: <a href="Algorithms.html#Algorithms">Algorithms</a></li>
|
||||
<li><a href="Algorithms.html#index-target_005fremove_005fwatchpoint-31"><code>target_remove_watchpoint</code></a>: <a href="Algorithms.html#Algorithms">Algorithms</a></li>
|
||||
<li><a href="GDB-Observers.html#index-target_005fresumed-520"><code>target_resumed</code></a>: <a href="GDB-Observers.html#GDB-Observers">GDB Observers</a></li>
|
||||
<li><a href="Algorithms.html#index-target_005fstopped_005fdata_005faddress-32"><code>target_stopped_data_address</code></a>: <a href="Algorithms.html#Algorithms">Algorithms</a></li>
|
||||
<li><a href="Algorithms.html#index-target_005fwatchpoint_005faddr_005fwithin_005frange-33"><code>target_watchpoint_addr_within_range</code></a>: <a href="Algorithms.html#Algorithms">Algorithms</a></li>
|
||||
<li><a href="GDB-Observers.html#index-test_005fnotification-539"><code>test_notification</code></a>: <a href="GDB-Observers.html#GDB-Observers">GDB Observers</a></li>
|
||||
<li><a href="GDB-Observers.html#index-thread_005fexit-518"><code>thread_exit</code></a>: <a href="GDB-Observers.html#GDB-Observers">GDB Observers</a></li>
|
||||
<li><a href="GDB-Observers.html#index-thread_005fptid_005fchanged-527"><code>thread_ptid_changed</code></a>: <a href="GDB-Observers.html#GDB-Observers">GDB Observers</a></li>
|
||||
<li><a href="GDB-Observers.html#index-thread_005fstop_005frequested-519"><code>thread_stop_requested</code></a>: <a href="GDB-Observers.html#GDB-Observers">GDB Observers</a></li>
|
||||
<li><a href="GDB-Observers.html#index-traceframe_005fchanged-525"><code>traceframe_changed</code></a>: <a href="GDB-Observers.html#GDB-Observers">GDB Observers</a></li>
|
||||
<li><a href="GDB-Observers.html#index-tsv_005fcreated-536"><code>tsv_created</code></a>: <a href="GDB-Observers.html#GDB-Observers">GDB Observers</a></li>
|
||||
<li><a href="GDB-Observers.html#index-tsv_005fdeleted-537"><code>tsv_deleted</code></a>: <a href="GDB-Observers.html#GDB-Observers">GDB Observers</a></li>
|
||||
<li><a href="GDB-Observers.html#index-tsv_005fmodified-538"><code>tsv_modified</code></a>: <a href="GDB-Observers.html#GDB-Observers">GDB Observers</a></li>
|
||||
<li><a href="User-Interface.html#index-ui_005fout_005ffield_005fcore_005faddr-87"><code>ui_out_field_core_addr</code></a>: <a href="User-Interface.html#User-Interface">User Interface</a></li>
|
||||
<li><a href="User-Interface.html#index-ui_005fout_005ffield_005ffmt-84"><code>ui_out_field_fmt</code></a>: <a href="User-Interface.html#User-Interface">User Interface</a></li>
|
||||
<li><a href="User-Interface.html#index-ui_005fout_005ffield_005ffmt_005fint-86"><code>ui_out_field_fmt_int</code></a>: <a href="User-Interface.html#User-Interface">User Interface</a></li>
|
||||
<li><a href="User-Interface.html#index-ui_005fout_005ffield_005fint-85"><code>ui_out_field_int</code></a>: <a href="User-Interface.html#User-Interface">User Interface</a></li>
|
||||
<li><a href="User-Interface.html#index-ui_005fout_005ffield_005fskip-92"><code>ui_out_field_skip</code></a>: <a href="User-Interface.html#User-Interface">User Interface</a></li>
|
||||
<li><a href="User-Interface.html#index-ui_005fout_005ffield_005fstream-91"><code>ui_out_field_stream</code></a>: <a href="User-Interface.html#User-Interface">User Interface</a></li>
|
||||
<li><a href="User-Interface.html#index-ui_005fout_005ffield_005fstring-88"><code>ui_out_field_string</code></a>: <a href="User-Interface.html#User-Interface">User Interface</a></li>
|
||||
<li><a href="User-Interface.html#index-ui_005fout_005fflush-97"><code>ui_out_flush</code></a>: <a href="User-Interface.html#User-Interface">User Interface</a></li>
|
||||
<li><a href="User-Interface.html#index-ui_005fout_005flist_005fbegin-78"><code>ui_out_list_begin</code></a>: <a href="User-Interface.html#User-Interface">User Interface</a></li>
|
||||
<li><a href="User-Interface.html#index-ui_005fout_005flist_005fend-79"><code>ui_out_list_end</code></a>: <a href="User-Interface.html#User-Interface">User Interface</a></li>
|
||||
<li><a href="User-Interface.html#index-ui_005fout_005fmessage-95"><code>ui_out_message</code></a>: <a href="User-Interface.html#User-Interface">User Interface</a></li>
|
||||
<li><a href="User-Interface.html#index-ui_005fout_005fspaces-94"><code>ui_out_spaces</code></a>: <a href="User-Interface.html#User-Interface">User Interface</a></li>
|
||||
<li><a href="User-Interface.html#index-ui_005fout_005fstream_005fdelete-90"><code>ui_out_stream_delete</code></a>: <a href="User-Interface.html#User-Interface">User Interface</a></li>
|
||||
<li><a href="User-Interface.html#index-ui_005fout_005fstream_005fnew-89"><code>ui_out_stream_new</code></a>: <a href="User-Interface.html#User-Interface">User Interface</a></li>
|
||||
<li><a href="User-Interface.html#index-ui_005fout_005ftable_005fbegin-71"><code>ui_out_table_begin</code></a>: <a href="User-Interface.html#User-Interface">User Interface</a></li>
|
||||
<li><a href="User-Interface.html#index-ui_005fout_005ftable_005fbody-73"><code>ui_out_table_body</code></a>: <a href="User-Interface.html#User-Interface">User Interface</a></li>
|
||||
<li><a href="User-Interface.html#index-ui_005fout_005ftable_005fend-74"><code>ui_out_table_end</code></a>: <a href="User-Interface.html#User-Interface">User Interface</a></li>
|
||||
<li><a href="User-Interface.html#index-ui_005fout_005ftable_005fheader-72"><code>ui_out_table_header</code></a>: <a href="User-Interface.html#User-Interface">User Interface</a></li>
|
||||
<li><a href="User-Interface.html#index-ui_005fout_005ftext-93"><code>ui_out_text</code></a>: <a href="User-Interface.html#User-Interface">User Interface</a></li>
|
||||
<li><a href="User-Interface.html#index-ui_005fout_005ftuple_005fbegin-75"><code>ui_out_tuple_begin</code></a>: <a href="User-Interface.html#User-Interface">User Interface</a></li>
|
||||
<li><a href="User-Interface.html#index-ui_005fout_005ftuple_005fend-76"><code>ui_out_tuple_end</code></a>: <a href="User-Interface.html#User-Interface">User Interface</a></li>
|
||||
<li><a href="User-Interface.html#index-ui_005fout_005fwrap_005fhint-96"><code>ui_out_wrap_hint</code></a>: <a href="User-Interface.html#User-Interface">User Interface</a></li>
|
||||
<li><a href="Functions-Creating-Dummy-Frames.html#index-unwind_005fdummy_005fid-356"><code>unwind_dummy_id</code></a>: <a href="Functions-Creating-Dummy-Frames.html#Functions-Creating-Dummy-Frames">Functions Creating Dummy Frames</a></li>
|
||||
<li><a href="Functions-to-Access-Frame-Data.html#index-unwind_005fpc-345"><code>unwind_pc</code></a>: <a href="Functions-to-Access-Frame-Data.html#Functions-to-Access-Frame-Data">Functions to Access Frame Data</a></li>
|
||||
<li><a href="Functions-to-Access-Frame-Data.html#index-unwind_005fsp-346"><code>unwind_sp</code></a>: <a href="Functions-to-Access-Frame-Data.html#Functions-to-Access-Frame-Data">Functions to Access Frame Data</a></li>
|
||||
<li><a href="Pointers-and-Addresses.html#index-value_005fas_005faddress-250"><code>value_as_address</code></a>: <a href="Pointers-and-Addresses.html#Pointers-and-Addresses">Pointers and Addresses</a></li>
|
||||
<li><a href="Pointers-and-Addresses.html#index-value_005ffrom_005fpointer-251"><code>value_from_pointer</code></a>: <a href="Pointers-and-Addresses.html#Pointers-and-Addresses">Pointers and Addresses</a></li>
|
||||
<li><a href="GDB-Observers.html#index-void-507"><code>void</code></a>: <a href="GDB-Observers.html#GDB-Observers">GDB Observers</a></li>
|
||||
<li><a href="Host-Definition.html#index-volatile-191"><code>volatile</code></a>: <a href="Host-Definition.html#Host-Definition">Host Definition</a></li>
|
||||
<li><a href="Misc-Guidelines.html#index-wrap_005fhere-472"><code>wrap_here</code></a>: <a href="Misc-Guidelines.html#Misc-Guidelines">Misc Guidelines</a></li>
|
||||
<li><a href="Register-Architecture-Functions-_0026-Variables.html#index-write_005fpc-265"><code>write_pc</code></a>: <a href="Register-Architecture-Functions-_0026-Variables.html#Register-Architecture-Functions-_0026-Variables">Register Architecture Functions & Variables</a></li>
|
||||
</ul></body></html>
|
||||
|
||||
|
|
@ -0,0 +1,130 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>Functions Creating Dummy Frames - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="up" href="Inferior-Call-Setup.html#Inferior-Call-Setup" title="Inferior Call Setup">
|
||||
<link rel="prev" href="About-Dummy-Frames.html#About-Dummy-Frames" title="About Dummy Frames">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Functions-Creating-Dummy-Frames"></a>
|
||||
Previous: <a rel="previous" accesskey="p" href="About-Dummy-Frames.html#About-Dummy-Frames">About Dummy Frames</a>,
|
||||
Up: <a rel="up" accesskey="u" href="Inferior-Call-Setup.html#Inferior-Call-Setup">Inferior Call Setup</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h4 class="subsection">11.8.2 Functions Creating Dummy Frames</h4>
|
||||
|
||||
<p>The following functions provide the functionality to set up such
|
||||
<dfn>dummy</dfn> stack frames.
|
||||
|
||||
<div class="defun">
|
||||
— Architecture Function: CORE_ADDR <b>push_dummy_call</b> (<var>struct gdbarch *gdbarch, struct value *function, struct regcache *regcache, CORE_ADDR bp_addr, int nargs, struct value **args, CORE_ADDR sp, int struct_return, CORE_ADDR struct_addr</var>)<var><a name="index-push_005fdummy_005fcall-355"></a></var><br>
|
||||
<blockquote>
|
||||
<p>This function sets up a dummy stack frame for the function about to be
|
||||
called. <code>push_dummy_call</code> is given the arguments to be passed
|
||||
and must copy them into registers or push them on to the stack as
|
||||
appropriate for the ABI.
|
||||
|
||||
<p><var>function</var> is a pointer to the function
|
||||
that will be called and <var>regcache</var> the register cache from which
|
||||
values should be obtained. <var>bp_addr</var> is the address to which the
|
||||
function should return (which is breakpointed, so <span class="sc">gdb</span> can
|
||||
regain control, hence the name). <var>nargs</var> is the number of
|
||||
arguments to pass and <var>args</var> an array containing the argument
|
||||
values. <var>struct_return</var> is non-zero (true) if the function returns
|
||||
a structure, and if so <var>struct_addr</var> is the address in which the
|
||||
structure should be returned.
|
||||
|
||||
<p>After calling this function, <span class="sc">gdb</span> will pass control to the
|
||||
target at the address of the function, which will find the stack and
|
||||
registers set up just as expected.
|
||||
|
||||
<p>The default value of this function is <code>NULL</code> (undefined). If the
|
||||
function is not defined, then <span class="sc">gdb</span> will not allow the user to
|
||||
call functions within the target being debugged.
|
||||
|
||||
</blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Architecture Function: struct frame_id <b>unwind_dummy_id</b> (<var>struct gdbarch *gdbarch, struct frame_info *next_frame</var>)<var><a name="index-unwind_005fdummy_005fid-356"></a></var><br>
|
||||
<blockquote>
|
||||
<p>This is the inverse of <code>push_dummy_call</code> which restores the stack
|
||||
pointer and program counter after a call to evaluate a function using
|
||||
a dummy stack frame. The result is a <code>struct frame_id<!-- /@w --></code>, which
|
||||
contains the value of the stack pointer and program counter to be
|
||||
used.
|
||||
|
||||
<p>The NEXT frame pointer is provided as argument,
|
||||
<var>next_frame</var>. THIS frame is the frame of the dummy function,
|
||||
which can be unwound, to yield the required stack pointer and program
|
||||
counter from the PREVIOUS frame.
|
||||
|
||||
<p>The default value is <code>NULL</code> (undefined). If <code>push_dummy_call</code> is
|
||||
defined, then this function should also be defined.
|
||||
|
||||
</blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Architecture Function: CORE_ADDR <b>push_dummy_code</b> (<var>struct gdbarch *gdbarch, CORE_ADDR sp, CORE_ADDR funaddr, struct value **args, int nargs, struct type *value_type, CORE_ADDR *real_pc, CORE_ADDR *bp_addr, struct regcache *regcache</var>)<var><a name="index-push_005fdummy_005fcode-357"></a></var><br>
|
||||
<blockquote>
|
||||
<p>If this function is not defined (its default value is <code>NULL</code>), a dummy
|
||||
call will use the entry point of the currently loaded code on the
|
||||
target as its return address. A temporary breakpoint will be set
|
||||
there, so the location must be writable and have room for a
|
||||
breakpoint.
|
||||
|
||||
<p>It is possible that this default is not suitable. It might not be
|
||||
writable (in ROM possibly), or the ABI might require code to be
|
||||
executed on return from a call to unwind the stack before the
|
||||
breakpoint is encountered.
|
||||
|
||||
<p>If either of these is the case, then push_dummy_code should be defined
|
||||
to push an instruction sequence onto the end of the stack to which the
|
||||
dummy call should return.
|
||||
|
||||
<p>The arguments are essentially the same as those to
|
||||
<code>push_dummy_call</code>. However the function is provided with the
|
||||
type of the function result, <var>value_type</var>, <var>bp_addr</var> is used
|
||||
to return a value (the address at which the breakpoint instruction
|
||||
should be inserted) and <var>real pc</var> is used to specify the resume
|
||||
address when starting the call sequence. The function should return
|
||||
the updated innermost stack address.
|
||||
|
||||
<blockquote>
|
||||
<em>Note:</em> This does require that code in the stack can be executed.
|
||||
Some Harvard architectures may not allow this.
|
||||
</blockquote>
|
||||
|
||||
</blockquote></div>
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,131 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>Functions and Variable to Analyze Frames - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="up" href="Frame-Interpretation.html#Frame-Interpretation" title="Frame Interpretation">
|
||||
<link rel="prev" href="Prologue-Caches.html#Prologue-Caches" title="Prologue Caches">
|
||||
<link rel="next" href="Functions-to-Access-Frame-Data.html#Functions-to-Access-Frame-Data" title="Functions to Access Frame Data">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Functions-and-Variable-to-Analyze-Frames"></a>
|
||||
Next: <a rel="next" accesskey="n" href="Functions-to-Access-Frame-Data.html#Functions-to-Access-Frame-Data">Functions to Access Frame Data</a>,
|
||||
Previous: <a rel="previous" accesskey="p" href="Prologue-Caches.html#Prologue-Caches">Prologue Caches</a>,
|
||||
Up: <a rel="up" accesskey="u" href="Frame-Interpretation.html#Frame-Interpretation">Frame Interpretation</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h4 class="subsection">11.7.4 Functions and Variable to Analyze Frames</h4>
|
||||
|
||||
<p>These struct <code>gdbarch</code> functions and variable should be defined
|
||||
to provide analysis of the stack frame and allow it to be adjusted as
|
||||
required.
|
||||
|
||||
<div class="defun">
|
||||
— Architecture Function: CORE_ADDR <b>skip_prologue</b> (<var>struct gdbarch *gdbarch, CORE_ADDR pc</var>)<var><a name="index-skip_005fprologue-337"></a></var><br>
|
||||
<blockquote>
|
||||
<p>The prologue of a function is the code at the beginning of the
|
||||
function which sets up the stack frame, saves the return address
|
||||
etc. The code representing the behavior of the function starts after
|
||||
the prologue.
|
||||
|
||||
<p>This function skips past the prologue of a function if the program
|
||||
counter, <var>pc</var>, is within the prologue of a function. The result is
|
||||
the program counter immediately after the prologue. With modern
|
||||
optimizing compilers, this may be a far from trivial exercise. However
|
||||
the required information may be within the binary as DWARF2 debugging
|
||||
information, making the job much easier.
|
||||
|
||||
<p>The default value is <code>NULL</code> (not defined). This function should always
|
||||
be provided, but can take advantage of DWARF2 debugging information,
|
||||
if that is available.
|
||||
|
||||
</blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Architecture Function: int <b>inner_than</b> (<var>CORE_ADDR lhs, CORE_ADDR rhs</var>)<var><a name="index-inner_005fthan-338"></a></var><br>
|
||||
<blockquote><p><a name="index-core_005faddr_005flessthan-339"></a><a name="index-core_005faddr_005fgreaterthan-340"></a>
|
||||
Given two frame or stack pointers, return non-zero (true) if the first
|
||||
represents the <dfn>inner</dfn> stack frame and 0 (false) otherwise. This
|
||||
is used to determine whether the target has a stack which grows up in
|
||||
memory (rising stack) or grows down in memory (falling stack).
|
||||
See <a href="All-About-Stack-Frames.html#All-About-Stack-Frames">All About Stack Frames</a>, for an
|
||||
explanation of <dfn>inner</dfn> frames.
|
||||
|
||||
<p>The default value of this function is <code>NULL</code> and it should always
|
||||
be defined. However for almost all architectures one of the built-in
|
||||
functions can be used: <code>core_addr_lessthan</code> (for stacks growing
|
||||
down in memory) or <code>core_addr_greaterthan</code> (for stacks growing up
|
||||
in memory).
|
||||
|
||||
</blockquote></div>
|
||||
|
||||
<p><a name="frame_005falign"></a>
|
||||
|
||||
<div class="defun">
|
||||
— Architecture Function: CORE_ADDR <b>frame_align</b> (<var>struct gdbarch *gdbarch, CORE_ADDR address</var>)<var><a name="index-frame_005falign-341"></a></var><br>
|
||||
<blockquote><p><a name="index-align_005fdown-342"></a><a name="index-align_005fup-343"></a>
|
||||
The architecture may have constraints on how its frames are
|
||||
aligned. For example the OpenRISC 1000 ABI requires stack frames to be
|
||||
double-word aligned, but 32-bit versions of the architecture allocate
|
||||
single-word values to the stack. Thus extra padding may be needed at
|
||||
the end of a stack frame.
|
||||
|
||||
<p>Given a proposed address for the stack pointer, this function
|
||||
returns a suitably aligned address (by expanding the stack frame).
|
||||
|
||||
<p>The default value is <code>NULL</code> (undefined). This function should be defined
|
||||
for any architecture where it is possible the stack could become
|
||||
misaligned. The utility functions <code>align_down</code> (for falling
|
||||
stacks) and <code>align_up</code> (for rising stacks) will facilitate the
|
||||
implementation of this function.
|
||||
|
||||
</blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Architecture Variable: int <b>frame_red_zone_size</b><var><a name="index-frame_005fred_005fzone_005fsize-344"></a></var><br>
|
||||
<blockquote>
|
||||
<p>Some ABIs reserve space beyond the end of the stack for use by leaf
|
||||
functions without prologue or epilogue or by exception handlers (for
|
||||
example the OpenRISC 1000).
|
||||
|
||||
<p>This is known as a <dfn>red zone</dfn> (AMD terminology). The <span class="sc">amd64</span>
|
||||
(nee x86-64) ABI documentation refers to the <dfn>red zone</dfn> when
|
||||
describing this scratch area.
|
||||
|
||||
<p>The default value is 0. Set this field if the architecture has such a
|
||||
red zone. The value must be aligned as required by the ABI (see
|
||||
<code>frame_align</code> above for an explanation of stack frame alignment).
|
||||
|
||||
</blockquote></div>
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,100 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>Functions to Access Frame Data - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="up" href="Frame-Interpretation.html#Frame-Interpretation" title="Frame Interpretation">
|
||||
<link rel="prev" href="Functions-and-Variable-to-Analyze-Frames.html#Functions-and-Variable-to-Analyze-Frames" title="Functions and Variable to Analyze Frames">
|
||||
<link rel="next" href="Analyzing-Stacks_002d_002d_002dFrame-Sniffers.html#Analyzing-Stacks_002d_002d_002dFrame-Sniffers" title="Analyzing Stacks---Frame Sniffers">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Functions-to-Access-Frame-Data"></a>
|
||||
Next: <a rel="next" accesskey="n" href="Analyzing-Stacks_002d_002d_002dFrame-Sniffers.html#Analyzing-Stacks_002d_002d_002dFrame-Sniffers">Analyzing Stacks---Frame Sniffers</a>,
|
||||
Previous: <a rel="previous" accesskey="p" href="Functions-and-Variable-to-Analyze-Frames.html#Functions-and-Variable-to-Analyze-Frames">Functions and Variable to Analyze Frames</a>,
|
||||
Up: <a rel="up" accesskey="u" href="Frame-Interpretation.html#Frame-Interpretation">Frame Interpretation</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h4 class="subsection">11.7.5 Functions to Access Frame Data</h4>
|
||||
|
||||
<p>These functions provide access to key registers and arguments in the
|
||||
stack frame.
|
||||
|
||||
<div class="defun">
|
||||
— Architecture Function: CORE_ADDR <b>unwind_pc</b> (<var>struct gdbarch *gdbarch, struct frame_info *next_frame</var>)<var><a name="index-unwind_005fpc-345"></a></var><br>
|
||||
<blockquote>
|
||||
<p>This function is given a pointer to the NEXT stack frame (see <a href="All-About-Stack-Frames.html#All-About-Stack-Frames">All About Stack Frames</a>, for how frames are
|
||||
represented) and returns the value of the program counter in the
|
||||
PREVIOUS frame (i.e. the frame of the function that called THIS
|
||||
one). This is commonly referred to as the <dfn>return address</dfn>.
|
||||
|
||||
<p>The implementation, which must be frame agnostic (work with any frame),
|
||||
is typically no more than:
|
||||
|
||||
<pre class="smallexample"> ULONGEST pc;
|
||||
pc = frame_unwind_register_unsigned (next_frame, <var>ARCH</var>_PC_REGNUM);
|
||||
return gdbarch_addr_bits_remove (gdbarch, pc);
|
||||
</pre>
|
||||
</blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Architecture Function: CORE_ADDR <b>unwind_sp</b> (<var>struct gdbarch *gdbarch, struct frame_info *next_frame</var>)<var><a name="index-unwind_005fsp-346"></a></var><br>
|
||||
<blockquote>
|
||||
<p>This function is given a pointer to the NEXT stack frame
|
||||
(see <a href="All-About-Stack-Frames.html#All-About-Stack-Frames">All About Stack Frames</a> for how
|
||||
frames are represented) and returns the value of the stack pointer in
|
||||
the PREVIOUS frame (i.e. the frame of the function that called
|
||||
THIS one).
|
||||
|
||||
<p>The implementation, which must be frame agnostic (work with any frame),
|
||||
is typically no more than:
|
||||
|
||||
<pre class="smallexample"> ULONGEST sp;
|
||||
sp = frame_unwind_register_unsigned (next_frame, <var>ARCH</var>_SP_REGNUM);
|
||||
return gdbarch_addr_bits_remove (gdbarch, sp);
|
||||
</pre>
|
||||
</blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Architecture Function: int <b>frame_num_args</b> (<var>struct gdbarch *gdbarch, struct frame_info *this_frame</var>)<var><a name="index-frame_005fnum_005fargs-347"></a></var><br>
|
||||
<blockquote>
|
||||
<p>This function is given a pointer to THIS stack frame (see <a href="All-About-Stack-Frames.html#All-About-Stack-Frames">All About Stack Frames</a> for how frames are
|
||||
represented), and returns the number of arguments that are being
|
||||
passed, or -1 if not known.
|
||||
|
||||
<p>The default value is <code>NULL</code> (undefined), in which case the number of
|
||||
arguments passed on any stack frame is always unknown. For many
|
||||
architectures this will be a suitable default.
|
||||
|
||||
</blockquote></div>
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,319 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>GDB Observers - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="prev" href="Hints.html#Hints" title="Hints">
|
||||
<link rel="next" href="GNU-Free-Documentation-License.html#GNU-Free-Documentation-License" title="GNU Free Documentation License">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="GDB-Observers"></a>
|
||||
Next: <a rel="next" accesskey="n" href="GNU-Free-Documentation-License.html#GNU-Free-Documentation-License">GNU Free Documentation License</a>,
|
||||
Previous: <a rel="previous" accesskey="p" href="Hints.html#Hints">Hints</a>,
|
||||
Up: <a rel="up" accesskey="u" href="index.html#Top">Top</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h2 class="appendix">Appendix A <span class="sc">gdb</span> Currently available observers</h2>
|
||||
|
||||
<h3 class="section">A.1 Implementation rationale</h3>
|
||||
|
||||
<p><a name="index-observers-implementation-rationale-503"></a>
|
||||
An <dfn>observer</dfn> is an entity which is interested in being notified
|
||||
when GDB reaches certain states, or certain events occur in GDB.
|
||||
The entity being observed is called the <dfn>subject</dfn>. To receive
|
||||
notifications, the observer attaches a callback to the subject.
|
||||
One subject can have several observers.
|
||||
|
||||
<p><samp><span class="file">observer.c</span></samp> implements an internal generic low-level event
|
||||
notification mechanism. This generic event notification mechanism is
|
||||
then re-used to implement the exported high-level notification
|
||||
management routines for all possible notifications.
|
||||
|
||||
<p>The current implementation of the generic observer provides support
|
||||
for contextual data. This contextual data is given to the subject
|
||||
when attaching the callback. In return, the subject will provide
|
||||
this contextual data back to the observer as a parameter of the
|
||||
callback.
|
||||
|
||||
<p>Note that the current support for the contextual data is only partial,
|
||||
as it lacks a mechanism that would deallocate this data when the
|
||||
callback is detached. This is not a problem so far, as this contextual
|
||||
data is only used internally to hold a function pointer. Later on, if
|
||||
a certain observer needs to provide support for user-level contextual
|
||||
data, then the generic notification mechanism will need to be
|
||||
enhanced to allow the observer to provide a routine to deallocate the
|
||||
data when attaching the callback.
|
||||
|
||||
<p>The observer implementation is also currently not reentrant.
|
||||
In particular, it is therefore not possible to call the attach
|
||||
or detach routines during a notification.
|
||||
|
||||
<h3 class="section">A.2 Debugging</h3>
|
||||
|
||||
<p>Observer notifications can be traced using the command ‘<samp><span class="samp">set debug
|
||||
observer 1</span></samp>’ (see <a href="../gdb/Debugging-Output.html#Debugging-Output">Optional messages about internal happenings</a>).
|
||||
|
||||
<h3 class="section">A.3 <code>normal_stop</code> Notifications</h3>
|
||||
|
||||
<p><a name="index-g_t_0040code_007bnormal_005fstop_007d-observer-504"></a><a name="index-notification-about-inferior-execution-stop-505"></a>
|
||||
<span class="sc">gdb</span> notifies all <code>normal_stop</code> observers when the
|
||||
inferior execution has just stopped, the associated messages and
|
||||
annotations have been printed, and the control is about to be returned
|
||||
to the user.
|
||||
|
||||
<p>Note that the <code>normal_stop</code> notification is not emitted when
|
||||
the execution stops due to a breakpoint, and this breakpoint has
|
||||
a condition that is not met. If the breakpoint has any associated
|
||||
commands list, the commands are executed after the notification
|
||||
is emitted.
|
||||
|
||||
<p>The following interfaces are available to manage observers:
|
||||
|
||||
<div class="defun">
|
||||
— Function: extern <b>struct</b><var> observer *observer_attach_event </var>(<var>observer_event_ftype *f</var>)<var><a name="index-struct-506"></a></var><br>
|
||||
<blockquote><p>Using the function <var>f</var>, create an observer that is notified when
|
||||
ever <var>event</var> occurs, return the observer.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: extern <b>void</b><var> observer_detach_event </var>(<var>struct observer *observer</var>)<var>;<a name="index-void-507"></a></var><br>
|
||||
<blockquote><p>Remove <var>observer</var> from the list of observers to be notified when
|
||||
<var>event</var> occurs.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: extern <b>void</b><var> observer_notify_event </var>(<var>void</var>)<var>;<a name="index-void-508"></a></var><br>
|
||||
<blockquote><p>Send a notification to all <var>event</var> observers.
|
||||
</p></blockquote></div>
|
||||
|
||||
<p>The following observable events are defined:
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>normal_stop</b> (<var>struct bpstats *bs, int print_frame</var>)<var><a name="index-normal_005fstop-509"></a></var><br>
|
||||
<blockquote><p>The inferior has stopped for real. The <var>bs</var> argument describes
|
||||
the breakpoints were are stopped at, if any. Second argument
|
||||
<var>print_frame</var> non-zero means display the location where the
|
||||
inferior has stopped.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>target_changed</b> (<var>struct target_ops *target</var>)<var><a name="index-target_005fchanged-510"></a></var><br>
|
||||
<blockquote><p>The target's register contents have changed.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>executable_changed</b> (<var>void</var>)<var><a name="index-executable_005fchanged-511"></a></var><br>
|
||||
<blockquote><p>The executable being debugged by GDB has changed: The user decided
|
||||
to debug a different program, or the program he was debugging has
|
||||
been modified since being loaded by the debugger (by being recompiled,
|
||||
for instance).
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>inferior_created</b> (<var>struct target_ops *objfile, int from_tty</var>)<var><a name="index-inferior_005fcreated-512"></a></var><br>
|
||||
<blockquote><p><span class="sc">gdb</span> has just connected to an inferior. For ‘<samp><span class="samp">run</span></samp>’,
|
||||
<span class="sc">gdb</span> calls this observer while the inferior is still stopped
|
||||
at the entry-point instruction. For ‘<samp><span class="samp">attach</span></samp>’ and ‘<samp><span class="samp">core</span></samp>’,
|
||||
<span class="sc">gdb</span> calls this observer immediately after connecting to the
|
||||
inferior, and before any information on the inferior has been printed.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>record_changed</b> (<var>struct inferior *inferior, int started</var>)<var><a name="index-record_005fchanged-513"></a></var><br>
|
||||
<blockquote><p>The status of process record for inferior <var>inferior</var> in
|
||||
<span class="sc">gdb</span> has changed. The process record is started if
|
||||
<var>started</var> is true, and the process record is stopped if
|
||||
<var>started</var> is false.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>solib_loaded</b> (<var>struct so_list *solib</var>)<var><a name="index-solib_005floaded-514"></a></var><br>
|
||||
<blockquote><p>The shared library specified by <var>solib</var> has been loaded. Note that
|
||||
when <span class="sc">gdb</span> calls this observer, the library's symbols probably
|
||||
haven't been loaded yet.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>solib_unloaded</b> (<var>struct so_list *solib</var>)<var><a name="index-solib_005funloaded-515"></a></var><br>
|
||||
<blockquote><p>The shared library specified by <var>solib</var> has been unloaded.
|
||||
Note that when <span class="sc">gdb</span> calls this observer, the library's
|
||||
symbols have not been unloaded yet, and thus are still available.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>new_objfile</b> (<var>struct objfile *objfile</var>)<var><a name="index-new_005fobjfile-516"></a></var><br>
|
||||
<blockquote><p>The symbol file specified by <var>objfile</var> has been loaded.
|
||||
Called with <var>objfile</var> equal to <code>NULL</code> to indicate
|
||||
previously loaded symbol table data has now been invalidated.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>new_thread</b> (<var>struct thread_info *t</var>)<var><a name="index-new_005fthread-517"></a></var><br>
|
||||
<blockquote><p>The thread specified by <var>t</var> has been created.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>thread_exit</b> (<var>struct thread_info *t, int silent</var>)<var><a name="index-thread_005fexit-518"></a></var><br>
|
||||
<blockquote><p>The thread specified by <var>t</var> has exited. The <var>silent</var> argument
|
||||
indicates that <span class="sc">gdb</span> is removing the thread from its tables
|
||||
without wanting to notify the user about it.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>thread_stop_requested</b> (<var>ptid_t ptid</var>)<var><a name="index-thread_005fstop_005frequested-519"></a></var><br>
|
||||
<blockquote><p>An explicit stop request was issued to <var>ptid</var>. If <var>ptid</var>
|
||||
equals <var>minus_one_ptid</var>, the request applied to all threads. If
|
||||
<code>ptid_is_pid(ptid)</code> returns true, the request applied to all
|
||||
threads of the process pointed at by <var>ptid</var>. Otherwise, the
|
||||
request applied to the single thread pointed at by <var>ptid</var>.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>target_resumed</b> (<var>ptid_t ptid</var>)<var><a name="index-target_005fresumed-520"></a></var><br>
|
||||
<blockquote><p>The target was resumed. The <var>ptid</var> parameter specifies which
|
||||
thread was resume, and may be RESUME_ALL if all threads are resumed.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>about_to_proceed</b> (<var>void</var>)<var><a name="index-about_005fto_005fproceed-521"></a></var><br>
|
||||
<blockquote><p>The target is about to be proceeded.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>breakpoint_created</b> (<var>struct breakpoint *b</var>)<var><a name="index-breakpoint_005fcreated-522"></a></var><br>
|
||||
<blockquote><p>A new breakpoint <var>b</var> has been created.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>breakpoint_deleted</b> (<var>struct breakpoint *b</var>)<var><a name="index-breakpoint_005fdeleted-523"></a></var><br>
|
||||
<blockquote><p>A breakpoint has been destroyed. The argument <var>b</var> is the
|
||||
pointer to the destroyed breakpoint.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>breakpoint_modified</b> (<var>struct breakpoint *b</var>)<var><a name="index-breakpoint_005fmodified-524"></a></var><br>
|
||||
<blockquote><p>A breakpoint has been modified in some way. The argument <var>b</var>
|
||||
is the modified breakpoint.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>traceframe_changed</b> (<var>int tfnum, int tpnum</var>)<var><a name="index-traceframe_005fchanged-525"></a></var><br>
|
||||
<blockquote><p>The trace frame is changed to <var>tfnum</var> (e.g., by using the
|
||||
<code>tfind</code> command). If <var>tfnum</var> is negative, it means
|
||||
<span class="sc">gdb</span> resumes live debugging. The number of the tracepoint
|
||||
associated with this traceframe is <var>tpnum</var>.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>architecture_changed</b> (<var>struct gdbarch *newarch</var>)<var><a name="index-architecture_005fchanged-526"></a></var><br>
|
||||
<blockquote><p>The current architecture has changed. The argument <var>newarch</var> is
|
||||
a pointer to the new architecture.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>thread_ptid_changed</b> (<var>ptid_t old_ptid, ptid_t new_ptid</var>)<var><a name="index-thread_005fptid_005fchanged-527"></a></var><br>
|
||||
<blockquote><p>The thread's ptid has changed. The <var>old_ptid</var> parameter specifies
|
||||
the old value, and <var>new_ptid</var> specifies the new value.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>inferior_added</b> (<var>struct inferior *inf</var>)<var><a name="index-inferior_005fadded-528"></a></var><br>
|
||||
<blockquote><p>The inferior <var>inf</var> has been added to the list of inferiors. At
|
||||
this point, it might not be associated with any process.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>inferior_appeared</b> (<var>struct inferior *inf</var>)<var><a name="index-inferior_005fappeared-529"></a></var><br>
|
||||
<blockquote><p>The inferior identified by <var>inf</var> has been attached to a process.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>inferior_exit</b> (<var>struct inferior *inf</var>)<var><a name="index-inferior_005fexit-530"></a></var><br>
|
||||
<blockquote><p>Either the inferior associated with <var>inf</var> has been detached from the
|
||||
process, or the process has exited.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>inferior_removed</b> (<var>struct inferior *inf</var>)<var><a name="index-inferior_005fremoved-531"></a></var><br>
|
||||
<blockquote><p>The inferior <var>inf</var> has been removed from the list of inferiors.
|
||||
This method is called immediately before freeing <var>inf</var>.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>memory_changed</b> (<var>struct inferior *inferior, CORE_ADDR addr, ssize_t len, const bfd_byte *data</var>)<var><a name="index-memory_005fchanged-532"></a></var><br>
|
||||
<blockquote><p>Bytes from <var>data</var> to <var>data</var> + <var>len</var> have been written
|
||||
to the <var>inferior</var> at <var>addr</var>.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>before_prompt</b> (<var>const char *current_prompt</var>)<var><a name="index-before_005fprompt-533"></a></var><br>
|
||||
<blockquote><p>Called before a top-level prompt is displayed. <var>current_prompt</var> is
|
||||
the current top-level prompt.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>gdb_datadir_changed</b> (<var>void</var>)<var><a name="index-gdb_005fdatadir_005fchanged-534"></a></var><br>
|
||||
<blockquote><p>Variable gdb_datadir has been set. The value may not necessarily change.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>command_param_changed</b> (<var>const char *param, const char *value</var>)<var><a name="index-command_005fparam_005fchanged-535"></a></var><br>
|
||||
<blockquote><p>The parameter of some <code>set</code> commands in console are changed. This
|
||||
method is called after a command <code>set </code><var>param</var> <var>value</var>.
|
||||
<var>param</var> is the parameter of <code>set</code> command, and <var>value</var>
|
||||
is the value of changed parameter.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>tsv_created</b> (<var>const struct trace_state_variable *tsv</var>)<var><a name="index-tsv_005fcreated-536"></a></var><br>
|
||||
<blockquote><p>The new trace state variable <var>tsv</var> is created.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>tsv_deleted</b> (<var>const struct trace_state_variable *tsv</var>)<var><a name="index-tsv_005fdeleted-537"></a></var><br>
|
||||
<blockquote><p>The trace state variable <var>tsv</var> is deleted. If <var>tsv</var> is
|
||||
<code>NULL</code>, all trace state variables are deleted.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>tsv_modified</b> (<var>const struct trace_state_variable *tsv</var>)<var><a name="index-tsv_005fmodified-538"></a></var><br>
|
||||
<blockquote><p>The trace state value <var>tsv</var> is modified.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>test_notification</b> (<var>int somearg</var>)<var><a name="index-test_005fnotification-539"></a></var><br>
|
||||
<blockquote><p>This observer is used for internal testing. Do not use.
|
||||
See testsuite/gdb.gdb/observer.exp.
|
||||
</p></blockquote></div>
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,514 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>GNU Free Documentation License - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="prev" href="GDB-Observers.html#GDB-Observers" title="GDB Observers">
|
||||
<link rel="next" href="Concept-Index.html#Concept-Index" title="Concept Index">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="GNU-Free-Documentation-License"></a>
|
||||
Next: <a rel="next" accesskey="n" href="Concept-Index.html#Concept-Index">Concept Index</a>,
|
||||
Previous: <a rel="previous" accesskey="p" href="GDB-Observers.html#GDB-Observers">GDB Observers</a>,
|
||||
Up: <a rel="up" accesskey="u" href="index.html#Top">Top</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h2 class="appendix">Appendix B GNU Free Documentation License</h2>
|
||||
|
||||
<!-- The GNU Free Documentation License. -->
|
||||
<div align="center">Version 1.3, 3 November 2008</div>
|
||||
|
||||
<!-- This file is intended to be included within another document, -->
|
||||
<!-- hence no sectioning command or @node. -->
|
||||
<pre class="display"> Copyright © 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
|
||||
<a href="http://fsf.org/">http://fsf.org/</a>
|
||||
|
||||
Everyone is permitted to copy and distribute verbatim copies
|
||||
of this license document, but changing it is not allowed.
|
||||
</pre>
|
||||
<ol type=1 start=0>
|
||||
<li>PREAMBLE
|
||||
|
||||
<p>The purpose of this License is to make a manual, textbook, or other
|
||||
functional and useful document <dfn>free</dfn> in the sense of freedom: to
|
||||
assure everyone the effective freedom to copy and redistribute it,
|
||||
with or without modifying it, either commercially or noncommercially.
|
||||
Secondarily, this License preserves for the author and publisher a way
|
||||
to get credit for their work, while not being considered responsible
|
||||
for modifications made by others.
|
||||
|
||||
<p>This License is a kind of “copyleft”, which means that derivative
|
||||
works of the document must themselves be free in the same sense. It
|
||||
complements the GNU General Public License, which is a copyleft
|
||||
license designed for free software.
|
||||
|
||||
<p>We have designed this License in order to use it for manuals for free
|
||||
software, because free software needs free documentation: a free
|
||||
program should come with manuals providing the same freedoms that the
|
||||
software does. But this License is not limited to software manuals;
|
||||
it can be used for any textual work, regardless of subject matter or
|
||||
whether it is published as a printed book. We recommend this License
|
||||
principally for works whose purpose is instruction or reference.
|
||||
|
||||
<li>APPLICABILITY AND DEFINITIONS
|
||||
|
||||
<p>This License applies to any manual or other work, in any medium, that
|
||||
contains a notice placed by the copyright holder saying it can be
|
||||
distributed under the terms of this License. Such a notice grants a
|
||||
world-wide, royalty-free license, unlimited in duration, to use that
|
||||
work under the conditions stated herein. The “Document”, below,
|
||||
refers to any such manual or work. Any member of the public is a
|
||||
licensee, and is addressed as “you”. You accept the license if you
|
||||
copy, modify or distribute the work in a way requiring permission
|
||||
under copyright law.
|
||||
|
||||
<p>A “Modified Version” of the Document means any work containing the
|
||||
Document or a portion of it, either copied verbatim, or with
|
||||
modifications and/or translated into another language.
|
||||
|
||||
<p>A “Secondary Section” is a named appendix or a front-matter section
|
||||
of the Document that deals exclusively with the relationship of the
|
||||
publishers or authors of the Document to the Document's overall
|
||||
subject (or to related matters) and contains nothing that could fall
|
||||
directly within that overall subject. (Thus, if the Document is in
|
||||
part a textbook of mathematics, a Secondary Section may not explain
|
||||
any mathematics.) The relationship could be a matter of historical
|
||||
connection with the subject or with related matters, or of legal,
|
||||
commercial, philosophical, ethical or political position regarding
|
||||
them.
|
||||
|
||||
<p>The “Invariant Sections” are certain Secondary Sections whose titles
|
||||
are designated, as being those of Invariant Sections, in the notice
|
||||
that says that the Document is released under this License. If a
|
||||
section does not fit the above definition of Secondary then it is not
|
||||
allowed to be designated as Invariant. The Document may contain zero
|
||||
Invariant Sections. If the Document does not identify any Invariant
|
||||
Sections then there are none.
|
||||
|
||||
<p>The “Cover Texts” are certain short passages of text that are listed,
|
||||
as Front-Cover Texts or Back-Cover Texts, in the notice that says that
|
||||
the Document is released under this License. A Front-Cover Text may
|
||||
be at most 5 words, and a Back-Cover Text may be at most 25 words.
|
||||
|
||||
<p>A “Transparent” copy of the Document means a machine-readable copy,
|
||||
represented in a format whose specification is available to the
|
||||
general public, that is suitable for revising the document
|
||||
straightforwardly with generic text editors or (for images composed of
|
||||
pixels) generic paint programs or (for drawings) some widely available
|
||||
drawing editor, and that is suitable for input to text formatters or
|
||||
for automatic translation to a variety of formats suitable for input
|
||||
to text formatters. A copy made in an otherwise Transparent file
|
||||
format whose markup, or absence of markup, has been arranged to thwart
|
||||
or discourage subsequent modification by readers is not Transparent.
|
||||
An image format is not Transparent if used for any substantial amount
|
||||
of text. A copy that is not “Transparent” is called “Opaque”.
|
||||
|
||||
<p>Examples of suitable formats for Transparent copies include plain
|
||||
<span class="sc">ascii</span> without markup, Texinfo input format, LaTeX input
|
||||
format, <acronym>SGML</acronym> or <acronym>XML</acronym> using a publicly available
|
||||
<acronym>DTD</acronym>, and standard-conforming simple <acronym>HTML</acronym>,
|
||||
PostScript or <acronym>PDF</acronym> designed for human modification. Examples
|
||||
of transparent image formats include <acronym>PNG</acronym>, <acronym>XCF</acronym> and
|
||||
<acronym>JPG</acronym>. Opaque formats include proprietary formats that can be
|
||||
read and edited only by proprietary word processors, <acronym>SGML</acronym> or
|
||||
<acronym>XML</acronym> for which the <acronym>DTD</acronym> and/or processing tools are
|
||||
not generally available, and the machine-generated <acronym>HTML</acronym>,
|
||||
PostScript or <acronym>PDF</acronym> produced by some word processors for
|
||||
output purposes only.
|
||||
|
||||
<p>The “Title Page” means, for a printed book, the title page itself,
|
||||
plus such following pages as are needed to hold, legibly, the material
|
||||
this License requires to appear in the title page. For works in
|
||||
formats which do not have any title page as such, “Title Page” means
|
||||
the text near the most prominent appearance of the work's title,
|
||||
preceding the beginning of the body of the text.
|
||||
|
||||
<p>The “publisher” means any person or entity that distributes copies
|
||||
of the Document to the public.
|
||||
|
||||
<p>A section “Entitled XYZ” means a named subunit of the Document whose
|
||||
title either is precisely XYZ or contains XYZ in parentheses following
|
||||
text that translates XYZ in another language. (Here XYZ stands for a
|
||||
specific section name mentioned below, such as “Acknowledgements”,
|
||||
“Dedications”, “Endorsements”, or “History”.) To “Preserve the Title”
|
||||
of such a section when you modify the Document means that it remains a
|
||||
section “Entitled XYZ” according to this definition.
|
||||
|
||||
<p>The Document may include Warranty Disclaimers next to the notice which
|
||||
states that this License applies to the Document. These Warranty
|
||||
Disclaimers are considered to be included by reference in this
|
||||
License, but only as regards disclaiming warranties: any other
|
||||
implication that these Warranty Disclaimers may have is void and has
|
||||
no effect on the meaning of this License.
|
||||
|
||||
<li>VERBATIM COPYING
|
||||
|
||||
<p>You may copy and distribute the Document in any medium, either
|
||||
commercially or noncommercially, provided that this License, the
|
||||
copyright notices, and the license notice saying this License applies
|
||||
to the Document are reproduced in all copies, and that you add no other
|
||||
conditions whatsoever to those of this License. You may not use
|
||||
technical measures to obstruct or control the reading or further
|
||||
copying of the copies you make or distribute. However, you may accept
|
||||
compensation in exchange for copies. If you distribute a large enough
|
||||
number of copies you must also follow the conditions in section 3.
|
||||
|
||||
<p>You may also lend copies, under the same conditions stated above, and
|
||||
you may publicly display copies.
|
||||
|
||||
<li>COPYING IN QUANTITY
|
||||
|
||||
<p>If you publish printed copies (or copies in media that commonly have
|
||||
printed covers) of the Document, numbering more than 100, and the
|
||||
Document's license notice requires Cover Texts, you must enclose the
|
||||
copies in covers that carry, clearly and legibly, all these Cover
|
||||
Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on
|
||||
the back cover. Both covers must also clearly and legibly identify
|
||||
you as the publisher of these copies. The front cover must present
|
||||
the full title with all words of the title equally prominent and
|
||||
visible. You may add other material on the covers in addition.
|
||||
Copying with changes limited to the covers, as long as they preserve
|
||||
the title of the Document and satisfy these conditions, can be treated
|
||||
as verbatim copying in other respects.
|
||||
|
||||
<p>If the required texts for either cover are too voluminous to fit
|
||||
legibly, you should put the first ones listed (as many as fit
|
||||
reasonably) on the actual cover, and continue the rest onto adjacent
|
||||
pages.
|
||||
|
||||
<p>If you publish or distribute Opaque copies of the Document numbering
|
||||
more than 100, you must either include a machine-readable Transparent
|
||||
copy along with each Opaque copy, or state in or with each Opaque copy
|
||||
a computer-network location from which the general network-using
|
||||
public has access to download using public-standard network protocols
|
||||
a complete Transparent copy of the Document, free of added material.
|
||||
If you use the latter option, you must take reasonably prudent steps,
|
||||
when you begin distribution of Opaque copies in quantity, to ensure
|
||||
that this Transparent copy will remain thus accessible at the stated
|
||||
location until at least one year after the last time you distribute an
|
||||
Opaque copy (directly or through your agents or retailers) of that
|
||||
edition to the public.
|
||||
|
||||
<p>It is requested, but not required, that you contact the authors of the
|
||||
Document well before redistributing any large number of copies, to give
|
||||
them a chance to provide you with an updated version of the Document.
|
||||
|
||||
<li>MODIFICATIONS
|
||||
|
||||
<p>You may copy and distribute a Modified Version of the Document under
|
||||
the conditions of sections 2 and 3 above, provided that you release
|
||||
the Modified Version under precisely this License, with the Modified
|
||||
Version filling the role of the Document, thus licensing distribution
|
||||
and modification of the Modified Version to whoever possesses a copy
|
||||
of it. In addition, you must do these things in the Modified Version:
|
||||
|
||||
<ol type=A start=1>
|
||||
<li>Use in the Title Page (and on the covers, if any) a title distinct
|
||||
from that of the Document, and from those of previous versions
|
||||
(which should, if there were any, be listed in the History section
|
||||
of the Document). You may use the same title as a previous version
|
||||
if the original publisher of that version gives permission.
|
||||
|
||||
<li>List on the Title Page, as authors, one or more persons or entities
|
||||
responsible for authorship of the modifications in the Modified
|
||||
Version, together with at least five of the principal authors of the
|
||||
Document (all of its principal authors, if it has fewer than five),
|
||||
unless they release you from this requirement.
|
||||
|
||||
<li>State on the Title page the name of the publisher of the
|
||||
Modified Version, as the publisher.
|
||||
|
||||
<li>Preserve all the copyright notices of the Document.
|
||||
|
||||
<li>Add an appropriate copyright notice for your modifications
|
||||
adjacent to the other copyright notices.
|
||||
|
||||
<li>Include, immediately after the copyright notices, a license notice
|
||||
giving the public permission to use the Modified Version under the
|
||||
terms of this License, in the form shown in the Addendum below.
|
||||
|
||||
<li>Preserve in that license notice the full lists of Invariant Sections
|
||||
and required Cover Texts given in the Document's license notice.
|
||||
|
||||
<li>Include an unaltered copy of this License.
|
||||
|
||||
<li>Preserve the section Entitled “History”, Preserve its Title, and add
|
||||
to it an item stating at least the title, year, new authors, and
|
||||
publisher of the Modified Version as given on the Title Page. If
|
||||
there is no section Entitled “History” in the Document, create one
|
||||
stating the title, year, authors, and publisher of the Document as
|
||||
given on its Title Page, then add an item describing the Modified
|
||||
Version as stated in the previous sentence.
|
||||
|
||||
<li>Preserve the network location, if any, given in the Document for
|
||||
public access to a Transparent copy of the Document, and likewise
|
||||
the network locations given in the Document for previous versions
|
||||
it was based on. These may be placed in the “History” section.
|
||||
You may omit a network location for a work that was published at
|
||||
least four years before the Document itself, or if the original
|
||||
publisher of the version it refers to gives permission.
|
||||
|
||||
<li>For any section Entitled “Acknowledgements” or “Dedications”, Preserve
|
||||
the Title of the section, and preserve in the section all the
|
||||
substance and tone of each of the contributor acknowledgements and/or
|
||||
dedications given therein.
|
||||
|
||||
<li>Preserve all the Invariant Sections of the Document,
|
||||
unaltered in their text and in their titles. Section numbers
|
||||
or the equivalent are not considered part of the section titles.
|
||||
|
||||
<li>Delete any section Entitled “Endorsements”. Such a section
|
||||
may not be included in the Modified Version.
|
||||
|
||||
<li>Do not retitle any existing section to be Entitled “Endorsements” or
|
||||
to conflict in title with any Invariant Section.
|
||||
|
||||
<li>Preserve any Warranty Disclaimers.
|
||||
</ol>
|
||||
|
||||
<p>If the Modified Version includes new front-matter sections or
|
||||
appendices that qualify as Secondary Sections and contain no material
|
||||
copied from the Document, you may at your option designate some or all
|
||||
of these sections as invariant. To do this, add their titles to the
|
||||
list of Invariant Sections in the Modified Version's license notice.
|
||||
These titles must be distinct from any other section titles.
|
||||
|
||||
<p>You may add a section Entitled “Endorsements”, provided it contains
|
||||
nothing but endorsements of your Modified Version by various
|
||||
parties—for example, statements of peer review or that the text has
|
||||
been approved by an organization as the authoritative definition of a
|
||||
standard.
|
||||
|
||||
<p>You may add a passage of up to five words as a Front-Cover Text, and a
|
||||
passage of up to 25 words as a Back-Cover Text, to the end of the list
|
||||
of Cover Texts in the Modified Version. Only one passage of
|
||||
Front-Cover Text and one of Back-Cover Text may be added by (or
|
||||
through arrangements made by) any one entity. If the Document already
|
||||
includes a cover text for the same cover, previously added by you or
|
||||
by arrangement made by the same entity you are acting on behalf of,
|
||||
you may not add another; but you may replace the old one, on explicit
|
||||
permission from the previous publisher that added the old one.
|
||||
|
||||
<p>The author(s) and publisher(s) of the Document do not by this License
|
||||
give permission to use their names for publicity for or to assert or
|
||||
imply endorsement of any Modified Version.
|
||||
|
||||
<li>COMBINING DOCUMENTS
|
||||
|
||||
<p>You may combine the Document with other documents released under this
|
||||
License, under the terms defined in section 4 above for modified
|
||||
versions, provided that you include in the combination all of the
|
||||
Invariant Sections of all of the original documents, unmodified, and
|
||||
list them all as Invariant Sections of your combined work in its
|
||||
license notice, and that you preserve all their Warranty Disclaimers.
|
||||
|
||||
<p>The combined work need only contain one copy of this License, and
|
||||
multiple identical Invariant Sections may be replaced with a single
|
||||
copy. If there are multiple Invariant Sections with the same name but
|
||||
different contents, make the title of each such section unique by
|
||||
adding at the end of it, in parentheses, the name of the original
|
||||
author or publisher of that section if known, or else a unique number.
|
||||
Make the same adjustment to the section titles in the list of
|
||||
Invariant Sections in the license notice of the combined work.
|
||||
|
||||
<p>In the combination, you must combine any sections Entitled “History”
|
||||
in the various original documents, forming one section Entitled
|
||||
“History”; likewise combine any sections Entitled “Acknowledgements”,
|
||||
and any sections Entitled “Dedications”. You must delete all
|
||||
sections Entitled “Endorsements.”
|
||||
|
||||
<li>COLLECTIONS OF DOCUMENTS
|
||||
|
||||
<p>You may make a collection consisting of the Document and other documents
|
||||
released under this License, and replace the individual copies of this
|
||||
License in the various documents with a single copy that is included in
|
||||
the collection, provided that you follow the rules of this License for
|
||||
verbatim copying of each of the documents in all other respects.
|
||||
|
||||
<p>You may extract a single document from such a collection, and distribute
|
||||
it individually under this License, provided you insert a copy of this
|
||||
License into the extracted document, and follow this License in all
|
||||
other respects regarding verbatim copying of that document.
|
||||
|
||||
<li>AGGREGATION WITH INDEPENDENT WORKS
|
||||
|
||||
<p>A compilation of the Document or its derivatives with other separate
|
||||
and independent documents or works, in or on a volume of a storage or
|
||||
distribution medium, is called an “aggregate” if the copyright
|
||||
resulting from the compilation is not used to limit the legal rights
|
||||
of the compilation's users beyond what the individual works permit.
|
||||
When the Document is included in an aggregate, this License does not
|
||||
apply to the other works in the aggregate which are not themselves
|
||||
derivative works of the Document.
|
||||
|
||||
<p>If the Cover Text requirement of section 3 is applicable to these
|
||||
copies of the Document, then if the Document is less than one half of
|
||||
the entire aggregate, the Document's Cover Texts may be placed on
|
||||
covers that bracket the Document within the aggregate, or the
|
||||
electronic equivalent of covers if the Document is in electronic form.
|
||||
Otherwise they must appear on printed covers that bracket the whole
|
||||
aggregate.
|
||||
|
||||
<li>TRANSLATION
|
||||
|
||||
<p>Translation is considered a kind of modification, so you may
|
||||
distribute translations of the Document under the terms of section 4.
|
||||
Replacing Invariant Sections with translations requires special
|
||||
permission from their copyright holders, but you may include
|
||||
translations of some or all Invariant Sections in addition to the
|
||||
original versions of these Invariant Sections. You may include a
|
||||
translation of this License, and all the license notices in the
|
||||
Document, and any Warranty Disclaimers, provided that you also include
|
||||
the original English version of this License and the original versions
|
||||
of those notices and disclaimers. In case of a disagreement between
|
||||
the translation and the original version of this License or a notice
|
||||
or disclaimer, the original version will prevail.
|
||||
|
||||
<p>If a section in the Document is Entitled “Acknowledgements”,
|
||||
“Dedications”, or “History”, the requirement (section 4) to Preserve
|
||||
its Title (section 1) will typically require changing the actual
|
||||
title.
|
||||
|
||||
<li>TERMINATION
|
||||
|
||||
<p>You may not copy, modify, sublicense, or distribute the Document
|
||||
except as expressly provided under this License. Any attempt
|
||||
otherwise to copy, modify, sublicense, or distribute it is void, and
|
||||
will automatically terminate your rights under this License.
|
||||
|
||||
<p>However, if you cease all violation of this License, then your license
|
||||
from a particular copyright holder is reinstated (a) provisionally,
|
||||
unless and until the copyright holder explicitly and finally
|
||||
terminates your license, and (b) permanently, if the copyright holder
|
||||
fails to notify you of the violation by some reasonable means prior to
|
||||
60 days after the cessation.
|
||||
|
||||
<p>Moreover, your license from a particular copyright holder is
|
||||
reinstated permanently if the copyright holder notifies you of the
|
||||
violation by some reasonable means, this is the first time you have
|
||||
received notice of violation of this License (for any work) from that
|
||||
copyright holder, and you cure the violation prior to 30 days after
|
||||
your receipt of the notice.
|
||||
|
||||
<p>Termination of your rights under this section does not terminate the
|
||||
licenses of parties who have received copies or rights from you under
|
||||
this License. If your rights have been terminated and not permanently
|
||||
reinstated, receipt of a copy of some or all of the same material does
|
||||
not give you any rights to use it.
|
||||
|
||||
<li>FUTURE REVISIONS OF THIS LICENSE
|
||||
|
||||
<p>The Free Software Foundation may publish new, revised versions
|
||||
of the GNU Free Documentation License from time to time. Such new
|
||||
versions will be similar in spirit to the present version, but may
|
||||
differ in detail to address new problems or concerns. See
|
||||
<a href="http://www.gnu.org/copyleft/">http://www.gnu.org/copyleft/</a>.
|
||||
|
||||
<p>Each version of the License is given a distinguishing version number.
|
||||
If the Document specifies that a particular numbered version of this
|
||||
License “or any later version” applies to it, you have the option of
|
||||
following the terms and conditions either of that specified version or
|
||||
of any later version that has been published (not as a draft) by the
|
||||
Free Software Foundation. If the Document does not specify a version
|
||||
number of this License, you may choose any version ever published (not
|
||||
as a draft) by the Free Software Foundation. If the Document
|
||||
specifies that a proxy can decide which future versions of this
|
||||
License can be used, that proxy's public statement of acceptance of a
|
||||
version permanently authorizes you to choose that version for the
|
||||
Document.
|
||||
|
||||
<li>RELICENSING
|
||||
|
||||
<p>“Massive Multiauthor Collaboration Site” (or “MMC Site”) means any
|
||||
World Wide Web server that publishes copyrightable works and also
|
||||
provides prominent facilities for anybody to edit those works. A
|
||||
public wiki that anybody can edit is an example of such a server. A
|
||||
“Massive Multiauthor Collaboration” (or “MMC”) contained in the
|
||||
site means any set of copyrightable works thus published on the MMC
|
||||
site.
|
||||
|
||||
<p>“CC-BY-SA” means the Creative Commons Attribution-Share Alike 3.0
|
||||
license published by Creative Commons Corporation, a not-for-profit
|
||||
corporation with a principal place of business in San Francisco,
|
||||
California, as well as future copyleft versions of that license
|
||||
published by that same organization.
|
||||
|
||||
<p>“Incorporate” means to publish or republish a Document, in whole or
|
||||
in part, as part of another Document.
|
||||
|
||||
<p>An MMC is “eligible for relicensing” if it is licensed under this
|
||||
License, and if all works that were first published under this License
|
||||
somewhere other than this MMC, and subsequently incorporated in whole
|
||||
or in part into the MMC, (1) had no cover texts or invariant sections,
|
||||
and (2) were thus incorporated prior to November 1, 2008.
|
||||
|
||||
<p>The operator of an MMC Site may republish an MMC contained in the site
|
||||
under CC-BY-SA on the same site at any time before August 1, 2009,
|
||||
provided the MMC is eligible for relicensing.
|
||||
|
||||
</ol>
|
||||
|
||||
<h3 class="heading">ADDENDUM: How to use this License for your documents</h3>
|
||||
|
||||
<p>To use this License in a document you have written, include a copy of
|
||||
the License in the document and put the following copyright and
|
||||
license notices just after the title page:
|
||||
|
||||
<pre class="smallexample"> Copyright (C) <var>year</var> <var>your name</var>.
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3
|
||||
or any later version published by the Free Software Foundation;
|
||||
with no Invariant Sections, no Front-Cover Texts, and no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.
|
||||
</pre>
|
||||
<p>If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts,
|
||||
replace the “with<small class="dots">...</small>Texts.” line with this:
|
||||
|
||||
<pre class="smallexample"> with the Invariant Sections being <var>list their titles</var>, with
|
||||
the Front-Cover Texts being <var>list</var>, and with the Back-Cover Texts
|
||||
being <var>list</var>.
|
||||
</pre>
|
||||
<p>If you have Invariant Sections without Cover Texts, or some other
|
||||
combination of the three, merge those two alternatives to suit the
|
||||
situation.
|
||||
|
||||
<p>If your document contains nontrivial examples of program code, we
|
||||
recommend releasing these examples in parallel under your choice of
|
||||
free software license, such as the GNU General Public License,
|
||||
to permit their use in free software.
|
||||
|
||||
<!-- Local Variables: -->
|
||||
<!-- ispell-local-pdict: "ispell-dict" -->
|
||||
<!-- End: -->
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,124 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>Getting Started - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="up" href="Hints.html#Hints" title="Hints">
|
||||
<link rel="next" href="Debugging-GDB.html#Debugging-GDB" title="Debugging GDB">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Getting-Started"></a>
|
||||
Next: <a rel="next" accesskey="n" href="Debugging-GDB.html#Debugging-GDB">Debugging GDB</a>,
|
||||
Up: <a rel="up" accesskey="u" href="Hints.html#Hints">Hints</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h3 class="section">23.1 Getting Started</h3>
|
||||
|
||||
<p><span class="sc">gdb</span> is a large and complicated program, and if you first starting to
|
||||
work on it, it can be hard to know where to start. Fortunately, if you
|
||||
know how to go about it, there are ways to figure out what is going on.
|
||||
|
||||
<p>This manual, the <span class="sc">gdb</span> Internals manual, has information which applies
|
||||
generally to many parts of <span class="sc">gdb</span>.
|
||||
|
||||
<p>Information about particular functions or data structures are located in
|
||||
comments with those functions or data structures. If you run across a
|
||||
function or a global variable which does not have a comment correctly
|
||||
explaining what is does, this can be thought of as a bug in <span class="sc">gdb</span>; feel
|
||||
free to submit a bug report, with a suggested comment if you can figure
|
||||
out what the comment should say. If you find a comment which is
|
||||
actually wrong, be especially sure to report that.
|
||||
|
||||
<p>Comments explaining the function of macros defined in host, target, or
|
||||
native dependent files can be in several places. Sometimes they are
|
||||
repeated every place the macro is defined. Sometimes they are where the
|
||||
macro is used. Sometimes there is a header file which supplies a
|
||||
default definition of the macro, and the comment is there. This manual
|
||||
also documents all the available macros.
|
||||
<!-- (@pxref{Host Conditionals}, @pxref{Target -->
|
||||
<!-- Conditionals}, @pxref{Native Conditionals}, and @pxref{Obsolete -->
|
||||
<!-- Conditionals}) -->
|
||||
|
||||
<p>Start with the header files. Once you have some idea of how
|
||||
<span class="sc">gdb</span>'s internal symbol tables are stored (see <samp><span class="file">symtab.h</span></samp>,
|
||||
<samp><span class="file">gdbtypes.h</span></samp>), you will find it much easier to understand the
|
||||
code which uses and creates those symbol tables.
|
||||
|
||||
<p>You may wish to process the information you are getting somehow, to
|
||||
enhance your understanding of it. Summarize it, translate it to another
|
||||
language, add some (perhaps trivial or non-useful) feature to <span class="sc">gdb</span>, use
|
||||
the code to predict what a test case would do and write the test case
|
||||
and verify your prediction, etc. If you are reading code and your eyes
|
||||
are starting to glaze over, this is a sign you need to use a more active
|
||||
approach.
|
||||
|
||||
<p>Once you have a part of <span class="sc">gdb</span> to start with, you can find more
|
||||
specifically the part you are looking for by stepping through each
|
||||
function with the <code>next</code> command. Do not use <code>step</code> or you
|
||||
will quickly get distracted; when the function you are stepping through
|
||||
calls another function try only to get a big-picture understanding
|
||||
(perhaps using the comment at the beginning of the function being
|
||||
called) of what it does. This way you can identify which of the
|
||||
functions being called by the function you are stepping through is the
|
||||
one which you are interested in. You may need to examine the data
|
||||
structures generated at each stage, with reference to the comments in
|
||||
the header files explaining what the data structures are supposed to
|
||||
look like.
|
||||
|
||||
<p>Of course, this same technique can be used if you are just reading the
|
||||
code, rather than actually stepping through it. The same general
|
||||
principle applies—when the code you are looking at calls something
|
||||
else, just try to understand generally what the code being called does,
|
||||
rather than worrying about all its details.
|
||||
|
||||
<p><a name="index-command-implementation-497"></a>A good place to start when tracking down some particular area is with
|
||||
a command which invokes that feature. Suppose you want to know how
|
||||
single-stepping works. As a <span class="sc">gdb</span> user, you know that the
|
||||
<code>step</code> command invokes single-stepping. The command is invoked
|
||||
via command tables (see <samp><span class="file">command.h</span></samp>); by convention the function
|
||||
which actually performs the command is formed by taking the name of
|
||||
the command and adding ‘<samp><span class="samp">_command</span></samp>’, or in the case of an
|
||||
<code>info</code> subcommand, ‘<samp><span class="samp">_info</span></samp>’. For example, the <code>step</code>
|
||||
command invokes the <code>step_command</code> function and the <code>info
|
||||
display</code> command invokes <code>display_info</code>. When this convention is
|
||||
not followed, you might have to use <code>grep</code> or <kbd>M-x
|
||||
tags-search</kbd> in emacs, or run <span class="sc">gdb</span> on itself and set a
|
||||
breakpoint in <code>execute_command</code>.
|
||||
|
||||
<p><a name="index-g_t_0040code_007bbug_002dgdb_007d-mailing-list-498"></a>If all of the above fail, it may be appropriate to ask for information
|
||||
on <code>bug-gdb</code>. But <em>never</em> post a generic question like “I was
|
||||
wondering if anyone could give me some tips about understanding
|
||||
<span class="sc">gdb</span>”—if we had some magic secret we would put it in this manual.
|
||||
Suggestions for improving the manual are always welcome, of course.
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,56 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>Hints - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="prev" href="Testsuite.html#Testsuite" title="Testsuite">
|
||||
<link rel="next" href="GDB-Observers.html#GDB-Observers" title="GDB Observers">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Hints"></a>
|
||||
Next: <a rel="next" accesskey="n" href="GDB-Observers.html#GDB-Observers">GDB Observers</a>,
|
||||
Previous: <a rel="previous" accesskey="p" href="Testsuite.html#Testsuite">Testsuite</a>,
|
||||
Up: <a rel="up" accesskey="u" href="index.html#Top">Top</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h2 class="chapter">23 Hints</h2>
|
||||
|
||||
<p>Check the <samp><span class="file">README</span></samp> file, it often has useful information that does not
|
||||
appear anywhere else in the directory.
|
||||
|
||||
<ul class="menu">
|
||||
<li><a accesskey="1" href="Getting-Started.html#Getting-Started">Getting Started</a>: Getting started working on <span class="sc">gdb</span>
|
||||
<li><a accesskey="2" href="Debugging-GDB.html#Debugging-GDB">Debugging GDB</a>: Debugging <span class="sc">gdb</span> with itself
|
||||
</ul>
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,146 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>Host Definition - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="prev" href="Language-Support.html#Language-Support" title="Language Support">
|
||||
<link rel="next" href="Target-Architecture-Definition.html#Target-Architecture-Definition" title="Target Architecture Definition">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Host-Definition"></a>
|
||||
Next: <a rel="next" accesskey="n" href="Target-Architecture-Definition.html#Target-Architecture-Definition">Target Architecture Definition</a>,
|
||||
Previous: <a rel="previous" accesskey="p" href="Language-Support.html#Language-Support">Language Support</a>,
|
||||
Up: <a rel="up" accesskey="u" href="index.html#Top">Top</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h2 class="chapter">10 Host Definition</h2>
|
||||
|
||||
<p>With the advent of Autoconf, it's rarely necessary to have host
|
||||
definition machinery anymore. The following information is provided,
|
||||
mainly, as an historical reference.
|
||||
|
||||
<h3 class="section">10.1 Adding a New Host</h3>
|
||||
|
||||
<p><a name="index-adding-a-new-host-173"></a><a name="index-host_002c-adding-174"></a><span class="sc">gdb</span>'s host configuration support normally happens via Autoconf.
|
||||
New host-specific definitions should not be needed. Older hosts
|
||||
<span class="sc">gdb</span> still use the host-specific definitions and files listed
|
||||
below, but these mostly exist for historical reasons, and will
|
||||
eventually disappear.
|
||||
|
||||
<dl>
|
||||
<dt><samp><span class="file">gdb/config/</span><var>arch</var><span class="file">/</span><var>xyz</var><span class="file">.mh</span></samp><dd>This file is a Makefile fragment that once contained both host and
|
||||
native configuration information (see <a href="Native-Debugging.html#Native-Debugging">Native Debugging</a>) for the
|
||||
machine <var>xyz</var>. The host configuration information is now handled
|
||||
by Autoconf.
|
||||
|
||||
<p>Host configuration information included definitions for <code>CC</code>,
|
||||
<code>SYSV_DEFINE</code>, <code>XM_CFLAGS</code>, <code>XM_ADD_FILES</code>,
|
||||
<code>XM_CLIBS</code>, <code>XM_CDEPS</code>, etc.; see <samp><span class="file">Makefile.in</span></samp>.
|
||||
|
||||
<p>New host-only configurations do not need this file.
|
||||
|
||||
</dl>
|
||||
|
||||
<p>(Files named <samp><span class="file">gdb/config/</span><var>arch</var><span class="file">/xm-</span><var>xyz</var><span class="file">.h</span></samp> were once
|
||||
used to define host-specific macros, but were no longer needed and
|
||||
have all been removed.)
|
||||
|
||||
<h4 class="subheading">Generic Host Support Files</h4>
|
||||
|
||||
<p><a name="index-generic-host-support-175"></a>There are some “generic” versions of routines that can be used by
|
||||
various systems.
|
||||
|
||||
|
||||
<a name="index-remote-debugging-support-176"></a>
|
||||
<a name="index-serial-line-support-177"></a>
|
||||
<dl><dt><samp><span class="file">ser-unix.c</span></samp><dd>This contains serial line support for Unix systems. It is included by
|
||||
default on all Unix-like hosts.
|
||||
|
||||
<br><dt><samp><span class="file">ser-pipe.c</span></samp><dd>This contains serial pipe support for Unix systems. It is included by
|
||||
default on all Unix-like hosts.
|
||||
|
||||
<br><dt><samp><span class="file">ser-mingw.c</span></samp><dd>This contains serial line support for 32-bit programs running under
|
||||
Windows using MinGW.
|
||||
|
||||
<br><dt><samp><span class="file">ser-go32.c</span></samp><dd>This contains serial line support for 32-bit programs running under DOS,
|
||||
using the DJGPP (a.k.a. GO32) execution environment.
|
||||
|
||||
<p><a name="index-TCP-remote-support-178"></a><br><dt><samp><span class="file">ser-tcp.c</span></samp><dd>This contains generic TCP support using sockets. It is included by
|
||||
default on all Unix-like hosts and with MinGW.
|
||||
</dl>
|
||||
|
||||
<h3 class="section">10.2 Host Conditionals</h3>
|
||||
|
||||
<p>When <span class="sc">gdb</span> is configured and compiled, various macros are
|
||||
defined or left undefined, to control compilation based on the
|
||||
attributes of the host system. While formerly they could be set in
|
||||
host-specific header files, at present they can be changed only by
|
||||
setting <code>CFLAGS</code> when building, or by editing the source code.
|
||||
|
||||
<p>These macros and their meanings (or if the meaning is not documented
|
||||
here, then one of the source files where they are used is indicated)
|
||||
are:
|
||||
|
||||
<dl>
|
||||
<dt><span class="sc">gdb</span><code>INIT_FILENAME</code><a name="index-g_t_0040value_007bGDBN_007dINIT_005fFILENAME-179"></a><dd>The default name of <span class="sc">gdb</span>'s initialization file (normally
|
||||
<samp><span class="file">.gdbinit</span></samp>).
|
||||
|
||||
<br><dt><code>CRLF_SOURCE_FILES</code><a name="index-CRLF_005fSOURCE_005fFILES-180"></a><dd><a name="index-DOS-text-files-181"></a>Define this if host files use <code>\r\n</code> rather than <code>\n</code> as a
|
||||
line terminator. This will cause source file listings to omit <code>\r</code>
|
||||
characters when printing and it will allow <code>\r\n</code> line endings of files
|
||||
which are “sourced” by gdb. It must be possible to open files in binary
|
||||
mode using <code>O_BINARY</code> or, for fopen, <code>"rb"</code>.
|
||||
|
||||
<br><dt><code>DEFAULT_PROMPT</code><a name="index-DEFAULT_005fPROMPT-182"></a><dd><a name="index-prompt-183"></a>The default value of the prompt string (normally <code>"(gdb) "</code>).
|
||||
|
||||
<br><dt><code>DEV_TTY</code><a name="index-DEV_005fTTY-184"></a><dd><a name="index-terminal-device-185"></a>The name of the generic TTY device, defaults to <code>"/dev/tty"</code>.
|
||||
|
||||
<br><dt><code>ISATTY</code><a name="index-ISATTY-186"></a><dd>Substitute for isatty, if not available.
|
||||
|
||||
<br><dt><code>FOPEN_RB</code><a name="index-FOPEN_005fRB-187"></a><dd>Define this if binary files are opened the same way as text files.
|
||||
|
||||
<br><dt><code>PRINTF_HAS_LONG_LONG</code><a name="index-PRINTF_005fHAS_005fLONG_005fLONG-188"></a><dd>Define this if the host can handle printing of long long integers via
|
||||
the printf format conversion specifier <code>ll</code>. This is set by the
|
||||
<code>configure</code> script.
|
||||
|
||||
<br><dt><code>LSEEK_NOT_LINEAR</code><a name="index-LSEEK_005fNOT_005fLINEAR-189"></a><dd>Define this if <code>lseek (n)</code> does not necessarily move to byte number
|
||||
<code>n</code> in the file. This is only used when reading source files. It
|
||||
is normally faster to define <code>CRLF_SOURCE_FILES</code> when possible.
|
||||
|
||||
<br><dt><code>lint</code><a name="index-lint-190"></a><dd>Define this to help placate <code>lint</code> in some situations.
|
||||
|
||||
<br><dt><code>volatile</code><a name="index-volatile-191"></a><dd>Define this to override the defaults of <code>__volatile__</code> or
|
||||
<code>/**/</code>.
|
||||
</dl>
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,86 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>How an Architecture is Represented - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="up" href="Initialize-New-Architecture.html#Initialize-New-Architecture" title="Initialize New Architecture">
|
||||
<link rel="next" href="Looking-Up-an-Existing-Architecture.html#Looking-Up-an-Existing-Architecture" title="Looking Up an Existing Architecture">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="How-an-Architecture-is-Represented"></a>
|
||||
Next: <a rel="next" accesskey="n" href="Looking-Up-an-Existing-Architecture.html#Looking-Up-an-Existing-Architecture">Looking Up an Existing Architecture</a>,
|
||||
Up: <a rel="up" accesskey="u" href="Initialize-New-Architecture.html#Initialize-New-Architecture">Initialize New Architecture</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h4 class="subsection">11.2.1 How an Architecture is Represented</h4>
|
||||
|
||||
<p><a name="index-architecture-representation-222"></a><a name="index-representation-of-architecture-223"></a>
|
||||
Each <code>gdbarch</code> is associated with a single <span class="sc">bfd</span> architecture,
|
||||
via a <code>bfd_arch_</code><var>arch</var> in the <code>bfd_architecture</code>
|
||||
enumeration. The <code>gdbarch</code> is registered by a call to
|
||||
<code>register_gdbarch_init</code>, usually from the file's
|
||||
<code>_initialize_</code><var>filename</var> routine, which will be automatically
|
||||
called during <span class="sc">gdb</span> startup. The arguments are a <span class="sc">bfd</span>
|
||||
architecture constant and an initialization function.
|
||||
|
||||
<p><a name="index-g_t_005finitialize_005f_0040var_007barch_007d_005ftdep-224"></a><a name="index-g_t_0040file_007b_0040var_007barch_007d_002dtdep_002ec_007d-225"></a>A <span class="sc">gdb</span> description for a new architecture, <var>arch</var> is created by
|
||||
defining a global function <code>_initialize_</code><var>arch</var><code>_tdep</code>, by
|
||||
convention in the source file <samp><var>arch</var><span class="file">-tdep.c</span></samp>. For example,
|
||||
in the case of the OpenRISC 1000, this function is called
|
||||
<code>_initialize_or1k_tdep</code> and is found in the file
|
||||
<samp><span class="file">or1k-tdep.c</span></samp>.
|
||||
|
||||
<p><a name="index-g_t_0040file_007bconfigure_002etgt_007d-226"></a><a name="index-g_t_0040code_007bgdbarch_007d-227"></a><a name="index-gdbarch_005fregister-228"></a>The resulting object files containing the implementation of the
|
||||
<code>_initialize_</code><var>arch</var><code>_tdep</code> function are specified in the <span class="sc">gdb</span>
|
||||
<samp><span class="file">configure.tgt</span></samp> file, which includes a large case statement
|
||||
pattern matching against the <code>--target</code> option of the
|
||||
<code>configure</code> script. The new <code>struct gdbarch</code> is created
|
||||
within the <code>_initialize_</code><var>arch</var><code>_tdep</code> function by calling
|
||||
<code>gdbarch_register</code>:
|
||||
|
||||
<pre class="smallexample"> void gdbarch_register (enum bfd_architecture <var>architecture</var>,
|
||||
gdbarch_init_ftype *<var>init_func</var>,
|
||||
gdbarch_dump_tdep_ftype *<var>tdep_dump_func</var>);
|
||||
</pre>
|
||||
<p>The <var>architecture</var> will identify the unique <span class="sc">bfd</span> to be
|
||||
associated with this <code>gdbarch</code>. The <var>init_func</var> funciton is
|
||||
called to create and return the new <code>struct gdbarch</code>. The
|
||||
<var>tdep_dump_func</var> function will dump the target specific details
|
||||
associated with this architecture.
|
||||
|
||||
<p>For example the function <code>_initialize_or1k_tdep</code> creates its
|
||||
architecture for 32-bit OpenRISC 1000 architectures by calling:
|
||||
|
||||
<pre class="smallexample"> gdbarch_register (bfd_arch_or32, or1k_gdbarch_init, or1k_dump_tdep);
|
||||
</pre>
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,56 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>Inferior Call Setup - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="up" href="Target-Architecture-Definition.html#Target-Architecture-Definition" title="Target Architecture Definition">
|
||||
<link rel="prev" href="Frame-Interpretation.html#Frame-Interpretation" title="Frame Interpretation">
|
||||
<link rel="next" href="Adding-support-for-debugging-core-files.html#Adding-support-for-debugging-core-files" title="Adding support for debugging core files">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Inferior-Call-Setup"></a>
|
||||
Next: <a rel="next" accesskey="n" href="Adding-support-for-debugging-core-files.html#Adding-support-for-debugging-core-files">Adding support for debugging core files</a>,
|
||||
Previous: <a rel="previous" accesskey="p" href="Frame-Interpretation.html#Frame-Interpretation">Frame Interpretation</a>,
|
||||
Up: <a rel="up" accesskey="u" href="Target-Architecture-Definition.html#Target-Architecture-Definition">Target Architecture Definition</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h3 class="section">11.8 Inferior Call Setup</h3>
|
||||
|
||||
<p><a name="index-calls-to-the-inferior-353"></a>
|
||||
|
||||
<ul class="menu">
|
||||
<li><a accesskey="1" href="About-Dummy-Frames.html#About-Dummy-Frames">About Dummy Frames</a>
|
||||
<li><a accesskey="2" href="Functions-Creating-Dummy-Frames.html#Functions-Creating-Dummy-Frames">Functions Creating Dummy Frames</a>
|
||||
</ul>
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,55 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>Initialize New Architecture - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="up" href="Target-Architecture-Definition.html#Target-Architecture-Definition" title="Target Architecture Definition">
|
||||
<link rel="prev" href="OS-ABI-Variant-Handling.html#OS-ABI-Variant-Handling" title="OS ABI Variant Handling">
|
||||
<link rel="next" href="Registers-and-Memory.html#Registers-and-Memory" title="Registers and Memory">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Initialize-New-Architecture"></a>
|
||||
Next: <a rel="next" accesskey="n" href="Registers-and-Memory.html#Registers-and-Memory">Registers and Memory</a>,
|
||||
Previous: <a rel="previous" accesskey="p" href="OS-ABI-Variant-Handling.html#OS-ABI-Variant-Handling">OS ABI Variant Handling</a>,
|
||||
Up: <a rel="up" accesskey="u" href="Target-Architecture-Definition.html#Target-Architecture-Definition">Target Architecture Definition</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h3 class="section">11.2 Initializing a New Architecture</h3>
|
||||
|
||||
<ul class="menu">
|
||||
<li><a accesskey="1" href="How-an-Architecture-is-Represented.html#How-an-Architecture-is-Represented">How an Architecture is Represented</a>
|
||||
<li><a accesskey="2" href="Looking-Up-an-Existing-Architecture.html#Looking-Up-an-Existing-Architecture">Looking Up an Existing Architecture</a>
|
||||
<li><a accesskey="3" href="Creating-a-New-Architecture.html#Creating-a-New-Architecture">Creating a New Architecture</a>
|
||||
</ul>
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,150 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>Language Support - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="prev" href="Symbol-Handling.html#Symbol-Handling" title="Symbol Handling">
|
||||
<link rel="next" href="Host-Definition.html#Host-Definition" title="Host Definition">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Language-Support"></a>
|
||||
Next: <a rel="next" accesskey="n" href="Host-Definition.html#Host-Definition">Host Definition</a>,
|
||||
Previous: <a rel="previous" accesskey="p" href="Symbol-Handling.html#Symbol-Handling">Symbol Handling</a>,
|
||||
Up: <a rel="up" accesskey="u" href="index.html#Top">Top</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h2 class="chapter">9 Language Support</h2>
|
||||
|
||||
<p><a name="index-language-support-159"></a><span class="sc">gdb</span>'s language support is mainly driven by the symbol reader,
|
||||
although it is possible for the user to set the source language
|
||||
manually.
|
||||
|
||||
<p><span class="sc">gdb</span> chooses the source language by looking at the extension
|
||||
of the file recorded in the debug info; <samp><span class="file">.c</span></samp> means C, <samp><span class="file">.f</span></samp>
|
||||
means Fortran, etc. It may also use a special-purpose language
|
||||
identifier if the debug format supports it, like with DWARF.
|
||||
|
||||
<h3 class="section">9.1 Adding a Source Language to <span class="sc">gdb</span></h3>
|
||||
|
||||
<p><a name="index-adding-source-language-160"></a>To add other languages to <span class="sc">gdb</span>'s expression parser, follow the
|
||||
following steps:
|
||||
|
||||
<dl>
|
||||
<dt><em>Create the expression parser.</em><dd>
|
||||
<a name="index-expression-parser-161"></a>This should reside in a file <samp><var>lang</var><span class="file">-exp.y</span></samp>. Routines for
|
||||
building parsed expressions into a <code>union exp_element</code> list are in
|
||||
<samp><span class="file">parse.c</span></samp>.
|
||||
|
||||
<p><a name="index-language-parser-162"></a>Since we can't depend upon everyone having Bison, and YACC produces
|
||||
parsers that define a bunch of global names, the following lines
|
||||
<strong>must</strong> be included at the top of the YACC parser, to prevent the
|
||||
various parsers from defining the same global names:
|
||||
|
||||
<pre class="smallexample"> #define yyparse <var>lang</var>_parse
|
||||
#define yylex <var>lang</var>_lex
|
||||
#define yyerror <var>lang</var>_error
|
||||
#define yylval <var>lang</var>_lval
|
||||
#define yychar <var>lang</var>_char
|
||||
#define yydebug <var>lang</var>_debug
|
||||
#define yypact <var>lang</var>_pact
|
||||
#define yyr1 <var>lang</var>_r1
|
||||
#define yyr2 <var>lang</var>_r2
|
||||
#define yydef <var>lang</var>_def
|
||||
#define yychk <var>lang</var>_chk
|
||||
#define yypgo <var>lang</var>_pgo
|
||||
#define yyact <var>lang</var>_act
|
||||
#define yyexca <var>lang</var>_exca
|
||||
#define yyerrflag <var>lang</var>_errflag
|
||||
#define yynerrs <var>lang</var>_nerrs
|
||||
</pre>
|
||||
<p>At the bottom of your parser, define a <code>struct language_defn</code> and
|
||||
initialize it with the right values for your language. Define an
|
||||
<code>initialize_</code><var>lang</var> routine and have it call
|
||||
‘<samp><span class="samp">add_language(</span><var>lang</var><span class="samp">_language_defn)</span></samp>’ to tell the rest of <span class="sc">gdb</span>
|
||||
that your language exists. You'll need some other supporting variables
|
||||
and functions, which will be used via pointers from your
|
||||
<var>lang</var><code>_language_defn</code>. See the declaration of <code>struct
|
||||
language_defn</code> in <samp><span class="file">language.h</span></samp>, and the other <samp><span class="file">*-exp.y</span></samp> files,
|
||||
for more information.
|
||||
|
||||
<br><dt><em>Add any evaluation routines, if necessary</em><dd>
|
||||
<a name="index-expression-evaluation-routines-163"></a><a name="index-evaluate_005fsubexp-164"></a><a name="index-prefixify_005fsubexp-165"></a><a name="index-length_005fof_005fsubexp-166"></a>If you need new opcodes (that represent the operations of the language),
|
||||
add them to the enumerated type in <samp><span class="file">expression.h</span></samp>. Add support
|
||||
code for these operations in the <code>evaluate_subexp</code> function
|
||||
defined in the file <samp><span class="file">eval.c</span></samp>. Add cases
|
||||
for new opcodes in two functions from <samp><span class="file">parse.c</span></samp>:
|
||||
<code>prefixify_subexp</code> and <code>length_of_subexp</code>. These compute
|
||||
the number of <code>exp_element</code>s that a given operation takes up.
|
||||
|
||||
<br><dt><em>Update some existing code</em><dd>
|
||||
Add an enumerated identifier for your language to the enumerated type
|
||||
<code>enum language</code> in <samp><span class="file">defs.h</span></samp>.
|
||||
|
||||
<p>Update the routines in <samp><span class="file">language.c</span></samp> so your language is included.
|
||||
These routines include type predicates and such, which (in some cases)
|
||||
are language dependent. If your language does not appear in the switch
|
||||
statement, an error is reported.
|
||||
|
||||
<p><a name="index-current_005flanguage-167"></a>Also included in <samp><span class="file">language.c</span></samp> is the code that updates the variable
|
||||
<code>current_language</code>, and the routines that translate the
|
||||
<code>language_</code><var>lang</var> enumerated identifier into a printable
|
||||
string.
|
||||
|
||||
<p><a name="index-g_t_005finitialize_005flanguage-168"></a>Update the function <code>_initialize_language</code> to include your
|
||||
language. This function picks the default language upon startup, so is
|
||||
dependent upon which languages that <span class="sc">gdb</span> is built for.
|
||||
|
||||
<p><a name="index-allocate_005fsymtab-169"></a>Update <code>allocate_symtab</code> in <samp><span class="file">symfile.c</span></samp> and/or symbol-reading
|
||||
code so that the language of each symtab (source file) is set properly.
|
||||
This is used to determine the language to use at each stack frame level.
|
||||
Currently, the language is set based upon the extension of the source
|
||||
file. If the language can be better inferred from the symbol
|
||||
information, please set the language of the symtab in the symbol-reading
|
||||
code.
|
||||
|
||||
<p><a name="index-print_005fsubexp-170"></a><a name="index-op_005fprint_005ftab-171"></a>Add helper code to <code>print_subexp</code> (in <samp><span class="file">expprint.c</span></samp>) to handle any new
|
||||
expression opcodes you have added to <samp><span class="file">expression.h</span></samp>. Also, add the
|
||||
printed representations of your operators to <code>op_print_tab</code>.
|
||||
|
||||
<br><dt><em>Add a place of call</em><dd>
|
||||
<a name="index-parse_005fexp_005f1-172"></a>Add a call to <var>lang</var><code>_parse()</code> and <var>lang</var><code>_error</code> in
|
||||
<code>parse_exp_1</code> (defined in <samp><span class="file">parse.c</span></samp>).
|
||||
|
||||
<br><dt><em>Edit </em><samp><span class="file">Makefile.in</span></samp><dd>
|
||||
Add dependencies in <samp><span class="file">Makefile.in</span></samp>. Make sure you update the macro
|
||||
variables such as <code>HFILES</code> and <code>OBJS</code>, otherwise your code may
|
||||
not get linked in, or, worse yet, it may not get <code>tar</code>red into the
|
||||
distribution!
|
||||
</dl>
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,111 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>Looking Up an Existing Architecture - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="up" href="Initialize-New-Architecture.html#Initialize-New-Architecture" title="Initialize New Architecture">
|
||||
<link rel="prev" href="How-an-Architecture-is-Represented.html#How-an-Architecture-is-Represented" title="How an Architecture is Represented">
|
||||
<link rel="next" href="Creating-a-New-Architecture.html#Creating-a-New-Architecture" title="Creating a New Architecture">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Looking-Up-an-Existing-Architecture"></a>
|
||||
Next: <a rel="next" accesskey="n" href="Creating-a-New-Architecture.html#Creating-a-New-Architecture">Creating a New Architecture</a>,
|
||||
Previous: <a rel="previous" accesskey="p" href="How-an-Architecture-is-Represented.html#How-an-Architecture-is-Represented">How an Architecture is Represented</a>,
|
||||
Up: <a rel="up" accesskey="u" href="Initialize-New-Architecture.html#Initialize-New-Architecture">Initialize New Architecture</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h4 class="subsection">11.2.2 Looking Up an Existing Architecture</h4>
|
||||
|
||||
<p><a name="index-g_t_0040code_007bgdbarch_007d-lookup-229"></a>
|
||||
The initialization function has this prototype:
|
||||
|
||||
<pre class="smallexample"> static struct gdbarch *
|
||||
<var>arch</var>_gdbarch_init (struct gdbarch_info <var>info</var>,
|
||||
struct gdbarch_list *<var>arches</var>)
|
||||
</pre>
|
||||
<p>The <var>info</var> argument contains parameters used to select the correct
|
||||
architecture, and <var>arches</var> is a list of architectures which
|
||||
have already been created with the same <code>bfd_arch_</code><var>arch</var>
|
||||
value.
|
||||
|
||||
<p>The initialization function should first make sure that <var>info</var>
|
||||
is acceptable, and return <code>NULL</code> if it is not. Then, it should
|
||||
search through <var>arches</var> for an exact match to <var>info</var>, and
|
||||
return one if found. Lastly, if no exact match was found, it should
|
||||
create a new architecture based on <var>info</var> and return it.
|
||||
|
||||
<p><a name="index-gdbarch_005flist_005flookup_005fby_005finfo-230"></a><a name="index-g_t_0040code_007bgdbarch_005finfo_007d-231"></a>The lookup is done using <code>gdbarch_list_lookup_by_info</code>. It is
|
||||
passed the list of existing architectures, <var>arches</var>, and the
|
||||
<code>struct gdbarch_info</code>, <var>info</var>, and returns the first matching
|
||||
architecture it finds, or <code>NULL</code> if none are found. If an
|
||||
architecture is found it can be returned as the result from the
|
||||
initialization function, otherwise a new <code>struct gdbach</code> will need
|
||||
to be created.
|
||||
|
||||
<p>The struct gdbarch_info has the following components:
|
||||
|
||||
<pre class="smallexample"> struct gdbarch_info
|
||||
{
|
||||
const struct bfd_arch_info *bfd_arch_info;
|
||||
int byte_order;
|
||||
bfd *abfd;
|
||||
struct gdbarch_tdep_info *tdep_info;
|
||||
enum gdb_osabi osabi;
|
||||
const struct target_desc *target_desc;
|
||||
};
|
||||
</pre>
|
||||
<p><a name="index-bfd_005farch_005finfo-232"></a>The <code>bfd_arch_info</code> member holds the key details about the
|
||||
architecture. The <code>byte_order</code> member is a value in an
|
||||
enumeration indicating the endianism. The <code>abfd</code> member is a
|
||||
pointer to the full <span class="sc">bfd</span>, the <code>tdep_info</code> member is
|
||||
additional custom target specific information, <code>osabi</code> identifies
|
||||
which (if any) of a number of operating specific ABIs are used by this
|
||||
architecture and the <code>target_desc</code> member is a set of name-value
|
||||
pairs with information about register usage in this target.
|
||||
|
||||
<p>When the <code>struct gdbarch</code> initialization function is called, not
|
||||
all the fields are provided—only those which can be deduced from the
|
||||
<span class="sc">bfd</span>. The <code>struct gdbarch_info</code>, <var>info</var> is used as a
|
||||
look-up key with the list of existing architectures, <var>arches</var> to
|
||||
see if a suitable architecture already exists. The <var>tdep_info</var>,
|
||||
<var>osabi</var> and <var>target_desc</var> fields may be added before this
|
||||
lookup to refine the search.
|
||||
|
||||
<p>Only information in <var>info</var> should be used to choose the new
|
||||
architecture. Historically, <var>info</var> could be sparse, and
|
||||
defaults would be collected from the first element on <var>arches</var>.
|
||||
However, <span class="sc">gdb</span> now fills in <var>info</var> more thoroughly,
|
||||
so new <code>gdbarch</code> initialization functions should not take
|
||||
defaults from <var>arches</var>.
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,80 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>Managing Execution State - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="up" href="Target-Vector-Definition.html#Target-Vector-Definition" title="Target Vector Definition">
|
||||
<link rel="next" href="Existing-Targets.html#Existing-Targets" title="Existing Targets">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Managing-Execution-State"></a>
|
||||
Next: <a rel="next" accesskey="n" href="Existing-Targets.html#Existing-Targets">Existing Targets</a>,
|
||||
Up: <a rel="up" accesskey="u" href="Target-Vector-Definition.html#Target-Vector-Definition">Target Vector Definition</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h3 class="section">13.1 Managing Execution State</h3>
|
||||
|
||||
<p><a name="index-execution-state-438"></a>
|
||||
A target vector can be completely inactive (not pushed on the target
|
||||
stack), active but not running (pushed, but not connected to a fully
|
||||
manifested inferior), or completely active (pushed, with an accessible
|
||||
inferior). Most targets are only completely inactive or completely
|
||||
active, but some support persistent connections to a target even
|
||||
when the target has exited or not yet started.
|
||||
|
||||
<p>For example, connecting to the simulator using <code>target sim</code> does
|
||||
not create a running program. Neither registers nor memory are
|
||||
accessible until <code>run</code>. Similarly, after <code>kill</code>, the
|
||||
program can not continue executing. But in both cases <span class="sc">gdb</span>
|
||||
remains connected to the simulator, and target-specific commands
|
||||
are directed to the simulator.
|
||||
|
||||
<p>A target which only supports complete activation should push itself
|
||||
onto the stack in its <code>to_open</code> routine (by calling
|
||||
<code>push_target</code>), and unpush itself from the stack in its
|
||||
<code>to_mourn_inferior</code> routine (by calling <code>unpush_target</code>).
|
||||
|
||||
<p>A target which supports both partial and complete activation should
|
||||
still call <code>push_target</code> in <code>to_open</code>, but not call
|
||||
<code>unpush_target</code> in <code>to_mourn_inferior</code>. Instead, it should
|
||||
call either <code>target_mark_running</code> or <code>target_mark_exited</code>
|
||||
in its <code>to_open</code>, depending on whether the target is fully active
|
||||
after connection. It should also call <code>target_mark_running</code> any
|
||||
time the inferior becomes fully active (e.g. in
|
||||
<code>to_create_inferior</code> and <code>to_attach</code>), and
|
||||
<code>target_mark_exited</code> when the inferior becomes inactive (in
|
||||
<code>to_mourn_inferior</code>). The target should also make sure to call
|
||||
<code>target_mourn_inferior</code> from its <code>to_kill</code>, to return the
|
||||
target to inactive state.
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,482 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>Misc Guidelines - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="prev" href="Coding-Standards.html#Coding-Standards" title="Coding Standards">
|
||||
<link rel="next" href="Porting-GDB.html#Porting-GDB" title="Porting GDB">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Misc-Guidelines"></a>
|
||||
Next: <a rel="next" accesskey="n" href="Porting-GDB.html#Porting-GDB">Porting GDB</a>,
|
||||
Previous: <a rel="previous" accesskey="p" href="Coding-Standards.html#Coding-Standards">Coding Standards</a>,
|
||||
Up: <a rel="up" accesskey="u" href="index.html#Top">Top</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h2 class="chapter">17 Misc Guidelines</h2>
|
||||
|
||||
<p>This chapter covers topics that are lower-level than the major
|
||||
algorithms of <span class="sc">gdb</span>.
|
||||
|
||||
<h3 class="section">17.1 Cleanups</h3>
|
||||
|
||||
<p><a name="index-cleanups-461"></a>
|
||||
Cleanups are a structured way to deal with things that need to be done
|
||||
later.
|
||||
|
||||
<p>When your code does something (e.g., <code>xmalloc</code> some memory, or
|
||||
<code>open</code> a file) that needs to be undone later (e.g., <code>xfree</code>
|
||||
the memory or <code>close</code> the file), it can make a cleanup. The
|
||||
cleanup will be done at some future point: when the command is finished
|
||||
and control returns to the top level; when an error occurs and the stack
|
||||
is unwound; or when your code decides it's time to explicitly perform
|
||||
cleanups. Alternatively you can elect to discard the cleanups you
|
||||
created.
|
||||
|
||||
<p>Syntax:
|
||||
|
||||
<dl>
|
||||
<dt><code>struct cleanup *</code><var>old_chain</var><code>;</code><dd>Declare a variable which will hold a cleanup chain handle.
|
||||
|
||||
<p><a name="index-make_005fcleanup-462"></a><br><dt><var>old_chain</var><code> = make_cleanup (</code><var>function</var><code>, </code><var>arg</var><code>);</code><dd>Make a cleanup which will cause <var>function</var> to be called with
|
||||
<var>arg</var> (a <code>char *</code>) later. The result, <var>old_chain</var>, is a
|
||||
handle that can later be passed to <code>do_cleanups</code> or
|
||||
<code>discard_cleanups</code>. Unless you are going to call
|
||||
<code>do_cleanups</code> or <code>discard_cleanups</code>, you can ignore the result
|
||||
from <code>make_cleanup</code>.
|
||||
|
||||
<p><a name="index-do_005fcleanups-463"></a><br><dt><code>do_cleanups (</code><var>old_chain</var><code>);</code><dd>Do all cleanups added to the chain since the corresponding
|
||||
<code>make_cleanup</code> call was made.
|
||||
|
||||
<p><a name="index-discard_005fcleanups-464"></a><br><dt><code>discard_cleanups (</code><var>old_chain</var><code>);</code><dd>Same as <code>do_cleanups</code> except that it just removes the cleanups from
|
||||
the chain and does not call the specified functions.
|
||||
</dl>
|
||||
|
||||
<p>Cleanups are implemented as a chain. The handle returned by
|
||||
<code>make_cleanups</code> includes the cleanup passed to the call and any
|
||||
later cleanups appended to the chain (but not yet discarded or
|
||||
performed). E.g.:
|
||||
|
||||
<pre class="smallexample"> make_cleanup (a, 0);
|
||||
{
|
||||
struct cleanup *old = make_cleanup (b, 0);
|
||||
make_cleanup (c, 0)
|
||||
...
|
||||
do_cleanups (old);
|
||||
}
|
||||
</pre>
|
||||
<p class="noindent">will call <code>c()</code> and <code>b()</code> but will not call <code>a()</code>. The
|
||||
cleanup that calls <code>a()</code> will remain in the cleanup chain, and will
|
||||
be done later unless otherwise discarded.
|
||||
|
||||
<p>Your function should explicitly do or discard the cleanups it creates.
|
||||
Failing to do this leads to non-deterministic behavior since the caller
|
||||
will arbitrarily do or discard your functions cleanups. This need leads
|
||||
to two common cleanup styles.
|
||||
|
||||
<p>The first style is try/finally. Before it exits, your code-block calls
|
||||
<code>do_cleanups</code> with the old cleanup chain and thus ensures that your
|
||||
code-block's cleanups are always performed. For instance, the following
|
||||
code-segment avoids a memory leak problem (even when <code>error</code> is
|
||||
called and a forced stack unwind occurs) by ensuring that the
|
||||
<code>xfree</code> will always be called:
|
||||
|
||||
<pre class="smallexample"> struct cleanup *old = make_cleanup (null_cleanup, 0);
|
||||
data = xmalloc (sizeof blah);
|
||||
make_cleanup (xfree, data);
|
||||
... blah blah ...
|
||||
do_cleanups (old);
|
||||
</pre>
|
||||
<p>The second style is try/except. Before it exits, your code-block calls
|
||||
<code>discard_cleanups</code> with the old cleanup chain and thus ensures that
|
||||
any created cleanups are not performed. For instance, the following
|
||||
code segment, ensures that the file will be closed but only if there is
|
||||
an error:
|
||||
|
||||
<pre class="smallexample"> FILE *file = fopen ("afile", "r");
|
||||
struct cleanup *old = make_cleanup (close_file, file);
|
||||
... blah blah ...
|
||||
discard_cleanups (old);
|
||||
return file;
|
||||
</pre>
|
||||
<p>Some functions, e.g., <code>fputs_filtered()</code> or <code>error()</code>, specify
|
||||
that they “should not be called when cleanups are not in place”. This
|
||||
means that any actions you need to reverse in the case of an error or
|
||||
interruption must be on the cleanup chain before you call these
|
||||
functions, since they might never return to your code (they
|
||||
‘<samp><span class="samp">longjmp</span></samp>’ instead).
|
||||
|
||||
<h3 class="section">17.2 Per-architecture module data</h3>
|
||||
|
||||
<p><a name="index-per_002darchitecture-module-data-465"></a><a name="index-multi_002darch-data-466"></a><a name="index-data_002dpointer_002c-per_002darchitecture_002fper_002dmodule-467"></a>
|
||||
The multi-arch framework includes a mechanism for adding module
|
||||
specific per-architecture data-pointers to the <code>struct gdbarch</code>
|
||||
architecture object.
|
||||
|
||||
<p>A module registers one or more per-architecture data-pointers using:
|
||||
|
||||
<div class="defun">
|
||||
— Architecture Function: struct gdbarch_data * <b>gdbarch_data_register_pre_init</b> (<var>gdbarch_data_pre_init_ftype *pre_init</var>)<var><a name="index-gdbarch_005fdata_005fregister_005fpre_005finit-468"></a></var><br>
|
||||
<blockquote><p><var>pre_init</var> is used to, on-demand, allocate an initial value for a
|
||||
per-architecture data-pointer using the architecture's obstack (passed
|
||||
in as a parameter). Since <var>pre_init</var> can be called during
|
||||
architecture creation, it is not parameterized with the architecture.
|
||||
and must not call modules that use per-architecture data.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Architecture Function: struct gdbarch_data * <b>gdbarch_data_register_post_init</b> (<var>gdbarch_data_post_init_ftype *post_init</var>)<var><a name="index-gdbarch_005fdata_005fregister_005fpost_005finit-469"></a></var><br>
|
||||
<blockquote><p><var>post_init</var> is used to obtain an initial value for a
|
||||
per-architecture data-pointer <em>after</em>. Since <var>post_init</var> is
|
||||
always called after architecture creation, it both receives the fully
|
||||
initialized architecture and is free to call modules that use
|
||||
per-architecture data (care needs to be taken to ensure that those
|
||||
other modules do not try to call back to this module as that will
|
||||
create in cycles in the initialization call graph).
|
||||
</p></blockquote></div>
|
||||
|
||||
<p>These functions return a <code>struct gdbarch_data</code> that is used to
|
||||
identify the per-architecture data-pointer added for that module.
|
||||
|
||||
<p>The per-architecture data-pointer is accessed using the function:
|
||||
|
||||
<div class="defun">
|
||||
— Architecture Function: void * <b>gdbarch_data</b> (<var>struct gdbarch *gdbarch, struct gdbarch_data *data_handle</var>)<var><a name="index-gdbarch_005fdata-470"></a></var><br>
|
||||
<blockquote><p>Given the architecture <var>arch</var> and module data handle
|
||||
<var>data_handle</var> (returned by <code>gdbarch_data_register_pre_init</code>
|
||||
or <code>gdbarch_data_register_post_init</code>), this function returns the
|
||||
current value of the per-architecture data-pointer. If the data
|
||||
pointer is <code>NULL</code>, it is first initialized by calling the
|
||||
corresponding <var>pre_init</var> or <var>post_init</var> method.
|
||||
</p></blockquote></div>
|
||||
|
||||
<p>The examples below assume the following definitions:
|
||||
|
||||
<pre class="smallexample"> struct nozel { int total; };
|
||||
static struct gdbarch_data *nozel_handle;
|
||||
</pre>
|
||||
<p>A module can extend the architecture vector, adding additional
|
||||
per-architecture data, using the <var>pre_init</var> method. The module's
|
||||
per-architecture data is then initialized during architecture
|
||||
creation.
|
||||
|
||||
<p>In the below, the module's per-architecture <em>nozel</em> is added. An
|
||||
architecture can specify its nozel by calling <code>set_gdbarch_nozel</code>
|
||||
from <code>gdbarch_init</code>.
|
||||
|
||||
<pre class="smallexample"> static void *
|
||||
nozel_pre_init (struct obstack *obstack)
|
||||
{
|
||||
struct nozel *data = OBSTACK_ZALLOC (obstack, struct nozel);
|
||||
return data;
|
||||
}
|
||||
</pre>
|
||||
<pre class="smallexample"> extern void
|
||||
set_gdbarch_nozel (struct gdbarch *gdbarch, int total)
|
||||
{
|
||||
struct nozel *data = gdbarch_data (gdbarch, nozel_handle);
|
||||
data->total = nozel;
|
||||
}
|
||||
</pre>
|
||||
<p>A module can on-demand create architecture dependent data structures
|
||||
using <code>post_init</code>.
|
||||
|
||||
<p>In the below, the nozel's total is computed on-demand by
|
||||
<code>nozel_post_init</code> using information obtained from the
|
||||
architecture.
|
||||
|
||||
<pre class="smallexample"> static void *
|
||||
nozel_post_init (struct gdbarch *gdbarch)
|
||||
{
|
||||
struct nozel *data = GDBARCH_OBSTACK_ZALLOC (gdbarch, struct nozel);
|
||||
nozel->total = gdbarch... (gdbarch);
|
||||
return data;
|
||||
}
|
||||
</pre>
|
||||
<pre class="smallexample"> extern int
|
||||
nozel_total (struct gdbarch *gdbarch)
|
||||
{
|
||||
struct nozel *data = gdbarch_data (gdbarch, nozel_handle);
|
||||
return data->total;
|
||||
}
|
||||
</pre>
|
||||
<h3 class="section">17.3 Wrapping Output Lines</h3>
|
||||
|
||||
<p><a name="index-line-wrap-in-output-471"></a>
|
||||
<a name="index-wrap_005fhere-472"></a>Output that goes through <code>printf_filtered</code> or <code>fputs_filtered</code>
|
||||
or <code>fputs_demangled</code> needs only to have calls to <code>wrap_here</code>
|
||||
added in places that would be good breaking points. The utility
|
||||
routines will take care of actually wrapping if the line width is
|
||||
exceeded.
|
||||
|
||||
<p>The argument to <code>wrap_here</code> is an indentation string which is
|
||||
printed <em>only</em> if the line breaks there. This argument is saved
|
||||
away and used later. It must remain valid until the next call to
|
||||
<code>wrap_here</code> or until a newline has been printed through the
|
||||
<code>*_filtered</code> functions. Don't pass in a local variable and then
|
||||
return!
|
||||
|
||||
<p>It is usually best to call <code>wrap_here</code> after printing a comma or
|
||||
space. If you call it before printing a space, make sure that your
|
||||
indentation properly accounts for the leading space that will print if
|
||||
the line wraps there.
|
||||
|
||||
<p>Any function or set of functions that produce filtered output must
|
||||
finish by printing a newline, to flush the wrap buffer, before switching
|
||||
to unfiltered (<code>printf</code>) output. Symbol reading routines that
|
||||
print warnings are a good example.
|
||||
|
||||
<h3 class="section">17.4 Memory Management</h3>
|
||||
|
||||
<p><span class="sc">gdb</span> does not use the functions <code>malloc</code>, <code>realloc</code>,
|
||||
<code>calloc</code>, <code>free</code> and <code>asprintf</code>.
|
||||
|
||||
<p><span class="sc">gdb</span> uses the functions <code>xmalloc</code>, <code>xrealloc</code> and
|
||||
<code>xcalloc</code> when allocating memory. Unlike <code>malloc</code> et.al.
|
||||
these functions do not return when the memory pool is empty. Instead,
|
||||
they unwind the stack using cleanups. These functions return
|
||||
<code>NULL</code> when requested to allocate a chunk of memory of size zero.
|
||||
|
||||
<p><em>Pragmatics: By using these functions, the need to check every
|
||||
memory allocation is removed. These functions provide portable
|
||||
behavior.</em>
|
||||
|
||||
<p><span class="sc">gdb</span> does not use the function <code>free</code>.
|
||||
|
||||
<p><span class="sc">gdb</span> uses the function <code>xfree</code> to return memory to the
|
||||
memory pool. Consistent with ISO-C, this function ignores a request to
|
||||
free a <code>NULL</code> pointer.
|
||||
|
||||
<p><em>Pragmatics: On some systems </em><code>free</code><em> fails when passed a
|
||||
</em><code>NULL</code><em> pointer.</em>
|
||||
|
||||
<p><span class="sc">gdb</span> can use the non-portable function <code>alloca</code> for the
|
||||
allocation of small temporary values (such as strings).
|
||||
|
||||
<p><em>Pragmatics: This function is very non-portable. Some systems
|
||||
restrict the memory being allocated to no more than a few kilobytes.</em>
|
||||
|
||||
<p><span class="sc">gdb</span> uses the string function <code>xstrdup</code> and the print
|
||||
function <code>xstrprintf</code>.
|
||||
|
||||
<p><em>Pragmatics: </em><code>asprintf</code><em> and </em><code>strdup</code><em> can fail. Print
|
||||
functions such as </em><code>sprintf</code><em> are very prone to buffer overflow
|
||||
errors.</em>
|
||||
|
||||
<h3 class="section">17.5 Compiler Warnings</h3>
|
||||
|
||||
<p><a name="index-compiler-warnings-473"></a>
|
||||
With few exceptions, developers should avoid the configuration option
|
||||
‘<samp><span class="samp">--disable-werror</span></samp>’ when building <span class="sc">gdb</span>. The exceptions
|
||||
are listed in the file <samp><span class="file">gdb/MAINTAINERS</span></samp>. The default, when
|
||||
building with <span class="sc">gcc</span>, is ‘<samp><span class="samp">--enable-werror</span></samp>’.
|
||||
|
||||
<p>This option causes <span class="sc">gdb</span> (when built using GCC) to be compiled
|
||||
with a carefully selected list of compiler warning flags. Any warnings
|
||||
from those flags are treated as errors.
|
||||
|
||||
<p>The current list of warning flags includes:
|
||||
|
||||
<dl>
|
||||
<dt>‘<samp><span class="samp">-Wall</span></samp>’<dd>Recommended <span class="sc">gcc</span> warnings.
|
||||
|
||||
<br><dt>‘<samp><span class="samp">-Wdeclaration-after-statement</span></samp>’<dd>
|
||||
<span class="sc">gcc</span> 3.x (and later) and <span class="sc">c99</span> allow declarations mixed with
|
||||
code, but <span class="sc">gcc</span> 2.x and <span class="sc">c89</span> do not.
|
||||
|
||||
<br><dt>‘<samp><span class="samp">-Wpointer-arith</span></samp>’
|
||||
<br><dt>‘<samp><span class="samp">-Wformat-nonliteral</span></samp>’<dd>Non-literal format strings, with a few exceptions, are bugs - they
|
||||
might contain unintended user-supplied format specifiers.
|
||||
Since <span class="sc">gdb</span> uses the <code>format printf</code> attribute on all
|
||||
<code>printf</code> like functions this checks not just <code>printf</code> calls
|
||||
but also calls to functions such as <code>fprintf_unfiltered</code>.
|
||||
|
||||
<br><dt>‘<samp><span class="samp">-Wno-pointer-sign</span></samp>’<dd>In version 4.0, GCC began warning about pointer argument passing or
|
||||
assignment even when the source and destination differed only in
|
||||
signedness. However, most <span class="sc">gdb</span> code doesn't distinguish
|
||||
carefully between <code>char</code> and <code>unsigned char</code>. In early 2006
|
||||
the <span class="sc">gdb</span> developers decided correcting these warnings wasn't
|
||||
worth the time it would take.
|
||||
|
||||
<br><dt>‘<samp><span class="samp">-Wno-unused-parameter</span></samp>’<dd>Due to the way that <span class="sc">gdb</span> is implemented many functions have
|
||||
unused parameters. Consequently this warning is avoided. The macro
|
||||
<code>ATTRIBUTE_UNUSED</code> is not used as it leads to false negatives —
|
||||
it is not an error to have <code>ATTRIBUTE_UNUSED</code> on a parameter that
|
||||
is being used.
|
||||
|
||||
<br><dt>‘<samp><span class="samp">-Wno-unused</span></samp>’<dt>‘<samp><span class="samp">-Wno-switch</span></samp>’<dt>‘<samp><span class="samp">-Wno-char-subscripts</span></samp>’<dd>These are warnings which might be useful for <span class="sc">gdb</span>, but are
|
||||
currently too noisy to enable with ‘<samp><span class="samp">-Werror</span></samp>’.
|
||||
|
||||
</dl>
|
||||
|
||||
<h3 class="section">17.6 Internal Error Recovery</h3>
|
||||
|
||||
<p>During its execution, <span class="sc">gdb</span> can encounter two types of errors.
|
||||
User errors and internal errors. User errors include not only a user
|
||||
entering an incorrect command but also problems arising from corrupt
|
||||
object files and system errors when interacting with the target.
|
||||
Internal errors include situations where <span class="sc">gdb</span> has detected, at
|
||||
run time, a corrupt or erroneous situation.
|
||||
|
||||
<p>When reporting an internal error, <span class="sc">gdb</span> uses
|
||||
<code>internal_error</code> and <code>gdb_assert</code>.
|
||||
|
||||
<p><span class="sc">gdb</span> must not call <code>abort</code> or <code>assert</code>.
|
||||
|
||||
<p><em>Pragmatics: There is no </em><code>internal_warning</code><em> function. Either
|
||||
the code detected a user error, recovered from it and issued a
|
||||
</em><code>warning</code><em> or the code failed to correctly recover from the user
|
||||
error and issued an </em><code>internal_error</code><em>.</em>
|
||||
|
||||
<h3 class="section">17.7 Command Names</h3>
|
||||
|
||||
<p>GDB U/I commands are written ‘<samp><span class="samp">foo-bar</span></samp>’, not ‘<samp><span class="samp">foo_bar</span></samp>’.
|
||||
|
||||
<h3 class="section">17.8 Clean Design and Portable Implementation</h3>
|
||||
|
||||
<p><a name="index-design-474"></a>In addition to getting the syntax right, there's the little question of
|
||||
semantics. Some things are done in certain ways in <span class="sc">gdb</span> because long
|
||||
experience has shown that the more obvious ways caused various kinds of
|
||||
trouble.
|
||||
|
||||
<p><a name="index-assumptions-about-targets-475"></a>You can't assume the byte order of anything that comes from a target
|
||||
(including <var>value</var>s, object files, and instructions). Such things
|
||||
must be byte-swapped using <code>SWAP_TARGET_AND_HOST</code> in
|
||||
<span class="sc">gdb</span>, or one of the swap routines defined in <samp><span class="file">bfd.h</span></samp>,
|
||||
such as <code>bfd_get_32</code>.
|
||||
|
||||
<p>You can't assume that you know what interface is being used to talk to
|
||||
the target system. All references to the target must go through the
|
||||
current <code>target_ops</code> vector.
|
||||
|
||||
<p>You can't assume that the host and target machines are the same machine
|
||||
(except in the “native” support modules). In particular, you can't
|
||||
assume that the target machine's header files will be available on the
|
||||
host machine. Target code must bring along its own header files –
|
||||
written from scratch or explicitly donated by their owner, to avoid
|
||||
copyright problems.
|
||||
|
||||
<p><a name="index-portability-476"></a>Insertion of new <code>#ifdef</code>'s will be frowned upon. It's much better
|
||||
to write the code portably than to conditionalize it for various
|
||||
systems.
|
||||
|
||||
<p><a name="index-system-dependencies-477"></a>New <code>#ifdef</code>'s which test for specific compilers or manufacturers
|
||||
or operating systems are unacceptable. All <code>#ifdef</code>'s should test
|
||||
for features. The information about which configurations contain which
|
||||
features should be segregated into the configuration files. Experience
|
||||
has proven far too often that a feature unique to one particular system
|
||||
often creeps into other systems; and that a conditional based on some
|
||||
predefined macro for your current system will become worthless over
|
||||
time, as new versions of your system come out that behave differently
|
||||
with regard to this feature.
|
||||
|
||||
<p>Adding code that handles specific architectures, operating systems,
|
||||
target interfaces, or hosts, is not acceptable in generic code.
|
||||
|
||||
<p><a name="index-portable-file-name-handling-478"></a><a name="index-file-names_002c-portability-479"></a>One particularly notorious area where system dependencies tend to
|
||||
creep in is handling of file names. The mainline <span class="sc">gdb</span> code
|
||||
assumes Posix semantics of file names: absolute file names begin with
|
||||
a forward slash <samp><span class="file">/</span></samp>, slashes are used to separate leading
|
||||
directories, case-sensitive file names. These assumptions are not
|
||||
necessarily true on non-Posix systems such as MS-Windows. To avoid
|
||||
system-dependent code where you need to take apart or construct a file
|
||||
name, use the following portable macros:
|
||||
|
||||
|
||||
<a name="index-HAVE_005fDOS_005fBASED_005fFILE_005fSYSTEM-480"></a>
|
||||
<dl><dt><code>HAVE_DOS_BASED_FILE_SYSTEM</code><dd>This preprocessing symbol is defined to a non-zero value on hosts
|
||||
whose filesystems belong to the MS-DOS/MS-Windows family. Use this
|
||||
symbol to write conditional code which should only be compiled for
|
||||
such hosts.
|
||||
|
||||
<p><a name="index-IS_005fDIR_005fSEPARATOR-481"></a><br><dt><code>IS_DIR_SEPARATOR (</code><var>c</var><code>)</code><dd>Evaluates to a non-zero value if <var>c</var> is a directory separator
|
||||
character. On Unix and GNU/Linux systems, only a slash <samp><span class="file">/</span></samp> is
|
||||
such a character, but on Windows, both <samp><span class="file">/</span></samp> and <samp><span class="file">\</span></samp> will
|
||||
pass.
|
||||
|
||||
<p><a name="index-IS_005fABSOLUTE_005fPATH-482"></a><br><dt><code>IS_ABSOLUTE_PATH (</code><var>file</var><code>)</code><dd>Evaluates to a non-zero value if <var>file</var> is an absolute file name.
|
||||
For Unix and GNU/Linux hosts, a name which begins with a slash
|
||||
<samp><span class="file">/</span></samp> is absolute. On DOS and Windows, <samp><span class="file">d:/foo</span></samp> and
|
||||
<samp><span class="file">x:\bar</span></samp> are also absolute file names.
|
||||
|
||||
<p><a name="index-FILENAME_005fCMP-483"></a><br><dt><code>FILENAME_CMP (</code><var>f1</var><code>, </code><var>f2</var><code>)</code><dd>Calls a function which compares file names <var>f1</var> and <var>f2</var> as
|
||||
appropriate for the underlying host filesystem. For Posix systems,
|
||||
this simply calls <code>strcmp</code>; on case-insensitive filesystems it
|
||||
will call <code>strcasecmp</code> instead.
|
||||
|
||||
<p><a name="index-DIRNAME_005fSEPARATOR-484"></a><br><dt><code>DIRNAME_SEPARATOR</code><dd>Evaluates to a character which separates directories in
|
||||
<code>PATH</code>-style lists, typically held in environment variables.
|
||||
This character is ‘<samp><span class="samp">:</span></samp>’ on Unix, ‘<samp><span class="samp">;</span></samp>’ on DOS and Windows.
|
||||
|
||||
<p><a name="index-SLASH_005fSTRING-485"></a><br><dt><code>SLASH_STRING</code><dd>This evaluates to a constant string you should use to produce an
|
||||
absolute filename from leading directories and the file's basename.
|
||||
<code>SLASH_STRING</code> is <code>"/"</code> on most systems, but might be
|
||||
<code>"\\"</code> for some Windows-based ports.
|
||||
</dl>
|
||||
|
||||
<p>In addition to using these macros, be sure to use portable library
|
||||
functions whenever possible. For example, to extract a directory or a
|
||||
basename part from a file name, use the <code>dirname</code> and
|
||||
<code>basename</code> library functions (available in <code>libiberty</code> for
|
||||
platforms which don't provide them), instead of searching for a slash
|
||||
with <code>strrchr</code>.
|
||||
|
||||
<p>Another way to generalize <span class="sc">gdb</span> along a particular interface is with an
|
||||
attribute struct. For example, <span class="sc">gdb</span> has been generalized to handle
|
||||
multiple kinds of remote interfaces—not by <code>#ifdef</code>s everywhere, but
|
||||
by defining the <code>target_ops</code> structure and having a current target (as
|
||||
well as a stack of targets below it, for memory references). Whenever
|
||||
something needs to be done that depends on which remote interface we are
|
||||
using, a flag in the current target_ops structure is tested (e.g.,
|
||||
<code>target_has_stack</code>), or a function is called through a pointer in the
|
||||
current target_ops structure. In this way, when a new remote interface
|
||||
is added, only one module needs to be touched—the one that actually
|
||||
implements the new remote interface. Other examples of
|
||||
attribute-structs are BFD access to multiple kinds of object file
|
||||
formats, or <span class="sc">gdb</span>'s access to multiple source languages.
|
||||
|
||||
<p>Please avoid duplicating code. For example, in <span class="sc">gdb</span> 3.x all
|
||||
the code interfacing between <code>ptrace</code> and the rest of
|
||||
<span class="sc">gdb</span> was duplicated in <samp><span class="file">*-dep.c</span></samp>, and so changing
|
||||
something was very painful. In <span class="sc">gdb</span> 4.x, these have all been
|
||||
consolidated into <samp><span class="file">infptrace.c</span></samp>. <samp><span class="file">infptrace.c</span></samp> can deal
|
||||
with variations between systems the same way any system-independent
|
||||
file would (hooks, <code>#if defined</code>, etc.), and machines which are
|
||||
radically different don't need to use <samp><span class="file">infptrace.c</span></samp> at all.
|
||||
|
||||
<p>All debugging code must be controllable using the ‘<samp><span class="samp">set debug
|
||||
</span><var>module</var></samp>’ command. Do not use <code>printf</code> to print trace
|
||||
messages. Use <code>fprintf_unfiltered(gdb_stdlog, ...</code>. Do not use
|
||||
<code>#ifdef DEBUG</code>.
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,137 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>Native Debugging - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="prev" href="Target-Vector-Definition.html#Target-Vector-Definition" title="Target Vector Definition">
|
||||
<link rel="next" href="Support-Libraries.html#Support-Libraries" title="Support Libraries">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Native-Debugging"></a>
|
||||
Next: <a rel="next" accesskey="n" href="Support-Libraries.html#Support-Libraries">Support Libraries</a>,
|
||||
Previous: <a rel="previous" accesskey="p" href="Target-Vector-Definition.html#Target-Vector-Definition">Target Vector Definition</a>,
|
||||
Up: <a rel="up" accesskey="u" href="index.html#Top">Top</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h2 class="chapter">14 Native Debugging</h2>
|
||||
|
||||
<p><a name="index-native-debugging-440"></a>
|
||||
Several files control <span class="sc">gdb</span>'s configuration for native support:
|
||||
|
||||
|
||||
<a name="index-NATDEPFILES-441"></a>
|
||||
<dl><dt><samp><span class="file">gdb/config/</span><var>arch</var><span class="file">/</span><var>xyz</var><span class="file">.mh</span></samp><dd>Specifies Makefile fragments needed by a <em>native</em> configuration on
|
||||
machine <var>xyz</var>. In particular, this lists the required
|
||||
native-dependent object files, by defining ‘<samp><span class="samp">NATDEPFILES=...</span></samp>’.
|
||||
Also specifies the header file which describes native support on
|
||||
<var>xyz</var>, by defining ‘<samp><span class="samp">NAT_FILE= nm-</span><var>xyz</var><span class="samp">.h</span></samp>’. You can also
|
||||
define ‘<samp><span class="samp">NAT_CFLAGS</span></samp>’, ‘<samp><span class="samp">NAT_ADD_FILES</span></samp>’, ‘<samp><span class="samp">NAT_CLIBS</span></samp>’,
|
||||
‘<samp><span class="samp">NAT_CDEPS</span></samp>’, ‘<samp><span class="samp">NAT_GENERATED_FILES</span></samp>’, etc.; see <samp><span class="file">Makefile.in</span></samp>.
|
||||
|
||||
<p><em>Maintainer's note: The </em><samp><span class="file">.mh</span></samp><em> suffix is because this file
|
||||
originally contained </em><samp><span class="file">Makefile</span></samp><em> fragments for hosting </em><span class="sc">gdb</span><em>
|
||||
on machine </em><var>xyz</var><em>. While the file is no longer used for this
|
||||
purpose, the </em><samp><span class="file">.mh</span></samp><em> suffix remains. Perhaps someone will
|
||||
eventually rename these fragments so that they have a </em><samp><span class="file">.mn</span></samp><em>
|
||||
suffix.</em>
|
||||
|
||||
<br><dt><samp><span class="file">gdb/config/</span><var>arch</var><span class="file">/nm-</span><var>xyz</var><span class="file">.h</span></samp><dd>(<samp><span class="file">nm.h</span></samp> is a link to this file, created by <code>configure</code>). Contains C
|
||||
macro definitions describing the native system environment, such as
|
||||
child process control and core file support.
|
||||
|
||||
<br><dt><samp><span class="file">gdb/</span><var>xyz</var><span class="file">-nat.c</span></samp><dd>Contains any miscellaneous C code required for this native support of
|
||||
this machine. On some machines it doesn't exist at all.
|
||||
</dl>
|
||||
|
||||
<p>There are some “generic” versions of routines that can be used by
|
||||
various systems. These can be customized in various ways by macros
|
||||
defined in your <samp><span class="file">nm-</span><var>xyz</var><span class="file">.h</span></samp> file. If these routines work for
|
||||
the <var>xyz</var> host, you can just include the generic file's name (with
|
||||
‘<samp><span class="samp">.o</span></samp>’, not ‘<samp><span class="samp">.c</span></samp>’) in <code>NATDEPFILES</code>.
|
||||
|
||||
<p>Otherwise, if your machine needs custom support routines, you will need
|
||||
to write routines that perform the same functions as the generic file.
|
||||
Put them into <samp><var>xyz</var><span class="file">-nat.c</span></samp>, and put <samp><var>xyz</var><span class="file">-nat.o</span></samp>
|
||||
into <code>NATDEPFILES</code>.
|
||||
|
||||
<dl>
|
||||
<dt><samp><span class="file">inftarg.c</span></samp><dd>This contains the <em>target_ops vector</em> that supports Unix child
|
||||
processes on systems which use ptrace and wait to control the child.
|
||||
|
||||
<br><dt><samp><span class="file">procfs.c</span></samp><dd>This contains the <em>target_ops vector</em> that supports Unix child
|
||||
processes on systems which use /proc to control the child.
|
||||
|
||||
<br><dt><samp><span class="file">fork-child.c</span></samp><dd>This does the low-level grunge that uses Unix system calls to do a “fork
|
||||
and exec” to start up a child process.
|
||||
|
||||
<br><dt><samp><span class="file">infptrace.c</span></samp><dd>This is the low level interface to inferior processes for systems using
|
||||
the Unix <code>ptrace</code> call in a vanilla way.
|
||||
</dl>
|
||||
|
||||
<h3 class="section">14.1 ptrace</h3>
|
||||
|
||||
<h3 class="section">14.2 /proc</h3>
|
||||
|
||||
<h3 class="section">14.3 win32</h3>
|
||||
|
||||
<h3 class="section">14.4 shared libraries</h3>
|
||||
|
||||
<h3 class="section">14.5 Native Conditionals</h3>
|
||||
|
||||
<p><a name="index-native-conditionals-442"></a>
|
||||
When <span class="sc">gdb</span> is configured and compiled, various macros are
|
||||
defined or left undefined, to control compilation when the host and
|
||||
target systems are the same. These macros should be defined (or left
|
||||
undefined) in <samp><span class="file">nm-</span><var>system</var><span class="file">.h</span></samp>.
|
||||
|
||||
<dl>
|
||||
<dt><code>I386_USE_GENERIC_WATCHPOINTS</code><dd>An x86-based machine can define this to use the generic x86 watchpoint
|
||||
support; see <a href="Algorithms.html#Algorithms">I386_USE_GENERIC_WATCHPOINTS</a>.
|
||||
|
||||
<br><dt><code>SOLIB_ADD (</code><var>filename</var><code>, </code><var>from_tty</var><code>, </code><var>targ</var><code>, </code><var>readsyms</var><code>)</code><dd><a name="index-SOLIB_005fADD-443"></a>Define this to expand into an expression that will cause the symbols in
|
||||
<var>filename</var> to be added to <span class="sc">gdb</span>'s symbol table. If
|
||||
<var>readsyms</var> is zero symbols are not read but any necessary low level
|
||||
processing for <var>filename</var> is still done.
|
||||
|
||||
<br><dt><code>SOLIB_CREATE_INFERIOR_HOOK</code><dd><a name="index-SOLIB_005fCREATE_005fINFERIOR_005fHOOK-444"></a>Define this to expand into any shared-library-relocation code that you
|
||||
want to be run just after the child process has been forked.
|
||||
|
||||
<br><dt><code>START_INFERIOR_TRAPS_EXPECTED</code><dd><a name="index-START_005fINFERIOR_005fTRAPS_005fEXPECTED-445"></a>When starting an inferior, <span class="sc">gdb</span> normally expects to trap
|
||||
twice; once when
|
||||
the shell execs, and once when the program itself execs. If the actual
|
||||
number of traps is something other than 2, then define this macro to
|
||||
expand into the number expected.
|
||||
|
||||
</dl>
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,167 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>OS ABI Variant Handling - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="up" href="Target-Architecture-Definition.html#Target-Architecture-Definition" title="Target Architecture Definition">
|
||||
<link rel="next" href="Initialize-New-Architecture.html#Initialize-New-Architecture" title="Initialize New Architecture">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="OS-ABI-Variant-Handling"></a>
|
||||
Next: <a rel="next" accesskey="n" href="Initialize-New-Architecture.html#Initialize-New-Architecture">Initialize New Architecture</a>,
|
||||
Up: <a rel="up" accesskey="u" href="Target-Architecture-Definition.html#Target-Architecture-Definition">Target Architecture Definition</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h3 class="section">11.1 Operating System ABI Variant Handling</h3>
|
||||
|
||||
<p><a name="index-OS-ABI-variants-193"></a>
|
||||
<span class="sc">gdb</span> 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>A <dfn>sniffer</dfn> 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 <dfn>generic</dfn>, while sniffers for a specific architecture are
|
||||
considered to be <dfn>specific</dfn>. 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><a name="index-fine_002dtuning-_0040code_007bgdbarch_007d-structure-194"></a>A <dfn>handler</dfn> 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>The following OS ABI variants are defined in <samp><span class="file">defs.h</span></samp>:
|
||||
|
||||
|
||||
<a name="index-GDB_005fOSABI_005fUNINITIALIZED-195"></a>
|
||||
<dl><dt><code>GDB_OSABI_UNINITIALIZED</code><dd>Used for struct gdbarch_info if ABI is still uninitialized.
|
||||
|
||||
<p><a name="index-GDB_005fOSABI_005fUNKNOWN-196"></a><br><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="index-GDB_005fOSABI_005fSVR4-197"></a><br><dt><code>GDB_OSABI_SVR4</code><dd>UNIX System V Release 4.
|
||||
|
||||
<p><a name="index-GDB_005fOSABI_005fHURD-198"></a><br><dt><code>GDB_OSABI_HURD</code><dd>GNU using the Hurd kernel.
|
||||
|
||||
<p><a name="index-GDB_005fOSABI_005fSOLARIS-199"></a><br><dt><code>GDB_OSABI_SOLARIS</code><dd>Sun Solaris.
|
||||
|
||||
<p><a name="index-GDB_005fOSABI_005fOSF1-200"></a><br><dt><code>GDB_OSABI_OSF1</code><dd>OSF/1, including Digital UNIX and Compaq Tru64 UNIX.
|
||||
|
||||
<p><a name="index-GDB_005fOSABI_005fLINUX-201"></a><br><dt><code>GDB_OSABI_LINUX</code><dd>GNU using the Linux kernel.
|
||||
|
||||
<p><a name="index-GDB_005fOSABI_005fFREEBSD_005fAOUT-202"></a><br><dt><code>GDB_OSABI_FREEBSD_AOUT</code><dd>FreeBSD using the <code>a.out</code> executable format.
|
||||
|
||||
<p><a name="index-GDB_005fOSABI_005fFREEBSD_005fELF-203"></a><br><dt><code>GDB_OSABI_FREEBSD_ELF</code><dd>FreeBSD using the ELF executable format.
|
||||
|
||||
<p><a name="index-GDB_005fOSABI_005fNETBSD_005fAOUT-204"></a><br><dt><code>GDB_OSABI_NETBSD_AOUT</code><dd>NetBSD using the <code>a.out</code> executable format.
|
||||
|
||||
<p><a name="index-GDB_005fOSABI_005fNETBSD_005fELF-205"></a><br><dt><code>GDB_OSABI_NETBSD_ELF</code><dd>NetBSD using the ELF executable format.
|
||||
|
||||
<p><a name="index-GDB_005fOSABI_005fOPENBSD_005fELF-206"></a><br><dt><code>GDB_OSABI_OPENBSD_ELF</code><dd>OpenBSD using the ELF executable format.
|
||||
|
||||
<p><a name="index-GDB_005fOSABI_005fWINCE-207"></a><br><dt><code>GDB_OSABI_WINCE</code><dd>Windows CE.
|
||||
|
||||
<p><a name="index-GDB_005fOSABI_005fGO32-208"></a><br><dt><code>GDB_OSABI_GO32</code><dd>DJGPP.
|
||||
|
||||
<p><a name="index-GDB_005fOSABI_005fIRIX-209"></a><br><dt><code>GDB_OSABI_IRIX</code><dd>Irix.
|
||||
|
||||
<p><a name="index-GDB_005fOSABI_005fINTERIX-210"></a><br><dt><code>GDB_OSABI_INTERIX</code><dd>Interix (Posix layer for MS-Windows systems).
|
||||
|
||||
<p><a name="index-GDB_005fOSABI_005fHPUX_005fELF-211"></a><br><dt><code>GDB_OSABI_HPUX_ELF</code><dd>HP/UX using the ELF executable format.
|
||||
|
||||
<p><a name="index-GDB_005fOSABI_005fHPUX_005fSOM-212"></a><br><dt><code>GDB_OSABI_HPUX_SOM</code><dd>HP/UX using the SOM executable format.
|
||||
|
||||
<p><a name="index-GDB_005fOSABI_005fQNXNTO-213"></a><br><dt><code>GDB_OSABI_QNXNTO</code><dd>QNX Neutrino.
|
||||
|
||||
<p><a name="index-GDB_005fOSABI_005fCYGWIN-214"></a><br><dt><code>GDB_OSABI_CYGWIN</code><dd>Cygwin.
|
||||
|
||||
<p><a name="index-GDB_005fOSABI_005fAIX-215"></a><br><dt><code>GDB_OSABI_AIX</code><dd>AIX.
|
||||
|
||||
</dl>
|
||||
|
||||
<p>Here are the functions that make up the OS ABI framework:
|
||||
|
||||
<div class="defun">
|
||||
— Function: const char * <b>gdbarch_osabi_name</b> (<var>enum gdb_osabi osabi</var>)<var><a name="index-gdbarch_005fosabi_005fname-216"></a></var><br>
|
||||
<blockquote><p>Return the name of the OS ABI corresponding to <var>osabi</var>.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>gdbarch_register_osabi</b> (<var>enum bfd_architecture arch, unsigned long machine, enum gdb_osabi osabi, void </var>(<var>*init_osabi</var>)(<var>struct gdbarch_info info, struct gdbarch *gdbarch</var>))<var><a name="index-gdbarch_005fregister_005fosabi-217"></a></var><br>
|
||||
<blockquote><p>Register the OS ABI handler specified by <var>init_osabi</var> for the
|
||||
architecture, machine type and OS ABI specified by <var>arch</var>,
|
||||
<var>machine</var> and <var>osabi</var>. In most cases, a value of zero for the
|
||||
machine type, which implies the architecture's default machine type,
|
||||
will suffice.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>gdbarch_register_osabi_sniffer</b> (<var>enum bfd_architecture arch, enum bfd_flavour flavour, enum gdb_osabi </var>(<var>*sniffer</var>)(<var>bfd *abfd</var>))<var><a name="index-gdbarch_005fregister_005fosabi_005fsniffer-218"></a></var><br>
|
||||
<blockquote><p>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.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: enum gdb_osabi <b>gdbarch_lookup_osabi</b> (<var>bfd *abfd</var>)<var><a name="index-gdbarch_005flookup_005fosabi-219"></a></var><br>
|
||||
<blockquote><p>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.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>gdbarch_init_osabi</b> (<var>struct gdbarch info info, struct gdbarch *gdbarch, enum gdb_osabi osabi</var>)<var><a name="index-gdbarch_005finit_005fosabi-220"></a></var><br>
|
||||
<blockquote><p>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>.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>generic_elf_osabi_sniff_abi_tag_sections</b> (<var>bfd *abfd, asection *sect, void *obj</var>)<var><a name="index-generic_005felf_005fosabi_005fsniff_005fabi_005ftag_005fsections-221"></a></var><br>
|
||||
<blockquote><p>Helper routine for ELF file sniffers. Examine the file described by
|
||||
<var>abfd</var> and look at ABI tag note sections to determine the OS ABI
|
||||
from the note. This function should be called via
|
||||
<code>bfd_map_over_sections</code>.
|
||||
</p></blockquote></div>
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,164 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>Overall Structure - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="prev" href="Summary.html#Summary" title="Summary">
|
||||
<link rel="next" href="Algorithms.html#Algorithms" title="Algorithms">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Overall-Structure"></a>
|
||||
Next: <a rel="next" accesskey="n" href="Algorithms.html#Algorithms">Algorithms</a>,
|
||||
Previous: <a rel="previous" accesskey="p" href="Summary.html#Summary">Summary</a>,
|
||||
Up: <a rel="up" accesskey="u" href="index.html#Top">Top</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h2 class="chapter">2 Overall Structure</h2>
|
||||
|
||||
<p><span class="sc">gdb</span> consists of three major subsystems: user interface,
|
||||
symbol handling (the <dfn>symbol side</dfn>), and target system handling (the
|
||||
<dfn>target side</dfn>).
|
||||
|
||||
<p>The user interface consists of several actual interfaces, plus
|
||||
supporting code.
|
||||
|
||||
<p>The symbol side consists of object file readers, debugging info
|
||||
interpreters, symbol table management, source language expression
|
||||
parsing, type and value printing.
|
||||
|
||||
<p>The target side consists of execution control, stack frame analysis, and
|
||||
physical target manipulation.
|
||||
|
||||
<p>The target side/symbol side division is not formal, and there are a
|
||||
number of exceptions. For instance, core file support involves symbolic
|
||||
elements (the basic core file reader is in BFD) and target elements (it
|
||||
supplies the contents of memory and the values of registers). Instead,
|
||||
this division is useful for understanding how the minor subsystems
|
||||
should fit together.
|
||||
|
||||
<h3 class="section">2.1 The Symbol Side</h3>
|
||||
|
||||
<p>The symbolic side of <span class="sc">gdb</span> can be thought of as “everything
|
||||
you can do in <span class="sc">gdb</span> without having a live program running”.
|
||||
For instance, you can look at the types of variables, and evaluate
|
||||
many kinds of expressions.
|
||||
|
||||
<h3 class="section">2.2 The Target Side</h3>
|
||||
|
||||
<p>The target side of <span class="sc">gdb</span> is the “bits and bytes manipulator”.
|
||||
Although it may make reference to symbolic info here and there, most
|
||||
of the target side will run with only a stripped executable
|
||||
available—or even no executable at all, in remote debugging cases.
|
||||
|
||||
<p>Operations such as disassembly, stack frame crawls, and register
|
||||
display, are able to work with no symbolic info at all. In some cases,
|
||||
such as disassembly, <span class="sc">gdb</span> will use symbolic info to present addresses
|
||||
relative to symbols rather than as raw numbers, but it will work either
|
||||
way.
|
||||
|
||||
<h3 class="section">2.3 Configurations</h3>
|
||||
|
||||
<p><a name="index-host-2"></a><a name="index-target-3"></a><dfn>Host</dfn> refers to attributes of the system where <span class="sc">gdb</span> runs.
|
||||
<dfn>Target</dfn> refers to the system where the program being debugged
|
||||
executes. In most cases they are the same machine, in which case a
|
||||
third type of <dfn>Native</dfn> attributes come into play.
|
||||
|
||||
<p>Defines and include files needed to build on the host are host
|
||||
support. Examples are tty support, system defined types, host byte
|
||||
order, host float format. These are all calculated by <code>autoconf</code>
|
||||
when the debugger is built.
|
||||
|
||||
<p>Defines and information needed to handle the target format are target
|
||||
dependent. Examples are the stack frame format, instruction set,
|
||||
breakpoint instruction, registers, and how to set up and tear down the stack
|
||||
to call a function.
|
||||
|
||||
<p>Information that is only needed when the host and target are the same,
|
||||
is native dependent. One example is Unix child process support; if the
|
||||
host and target are not the same, calling <code>fork</code> to start the target
|
||||
process is a bad idea. The various macros needed for finding the
|
||||
registers in the <code>upage</code>, running <code>ptrace</code>, and such are all
|
||||
in the native-dependent files.
|
||||
|
||||
<p>Another example of native-dependent code is support for features that
|
||||
are really part of the target environment, but which require
|
||||
<code>#include</code> files that are only available on the host system. Core
|
||||
file handling and <code>setjmp</code> handling are two common cases.
|
||||
|
||||
<p>When you want to make <span class="sc">gdb</span> work as the traditional native debugger
|
||||
on a system, you will need to supply both target and native information.
|
||||
|
||||
<h3 class="section">2.4 Source Tree Structure</h3>
|
||||
|
||||
<p><a name="index-g_t_0040value_007bGDBN_007d-source-tree-structure-4"></a>
|
||||
The <span class="sc">gdb</span> source directory has a mostly flat structure—there
|
||||
are only a few subdirectories. A file's name usually gives a hint as
|
||||
to what it does; for example, <samp><span class="file">stabsread.c</span></samp> reads stabs,
|
||||
<samp><span class="file">dwarf2read.c</span></samp> reads <span class="sc">DWARF 2</span>, etc.
|
||||
|
||||
<p>Files that are related to some common task have names that share
|
||||
common substrings. For example, <samp><span class="file">*-thread.c</span></samp> files deal with
|
||||
debugging threads on various platforms; <samp><span class="file">*read.c</span></samp> files deal with
|
||||
reading various kinds of symbol and object files; <samp><span class="file">inf*.c</span></samp> files
|
||||
deal with direct control of the <dfn>inferior program</dfn> (<span class="sc">gdb</span>
|
||||
parlance for the program being debugged).
|
||||
|
||||
<p>There are several dozens of files in the <samp><span class="file">*-tdep.c</span></samp> family.
|
||||
‘<samp><span class="samp">tdep</span></samp>’ stands for <dfn>target-dependent code</dfn>—each of these
|
||||
files implements debug support for a specific target architecture
|
||||
(sparc, mips, etc). Usually, only one of these will be used in a
|
||||
specific <span class="sc">gdb</span> configuration (sometimes two, closely related).
|
||||
|
||||
<p>Similarly, there are many <samp><span class="file">*-nat.c</span></samp> files, each one for native
|
||||
debugging on a specific system (e.g., <samp><span class="file">sparc-linux-nat.c</span></samp> is for
|
||||
native debugging of Sparc machines running the Linux kernel).
|
||||
|
||||
<p>The few subdirectories of the source tree are:
|
||||
|
||||
<dl>
|
||||
<dt><samp><span class="file">cli</span></samp><dd>Code that implements <dfn>CLI</dfn>, the <span class="sc">gdb</span> Command-Line
|
||||
Interpreter. See <a href="User-Interface.html#User-Interface">Command Interpreter</a>.
|
||||
|
||||
<br><dt><samp><span class="file">gdbserver</span></samp><dd>Code for the <span class="sc">gdb</span> remote server.
|
||||
|
||||
<br><dt><samp><span class="file">gdbtk</span></samp><dd>Code for Insight, the <span class="sc">gdb</span> TK-based GUI front-end.
|
||||
|
||||
<br><dt><samp><span class="file">mi</span></samp><dd>The <dfn>GDB/MI</dfn>, the <span class="sc">gdb</span> Machine Interface interpreter.
|
||||
|
||||
<br><dt><samp><span class="file">signals</span></samp><dd>Target signal translation code.
|
||||
|
||||
<br><dt><samp><span class="file">tui</span></samp><dd>Code for <dfn>TUI</dfn>, the <span class="sc">gdb</span> Text-mode full-screen User
|
||||
Interface. See <a href="User-Interface.html#User-Interface">TUI</a>.
|
||||
</dl>
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,183 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>Pointers and Addresses - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="up" href="Target-Architecture-Definition.html#Target-Architecture-Definition" title="Target Architecture Definition">
|
||||
<link rel="prev" href="Registers-and-Memory.html#Registers-and-Memory" title="Registers and Memory">
|
||||
<link rel="next" href="Address-Classes.html#Address-Classes" title="Address Classes">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Pointers-and-Addresses"></a>
|
||||
Next: <a rel="next" accesskey="n" href="Address-Classes.html#Address-Classes">Address Classes</a>,
|
||||
Previous: <a rel="previous" accesskey="p" href="Registers-and-Memory.html#Registers-and-Memory">Registers and Memory</a>,
|
||||
Up: <a rel="up" accesskey="u" href="Target-Architecture-Definition.html#Target-Architecture-Definition">Target Architecture Definition</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h3 class="section">11.4 Pointers Are Not Always Addresses</h3>
|
||||
|
||||
<p><a name="index-pointer-representation-239"></a><a name="index-address-representation-240"></a><a name="index-word_002daddressed-machines-241"></a><a name="index-separate-data-and-code-address-spaces-242"></a><a name="index-spaces_002c-separate-data-and-code-address-243"></a><a name="index-address-spaces_002c-separate-data-and-code-244"></a><a name="index-code-pointers_002c-word_002daddressed-245"></a><a name="index-converting-between-pointers-and-addresses-246"></a><a name="index-D10V-addresses-247"></a>
|
||||
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.
|
||||
|
||||
<!-- D10V is gone from sources - more current example? -->
|
||||
<p>For example, the Renesas D10V is a 16-bit VLIW processor whose
|
||||
instructions are 32 bits long<a rel="footnote" href="#fn-1" name="fnd-1"><sup>1</sup></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>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>(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>To cope with architectures like this—the D10V is not the only
|
||||
one!—<span class="sc">gdb</span> tries to distinguish between <dfn>addresses</dfn>, which are
|
||||
byte numbers, and <dfn>pointers</dfn>, 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.
|
||||
<span class="sc">gdb</span> provides functions for turning a pointer into an address
|
||||
and vice versa, in the appropriate way for the current architecture.
|
||||
|
||||
<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 <span class="sc">gdb</span> to an architecture which does
|
||||
distinguish between pointers and addresses, you'll probably need to
|
||||
clean up some architecture-independent code.
|
||||
|
||||
<p>Here are functions which convert between pointers and addresses:
|
||||
|
||||
<div class="defun">
|
||||
— Function: CORE_ADDR <b>extract_typed_address</b> (<var>void *buf, struct type *type</var>)<var><a name="index-extract_005ftyped_005faddress-248"></a></var><br>
|
||||
<blockquote><p>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
|
||||
<span class="sc">gdb</span> can use to read target memory, disassemble, etc. Note that
|
||||
<var>buf</var> refers to a buffer in <span class="sc">gdb</span>'s memory, not the
|
||||
inferior's.
|
||||
|
||||
<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>If <var>type</var> is not a pointer or reference type, then this function
|
||||
will signal an internal error.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: CORE_ADDR <b>store_typed_address</b> (<var>void *buf, struct type *type, CORE_ADDR addr</var>)<var><a name="index-store_005ftyped_005faddress-249"></a></var><br>
|
||||
<blockquote><p>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 <span class="sc">gdb</span>'s memory, not the
|
||||
inferior's.
|
||||
|
||||
<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>If <var>type</var> is not a pointer or reference type, then this function
|
||||
will signal an internal error.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: CORE_ADDR <b>value_as_address</b> (<var>struct value *val</var>)<var><a name="index-value_005fas_005faddress-250"></a></var><br>
|
||||
<blockquote><p>Assuming that <var>val</var> is a pointer, return the address it represents,
|
||||
as appropriate for the current architecture.
|
||||
|
||||
<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>.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: CORE_ADDR <b>value_from_pointer</b> (<var>struct type *type, CORE_ADDR addr</var>)<var><a name="index-value_005ffrom_005fpointer-251"></a></var><br>
|
||||
<blockquote><p>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>.
|
||||
</p></blockquote></div>
|
||||
|
||||
<p>Here are two functions which architectures can define to indicate the
|
||||
relationship between pointers and addresses. These have default
|
||||
definitions, appropriate for architectures on which all pointers are
|
||||
simple unsigned byte addresses.
|
||||
|
||||
<div class="defun">
|
||||
— Function: CORE_ADDR <b>gdbarch_pointer_to_address</b> (<var>struct gdbarch *gdbarch, struct type *type, char *buf</var>)<var><a name="index-gdbarch_005fpointer_005fto_005faddress-252"></a></var><br>
|
||||
<blockquote><p>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>This function may safely assume that <var>type</var> is either a pointer or a
|
||||
C<tt>++</tt> reference type.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>gdbarch_address_to_pointer</b> (<var>struct gdbarch *gdbarch, struct type *type, char *buf, CORE_ADDR addr</var>)<var><a name="index-gdbarch_005faddress_005fto_005fpointer-253"></a></var><br>
|
||||
<blockquote><p>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>This function may safely assume that <var>type</var> is either a pointer or a
|
||||
C<tt>++</tt> reference type.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="footnote">
|
||||
<hr>
|
||||
<h4>Footnotes</h4><p class="footnote"><small>[<a name="fn-1" href="#fnd-1">1</a>]</small> Some D10V instructions are
|
||||
actually pairs of 16-bit sub-instructions. However, since you can't
|
||||
jump into the middle of such a pair, code addresses can only refer to
|
||||
full 32 bit instructions, which is what matters in this explanation.</p>
|
||||
|
||||
<hr></div>
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,90 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>Porting GDB - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="prev" href="Misc-Guidelines.html#Misc-Guidelines" title="Misc Guidelines">
|
||||
<link rel="next" href="Versions-and-Branches.html#Versions-and-Branches" title="Versions and Branches">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Porting-GDB"></a>
|
||||
Next: <a rel="next" accesskey="n" href="Versions-and-Branches.html#Versions-and-Branches">Versions and Branches</a>,
|
||||
Previous: <a rel="previous" accesskey="p" href="Misc-Guidelines.html#Misc-Guidelines">Misc Guidelines</a>,
|
||||
Up: <a rel="up" accesskey="u" href="index.html#Top">Top</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h2 class="chapter">18 Porting <span class="sc">gdb</span></h2>
|
||||
|
||||
<p><a name="index-porting-to-new-machines-486"></a>
|
||||
Most of the work in making <span class="sc">gdb</span> compile on a new machine is in
|
||||
specifying the configuration of the machine. Porting a new
|
||||
architecture to <span class="sc">gdb</span> can be broken into a number of steps.
|
||||
|
||||
<ul>
|
||||
<li>Ensure a <span class="sc">bfd</span> exists for executables of the target architecture in
|
||||
the <samp><span class="file">bfd</span></samp> directory. If one does not exist, create one by
|
||||
modifying an existing similar one.
|
||||
|
||||
<li>Implement a disassembler for the target architecture in the <samp><span class="file">opcodes</span></samp>
|
||||
directory.
|
||||
|
||||
<li>Define the target architecture in the <samp><span class="file">gdb</span></samp> directory
|
||||
(see <a href="Adding-a-New-Target.html#Adding-a-New-Target">Adding a New Target</a>). Add the pattern
|
||||
for the new target to <samp><span class="file">configure.tgt</span></samp> with the names of the files
|
||||
that contain the code. By convention the target architecture
|
||||
definition for an architecture <var>arch</var> is placed in
|
||||
<samp><var>arch</var><span class="file">-tdep.c</span></samp>.
|
||||
|
||||
<p>Within <samp><var>arch</var><span class="file">-tdep.c</span></samp> define the function
|
||||
<code>_initialize_</code><var>arch</var><code>_tdep</code> which calls
|
||||
<code>gdbarch_register</code> to create the new <code>struct gdbarch<!-- /@w --></code> for the architecture.
|
||||
|
||||
<li>If a new remote target is needed, consider adding a new remote target
|
||||
by defining a function
|
||||
<code>_initialize_remote_</code><var>arch</var>. However if at all possible
|
||||
use the <span class="sc">gdb</span> <em>Remote Serial Protocol</em> for this and implement
|
||||
the server side protocol independently with the target.
|
||||
|
||||
<li>If desired implement a simulator in the <samp><span class="file">sim</span></samp> directory. This
|
||||
should create the library <samp><span class="file">libsim.a</span></samp> implementing the interface
|
||||
in <samp><span class="file">remote-sim.h</span></samp> (found in the <samp><span class="file">include</span></samp> directory).
|
||||
|
||||
<li>Build and test. If desired, lobby the <span class="sc">gdb</span> steering group to
|
||||
have the new port included in the main distribution!
|
||||
|
||||
<li>Add a description of the new architecture to the main <span class="sc">gdb</span> user
|
||||
guide (see <a href="../gdb/Configuration-Specific-Information.html#Configuration-Specific-Information">Configuration Specific Information</a>).
|
||||
|
||||
</ul>
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,79 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>Prologue Caches - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="up" href="Frame-Interpretation.html#Frame-Interpretation" title="Frame Interpretation">
|
||||
<link rel="prev" href="Frame-Handling-Terminology.html#Frame-Handling-Terminology" title="Frame Handling Terminology">
|
||||
<link rel="next" href="Functions-and-Variable-to-Analyze-Frames.html#Functions-and-Variable-to-Analyze-Frames" title="Functions and Variable to Analyze Frames">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Prologue-Caches"></a>
|
||||
Next: <a rel="next" accesskey="n" href="Functions-and-Variable-to-Analyze-Frames.html#Functions-and-Variable-to-Analyze-Frames">Functions and Variable to Analyze Frames</a>,
|
||||
Previous: <a rel="previous" accesskey="p" href="Frame-Handling-Terminology.html#Frame-Handling-Terminology">Frame Handling Terminology</a>,
|
||||
Up: <a rel="up" accesskey="u" href="Frame-Interpretation.html#Frame-Interpretation">Frame Interpretation</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h4 class="subsection">11.7.3 Prologue Caches</h4>
|
||||
|
||||
<p><a name="index-function-prologue-334"></a><a name="index-prologue-of-a-function-335"></a>All the frame sniffing functions typically examine the code at the
|
||||
start of the corresponding function, to determine the state of
|
||||
registers. The ABI will save old values and set new values of key
|
||||
registers at the start of each function in what is known as the
|
||||
function <dfn>prologue</dfn>.
|
||||
|
||||
<p><a name="index-prologue-cache-336"></a>For any particular stack frame this data does not change, so all the
|
||||
standard unwinding functions, in addition to receiving a pointer to
|
||||
the NEXT frame as their first argument, receive a pointer to a
|
||||
<dfn>prologue cache</dfn> as their second argument. This can be used to store
|
||||
values associated with a particular frame, for reuse on subsequent
|
||||
calls involving the same frame.
|
||||
|
||||
<p>It is up to the user to define the structure used (it is a
|
||||
<code>void <!-- /@w -->*</code> pointer) and arrange allocation and deallocation of
|
||||
storage. However for general use, <span class="sc">gdb</span> provides
|
||||
<code>struct trad_frame_cache<!-- /@w --></code>, with a set of accessor
|
||||
routines. This structure holds the stack and code address of
|
||||
THIS frame, the base address of the frame, a pointer to the
|
||||
struct <code>frame_info</code> for the NEXT frame and details of
|
||||
where the registers of the PREVIOUS frame may be found in THIS
|
||||
frame.
|
||||
|
||||
<p>Typically the first time any sniffer function is called with NEXT
|
||||
frame, the prologue sniffer for THIS frame will be <code>NULL</code>. The
|
||||
sniffer will analyze the frame, allocate a prologue cache structure
|
||||
and populate it. Subsequent calls using the same NEXT frame will
|
||||
pass in this prologue cache, so the data can be returned with no
|
||||
additional analysis.
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,65 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>Raw and Cooked Registers - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="up" href="Register-Representation.html#Register-Representation" title="Register Representation">
|
||||
<link rel="next" href="Register-Architecture-Functions-_0026-Variables.html#Register-Architecture-Functions-_0026-Variables" title="Register Architecture Functions & Variables">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Raw-and-Cooked-Registers"></a>
|
||||
Next: <a rel="next" accesskey="n" href="Register-Architecture-Functions-_0026-Variables.html#Register-Architecture-Functions-_0026-Variables">Register Architecture Functions & Variables</a>,
|
||||
Up: <a rel="up" accesskey="u" href="Register-Representation.html#Register-Representation">Register Representation</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h4 class="subsection">11.6.1 Raw and Cooked Registers</h4>
|
||||
|
||||
<p><a name="index-raw-register-representation-260"></a><a name="index-cooked-register-representation-261"></a><a name="index-representations_002c-raw-and-cooked-registers-262"></a>
|
||||
<span class="sc">gdb</span> considers registers to be a set with members numbered
|
||||
linearly from 0 upwards. The first part of that set corresponds to real
|
||||
physical registers, the second part to any <dfn>pseudo-registers</dfn>.
|
||||
Pseudo-registers have no independent physical existence, but are useful
|
||||
representations of information within the architecture. For example the
|
||||
OpenRISC 1000 architecture has up to 32 general purpose registers, which
|
||||
are typically represented as 32-bit (or 64-bit) integers. However the
|
||||
GPRs are also used as operands to the floating point operations, and it
|
||||
could be convenient to define a set of pseudo-registers, to show the
|
||||
GPRs represented as floating point values.
|
||||
|
||||
<p>For any architecture, the implementer will decide on a mapping from
|
||||
hardware to <span class="sc">gdb</span> register numbers. The registers corresponding to real
|
||||
hardware are referred to as <dfn>raw</dfn> registers, the remaining registers are
|
||||
<dfn>pseudo-registers</dfn>. The total register set (raw and pseudo) is called
|
||||
the <dfn>cooked</dfn> register set.
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,142 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>Register Architecture Functions & Variables - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="up" href="Register-Representation.html#Register-Representation" title="Register Representation">
|
||||
<link rel="prev" href="Raw-and-Cooked-Registers.html#Raw-and-Cooked-Registers" title="Raw and Cooked Registers">
|
||||
<link rel="next" href="Register-Information-Functions.html#Register-Information-Functions" title="Register Information Functions">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Register-Architecture-Functions-%26-Variables"></a>
|
||||
<a name="Register-Architecture-Functions-_0026-Variables"></a>
|
||||
Next: <a rel="next" accesskey="n" href="Register-Information-Functions.html#Register-Information-Functions">Register Information Functions</a>,
|
||||
Previous: <a rel="previous" accesskey="p" href="Raw-and-Cooked-Registers.html#Raw-and-Cooked-Registers">Raw and Cooked Registers</a>,
|
||||
Up: <a rel="up" accesskey="u" href="Register-Representation.html#Register-Representation">Register Representation</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h4 class="subsection">11.6.2 Functions and Variables Specifying the Register Architecture</h4>
|
||||
|
||||
<p><a name="index-g_t_0040code_007bgdbarch_007d-register-architecture-functions-263"></a>
|
||||
These <code>struct gdbarch</code> functions and variables specify the number
|
||||
and type of registers in the architecture.
|
||||
|
||||
<div class="defun">
|
||||
— Architecture Function: CORE_ADDR <b>read_pc</b> (<var>struct regcache *regcache</var>)<var><a name="index-read_005fpc-264"></a></var><br>
|
||||
</div>
|
||||
|
||||
<div class="defun">
|
||||
— Architecture Function: void <b>write_pc</b> (<var>struct regcache *regcache, CORE_ADDR val</var>)<var><a name="index-write_005fpc-265"></a></var><br>
|
||||
<blockquote>
|
||||
<p>Read or write the program counter. The default value of both
|
||||
functions is <code>NULL</code> (no function available). If the program
|
||||
counter is just an ordinary register, it can be specified in
|
||||
<code>struct gdbarch</code> instead (see <code>pc_regnum</code> below) and it will
|
||||
be read or written using the standard routines to access registers. This
|
||||
function need only be specified if the program counter is not an
|
||||
ordinary register.
|
||||
|
||||
<p>Any register information can be obtained using the supplied register
|
||||
cache, <var>regcache</var>. See <a href="Register-Caching.html#Register-Caching">Register Caching</a>.
|
||||
|
||||
</blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Architecture Function: void <b>pseudo_register_read</b> (<var>struct gdbarch *gdbarch, struct regcache *regcache, int regnum, const gdb_byte *buf</var>)<var><a name="index-pseudo_005fregister_005fread-266"></a></var><br>
|
||||
</div>
|
||||
|
||||
<div class="defun">
|
||||
— Architecture Function: void <b>pseudo_register_write</b> (<var>struct gdbarch *gdbarch, struct regcache *regcache, int regnum, const gdb_byte *buf</var>)<var><a name="index-pseudo_005fregister_005fwrite-267"></a></var><br>
|
||||
<blockquote>
|
||||
<p>These functions should be defined if there are any pseudo-registers.
|
||||
The default value is <code>NULL</code>. <var>regnum</var> is the number of the
|
||||
register to read or write (which will be a <dfn>cooked</dfn> register
|
||||
number) and <var>buf</var> is the buffer where the value read will be
|
||||
placed, or from which the value to be written will be taken. The
|
||||
value in the buffer may be converted to or from a signed or unsigned
|
||||
integral value using one of the utility functions (see <a href="Register-and-Memory-Data.html#Register-and-Memory-Data">Using Different Register and Memory Data Representations</a>).
|
||||
|
||||
<p>The access should be for the specified architecture,
|
||||
<var>gdbarch</var>. Any register information can be obtained using the
|
||||
supplied register cache, <var>regcache</var>. See <a href="Register-Caching.html#Register-Caching">Register Caching</a>.
|
||||
|
||||
</blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Architecture Variable: int <b>sp_regnum</b><var><a name="index-sp_005fregnum-268"></a></var><br>
|
||||
<blockquote><p><a name="index-sp_005fregnum-269"></a><a name="index-stack-pointer-270"></a><a name="index-g_t_0040kbd_007b_0024sp_007d-271"></a>
|
||||
This specifies the register holding the stack pointer, which may be a
|
||||
raw or pseudo-register. It defaults to -1 (not defined), but it is an
|
||||
error for it not to be defined.
|
||||
|
||||
<p>The value of the stack pointer register can be accessed withing
|
||||
<span class="sc">gdb</span> as the variable <kbd>$sp</kbd>.
|
||||
|
||||
</blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Architecture Variable: int <b>pc_regnum</b><var><a name="index-pc_005fregnum-272"></a></var><br>
|
||||
<blockquote><p><a name="index-pc_005fregnum-273"></a><a name="index-program-counter-274"></a><a name="index-g_t_0040kbd_007b_0024pc_007d-275"></a>
|
||||
This specifies the register holding the program counter, which may be a
|
||||
raw or pseudo-register. It defaults to -1 (not defined). If
|
||||
<code>pc_regnum</code> is not defined, then the functions <code>read_pc</code> and
|
||||
<code>write_pc</code> (see above) must be defined.
|
||||
|
||||
<p>The value of the program counter (whether defined as a register, or
|
||||
through <code>read_pc</code> and <code>write_pc</code>) can be accessed withing
|
||||
<span class="sc">gdb</span> as the variable <kbd>$pc</kbd>.
|
||||
|
||||
</blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Architecture Variable: int <b>ps_regnum</b><var><a name="index-ps_005fregnum-276"></a></var><br>
|
||||
<blockquote><p><a name="index-ps_005fregnum-277"></a><a name="index-processor-status-register-278"></a><a name="index-status-register-279"></a><a name="index-g_t_0040kbd_007b_0024ps_007d-280"></a>
|
||||
This specifies the register holding the processor status (often called
|
||||
the status register), which may be a raw or pseudo-register. It
|
||||
defaults to -1 (not defined).
|
||||
|
||||
<p>If defined, the value of this register can be accessed withing
|
||||
<span class="sc">gdb</span> as the variable <kbd>$ps</kbd>.
|
||||
|
||||
</blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Architecture Variable: int <b>fp0_regnum</b><var><a name="index-fp0_005fregnum-281"></a></var><br>
|
||||
<blockquote><p><a name="index-fp0_005fregnum-282"></a><a name="index-first-floating-point-register-283"></a>
|
||||
This specifies the first floating point register. It defaults to
|
||||
0. <code>fp0_regnum</code> is not needed unless the target offers support
|
||||
for floating point.
|
||||
|
||||
</blockquote></div>
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,76 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>Register Caching - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="up" href="Register-Representation.html#Register-Representation" title="Register Representation">
|
||||
<link rel="prev" href="Register-and-Memory-Data.html#Register-and-Memory-Data" title="Register and Memory Data">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Register-Caching"></a>
|
||||
Previous: <a rel="previous" accesskey="p" href="Register-and-Memory-Data.html#Register-and-Memory-Data">Register and Memory Data</a>,
|
||||
Up: <a rel="up" accesskey="u" href="Register-Representation.html#Register-Representation">Register Representation</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h4 class="subsection">11.6.5 Register Caching</h4>
|
||||
|
||||
<p><a name="index-register-caching-301"></a>
|
||||
Caching of registers is used, so that the target does not need to be
|
||||
accessed and reanalyzed multiple times for each register in
|
||||
circumstances where the register value cannot have changed.
|
||||
|
||||
<p><a name="index-g_t_0040code_007bstruct-regcache_007d-302"></a><span class="sc">gdb</span> provides <code>struct regcache</code>, associated with a
|
||||
particular <code>struct gdbarch</code> to hold the cached values of the raw
|
||||
registers. A set of functions is provided to access both the raw
|
||||
registers (with <code>raw</code> in their name) and the full set of cooked
|
||||
registers (with <code>cooked</code> in their name). Functions are provided
|
||||
to ensure the register cache is kept synchronized with the values of
|
||||
the actual registers in the target.
|
||||
|
||||
<p>Accessing registers through the <code>struct regcache</code> routines will
|
||||
ensure that the appropriate <code>struct gdbarch</code> functions are called
|
||||
when necessary to access the underlying target architecture. In general
|
||||
users should use the <dfn>cooked</dfn> functions, since these will map to the
|
||||
<dfn>raw</dfn> functions automatically as appropriate.
|
||||
|
||||
<p><a name="index-regcache_005fcooked_005fread-303"></a><a name="index-regcache_005fcooked_005fwrite-304"></a><a name="index-g_t_0040code_007bgdb_005fbyte_007d-305"></a><a name="index-regcache_005fcooked_005fread_005fsigned-306"></a><a name="index-regcache_005fcooked_005fread_005funsigned-307"></a><a name="index-regcache_005fcooked_005fwrite_005fsigned-308"></a><a name="index-regcache_005fcooked_005fwrite_005funsigned-309"></a>The two key functions are <code>regcache_cooked_read</code> and
|
||||
<code>regcache_cooked_write</code> which read or write a register from or to
|
||||
a byte buffer (type <code>gdb_byte *</code>). For convenience the wrapper
|
||||
functions <code>regcache_cooked_read_signed</code>,
|
||||
<code>regcache_cooked_read_unsigned</code>,
|
||||
<code>regcache_cooked_write_signed</code> and
|
||||
<code>regcache_cooked_write_unsigned</code> are provided, which read or
|
||||
write the value using the buffer and convert to or from an integral
|
||||
value as appropriate.
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,190 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>Register Information Functions - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="up" href="Register-Representation.html#Register-Representation" title="Register Representation">
|
||||
<link rel="prev" href="Register-Architecture-Functions-_0026-Variables.html#Register-Architecture-Functions-_0026-Variables" title="Register Architecture Functions & Variables">
|
||||
<link rel="next" href="Register-and-Memory-Data.html#Register-and-Memory-Data" title="Register and Memory Data">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Register-Information-Functions"></a>
|
||||
Next: <a rel="next" accesskey="n" href="Register-and-Memory-Data.html#Register-and-Memory-Data">Register and Memory Data</a>,
|
||||
Previous: <a rel="previous" accesskey="p" href="Register-Architecture-Functions-_0026-Variables.html#Register-Architecture-Functions-_0026-Variables">Register Architecture Functions & Variables</a>,
|
||||
Up: <a rel="up" accesskey="u" href="Register-Representation.html#Register-Representation">Register Representation</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h4 class="subsection">11.6.3 Functions Giving Register Information</h4>
|
||||
|
||||
<p><a name="index-g_t_0040code_007bgdbarch_007d-register-information-functions-284"></a>
|
||||
These functions return information about registers.
|
||||
|
||||
<div class="defun">
|
||||
— Architecture Function: const char * <b>register_name</b> (<var>struct gdbarch *gdbarch, int regnum</var>)<var><a name="index-register_005fname-285"></a></var><br>
|
||||
<blockquote>
|
||||
<p>This function should convert a register number (raw or pseudo) to a
|
||||
register name (as a C <code>const char *</code>). This is used both to
|
||||
determine the name of a register for output and to work out the meaning
|
||||
of any register names used as input. The function may also return
|
||||
<code>NULL</code>, to indicate that <var>regnum</var> is not a valid register.
|
||||
|
||||
<p>For example with the OpenRISC 1000, <span class="sc">gdb</span> registers 0-31 are the
|
||||
General Purpose Registers, register 32 is the program counter and
|
||||
register 33 is the supervision register (i.e. the processor status
|
||||
register), which map to the strings <code>"gpr00"</code> through
|
||||
<code>"gpr31"</code>, <code>"pc"</code> and <code>"sr"</code> respectively. This means
|
||||
that the <span class="sc">gdb</span> command <kbd>print $gpr5</kbd> should print the value of
|
||||
the OR1K general purpose register 5<a rel="footnote" href="#fn-1" name="fnd-1"><sup>1</sup></a>.
|
||||
|
||||
<p>The default value for this function is <code>NULL</code>, meaning
|
||||
undefined. It should always be defined.
|
||||
|
||||
<p>The access should be for the specified architecture, <var>gdbarch</var>.
|
||||
|
||||
</blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Architecture Function: struct type * <b>register_type</b> (<var>struct gdbarch *gdbarch, int regnum</var>)<var><a name="index-register_005ftype-286"></a></var><br>
|
||||
<blockquote>
|
||||
<p>Given a register number, this function identifies the type of data it
|
||||
may be holding, specified as a <code>struct type</code>. <span class="sc">gdb</span> allows
|
||||
creation of arbitrary types, but a number of built in types are
|
||||
provided (<code>builtin_type_void</code>, <code>builtin_type_int32</code> etc),
|
||||
together with functions to derive types from these.
|
||||
|
||||
<p>Typically the program counter will have a type of “pointer to
|
||||
function” (it points to code), the frame pointer and stack pointer
|
||||
will have types of “pointer to void” (they point to data on the stack)
|
||||
and all other integer registers will have a type of 32-bit integer or
|
||||
64-bit integer.
|
||||
|
||||
<p>This information guides the formatting when displaying register
|
||||
information. The default value is <code>NULL</code> meaning no information is
|
||||
available to guide formatting when displaying registers.
|
||||
|
||||
</blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Architecture Function: void <b>print_registers_info</b> (<var>struct gdbarch *gdbarch, struct ui_file *file, struct frame_info *frame, int regnum, int all</var>)<var><a name="index-print_005fregisters_005finfo-287"></a></var><br>
|
||||
<blockquote>
|
||||
<p>Define this function to print out one or all of the registers for the
|
||||
<span class="sc">gdb</span> <kbd>info registers</kbd> command. The default value is the
|
||||
function <code>default_print_registers_info</code>, which uses the register
|
||||
type information (see <code>register_type</code> above) to determine how each
|
||||
register should be printed. Define a custom version of this function
|
||||
for fuller control over how the registers are displayed.
|
||||
|
||||
<p>The access should be for the specified architecture, <var>gdbarch</var>,
|
||||
with output to the file specified by the User Interface
|
||||
Independent Output file handle, <var>file</var> (see <a href="UI_002dIndependent-Output.html#UI_002dIndependent-Output">UI-Independent Output—the <code>ui_out</code> Functions</a>).
|
||||
|
||||
<p>The registers should show their values in the frame specified by
|
||||
<var>frame</var>. If <var>regnum</var> is -1 and <var>all</var> is zero, then all
|
||||
the “significant” registers should be shown (the implementer should
|
||||
decide which registers are “significant”). Otherwise only the value of
|
||||
the register specified by <var>regnum</var> should be output. If
|
||||
<var>regnum</var> is -1 and <var>all</var> is non-zero (true), then the value of
|
||||
all registers should be shown.
|
||||
|
||||
<p>By default <code>default_print_registers_info</code> prints one register per
|
||||
line, and if <var>all</var> is zero omits floating-point registers.
|
||||
|
||||
</blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Architecture Function: void <b>print_float_info</b> (<var>struct gdbarch *gdbarch, struct ui_file *file, struct frame_info *frame, const char *args</var>)<var><a name="index-print_005ffloat_005finfo-288"></a></var><br>
|
||||
<blockquote>
|
||||
<p>Define this function to provide output about the floating point unit and
|
||||
registers for the <span class="sc">gdb</span> <kbd>info float</kbd> command respectively.
|
||||
The default value is <code>NULL</code> (not defined), meaning no information
|
||||
will be provided.
|
||||
|
||||
<p>The <var>gdbarch</var> and <var>file</var> and <var>frame</var> arguments have the same
|
||||
meaning as in the <code>print_registers_info</code> function above. The string
|
||||
<var>args</var> contains any supplementary arguments to the <kbd>info float</kbd>
|
||||
command.
|
||||
|
||||
<p>Define this function if the target supports floating point operations.
|
||||
|
||||
</blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Architecture Function: void <b>print_vector_info</b> (<var>struct gdbarch *gdbarch, struct ui_file *file, struct frame_info *frame, const char *args</var>)<var><a name="index-print_005fvector_005finfo-289"></a></var><br>
|
||||
<blockquote>
|
||||
<p>Define this function to provide output about the vector unit and
|
||||
registers for the <span class="sc">gdb</span> <kbd>info vector</kbd> command respectively.
|
||||
The default value is <code>NULL</code> (not defined), meaning no information
|
||||
will be provided.
|
||||
|
||||
<p>The <var>gdbarch</var>, <var>file</var> and <var>frame</var> arguments have the
|
||||
same meaning as in the <code>print_registers_info</code> function above. The
|
||||
string <var>args</var> contains any supplementary arguments to the <kbd>info
|
||||
vector</kbd> command.
|
||||
|
||||
<p>Define this function if the target supports vector operations.
|
||||
|
||||
</blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Architecture Function: int <b>register_reggroup_p</b> (<var>struct gdbarch *gdbarch, int regnum, struct reggroup *group</var>)<var><a name="index-register_005freggroup_005fp-290"></a></var><br>
|
||||
<blockquote>
|
||||
<p><span class="sc">gdb</span> groups registers into different categories (general,
|
||||
vector, floating point etc). This function, given a register,
|
||||
<var>regnum</var>, and group, <var>group</var>, returns 1 (true) if the register
|
||||
is in the group and 0 (false) otherwise.
|
||||
|
||||
<p>The information should be for the specified architecture,
|
||||
<var>gdbarch</var>
|
||||
|
||||
<p>The default value is the function <code>default_register_reggroup_p</code>
|
||||
which will do a reasonable job based on the type of the register (see
|
||||
the function <code>register_type</code> above), with groups for general
|
||||
purpose registers, floating point registers, vector registers and raw
|
||||
(i.e not pseudo) registers.
|
||||
|
||||
</blockquote></div>
|
||||
|
||||
<div class="footnote">
|
||||
<hr>
|
||||
<h4>Footnotes</h4><p class="footnote"><small>[<a name="fn-1" href="#fnd-1">1</a>]</small>
|
||||
<a name="index-frame-pointer-291"></a><a name="index-g_t_0040kbd_007b_0024fp_007d-292"></a>Historically, <span class="sc">gdb</span> always had a concept of a frame pointer
|
||||
register, which could be accessed via the <span class="sc">gdb</span> variable,
|
||||
<kbd>$fp</kbd>. That concept is now deprecated, recognizing that not all
|
||||
architectures have a frame pointer. However if an architecture does
|
||||
have a frame pointer register, and defines a register or
|
||||
pseudo-register with the name <code>"fp"</code>, then that register will be
|
||||
used as the value of the <kbd>$fp</kbd> variable.</p>
|
||||
|
||||
<hr></div>
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,57 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>Register Representation - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="up" href="Target-Architecture-Definition.html#Target-Architecture-Definition" title="Target Architecture Definition">
|
||||
<link rel="prev" href="Address-Classes.html#Address-Classes" title="Address Classes">
|
||||
<link rel="next" href="Frame-Interpretation.html#Frame-Interpretation" title="Frame Interpretation">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Register-Representation"></a>
|
||||
Next: <a rel="next" accesskey="n" href="Frame-Interpretation.html#Frame-Interpretation">Frame Interpretation</a>,
|
||||
Previous: <a rel="previous" accesskey="p" href="Address-Classes.html#Address-Classes">Address Classes</a>,
|
||||
Up: <a rel="up" accesskey="u" href="Target-Architecture-Definition.html#Target-Architecture-Definition">Target Architecture Definition</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h3 class="section">11.6 Register Representation</h3>
|
||||
|
||||
<ul class="menu">
|
||||
<li><a accesskey="1" href="Raw-and-Cooked-Registers.html#Raw-and-Cooked-Registers">Raw and Cooked Registers</a>
|
||||
<li><a accesskey="2" href="Register-Architecture-Functions-_0026-Variables.html#Register-Architecture-Functions-_0026-Variables">Register Architecture Functions & Variables</a>
|
||||
<li><a accesskey="3" href="Register-Information-Functions.html#Register-Information-Functions">Register Information Functions</a>
|
||||
<li><a accesskey="4" href="Register-and-Memory-Data.html#Register-and-Memory-Data">Register and Memory Data</a>
|
||||
<li><a accesskey="5" href="Register-Caching.html#Register-Caching">Register Caching</a>
|
||||
</ul>
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,130 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>Register and Memory Data - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="up" href="Register-Representation.html#Register-Representation" title="Register Representation">
|
||||
<link rel="prev" href="Register-Information-Functions.html#Register-Information-Functions" title="Register Information Functions">
|
||||
<link rel="next" href="Register-Caching.html#Register-Caching" title="Register Caching">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Register-and-Memory-Data"></a>
|
||||
Next: <a rel="next" accesskey="n" href="Register-Caching.html#Register-Caching">Register Caching</a>,
|
||||
Previous: <a rel="previous" accesskey="p" href="Register-Information-Functions.html#Register-Information-Functions">Register Information Functions</a>,
|
||||
Up: <a rel="up" accesskey="u" href="Register-Representation.html#Register-Representation">Register Representation</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h4 class="subsection">11.6.4 Using Different Register and Memory Data Representations</h4>
|
||||
|
||||
<p><a name="index-register-representation-293"></a><a name="index-memory-representation-294"></a><a name="index-representations_002c-register-and-memory-295"></a><a name="index-register-data-formats_002c-converting-296"></a><a name="index-g_t_0040code_007bstruct-value_007d_002c-converting-register-contents-to-297"></a>
|
||||
Some architectures have different representations of data objects,
|
||||
depending whether the object is held in a register or memory. For
|
||||
example:
|
||||
|
||||
<ul>
|
||||
<li>The Alpha architecture can represent 32 bit integer values in
|
||||
floating-point registers.
|
||||
|
||||
<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.
|
||||
|
||||
</ul>
|
||||
|
||||
<p>In general, the register representation of a data type is determined by
|
||||
the architecture, or <span class="sc">gdb</span>'s interface to the architecture, while
|
||||
the memory representation is determined by the Application Binary
|
||||
Interface.
|
||||
|
||||
<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. An architecture may define the
|
||||
following <code>struct gdbarch</code> functions to request conversions
|
||||
between the register and memory representations of a data type:
|
||||
|
||||
<div class="defun">
|
||||
— Architecture Function: int <b>gdbarch_convert_register_p</b> (<var>struct gdbarch *gdbarch, int reg</var>)<var><a name="index-gdbarch_005fconvert_005fregister_005fp-298"></a></var><br>
|
||||
<blockquote>
|
||||
<p>Return non-zero (true) if the representation of a data value stored in
|
||||
this register may be different to the representation of that same data
|
||||
value when stored in memory. The default value is <code>NULL</code>
|
||||
(undefined).
|
||||
|
||||
<p>If this function is defined and returns non-zero, the <code>struct
|
||||
gdbarch</code> functions <code>gdbarch_register_to_value</code> and
|
||||
<code>gdbarch_value_to_register</code> (see below) should be used to perform
|
||||
any necessary conversion.
|
||||
|
||||
<p>If defined, this function should return zero for the register's native
|
||||
type, when no conversion is necessary.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Architecture Function: void <b>gdbarch_register_to_value</b> (<var>struct gdbarch *gdbarch, int reg, struct type *type, char *from, char *to</var>)<var><a name="index-gdbarch_005fregister_005fto_005fvalue-299"></a></var><br>
|
||||
<blockquote>
|
||||
<p>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>.
|
||||
|
||||
<blockquote>
|
||||
<em>Note:</em> <code>gdbarch_register_to_value</code> and
|
||||
<code>gdbarch_value_to_register</code> take their <var>reg</var> and <var>type</var>
|
||||
arguments in different orders.
|
||||
</blockquote>
|
||||
|
||||
<p><code>gdbarch_register_to_value</code> should only be used with registers
|
||||
for which the <code>gdbarch_convert_register_p</code> function returns a
|
||||
non-zero value.
|
||||
|
||||
</blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Architecture Function: void <b>gdbarch_value_to_register</b> (<var>struct gdbarch *gdbarch, struct type *type, int reg, char *from, char *to</var>)<var><a name="index-gdbarch_005fvalue_005fto_005fregister-300"></a></var><br>
|
||||
<blockquote>
|
||||
<p>Convert a data value of type <var>type</var> to register number <var>reg</var>'
|
||||
raw format.
|
||||
|
||||
<blockquote>
|
||||
<em>Note:</em> <code>gdbarch_register_to_value</code> and
|
||||
<code>gdbarch_value_to_register</code> take their <var>reg</var> and <var>type</var>
|
||||
arguments in different orders.
|
||||
</blockquote>
|
||||
|
||||
<p><code>gdbarch_value_to_register</code> should only be used with registers
|
||||
for which the <code>gdbarch_convert_register_p</code> function returns a
|
||||
non-zero value.
|
||||
|
||||
</blockquote></div>
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,61 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>Registers and Memory - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="up" href="Target-Architecture-Definition.html#Target-Architecture-Definition" title="Target Architecture Definition">
|
||||
<link rel="prev" href="Initialize-New-Architecture.html#Initialize-New-Architecture" title="Initialize New Architecture">
|
||||
<link rel="next" href="Pointers-and-Addresses.html#Pointers-and-Addresses" title="Pointers and Addresses">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Registers-and-Memory"></a>
|
||||
Next: <a rel="next" accesskey="n" href="Pointers-and-Addresses.html#Pointers-and-Addresses">Pointers and Addresses</a>,
|
||||
Previous: <a rel="previous" accesskey="p" href="Initialize-New-Architecture.html#Initialize-New-Architecture">Initialize New Architecture</a>,
|
||||
Up: <a rel="up" accesskey="u" href="Target-Architecture-Definition.html#Target-Architecture-Definition">Target Architecture Definition</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h3 class="section">11.3 Registers and Memory</h3>
|
||||
|
||||
<p><span class="sc">gdb</span>'s model of the target machine is rather simple.
|
||||
<span class="sc">gdb</span> assumes the machine includes a bank of registers and a
|
||||
block of memory. Each register may have a different size.
|
||||
|
||||
<p><span class="sc">gdb</span> 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>gdbarch_register_name</code> and related functions.
|
||||
|
||||
<p><span class="sc">gdb</span> can handle big-endian, little-endian, and bi-endian architectures.
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,637 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>Releasing GDB - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="prev" href="Start-of-New-Year-Procedure.html#Start-of-New-Year-Procedure" title="Start of New Year Procedure">
|
||||
<link rel="next" href="Testsuite.html#Testsuite" title="Testsuite">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Releasing-GDB"></a>
|
||||
Next: <a rel="next" accesskey="n" href="Testsuite.html#Testsuite">Testsuite</a>,
|
||||
Previous: <a rel="previous" accesskey="p" href="Start-of-New-Year-Procedure.html#Start-of-New-Year-Procedure">Start of New Year Procedure</a>,
|
||||
Up: <a rel="up" accesskey="u" href="index.html#Top">Top</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h2 class="chapter">21 Releasing <span class="sc">gdb</span></h2>
|
||||
|
||||
<p><a name="index-making-a-new-release-of-gdb-491"></a>
|
||||
|
||||
<h3 class="section">21.1 Branch Commit Policy</h3>
|
||||
|
||||
<p>The branch commit policy is pretty slack. <span class="sc">gdb</span> releases 5.0,
|
||||
5.1 and 5.2 all used the below:
|
||||
|
||||
<ul>
|
||||
<li>The <samp><span class="file">gdb/MAINTAINERS</span></samp> file still holds.
|
||||
<li>Don't fix something on the branch unless/until it is also fixed in the
|
||||
trunk. If this isn't possible, mentioning it in the <samp><span class="file">gdb/PROBLEMS</span></samp>
|
||||
file is better than committing a hack.
|
||||
<li>When considering a patch for the branch, suggested criteria include:
|
||||
Does it fix a build? Does it fix the sequence <kbd>break main; run</kbd>
|
||||
when debugging a static binary?
|
||||
<li>The further a change is from the core of <span class="sc">gdb</span>, the less likely
|
||||
the change will worry anyone (e.g., target specific code).
|
||||
<li>Only post a proposal to change the core of <span class="sc">gdb</span> after you've
|
||||
sent individual bribes to all the people listed in the
|
||||
<samp><span class="file">MAINTAINERS</span></samp> file <tt>;-)</tt>
|
||||
</ul>
|
||||
|
||||
<p><em>Pragmatics: Provided updates are restricted to non-core
|
||||
functionality there is little chance that a broken change will be fatal.
|
||||
This means that changes such as adding a new architectures or (within
|
||||
reason) support for a new host are considered acceptable.</em>
|
||||
|
||||
<h3 class="section">21.2 Obsoleting code</h3>
|
||||
|
||||
<p>Before anything else, poke the other developers (and around the source
|
||||
code) to see if there is anything that can be removed from <span class="sc">gdb</span>
|
||||
(an old target, an unused file).
|
||||
|
||||
<p>Obsolete code is identified by adding an <code>OBSOLETE</code> prefix to every
|
||||
line. Doing this means that it is easy to identify something that has
|
||||
been obsoleted when greping through the sources.
|
||||
|
||||
<p>The process is done in stages — this is mainly to ensure that the
|
||||
wider <span class="sc">gdb</span> community has a reasonable opportunity to respond.
|
||||
Remember, everything on the Internet takes a week.
|
||||
|
||||
<ol type=1 start=1>
|
||||
<li>Post the proposal on <a href="mailto:gdb@sourceware.org">the GDB mailing list</a> Creating a bug report to track the task's state, is also highly
|
||||
recommended.
|
||||
<li>Wait a week or so.
|
||||
<li>Post the proposal on <a href="mailto:gdb-announce@sourceware.org">the GDB Announcement mailing list</a>.
|
||||
<li>Wait a week or so.
|
||||
<li>Go through and edit all relevant files and lines so that they are
|
||||
prefixed with the word <code>OBSOLETE</code>.
|
||||
<li>Wait until the next GDB version, containing this obsolete code, has been
|
||||
released.
|
||||
<li>Remove the obsolete code.
|
||||
</ol>
|
||||
|
||||
<p class="noindent"><em>Maintainer note: While removing old code is regrettable it is
|
||||
hopefully better for </em><span class="sc">gdb</span><em>'s long term development. Firstly it
|
||||
helps the developers by removing code that is either no longer relevant
|
||||
or simply wrong. Secondly since it removes any history associated with
|
||||
the file (effectively clearing the slate) the developer has a much freer
|
||||
hand when it comes to fixing broken files.</em>
|
||||
|
||||
<h3 class="section">21.3 Before the Branch</h3>
|
||||
|
||||
<p>The most important objective at this stage is to find and fix simple
|
||||
changes that become a pain to track once the branch is created. For
|
||||
instance, configuration problems that stop <span class="sc">gdb</span> from even
|
||||
building. If you can't get the problem fixed, document it in the
|
||||
<samp><span class="file">gdb/PROBLEMS</span></samp> file.
|
||||
|
||||
<h4 class="subheading">Prompt for <samp><span class="file">gdb/NEWS</span></samp></h4>
|
||||
|
||||
<p>People always forget. Send a post reminding them but also if you know
|
||||
something interesting happened add it yourself. The <code>schedule</code>
|
||||
script will mention this in its e-mail.
|
||||
|
||||
<h4 class="subheading">Review <samp><span class="file">gdb/README</span></samp></h4>
|
||||
|
||||
<p>Grab one of the nightly snapshots and then walk through the
|
||||
<samp><span class="file">gdb/README</span></samp> looking for anything that can be improved. The
|
||||
<code>schedule</code> script will mention this in its e-mail.
|
||||
|
||||
<h4 class="subheading">Refresh any imported files.</h4>
|
||||
|
||||
<p>A number of files are taken from external repositories. They include:
|
||||
|
||||
<ul>
|
||||
<li><samp><span class="file">texinfo/texinfo.tex</span></samp>
|
||||
<li><samp><span class="file">config.guess</span></samp> et. al. (see the top-level <samp><span class="file">MAINTAINERS</span></samp>
|
||||
file)
|
||||
<li><samp><span class="file">etc/standards.texi</span></samp>, <samp><span class="file">etc/make-stds.texi</span></samp>
|
||||
</ul>
|
||||
|
||||
<h4 class="subheading">Check the ARI</h4>
|
||||
|
||||
<p><a href="http://sourceware.org/gdb/ari">A.R.I.</a> is an <code>awk</code> script
|
||||
(Awk Regression Index ;-) that checks for a number of errors and coding
|
||||
conventions. The checks include things like using <code>malloc</code> instead
|
||||
of <code>xmalloc</code> and file naming problems. There shouldn't be any
|
||||
regressions.
|
||||
|
||||
<h4 class="subsection">21.3.1 Review the bug data base</h4>
|
||||
|
||||
<p>Close anything obviously fixed.
|
||||
|
||||
<h4 class="subsection">21.3.2 Check all cross targets build</h4>
|
||||
|
||||
<p>The targets are listed in <samp><span class="file">gdb/MAINTAINERS</span></samp>.
|
||||
|
||||
<h3 class="section">21.4 Cut the Branch</h3>
|
||||
|
||||
<h4 class="subheading">Create the branch</h4>
|
||||
|
||||
<pre class="smallexample"> $ u=5.1
|
||||
$ v=5.2
|
||||
$ V=`echo $v | sed 's/\./_/g'`
|
||||
$ D=`date -u +%Y-%m-%d`
|
||||
$ echo $u $V $D
|
||||
5.1 5_2 2002-03-03
|
||||
$ echo cvs -f -d :ext:sourceware.org:/cvs/src rtag \
|
||||
-D $D-gmt gdb_$V-$D-branchpoint insight
|
||||
cvs -f -d :ext:sourceware.org:/cvs/src rtag
|
||||
-D 2002-03-03-gmt gdb_5_2-2002-03-03-branchpoint insight
|
||||
$ ^echo ^^
|
||||
...
|
||||
$ echo cvs -f -d :ext:sourceware.org:/cvs/src rtag \
|
||||
-b -r gdb_$V-$D-branchpoint gdb_$V-branch insight
|
||||
cvs -f -d :ext:sourceware.org:/cvs/src rtag \
|
||||
-b -r gdb_5_2-2002-03-03-branchpoint gdb_5_2-branch insight
|
||||
$ ^echo ^^
|
||||
...
|
||||
$
|
||||
</pre>
|
||||
<ul>
|
||||
<li>By using <kbd>-D YYYY-MM-DD-gmt</kbd>, the branch is forced to an exact
|
||||
date/time.
|
||||
<li>The trunk is first tagged so that the branch point can easily be found.
|
||||
<li>Insight, which includes <span class="sc">gdb</span>, is tagged at the same time.
|
||||
<li><samp><span class="file">version.in</span></samp> gets bumped to avoid version number conflicts.
|
||||
<li>The reading of <samp><span class="file">.cvsrc</span></samp> is disabled using <samp><span class="file">-f</span></samp>.
|
||||
</ul>
|
||||
|
||||
<h4 class="subheading">Update <samp><span class="file">version.in</span></samp></h4>
|
||||
|
||||
<pre class="smallexample"> $ u=5.1
|
||||
$ v=5.2
|
||||
$ V=`echo $v | sed 's/\./_/g'`
|
||||
$ echo $u $v$V
|
||||
5.1 5_2
|
||||
$ cd /tmp
|
||||
$ echo cvs -f -d :ext:sourceware.org:/cvs/src co \
|
||||
-r gdb_$V-branch src/gdb/version.in
|
||||
cvs -f -d :ext:sourceware.org:/cvs/src co
|
||||
-r gdb_5_2-branch src/gdb/version.in
|
||||
$ ^echo ^^
|
||||
U src/gdb/version.in
|
||||
$ cd src/gdb
|
||||
$ echo $u.90-0000-00-00-cvs > version.in
|
||||
$ cat version.in
|
||||
5.1.90-0000-00-00-cvs
|
||||
$ cvs -f commit version.in
|
||||
</pre>
|
||||
<ul>
|
||||
<li><samp><span class="file">0000-00-00</span></samp> is used as a date to pump prime the version.in update
|
||||
mechanism.
|
||||
<li><samp><span class="file">.90</span></samp> and the previous branch version are used as fairly arbitrary
|
||||
initial branch version number.
|
||||
</ul>
|
||||
|
||||
<h4 class="subheading">Update the web and news pages</h4>
|
||||
|
||||
<p>Something?
|
||||
|
||||
<h4 class="subheading">Tweak cron to track the new branch</h4>
|
||||
|
||||
<p>The file <samp><span class="file">gdbadmin/cron/crontab</span></samp> contains gdbadmin's cron table.
|
||||
This file needs to be updated so that:
|
||||
|
||||
<ul>
|
||||
<li>A daily timestamp is added to the file <samp><span class="file">version.in</span></samp>.
|
||||
<li>The new branch is included in the snapshot process.
|
||||
</ul>
|
||||
|
||||
<p class="noindent">See the file <samp><span class="file">gdbadmin/cron/README</span></samp> for how to install the updated
|
||||
cron table.
|
||||
|
||||
<p>The file <samp><span class="file">gdbadmin/ss/README</span></samp> should also be reviewed to reflect
|
||||
any changes. That file is copied to both the branch/ and current/
|
||||
snapshot directories.
|
||||
|
||||
<h4 class="subheading">Update the NEWS and README files</h4>
|
||||
|
||||
<p>The <samp><span class="file">NEWS</span></samp> file needs to be updated so that on the branch it refers
|
||||
to <em>changes in the current release</em> while on the trunk it also
|
||||
refers to <em>changes since the current release</em>.
|
||||
|
||||
<p>The <samp><span class="file">README</span></samp> file needs to be updated so that it refers to the
|
||||
current release.
|
||||
|
||||
<h4 class="subheading">Post the branch info</h4>
|
||||
|
||||
<p>Send an announcement to the mailing lists:
|
||||
|
||||
<ul>
|
||||
<li><a href="mailto:gdb-announce@sourceware.org">GDB Announcement mailing list</a>
|
||||
<li><a href="mailto:gdb@sourceware.org">GDB Discussion mailing list</a> and
|
||||
<a href="mailto:gdb-testers@sourceware.org">GDB Testers mailing list</a>
|
||||
</ul>
|
||||
|
||||
<p><em>Pragmatics: The branch creation is sent to the announce list to
|
||||
ensure that people people not subscribed to the higher volume discussion
|
||||
list are alerted.</em>
|
||||
|
||||
<p>The announcement should include:
|
||||
|
||||
<ul>
|
||||
<li>The branch tag.
|
||||
<li>How to check out the branch using CVS.
|
||||
<li>The date/number of weeks until the release.
|
||||
<li>The branch commit policy still holds.
|
||||
</ul>
|
||||
|
||||
<h3 class="section">21.5 Stabilize the branch</h3>
|
||||
|
||||
<p>Something goes here.
|
||||
|
||||
<h3 class="section">21.6 Create a Release</h3>
|
||||
|
||||
<p>The process of creating and then making available a release is broken
|
||||
down into a number of stages. The first part addresses the technical
|
||||
process of creating a releasable tar ball. The later stages address the
|
||||
process of releasing that tar ball.
|
||||
|
||||
<p>When making a release candidate just the first section is needed.
|
||||
|
||||
<h4 class="subsection">21.6.1 Create a release candidate</h4>
|
||||
|
||||
<p>The objective at this stage is to create a set of tar balls that can be
|
||||
made available as a formal release (or as a less formal release
|
||||
candidate).
|
||||
|
||||
<h5 class="subsubheading">Freeze the branch</h5>
|
||||
|
||||
<p>Send out an e-mail notifying everyone that the branch is frozen to
|
||||
<a href="mailto:gdb-patches@sourceware.org">gdb-patches@sourceware.org</a>.
|
||||
|
||||
<h5 class="subsubheading">Establish a few defaults.</h5>
|
||||
|
||||
<pre class="smallexample"> $ b=gdb_5_2-branch
|
||||
$ v=5.2
|
||||
$ t=/sourceware/snapshot-tmp/gdbadmin-tmp
|
||||
$ echo $t/$b/$v
|
||||
/sourceware/snapshot-tmp/gdbadmin-tmp/gdb_5_2-branch/5.2
|
||||
$ mkdir -p $t/$b/$v
|
||||
$ cd $t/$b/$v
|
||||
$ pwd
|
||||
/sourceware/snapshot-tmp/gdbadmin-tmp/gdb_5_2-branch/5.2
|
||||
$ which autoconf
|
||||
/home/gdbadmin/bin/autoconf
|
||||
$
|
||||
</pre>
|
||||
<p class="noindent">Notes:
|
||||
|
||||
<ul>
|
||||
<li>Check the <code>autoconf</code> version carefully. You want to be using the
|
||||
version documented in the toplevel <samp><span class="file">README-maintainer-mode</span></samp> file.
|
||||
It is very unlikely that the version of <code>autoconf</code> installed in
|
||||
system directories (e.g., <samp><span class="file">/usr/bin/autoconf</span></samp>) is correct.
|
||||
</ul>
|
||||
|
||||
<h5 class="subsubheading">Check out the relevant modules:</h5>
|
||||
|
||||
<pre class="smallexample"> $ for m in gdb insight
|
||||
do
|
||||
( mkdir -p $m && cd $m && cvs -q -f -d /cvs/src co -P -r $b $m )
|
||||
done
|
||||
$
|
||||
</pre>
|
||||
<p class="noindent">Note:
|
||||
|
||||
<ul>
|
||||
<li>The reading of <samp><span class="file">.cvsrc</span></samp> is disabled (<samp><span class="file">-f</span></samp>) so that there isn't
|
||||
any confusion between what is written here and what your local
|
||||
<code>cvs</code> really does.
|
||||
</ul>
|
||||
|
||||
<h5 class="subsubheading">Update relevant files.</h5>
|
||||
|
||||
<dl>
|
||||
<dt><samp><span class="file">gdb/NEWS</span></samp><dd>
|
||||
Major releases get their comments added as part of the mainline. Minor
|
||||
releases should probably mention any significant bugs that were fixed.
|
||||
|
||||
<p>Don't forget to include the <samp><span class="file">ChangeLog</span></samp> entry.
|
||||
|
||||
<pre class="smallexample"> $ emacs gdb/src/gdb/NEWS
|
||||
...
|
||||
c-x 4 a
|
||||
...
|
||||
c-x c-s c-x c-c
|
||||
$ cp gdb/src/gdb/NEWS insight/src/gdb/NEWS
|
||||
$ cp gdb/src/gdb/ChangeLog insight/src/gdb/ChangeLog
|
||||
</pre>
|
||||
<br><dt><samp><span class="file">gdb/README</span></samp><dd>
|
||||
You'll need to update:
|
||||
|
||||
<ul>
|
||||
<li>The version.
|
||||
<li>The update date.
|
||||
<li>Who did it.
|
||||
</ul>
|
||||
|
||||
<pre class="smallexample"> $ emacs gdb/src/gdb/README
|
||||
...
|
||||
c-x 4 a
|
||||
...
|
||||
c-x c-s c-x c-c
|
||||
$ cp gdb/src/gdb/README insight/src/gdb/README
|
||||
$ cp gdb/src/gdb/ChangeLog insight/src/gdb/ChangeLog
|
||||
</pre>
|
||||
<p><em>Maintainer note: Hopefully the </em><samp><span class="file">README</span></samp><em> file was reviewed
|
||||
before the initial branch was cut so just a simple substitute is needed
|
||||
to get it updated.</em>
|
||||
|
||||
<p><em>Maintainer note: Other projects generate </em><samp><span class="file">README</span></samp><em> and
|
||||
</em><samp><span class="file">INSTALL</span></samp><em> from the core documentation. This might be worth
|
||||
pursuing.</em>
|
||||
|
||||
<br><dt><samp><span class="file">gdb/version.in</span></samp><dd>
|
||||
<pre class="smallexample"> $ echo $v > gdb/src/gdb/version.in
|
||||
$ cat gdb/src/gdb/version.in
|
||||
5.2
|
||||
$ emacs gdb/src/gdb/version.in
|
||||
...
|
||||
c-x 4 a
|
||||
... Bump to version ...
|
||||
c-x c-s c-x c-c
|
||||
$ cp gdb/src/gdb/version.in insight/src/gdb/version.in
|
||||
$ cp gdb/src/gdb/ChangeLog insight/src/gdb/ChangeLog
|
||||
</pre>
|
||||
</dl>
|
||||
|
||||
<h5 class="subsubheading">Do the dirty work</h5>
|
||||
|
||||
<p>This is identical to the process used to create the daily snapshot.
|
||||
|
||||
<pre class="smallexample"> $ for m in gdb insight
|
||||
do
|
||||
( cd $m/src && gmake -f src-release $m.tar )
|
||||
done
|
||||
</pre>
|
||||
<p>If the top level source directory does not have <samp><span class="file">src-release</span></samp>
|
||||
(<span class="sc">gdb</span> version 5.3.1 or earlier), try these commands instead:
|
||||
|
||||
<pre class="smallexample"> $ for m in gdb insight
|
||||
do
|
||||
( cd $m/src && gmake -f Makefile.in $m.tar )
|
||||
done
|
||||
</pre>
|
||||
<h5 class="subsubheading">Check the source files</h5>
|
||||
|
||||
<p>You're looking for files that have mysteriously disappeared.
|
||||
<kbd>distclean</kbd> has the habit of deleting files it shouldn't. Watch out
|
||||
for the <samp><span class="file">version.in</span></samp> update <kbd>cronjob</kbd>.
|
||||
|
||||
<pre class="smallexample"> $ ( cd gdb/src && cvs -f -q -n update )
|
||||
M djunpack.bat
|
||||
? gdb-5.1.91.tar
|
||||
? proto-toplev
|
||||
... lots of generated files ...
|
||||
M gdb/ChangeLog
|
||||
M gdb/NEWS
|
||||
M gdb/README
|
||||
M gdb/version.in
|
||||
... lots of generated files ...
|
||||
$
|
||||
</pre>
|
||||
<p class="noindent"><em>Don't worry about the </em><samp><span class="file">gdb.info-??</span></samp><em> or
|
||||
</em><samp><span class="file">gdb/p-exp.tab.c</span></samp><em>. They were generated (and yes </em><samp><span class="file">gdb.info-1</span></samp><em>
|
||||
was also generated only something strange with CVS means that they
|
||||
didn't get suppressed). Fixing it would be nice though.</em>
|
||||
|
||||
<h5 class="subsubheading">Create compressed versions of the release</h5>
|
||||
|
||||
<pre class="smallexample"> $ cp */src/*.tar .
|
||||
$ cp */src/*.bz2 .
|
||||
$ ls -F
|
||||
gdb/ gdb-5.2.tar insight/ insight-5.2.tar
|
||||
$ for m in gdb insight
|
||||
do
|
||||
bzip2 -v -9 -c $m-$v.tar > $m-$v.tar.bz2
|
||||
gzip -v -9 -c $m-$v.tar > $m-$v.tar.gz
|
||||
done
|
||||
$
|
||||
</pre>
|
||||
<p class="noindent">Note:
|
||||
|
||||
<ul>
|
||||
<li>A pipe such as <kbd>bunzip2 < xxx.bz2 | gzip -9 > xxx.gz</kbd> is not since,
|
||||
in that mode, <code>gzip</code> does not know the name of the file and, hence,
|
||||
can not include it in the compressed file. This is also why the release
|
||||
process runs <code>tar</code> and <code>bzip2</code> as separate passes.
|
||||
</ul>
|
||||
|
||||
<h4 class="subsection">21.6.2 Sanity check the tar ball</h4>
|
||||
|
||||
<p>Pick a popular machine (Solaris/PPC?) and try the build on that.
|
||||
|
||||
<pre class="smallexample"> $ bunzip2 < gdb-5.2.tar.bz2 | tar xpf -
|
||||
$ cd gdb-5.2
|
||||
$ ./configure
|
||||
$ make
|
||||
...
|
||||
$ ./gdb/gdb ./gdb/gdb
|
||||
GNU gdb 5.2
|
||||
...
|
||||
(gdb) b main
|
||||
Breakpoint 1 at 0x80732bc: file main.c, line 734.
|
||||
(gdb) run
|
||||
Starting program: /tmp/gdb-5.2/gdb/gdb
|
||||
|
||||
Breakpoint 1, main (argc=1, argv=0xbffff8b4) at main.c:734
|
||||
734 catch_errors (captured_main, &args, "", RETURN_MASK_ALL);
|
||||
(gdb) print args
|
||||
$1 = {argc = 136426532, argv = 0x821b7f0}
|
||||
(gdb)
|
||||
</pre>
|
||||
<h4 class="subsection">21.6.3 Make a release candidate available</h4>
|
||||
|
||||
<p>If this is a release candidate then the only remaining steps are:
|
||||
|
||||
<ol type=1 start=1>
|
||||
<li>Commit <samp><span class="file">version.in</span></samp> and <samp><span class="file">ChangeLog</span></samp>
|
||||
<li>Tweak <samp><span class="file">version.in</span></samp> (and <samp><span class="file">ChangeLog</span></samp> to read
|
||||
<var>L</var>.<var>M</var>.<var>N</var>-0000-00-00-cvs so that the version update
|
||||
process can restart.
|
||||
<li>Make the release candidate available in
|
||||
<a href="ftp://sourceware.org/pub/gdb/snapshots/branch">ftp://sourceware.org/pub/gdb/snapshots/branch</a>
|
||||
<li>Notify the relevant mailing lists ( <a href="mailto:gdb@sourceware.org">gdb@sourceware.org</a> and
|
||||
<a href="mailto:gdb-testers@sourceware.org">gdb-testers@sourceware.org</a> that the candidate is available.
|
||||
</ol>
|
||||
|
||||
<h4 class="subsection">21.6.4 Make a formal release available</h4>
|
||||
|
||||
<p>(And you thought all that was required was to post an e-mail.)
|
||||
|
||||
<h5 class="subsubheading">Install on sware</h5>
|
||||
|
||||
<p>Copy the new files to both the release and the old release directory:
|
||||
|
||||
<pre class="smallexample"> $ cp *.bz2 *.gz ~ftp/pub/gdb/old-releases/
|
||||
$ cp *.bz2 *.gz ~ftp/pub/gdb/releases
|
||||
</pre>
|
||||
<p class="noindent">Clean up the releases directory so that only the most recent releases
|
||||
are available (e.g. keep 5.2 and 5.2.1 but remove 5.1):
|
||||
|
||||
<pre class="smallexample"> $ cd ~ftp/pub/gdb/releases
|
||||
$ rm ...
|
||||
</pre>
|
||||
<p class="noindent">Update the file <samp><span class="file">README</span></samp> and <samp><span class="file">.message</span></samp> in the releases
|
||||
directory:
|
||||
|
||||
<pre class="smallexample"> $ vi README
|
||||
...
|
||||
$ rm -f .message
|
||||
$ ln README .message
|
||||
</pre>
|
||||
<h5 class="subsubheading">Update the web pages.</h5>
|
||||
|
||||
<dl>
|
||||
<dt><samp><span class="file">htdocs/download/ANNOUNCEMENT</span></samp><dd>This file, which is posted as the official announcement, includes:
|
||||
<ul>
|
||||
<li>General announcement.
|
||||
<li>News. If making an <var>M</var>.<var>N</var>.1 release, retain the news from
|
||||
earlier <var>M</var>.<var>N</var> release.
|
||||
<li>Errata.
|
||||
</ul>
|
||||
|
||||
<br><dt><samp><span class="file">htdocs/index.html</span></samp><dt><samp><span class="file">htdocs/news/index.html</span></samp><dt><samp><span class="file">htdocs/download/index.html</span></samp><dd>These files include:
|
||||
<ul>
|
||||
<li>Announcement of the most recent release.
|
||||
<li>News entry (remember to update both the top level and the news directory).
|
||||
</ul>
|
||||
These pages also need to be regenerate using <code>index.sh</code>.
|
||||
|
||||
<br><dt><samp><span class="file">download/onlinedocs/</span></samp><dd>You need to find the magic command that is used to generate the online
|
||||
docs from the <samp><span class="file">.tar.bz2</span></samp>. The best way is to look in the output
|
||||
from one of the nightly <code>cron</code> jobs and then just edit accordingly.
|
||||
Something like:
|
||||
|
||||
<pre class="smallexample"> $ ~/ss/update-web-docs \
|
||||
~ftp/pub/gdb/releases/gdb-5.2.tar.bz2 \
|
||||
$PWD/www \
|
||||
/www/sourceware/htdocs/gdb/download/onlinedocs \
|
||||
gdb
|
||||
</pre>
|
||||
<br><dt><samp><span class="file">download/ari/</span></samp><dd>Just like the online documentation. Something like:
|
||||
|
||||
<pre class="smallexample"> $ /bin/sh ~/ss/update-web-ari \
|
||||
~ftp/pub/gdb/releases/gdb-5.2.tar.bz2 \
|
||||
$PWD/www \
|
||||
/www/sourceware/htdocs/gdb/download/ari \
|
||||
gdb
|
||||
</pre>
|
||||
</dl>
|
||||
|
||||
<h5 class="subsubheading">Shadow the pages onto gnu</h5>
|
||||
|
||||
<p>Something goes here.
|
||||
|
||||
<h5 class="subsubheading">Install the <span class="sc">gdb</span> tar ball on GNU</h5>
|
||||
|
||||
<p>At the time of writing, the GNU machine was <kbd>gnudist.gnu.org</kbd> in
|
||||
<samp><span class="file">~ftp/gnu/gdb</span></samp>.
|
||||
|
||||
<h5 class="subsubheading">Make the <samp><span class="file">ANNOUNCEMENT</span></samp></h5>
|
||||
|
||||
<p>Post the <samp><span class="file">ANNOUNCEMENT</span></samp> file you created above to:
|
||||
|
||||
<ul>
|
||||
<li><a href="mailto:gdb-announce@sourceware.org">GDB Announcement mailing list</a>
|
||||
<li><a href="mailto:info-gnu@gnu.org">General GNU Announcement list</a> (but delay it a
|
||||
day or so to let things get out)
|
||||
<li><a href="mailto:bug-gdb@gnu.org">GDB Bug Report mailing list</a>
|
||||
</ul>
|
||||
|
||||
<h4 class="subsection">21.6.5 Cleanup</h4>
|
||||
|
||||
<p>The release is out but you're still not finished.
|
||||
|
||||
<h5 class="subsubheading">Commit outstanding changes</h5>
|
||||
|
||||
<p>In particular you'll need to commit any changes to:
|
||||
|
||||
<ul>
|
||||
<li><samp><span class="file">gdb/ChangeLog</span></samp>
|
||||
<li><samp><span class="file">gdb/version.in</span></samp>
|
||||
<li><samp><span class="file">gdb/NEWS</span></samp>
|
||||
<li><samp><span class="file">gdb/README</span></samp>
|
||||
</ul>
|
||||
|
||||
<h5 class="subsubheading">Tag the release</h5>
|
||||
|
||||
<p>Something like:
|
||||
|
||||
<pre class="smallexample"> $ d=`date -u +%Y-%m-%d`
|
||||
$ echo $d
|
||||
2002-01-24
|
||||
$ ( cd insight/src/gdb && cvs -f -q update )
|
||||
$ ( cd insight/src && cvs -f -q tag gdb_5_2-$d-release )
|
||||
</pre>
|
||||
<p>Insight is used since that contains more of the release than
|
||||
<span class="sc">gdb</span>.
|
||||
|
||||
<h5 class="subsubheading">Mention the release on the trunk</h5>
|
||||
|
||||
<p>Just put something in the <samp><span class="file">ChangeLog</span></samp> so that the trunk also
|
||||
indicates when the release was made.
|
||||
|
||||
<h5 class="subsubheading">Restart <samp><span class="file">gdb/version.in</span></samp></h5>
|
||||
|
||||
<p>If <samp><span class="file">gdb/version.in</span></samp> does not contain an ISO date such as
|
||||
<kbd>2002-01-24</kbd> then the daily <code>cronjob</code> won't update it. Having
|
||||
committed all the release changes it can be set to
|
||||
<samp><span class="file">5.2.0_0000-00-00-cvs</span></samp> which will restart things (yes the <kbd>_</kbd>
|
||||
is important - it affects the snapshot process).
|
||||
|
||||
<p>Don't forget the <samp><span class="file">ChangeLog</span></samp>.
|
||||
|
||||
<h5 class="subsubheading">Merge into trunk</h5>
|
||||
|
||||
<p>The files committed to the branch may also need changes merged into the
|
||||
trunk.
|
||||
|
||||
<h5 class="subsubheading">Revise the release schedule</h5>
|
||||
|
||||
<p>Post a revised release schedule to <a href="mailto:gdb@sourceware.org">GDB Discussion List</a> with an updated announcement. The schedule can be
|
||||
generated by running:
|
||||
|
||||
<pre class="smallexample"> $ ~/ss/schedule `date +%s` schedule
|
||||
</pre>
|
||||
<p class="noindent">The first parameter is approximate date/time in seconds (from the epoch)
|
||||
of the most recent release.
|
||||
|
||||
<p>Also update the schedule <code>cronjob</code>.
|
||||
|
||||
<h3 class="section">21.7 Post release</h3>
|
||||
|
||||
<p>Remove any <code>OBSOLETE</code> code.
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,80 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>Requirements - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="up" href="Summary.html#Summary" title="Summary">
|
||||
<link rel="next" href="Contributors.html#Contributors" title="Contributors">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Requirements"></a>
|
||||
Next: <a rel="next" accesskey="n" href="Contributors.html#Contributors">Contributors</a>,
|
||||
Up: <a rel="up" accesskey="u" href="Summary.html#Summary">Summary</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h3 class="section">1.1 Requirements</h3>
|
||||
|
||||
<p><a name="index-requirements-for-_0040value_007bGDBN_007d-1"></a>
|
||||
Before diving into the internals, you should understand the formal
|
||||
requirements and other expectations for <span class="sc">gdb</span>. Although some
|
||||
of these may seem obvious, there have been proposals for <span class="sc">gdb</span>
|
||||
that have run counter to these requirements.
|
||||
|
||||
<p>First of all, <span class="sc">gdb</span> is a debugger. It's not designed to be a
|
||||
front panel for embedded systems. It's not a text editor. It's not a
|
||||
shell. It's not a programming environment.
|
||||
|
||||
<p><span class="sc">gdb</span> is an interactive tool. Although a batch mode is
|
||||
available, <span class="sc">gdb</span>'s primary role is to interact with a human
|
||||
programmer.
|
||||
|
||||
<p><span class="sc">gdb</span> should be responsive to the user. A programmer hot on
|
||||
the trail of a nasty bug, and operating under a looming deadline, is
|
||||
going to be very impatient of everything, including the response time
|
||||
to debugger commands.
|
||||
|
||||
<p><span class="sc">gdb</span> should be relatively permissive, such as for expressions.
|
||||
While the compiler should be picky (or have the option to be made
|
||||
picky), since source code lives for a long time usually, the
|
||||
programmer doing debugging shouldn't be spending time figuring out to
|
||||
mollify the debugger.
|
||||
|
||||
<p><span class="sc">gdb</span> will be called upon to deal with really large programs.
|
||||
Executable sizes of 50 to 100 megabytes occur regularly, and we've
|
||||
heard reports of programs approaching 1 gigabyte in size.
|
||||
|
||||
<p><span class="sc">gdb</span> should be able to run everywhere. No other debugger is
|
||||
available for even half as many configurations as <span class="sc">gdb</span>
|
||||
supports.
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,154 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>Stack Frames - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="prev" href="Values.html#Values" title="Values">
|
||||
<link rel="next" href="Symbol-Handling.html#Symbol-Handling" title="Symbol Handling">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Stack-Frames"></a>
|
||||
Next: <a rel="next" accesskey="n" href="Symbol-Handling.html#Symbol-Handling">Symbol Handling</a>,
|
||||
Previous: <a rel="previous" accesskey="p" href="Values.html#Values">Values</a>,
|
||||
Up: <a rel="up" accesskey="u" href="index.html#Top">Top</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h2 class="chapter">7 Stack Frames</h2>
|
||||
|
||||
<p><a name="index-frame-106"></a><a name="index-call-stack-frame-107"></a>A frame is a construct that <span class="sc">gdb</span> uses to keep track of calling
|
||||
and called functions.
|
||||
|
||||
<p><a name="index-unwind-frame-108"></a><span class="sc">gdb</span>'s frame model, a fresh design, was implemented with the
|
||||
need to support <span class="sc">dwarf</span>'s Call Frame Information in mind. In fact,
|
||||
the term “unwind” is taken directly from that specification.
|
||||
Developers wishing to learn more about unwinders, are encouraged to
|
||||
read the <span class="sc">dwarf</span> specification, available from
|
||||
<a href="http://www.dwarfstd.org">http://www.dwarfstd.org</a>.
|
||||
|
||||
<p><a name="index-frame_005fregister_005funwind-109"></a><a name="index-get_005fframe_005fregister-110"></a><span class="sc">gdb</span>'s model is that you find a frame's registers by
|
||||
“unwinding” them from the next younger frame. That is,
|
||||
‘<samp><span class="samp">get_frame_register</span></samp>’ which returns the value of a register in
|
||||
frame #1 (the next-to-youngest frame), is implemented by calling frame
|
||||
#0's <code>frame_register_unwind</code> (the youngest frame). But then the
|
||||
obvious question is: how do you access the registers of the youngest
|
||||
frame itself?
|
||||
|
||||
<p><a name="index-sentinel-frame-111"></a><a name="index-get_005fframe_005ftype-112"></a><a name="index-SENTINEL_005fFRAME-113"></a>To answer this question, <span class="sc">gdb</span> has the <dfn>sentinel</dfn> frame, the
|
||||
“-1st” frame. Unwinding registers from the sentinel frame gives you
|
||||
the current values of the youngest real frame's registers. If <var>f</var>
|
||||
is a sentinel frame, then <code>get_frame_type (</code><var>f</var><code>) ==
|
||||
SENTINEL_FRAME</code>.
|
||||
|
||||
<h3 class="section">7.1 Selecting an Unwinder</h3>
|
||||
|
||||
<p><a name="index-frame_005funwind_005fprepend_005funwinder-114"></a><a name="index-frame_005funwind_005fappend_005funwinder-115"></a>The architecture registers a list of frame unwinders (<code>struct
|
||||
frame_unwind</code>), using the functions
|
||||
<code>frame_unwind_prepend_unwinder</code> and
|
||||
<code>frame_unwind_append_unwinder</code>. Each unwinder includes a
|
||||
sniffer. Whenever <span class="sc">gdb</span> needs to unwind a frame (to fetch the
|
||||
previous frame's registers or the current frame's ID), it calls
|
||||
registered sniffers in order to find one which recognizes the frame.
|
||||
The first time a sniffer returns non-zero, the corresponding unwinder
|
||||
is assigned to the frame.
|
||||
|
||||
<h3 class="section">7.2 Unwinding the Frame ID</h3>
|
||||
|
||||
<p><a name="index-frame-ID-116"></a>
|
||||
Every frame has an associated ID, of type <code>struct frame_id</code>.
|
||||
The ID includes the stack base and function start address for
|
||||
the frame. The ID persists through the entire life of the frame,
|
||||
including while other called frames are running; it is used to
|
||||
locate an appropriate <code>struct frame_info</code> from the cache.
|
||||
|
||||
<p>Every time the inferior stops, and at various other times, the frame
|
||||
cache is flushed. Because of this, parts of <span class="sc">gdb</span> which need
|
||||
to keep track of individual frames cannot use pointers to <code>struct
|
||||
frame_info</code>. A frame ID provides a stable reference to a frame, even
|
||||
when the unwinder must be run again to generate a new <code>struct
|
||||
frame_info</code> for the same frame.
|
||||
|
||||
<p>The frame's unwinder's <code>this_id</code> method is called to find the ID.
|
||||
Note that this is different from register unwinding, where the next
|
||||
frame's <code>prev_register</code> is called to unwind this frame's
|
||||
registers.
|
||||
|
||||
<p>Both stack base and function address are required to identify the
|
||||
frame, because a recursive function has the same function address for
|
||||
two consecutive frames and a leaf function may have the same stack
|
||||
address as its caller. On some platforms, a third address is part of
|
||||
the ID to further disambiguate frames—for instance, on IA-64
|
||||
the separate register stack address is included in the ID.
|
||||
|
||||
<p>An invalid frame ID (<code>outer_frame_id</code>) returned from the
|
||||
<code>this_id</code> method means to stop unwinding after this frame.
|
||||
|
||||
<p><code>null_frame_id</code> is another invalid frame ID which should be used
|
||||
when there is no frame. For instance, certain breakpoints are attached
|
||||
to a specific frame, and that frame is identified through its frame ID
|
||||
(we use this to implement the "finish" command). Using
|
||||
<code>null_frame_id</code> as the frame ID for a given breakpoint means
|
||||
that the breakpoint is not specific to any frame. The <code>this_id</code>
|
||||
method should never return <code>null_frame_id</code>.
|
||||
|
||||
<h3 class="section">7.3 Unwinding Registers</h3>
|
||||
|
||||
<p>Each unwinder includes a <code>prev_register</code> method. This method
|
||||
takes a frame, an associated cache pointer, and a register number.
|
||||
It returns a <code>struct value *</code> describing the requested register,
|
||||
as saved by this frame. This is the value of the register that is
|
||||
current in this frame's caller.
|
||||
|
||||
<p>The returned value must have the same type as the register. It may
|
||||
have any lvalue type. In most circumstances one of these routines
|
||||
will generate the appropriate value:
|
||||
|
||||
<dl>
|
||||
<dt><code>frame_unwind_got_optimized</code><dd><a name="index-frame_005funwind_005fgot_005foptimized-117"></a>This register was not saved.
|
||||
|
||||
<br><dt><code>frame_unwind_got_register</code><dd><a name="index-frame_005funwind_005fgot_005fregister-118"></a>This register was copied into another register in this frame. This
|
||||
is also used for unchanged registers; they are “copied” into the
|
||||
same register.
|
||||
|
||||
<br><dt><code>frame_unwind_got_memory</code><dd><a name="index-frame_005funwind_005fgot_005fmemory-119"></a>This register was saved in memory.
|
||||
|
||||
<br><dt><code>frame_unwind_got_constant</code><dd><a name="index-frame_005funwind_005fgot_005fconstant-120"></a>This register was not saved, but the unwinder can compute the previous
|
||||
value some other way.
|
||||
|
||||
<br><dt><code>frame_unwind_got_address</code><dd><a name="index-frame_005funwind_005fgot_005faddress-121"></a>Same as <code>frame_unwind_got_constant</code>, except that the value is a target
|
||||
address. This is frequently used for the stack pointer, which is not
|
||||
explicitly saved but has a known offset from this frame's stack
|
||||
pointer. For architectures with a flat unified address space, this is
|
||||
generally the same as <code>frame_unwind_got_constant</code>.
|
||||
</dl>
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,86 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>Start of New Year Procedure - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="prev" href="Versions-and-Branches.html#Versions-and-Branches" title="Versions and Branches">
|
||||
<link rel="next" href="Releasing-GDB.html#Releasing-GDB" title="Releasing GDB">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Start-of-New-Year-Procedure"></a>
|
||||
Next: <a rel="next" accesskey="n" href="Releasing-GDB.html#Releasing-GDB">Releasing GDB</a>,
|
||||
Previous: <a rel="previous" accesskey="p" href="Versions-and-Branches.html#Versions-and-Branches">Versions and Branches</a>,
|
||||
Up: <a rel="up" accesskey="u" href="index.html#Top">Top</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h2 class="chapter">20 Start of New Year Procedure</h2>
|
||||
|
||||
<p><a name="index-new-year-procedure-490"></a>
|
||||
At the start of each new year, the following actions should be performed:
|
||||
|
||||
<ul>
|
||||
<li>Rotate the ChangeLog file
|
||||
|
||||
<p>The current <samp><span class="file">ChangeLog</span></samp> file should be renamed into
|
||||
<samp><span class="file">ChangeLog-YYYY</span></samp> where YYYY is the year that has just passed.
|
||||
A new <samp><span class="file">ChangeLog</span></samp> file should be created, and its contents should
|
||||
contain a reference to the previous ChangeLog. The following should
|
||||
also be preserved at the end of the new ChangeLog, in order to provide
|
||||
the appropriate settings when editing this file with Emacs:
|
||||
<pre class="smallexample"> Local Variables:
|
||||
mode: change-log
|
||||
left-margin: 8
|
||||
fill-column: 74
|
||||
version-control: never
|
||||
coding: utf-8
|
||||
End:
|
||||
</pre>
|
||||
<li>Add an entry for the newly created ChangeLog file (<samp><span class="file">ChangeLog-YYYY</span></samp>)
|
||||
in <samp><span class="file">gdb/config/djgpp/fnchange.lst</span></samp>.
|
||||
|
||||
<li>Update the copyright year in the startup message
|
||||
|
||||
<p>Update the copyright year in:
|
||||
<ul>
|
||||
<li> file <samp><span class="file">top.c</span></samp>, function <code>print_gdb_version</code>
|
||||
<li> file <samp><span class="file">gdbserver/server.c</span></samp>, function <code>gdbserver_version</code>
|
||||
<li> file <samp><span class="file">gdbserver/gdbreplay.c</span></samp>, function <code>gdbreplay_version</code>
|
||||
</ul>
|
||||
|
||||
<li>Run the <samp><span class="file">copyright.py</span></samp> Python script to add the new year in the copyright
|
||||
notices of most source files. This script has been tested with Python
|
||||
2.6 and 2.7.
|
||||
|
||||
</ul>
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,54 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>Summary - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="prev" href="index.html#Top" title="Top">
|
||||
<link rel="next" href="Overall-Structure.html#Overall-Structure" title="Overall Structure">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<h1 class="settitle">GDB Internals</h1>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Summary"></a>
|
||||
Next: <a rel="next" accesskey="n" href="Overall-Structure.html#Overall-Structure">Overall Structure</a>,
|
||||
Previous: <a rel="previous" accesskey="p" href="index.html#Top">Top</a>,
|
||||
Up: <a rel="up" accesskey="u" href="index.html#Top">Top</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h2 class="chapter">1 Summary</h2>
|
||||
|
||||
<ul class="menu">
|
||||
<li><a accesskey="1" href="Requirements.html#Requirements">Requirements</a>
|
||||
<li><a accesskey="2" href="Contributors.html#Contributors">Contributors</a>
|
||||
</ul>
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,312 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>Support Libraries - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="prev" href="Native-Debugging.html#Native-Debugging" title="Native Debugging">
|
||||
<link rel="next" href="Coding-Standards.html#Coding-Standards" title="Coding Standards">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Support-Libraries"></a>
|
||||
Next: <a rel="next" accesskey="n" href="Coding-Standards.html#Coding-Standards">Coding Standards</a>,
|
||||
Previous: <a rel="previous" accesskey="p" href="Native-Debugging.html#Native-Debugging">Native Debugging</a>,
|
||||
Up: <a rel="up" accesskey="u" href="index.html#Top">Top</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h2 class="chapter">15 Support Libraries</h2>
|
||||
|
||||
<h3 class="section">15.1 BFD</h3>
|
||||
|
||||
<p><a name="index-BFD-library-446"></a>
|
||||
BFD provides support for <span class="sc">gdb</span> in several ways:
|
||||
|
||||
<dl>
|
||||
<dt><em>identifying executable and core files</em><dd>BFD will identify a variety of file types, including a.out, coff, and
|
||||
several variants thereof, as well as several kinds of core files.
|
||||
|
||||
<br><dt><em>access to sections of files</em><dd>BFD parses the file headers to determine the names, virtual addresses,
|
||||
sizes, and file locations of all the various named sections in files
|
||||
(such as the text section or the data section). <span class="sc">gdb</span> simply
|
||||
calls BFD to read or write section <var>x</var> at byte offset <var>y</var> for
|
||||
length <var>z</var>.
|
||||
|
||||
<br><dt><em>specialized core file support</em><dd>BFD provides routines to determine the failing command name stored in a
|
||||
core file, the signal with which the program failed, and whether a core
|
||||
file matches (i.e. could be a core dump of) a particular executable
|
||||
file.
|
||||
|
||||
<br><dt><em>locating the symbol information</em><dd><span class="sc">gdb</span> uses an internal interface of BFD to determine where to find the
|
||||
symbol information in an executable file or symbol-file. <span class="sc">gdb</span> itself
|
||||
handles the reading of symbols, since BFD does not “understand” debug
|
||||
symbols, but <span class="sc">gdb</span> uses BFD's cached information to find the symbols,
|
||||
string table, etc.
|
||||
</dl>
|
||||
|
||||
<h3 class="section">15.2 opcodes</h3>
|
||||
|
||||
<p><a name="index-opcodes-library-447"></a>
|
||||
The opcodes library provides <span class="sc">gdb</span>'s disassembler. (It's a separate
|
||||
library because it's also used in binutils, for <samp><span class="file">objdump</span></samp>).
|
||||
|
||||
<h3 class="section">15.3 readline</h3>
|
||||
|
||||
<p><a name="index-readline-library-448"></a>The <code>readline</code> library provides a set of functions for use by applications
|
||||
that allow users to edit command lines as they are typed in.
|
||||
|
||||
<h3 class="section">15.4 libiberty</h3>
|
||||
|
||||
<p><a name="index-g_t_0040code_007blibiberty_007d-library-449"></a>
|
||||
The <code>libiberty</code> library provides a set of functions and features
|
||||
that integrate and improve on functionality found in modern operating
|
||||
systems. Broadly speaking, such features can be divided into three
|
||||
groups: supplemental functions (functions that may be missing in some
|
||||
environments and operating systems), replacement functions (providing
|
||||
a uniform and easier to use interface for commonly used standard
|
||||
functions), and extensions (which provide additional functionality
|
||||
beyond standard functions).
|
||||
|
||||
<p><span class="sc">gdb</span> uses various features provided by the <code>libiberty</code>
|
||||
library, for instance the C<tt>++</tt> demangler, the <acronym>IEEE</acronym>
|
||||
floating format support functions, the input options parser
|
||||
‘<samp><span class="samp">getopt</span></samp>’, the ‘<samp><span class="samp">obstack</span></samp>’ extension, and other functions.
|
||||
|
||||
<h4 class="subsection">15.4.1 <code>obstacks</code> in <span class="sc">gdb</span></h4>
|
||||
|
||||
<p><a name="index-g_t_0040code_007bobstacks_007d-450"></a>
|
||||
The obstack mechanism provides a convenient way to allocate and free
|
||||
chunks of memory. Each obstack is a pool of memory that is managed
|
||||
like a stack. Objects (of any nature, size and alignment) are
|
||||
allocated and freed in a <acronym>LIFO</acronym> fashion on an obstack (see
|
||||
<code>libiberty</code>'s documentation for a more detailed explanation of
|
||||
<code>obstacks</code>).
|
||||
|
||||
<p>The most noticeable use of the <code>obstacks</code> in <span class="sc">gdb</span> is in
|
||||
object files. There is an obstack associated with each internal
|
||||
representation of an object file. Lots of things get allocated on
|
||||
these <code>obstacks</code>: dictionary entries, blocks, blockvectors,
|
||||
symbols, minimal symbols, types, vectors of fundamental types, class
|
||||
fields of types, object files section lists, object files section
|
||||
offset lists, line tables, symbol tables, partial symbol tables,
|
||||
string tables, symbol table private data, macros tables, debug
|
||||
information sections and entries, import and export lists (som),
|
||||
unwind information (hppa), dwarf2 location expressions data. Plus
|
||||
various strings such as directory names strings, debug format strings,
|
||||
names of types.
|
||||
|
||||
<p>An essential and convenient property of all data on <code>obstacks</code> is
|
||||
that memory for it gets allocated (with <code>obstack_alloc</code>) at
|
||||
various times during a debugging session, but it is released all at
|
||||
once using the <code>obstack_free</code> function. The <code>obstack_free</code>
|
||||
function takes a pointer to where in the stack it must start the
|
||||
deletion from (much like the cleanup chains have a pointer to where to
|
||||
start the cleanups). Because of the stack like structure of the
|
||||
<code>obstacks</code>, this allows to free only a top portion of the
|
||||
obstack. There are a few instances in <span class="sc">gdb</span> where such thing
|
||||
happens. Calls to <code>obstack_free</code> are done after some local data
|
||||
is allocated to the obstack. Only the local data is deleted from the
|
||||
obstack. Of course this assumes that nothing between the
|
||||
<code>obstack_alloc</code> and the <code>obstack_free</code> allocates anything
|
||||
else on the same obstack. For this reason it is best and safest to
|
||||
use temporary <code>obstacks</code>.
|
||||
|
||||
<p>Releasing the whole obstack is also not safe per se. It is safe only
|
||||
under the condition that we know the <code>obstacks</code> memory is no
|
||||
longer needed. In <span class="sc">gdb</span> we get rid of the <code>obstacks</code> only
|
||||
when we get rid of the whole objfile(s), for instance upon reading a
|
||||
new symbol file.
|
||||
|
||||
<h3 class="section">15.5 gnu-regex</h3>
|
||||
|
||||
<p><a name="index-regular-expressions-library-451"></a>
|
||||
Regex conditionals.
|
||||
|
||||
<dl>
|
||||
<dt><code>C_ALLOCA</code>
|
||||
<br><dt><code>NFAILURES</code>
|
||||
<br><dt><code>RE_NREGS</code>
|
||||
<br><dt><code>SIGN_EXTEND_CHAR</code>
|
||||
<br><dt><code>SWITCH_ENUM_BUG</code>
|
||||
<br><dt><code>SYNTAX_TABLE</code>
|
||||
<br><dt><code>Sword</code>
|
||||
<br><dt><code>sparc</code><dd></dl>
|
||||
|
||||
<h3 class="section">15.6 Array Containers</h3>
|
||||
|
||||
<p><a name="index-Array-Containers-452"></a><a name="index-VEC-453"></a>
|
||||
Often it is necessary to manipulate a dynamic array of a set of
|
||||
objects. C forces some bookkeeping on this, which can get cumbersome
|
||||
and repetitive. The <samp><span class="file">vec.h</span></samp> file contains macros for defining
|
||||
and using a typesafe vector type. The functions defined will be
|
||||
inlined when compiling, and so the abstraction cost should be zero.
|
||||
Domain checks are added to detect programming errors.
|
||||
|
||||
<p>An example use would be an array of symbols or section information.
|
||||
The array can be grown as symbols are read in (or preallocated), and
|
||||
the accessor macros provided keep care of all the necessary
|
||||
bookkeeping. Because the arrays are type safe, there is no danger of
|
||||
accidentally mixing up the contents. Think of these as C++ templates,
|
||||
but implemented in C.
|
||||
|
||||
<p>Because of the different behavior of structure objects, scalar objects
|
||||
and of pointers, there are three flavors of vector, one for each of
|
||||
these variants. Both the structure object and pointer variants pass
|
||||
pointers to objects around — in the former case the pointers are
|
||||
stored into the vector and in the latter case the pointers are
|
||||
dereferenced and the objects copied into the vector. The scalar
|
||||
object variant is suitable for <code>int</code>-like objects, and the vector
|
||||
elements are returned by value.
|
||||
|
||||
<p>There are both <code>index</code> and <code>iterate</code> accessors. The iterator
|
||||
returns a boolean iteration condition and updates the iteration
|
||||
variable passed by reference. Because the iterator will be inlined,
|
||||
the address-of can be optimized away.
|
||||
|
||||
<p>The vectors are implemented using the trailing array idiom, thus they
|
||||
are not resizeable without changing the address of the vector object
|
||||
itself. This means you cannot have variables or fields of vector type
|
||||
— always use a pointer to a vector. The one exception is the final
|
||||
field of a structure, which could be a vector type. You will have to
|
||||
use the <code>embedded_size</code> & <code>embedded_init</code> calls to create
|
||||
such objects, and they will probably not be resizeable (so don't use
|
||||
the <dfn>safe</dfn> allocation variants). The trailing array idiom is used
|
||||
(rather than a pointer to an array of data), because, if we allow
|
||||
<code>NULL</code> to also represent an empty vector, empty vectors occupy
|
||||
minimal space in the structure containing them.
|
||||
|
||||
<p>Each operation that increases the number of active elements is
|
||||
available in <dfn>quick</dfn> and <dfn>safe</dfn> variants. The former presumes
|
||||
that there is sufficient allocated space for the operation to succeed
|
||||
(it dies if there is not). The latter will reallocate the vector, if
|
||||
needed. Reallocation causes an exponential increase in vector size.
|
||||
If you know you will be adding N elements, it would be more efficient
|
||||
to use the reserve operation before adding the elements with the
|
||||
<dfn>quick</dfn> operation. This will ensure there are at least as many
|
||||
elements as you ask for, it will exponentially increase if there are
|
||||
too few spare slots. If you want reserve a specific number of slots,
|
||||
but do not want the exponential increase (for instance, you know this
|
||||
is the last allocation), use a negative number for reservation. You
|
||||
can also create a vector of a specific size from the get go.
|
||||
|
||||
<p>You should prefer the push and pop operations, as they append and
|
||||
remove from the end of the vector. If you need to remove several items
|
||||
in one go, use the truncate operation. The insert and remove
|
||||
operations allow you to change elements in the middle of the vector.
|
||||
There are two remove operations, one which preserves the element
|
||||
ordering <code>ordered_remove</code>, and one which does not
|
||||
<code>unordered_remove</code>. The latter function copies the end element
|
||||
into the removed slot, rather than invoke a memmove operation. The
|
||||
<code>lower_bound</code> function will determine where to place an item in
|
||||
the array using insert that will maintain sorted order.
|
||||
|
||||
<p>If you need to directly manipulate a vector, then the <code>address</code>
|
||||
accessor will return the address of the start of the vector. Also the
|
||||
<code>space</code> predicate will tell you whether there is spare capacity in the
|
||||
vector. You will not normally need to use these two functions.
|
||||
|
||||
<p>Vector types are defined using a
|
||||
<code>DEF_VEC_{O,P,I}(</code><var>typename</var><code>)</code> macro. Variables of vector
|
||||
type are declared using a <code>VEC(</code><var>typename</var><code>)</code> macro. The
|
||||
characters <code>O</code>, <code>P</code> and <code>I</code> indicate whether
|
||||
<var>typename</var> is an object (<code>O</code>), pointer (<code>P</code>) or integral
|
||||
(<code>I</code>) type. Be careful to pick the correct one, as you'll get an
|
||||
awkward and inefficient API if you use the wrong one. There is a
|
||||
check, which results in a compile-time warning, for the <code>P</code> and
|
||||
<code>I</code> versions, but there is no check for the <code>O</code> versions, as
|
||||
that is not possible in plain C.
|
||||
|
||||
<p>An example of their use would be,
|
||||
|
||||
<pre class="smallexample"> DEF_VEC_P(tree); // non-managed tree vector.
|
||||
|
||||
struct my_struct {
|
||||
VEC(tree) *v; // A (pointer to) a vector of tree pointers.
|
||||
};
|
||||
|
||||
struct my_struct *s;
|
||||
|
||||
if (VEC_length(tree, s->v)) { we have some contents }
|
||||
VEC_safe_push(tree, s->v, decl); // append some decl onto the end
|
||||
for (ix = 0; VEC_iterate(tree, s->v, ix, elt); ix++)
|
||||
{ do something with elt }
|
||||
|
||||
</pre>
|
||||
<p>The <samp><span class="file">vec.h</span></samp> file provides details on how to invoke the various
|
||||
accessors provided. They are enumerated here:
|
||||
|
||||
<dl>
|
||||
<dt><code>VEC_length</code><dd>Return the number of items in the array,
|
||||
|
||||
<br><dt><code>VEC_empty</code><dd>Return true if the array has no elements.
|
||||
|
||||
<br><dt><code>VEC_last</code><dt><code>VEC_index</code><dd>Return the last or arbitrary item in the array.
|
||||
|
||||
<br><dt><code>VEC_iterate</code><dd>Access an array element and indicate whether the array has been
|
||||
traversed.
|
||||
|
||||
<br><dt><code>VEC_alloc</code><dt><code>VEC_free</code><dd>Create and destroy an array.
|
||||
|
||||
<br><dt><code>VEC_embedded_size</code><dt><code>VEC_embedded_init</code><dd>Helpers for embedding an array as the final element of another struct.
|
||||
|
||||
<br><dt><code>VEC_copy</code><dd>Duplicate an array.
|
||||
|
||||
<br><dt><code>VEC_space</code><dd>Return the amount of free space in an array.
|
||||
|
||||
<br><dt><code>VEC_reserve</code><dd>Ensure a certain amount of free space.
|
||||
|
||||
<br><dt><code>VEC_quick_push</code><dt><code>VEC_safe_push</code><dd>Append to an array, either assuming the space is available, or making
|
||||
sure that it is.
|
||||
|
||||
<br><dt><code>VEC_pop</code><dd>Remove the last item from an array.
|
||||
|
||||
<br><dt><code>VEC_truncate</code><dd>Remove several items from the end of an array.
|
||||
|
||||
<br><dt><code>VEC_safe_grow</code><dd>Add several items to the end of an array.
|
||||
|
||||
<br><dt><code>VEC_replace</code><dd>Overwrite an item in the array.
|
||||
|
||||
<br><dt><code>VEC_quick_insert</code><dt><code>VEC_safe_insert</code><dd>Insert an item into the middle of the array. Either the space must
|
||||
already exist, or the space is created.
|
||||
|
||||
<br><dt><code>VEC_ordered_remove</code><dt><code>VEC_unordered_remove</code><dd>Remove an item from the array, preserving order or not.
|
||||
|
||||
<br><dt><code>VEC_block_remove</code><dd>Remove a set of items from the array.
|
||||
|
||||
<br><dt><code>VEC_address</code><dd>Provide the address of the first element.
|
||||
|
||||
<br><dt><code>VEC_lower_bound</code><dd>Binary search the array.
|
||||
|
||||
</dl>
|
||||
|
||||
<h3 class="section">15.7 include</h3>
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,444 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>Symbol Handling - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="prev" href="Stack-Frames.html#Stack-Frames" title="Stack Frames">
|
||||
<link rel="next" href="Language-Support.html#Language-Support" title="Language Support">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Symbol-Handling"></a>
|
||||
Next: <a rel="next" accesskey="n" href="Language-Support.html#Language-Support">Language Support</a>,
|
||||
Previous: <a rel="previous" accesskey="p" href="Stack-Frames.html#Stack-Frames">Stack Frames</a>,
|
||||
Up: <a rel="up" accesskey="u" href="index.html#Top">Top</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h2 class="chapter">8 Symbol Handling</h2>
|
||||
|
||||
<p>Symbols are a key part of <span class="sc">gdb</span>'s operation. Symbols include
|
||||
variables, functions, and types.
|
||||
|
||||
<p>Symbol information for a large program can be truly massive, and
|
||||
reading of symbol information is one of the major performance
|
||||
bottlenecks in <span class="sc">gdb</span>; it can take many minutes to process it
|
||||
all. Studies have shown that nearly all the time spent is
|
||||
computational, rather than file reading.
|
||||
|
||||
<p>One of the ways for <span class="sc">gdb</span> to provide a good user experience is
|
||||
to start up quickly, taking no more than a few seconds. It is simply
|
||||
not possible to process all of a program's debugging info in that
|
||||
time, and so we attempt to handle symbols incrementally. For instance,
|
||||
we create <dfn>partial symbol tables</dfn> consisting of only selected
|
||||
symbols, and only expand them to full symbol tables when necessary.
|
||||
|
||||
<h3 class="section">8.1 Symbol Reading</h3>
|
||||
|
||||
<p><a name="index-symbol-reading-122"></a><a name="index-reading-of-symbols-123"></a><a name="index-symbol-files-124"></a><span class="sc">gdb</span> reads symbols from <dfn>symbol files</dfn>. The usual symbol
|
||||
file is the file containing the program which <span class="sc">gdb</span> is
|
||||
debugging. <span class="sc">gdb</span> can be directed to use a different file for
|
||||
symbols (with the ‘<samp><span class="samp">symbol-file</span></samp>’ command), and it can also read
|
||||
more symbols via the ‘<samp><span class="samp">add-file</span></samp>’ and ‘<samp><span class="samp">load</span></samp>’ commands. In
|
||||
addition, it may bring in more symbols while loading shared
|
||||
libraries.
|
||||
|
||||
<p><a name="index-find_005fsym_005ffns-125"></a>Symbol files are initially opened by code in <samp><span class="file">symfile.c</span></samp> using
|
||||
the BFD library (see <a href="Support-Libraries.html#Support-Libraries">Support Libraries</a>). BFD identifies the type
|
||||
of the file by examining its header. <code>find_sym_fns</code> then uses
|
||||
this identification to locate a set of symbol-reading functions.
|
||||
|
||||
<p><a name="index-add_005fsymtab_005ffns-126"></a><a name="index-g_t_0040code_007bsym_005ffns_007d-structure-127"></a><a name="index-adding-a-symbol_002dreading-module-128"></a>Symbol-reading modules identify themselves to <span class="sc">gdb</span> by calling
|
||||
<code>add_symtab_fns</code> during their module initialization. The argument
|
||||
to <code>add_symtab_fns</code> is a <code>struct sym_fns</code> which contains the
|
||||
name (or name prefix) of the symbol format, the length of the prefix,
|
||||
and pointers to four functions. These functions are called at various
|
||||
times to process symbol files whose identification matches the specified
|
||||
prefix.
|
||||
|
||||
<p>The functions supplied by each module are:
|
||||
|
||||
<dl>
|
||||
<dt><var>xyz</var><code>_symfile_init(struct sym_fns *sf)</code><dd>
|
||||
<a name="index-secondary-symbol-file-129"></a>Called from <code>symbol_file_add</code> when we are about to read a new
|
||||
symbol file. This function should clean up any internal state (possibly
|
||||
resulting from half-read previous files, for example) and prepare to
|
||||
read a new symbol file. Note that the symbol file which we are reading
|
||||
might be a new “main” symbol file, or might be a secondary symbol file
|
||||
whose symbols are being added to the existing symbol table.
|
||||
|
||||
<p>The argument to <var>xyz</var><code>_symfile_init</code> is a newly allocated
|
||||
<code>struct sym_fns</code> whose <code>bfd</code> field contains the BFD for the
|
||||
new symbol file being read. Its <code>private</code> field has been zeroed,
|
||||
and can be modified as desired. Typically, a struct of private
|
||||
information will be <code>malloc</code>'d, and a pointer to it will be placed
|
||||
in the <code>private</code> field.
|
||||
|
||||
<p>There is no result from <var>xyz</var><code>_symfile_init</code>, but it can call
|
||||
<code>error</code> if it detects an unavoidable problem.
|
||||
|
||||
<br><dt><var>xyz</var><code>_new_init()</code><dd>
|
||||
Called from <code>symbol_file_add</code> when discarding existing symbols.
|
||||
This function needs only handle the symbol-reading module's internal
|
||||
state; the symbol table data structures visible to the rest of
|
||||
<span class="sc">gdb</span> will be discarded by <code>symbol_file_add</code>. It has no
|
||||
arguments and no result. It may be called after
|
||||
<var>xyz</var><code>_symfile_init</code>, if a new symbol table is being read, or
|
||||
may be called alone if all symbols are simply being discarded.
|
||||
|
||||
<br><dt><var>xyz</var><code>_symfile_read(struct sym_fns *sf, CORE_ADDR addr, int mainline)</code><dd>
|
||||
Called from <code>symbol_file_add</code> to actually read the symbols from a
|
||||
symbol-file into a set of psymtabs or symtabs.
|
||||
|
||||
<p><code>sf</code> points to the <code>struct sym_fns</code> originally passed to
|
||||
<var>xyz</var><code>_sym_init</code> for possible initialization. <code>addr</code> is
|
||||
the offset between the file's specified start address and its true
|
||||
address in memory. <code>mainline</code> is 1 if this is the main symbol
|
||||
table being read, and 0 if a secondary symbol file (e.g., shared library
|
||||
or dynamically loaded file) is being read.
|
||||
</dl>
|
||||
|
||||
<p>In addition, if a symbol-reading module creates psymtabs when
|
||||
<var>xyz</var>_symfile_read is called, these psymtabs will contain a pointer
|
||||
to a function <var>xyz</var><code>_psymtab_to_symtab</code>, which can be called
|
||||
from any point in the <span class="sc">gdb</span> symbol-handling code.
|
||||
|
||||
<dl>
|
||||
<dt><var>xyz</var><code>_psymtab_to_symtab (struct partial_symtab *pst)</code><dd>
|
||||
Called from <code>psymtab_to_symtab</code> (or the <code>PSYMTAB_TO_SYMTAB</code> macro) if
|
||||
the psymtab has not already been read in and had its <code>pst->symtab</code>
|
||||
pointer set. The argument is the psymtab to be fleshed-out into a
|
||||
symtab. Upon return, <code>pst->readin</code> should have been set to 1, and
|
||||
<code>pst->symtab</code> should contain a pointer to the new corresponding symtab, or
|
||||
zero if there were no symbols in that part of the symbol file.
|
||||
</dl>
|
||||
|
||||
<h3 class="section">8.2 Partial Symbol Tables</h3>
|
||||
|
||||
<p><span class="sc">gdb</span> has three types of symbol tables:
|
||||
|
||||
|
||||
<a name="index-full-symbol-table-130"></a>
|
||||
<a name="index-symtabs-131"></a>
|
||||
<ul><li>Full symbol tables (<dfn>symtabs</dfn>). These contain the main
|
||||
information about symbols and addresses.
|
||||
|
||||
<p><a name="index-psymtabs-132"></a><li>Partial symbol tables (<dfn>psymtabs</dfn>). These contain enough
|
||||
information to know when to read the corresponding part of the full
|
||||
symbol table.
|
||||
|
||||
<p><a name="index-minimal-symbol-table-133"></a><a name="index-minsymtabs-134"></a><li>Minimal symbol tables (<dfn>msymtabs</dfn>). These contain information
|
||||
gleaned from non-debugging symbols.
|
||||
</ul>
|
||||
|
||||
<p><a name="index-partial-symbol-table-135"></a>This section describes partial symbol tables.
|
||||
|
||||
<p>A psymtab is constructed by doing a very quick pass over an executable
|
||||
file's debugging information. Small amounts of information are
|
||||
extracted—enough to identify which parts of the symbol table will
|
||||
need to be re-read and fully digested later, when the user needs the
|
||||
information. The speed of this pass causes <span class="sc">gdb</span> to start up very
|
||||
quickly. Later, as the detailed rereading occurs, it occurs in small
|
||||
pieces, at various times, and the delay therefrom is mostly invisible to
|
||||
the user.
|
||||
<!-- (@xref{Symbol Reading}.) -->
|
||||
|
||||
<p>The symbols that show up in a file's psymtab should be, roughly, those
|
||||
visible to the debugger's user when the program is not running code from
|
||||
that file. These include external symbols and types, static symbols and
|
||||
types, and <code>enum</code> values declared at file scope.
|
||||
|
||||
<p>The psymtab also contains the range of instruction addresses that the
|
||||
full symbol table would represent.
|
||||
|
||||
<p><a name="index-finding-a-symbol-136"></a><a name="index-symbol-lookup-137"></a>The idea is that there are only two ways for the user (or much of the
|
||||
code in the debugger) to reference a symbol:
|
||||
|
||||
|
||||
<a name="index-find_005fpc_005ffunction-138"></a>
|
||||
<a name="index-find_005fpc_005fline-139"></a>
|
||||
<ul><li>By its address (e.g., execution stops at some address which is inside a
|
||||
function in this file). The address will be noticed to be in the
|
||||
range of this psymtab, and the full symtab will be read in.
|
||||
<code>find_pc_function</code>, <code>find_pc_line</code>, and other
|
||||
<code>find_pc_...</code> functions handle this.
|
||||
|
||||
<p><a name="index-lookup_005fsymbol-140"></a><li>By its name
|
||||
(e.g., the user asks to print a variable, or set a breakpoint on a
|
||||
function). Global names and file-scope names will be found in the
|
||||
psymtab, which will cause the symtab to be pulled in. Local names will
|
||||
have to be qualified by a global name, or a file-scope name, in which
|
||||
case we will have already read in the symtab as we evaluated the
|
||||
qualifier. Or, a local symbol can be referenced when we are “in” a
|
||||
local scope, in which case the first case applies. <code>lookup_symbol</code>
|
||||
does most of the work here.
|
||||
</ul>
|
||||
|
||||
<p>The only reason that psymtabs exist is to cause a symtab to be read in
|
||||
at the right moment. Any symbol that can be elided from a psymtab,
|
||||
while still causing that to happen, should not appear in it. Since
|
||||
psymtabs don't have the idea of scope, you can't put local symbols in
|
||||
them anyway. Psymtabs don't have the idea of the type of a symbol,
|
||||
either, so types need not appear, unless they will be referenced by
|
||||
name.
|
||||
|
||||
<p>It is a bug for <span class="sc">gdb</span> to behave one way when only a psymtab has
|
||||
been read, and another way if the corresponding symtab has been read
|
||||
in. Such bugs are typically caused by a psymtab that does not contain
|
||||
all the visible symbols, or which has the wrong instruction address
|
||||
ranges.
|
||||
|
||||
<p>The psymtab for a particular section of a symbol file (objfile) could be
|
||||
thrown away after the symtab has been read in. The symtab should always
|
||||
be searched before the psymtab, so the psymtab will never be used (in a
|
||||
bug-free environment). Currently, psymtabs are allocated on an obstack,
|
||||
and all the psymbols themselves are allocated in a pair of large arrays
|
||||
on an obstack, so there is little to be gained by trying to free them
|
||||
unless you want to do a lot more work.
|
||||
|
||||
<p>Whether or not psymtabs are created depends on the objfile's symbol
|
||||
reader. The core of <span class="sc">gdb</span> hides the details of partial symbols
|
||||
and partial symbol tables behind a set of function pointers known as
|
||||
the <dfn>quick symbol functions</dfn>. These are documented in
|
||||
<samp><span class="file">symfile.h</span></samp>.
|
||||
|
||||
<h3 class="section">8.3 Types</h3>
|
||||
|
||||
<h4 class="unnumberedsubsec">Fundamental Types (e.g., <code>FT_VOID</code>, <code>FT_BOOLEAN</code>).</h4>
|
||||
|
||||
<p><a name="index-fundamental-types-141"></a>These are the fundamental types that <span class="sc">gdb</span> uses internally. Fundamental
|
||||
types from the various debugging formats (stabs, ELF, etc) are mapped
|
||||
into one of these. They are basically a union of all fundamental types
|
||||
that <span class="sc">gdb</span> knows about for all the languages that <span class="sc">gdb</span>
|
||||
knows about.
|
||||
|
||||
<h4 class="unnumberedsubsec">Type Codes (e.g., <code>TYPE_CODE_PTR</code>, <code>TYPE_CODE_ARRAY</code>).</h4>
|
||||
|
||||
<p><a name="index-type-codes-142"></a>Each time <span class="sc">gdb</span> builds an internal type, it marks it with one
|
||||
of these types. The type may be a fundamental type, such as
|
||||
<code>TYPE_CODE_INT</code>, or a derived type, such as <code>TYPE_CODE_PTR</code>
|
||||
which is a pointer to another type. Typically, several <code>FT_*</code>
|
||||
types map to one <code>TYPE_CODE_*</code> type, and are distinguished by
|
||||
other members of the type struct, such as whether the type is signed
|
||||
or unsigned, and how many bits it uses.
|
||||
|
||||
<h4 class="unnumberedsubsec">Builtin Types (e.g., <code>builtin_type_void</code>, <code>builtin_type_char</code>).</h4>
|
||||
|
||||
<p>These are instances of type structs that roughly correspond to
|
||||
fundamental types and are created as global types for <span class="sc">gdb</span> to
|
||||
use for various ugly historical reasons. We eventually want to
|
||||
eliminate these. Note for example that <code>builtin_type_int</code>
|
||||
initialized in <samp><span class="file">gdbtypes.c</span></samp> is basically the same as a
|
||||
<code>TYPE_CODE_INT</code> type that is initialized in <samp><span class="file">c-lang.c</span></samp> for
|
||||
an <code>FT_INTEGER</code> fundamental type. The difference is that the
|
||||
<code>builtin_type</code> is not associated with any particular objfile, and
|
||||
only one instance exists, while <samp><span class="file">c-lang.c</span></samp> builds as many
|
||||
<code>TYPE_CODE_INT</code> types as needed, with each one associated with
|
||||
some particular objfile.
|
||||
|
||||
<h3 class="section">8.4 Object File Formats</h3>
|
||||
|
||||
<p><a name="index-object-file-formats-143"></a>
|
||||
|
||||
<h4 class="subsection">8.4.1 a.out</h4>
|
||||
|
||||
<p><a name="index-g_t_0040code_007ba_002eout_007d-format-144"></a>The <code>a.out</code> format is the original file format for Unix. It
|
||||
consists of three sections: <code>text</code>, <code>data</code>, and <code>bss</code>,
|
||||
which are for program code, initialized data, and uninitialized data,
|
||||
respectively.
|
||||
|
||||
<p>The <code>a.out</code> format is so simple that it doesn't have any reserved
|
||||
place for debugging information. (Hey, the original Unix hackers used
|
||||
‘<samp><span class="samp">adb</span></samp>’, which is a machine-language debugger!) The only debugging
|
||||
format for <code>a.out</code> is stabs, which is encoded as a set of normal
|
||||
symbols with distinctive attributes.
|
||||
|
||||
<p>The basic <code>a.out</code> reader is in <samp><span class="file">dbxread.c</span></samp>.
|
||||
|
||||
<h4 class="subsection">8.4.2 COFF</h4>
|
||||
|
||||
<p><a name="index-COFF-format-145"></a>The COFF format was introduced with System V Release 3 (SVR3) Unix.
|
||||
COFF files may have multiple sections, each prefixed by a header. The
|
||||
number of sections is limited.
|
||||
|
||||
<p>The COFF specification includes support for debugging. Although this
|
||||
was a step forward, the debugging information was woefully limited.
|
||||
For instance, it was not possible to represent code that came from an
|
||||
included file. GNU's COFF-using configs often use stabs-type info,
|
||||
encapsulated in special sections.
|
||||
|
||||
<p>The COFF reader is in <samp><span class="file">coffread.c</span></samp>.
|
||||
|
||||
<h4 class="subsection">8.4.3 ECOFF</h4>
|
||||
|
||||
<p><a name="index-ECOFF-format-146"></a>ECOFF is an extended COFF originally introduced for Mips and Alpha
|
||||
workstations.
|
||||
|
||||
<p>The basic ECOFF reader is in <samp><span class="file">mipsread.c</span></samp>.
|
||||
|
||||
<h4 class="subsection">8.4.4 XCOFF</h4>
|
||||
|
||||
<p><a name="index-XCOFF-format-147"></a>The IBM RS/6000 running AIX uses an object file format called XCOFF.
|
||||
The COFF sections, symbols, and line numbers are used, but debugging
|
||||
symbols are <code>dbx</code>-style stabs whose strings are located in the
|
||||
<code>.debug</code> section (rather than the string table). For more
|
||||
information, see <a href="../stabs/index.html#Top">Top</a>.
|
||||
|
||||
<p>The shared library scheme has a clean interface for figuring out what
|
||||
shared libraries are in use, but the catch is that everything which
|
||||
refers to addresses (symbol tables and breakpoints at least) needs to be
|
||||
relocated for both shared libraries and the main executable. At least
|
||||
using the standard mechanism this can only be done once the program has
|
||||
been run (or the core file has been read).
|
||||
|
||||
<h4 class="subsection">8.4.5 PE</h4>
|
||||
|
||||
<p><a name="index-PE_002dCOFF-format-148"></a>Windows 95 and NT use the PE (<dfn>Portable Executable</dfn>) format for their
|
||||
executables. PE is basically COFF with additional headers.
|
||||
|
||||
<p>While BFD includes special PE support, <span class="sc">gdb</span> needs only the basic
|
||||
COFF reader.
|
||||
|
||||
<h4 class="subsection">8.4.6 ELF</h4>
|
||||
|
||||
<p><a name="index-ELF-format-149"></a>The ELF format came with System V Release 4 (SVR4) Unix. ELF is
|
||||
similar to COFF in being organized into a number of sections, but it
|
||||
removes many of COFF's limitations. Debugging info may be either stabs
|
||||
encapsulated in ELF sections, or more commonly these days, DWARF.
|
||||
|
||||
<p>The basic ELF reader is in <samp><span class="file">elfread.c</span></samp>.
|
||||
|
||||
<h4 class="subsection">8.4.7 SOM</h4>
|
||||
|
||||
<p><a name="index-SOM-format-150"></a>SOM is HP's object file and debug format (not to be confused with IBM's
|
||||
SOM, which is a cross-language ABI).
|
||||
|
||||
<p>The SOM reader is in <samp><span class="file">somread.c</span></samp>.
|
||||
|
||||
<h3 class="section">8.5 Debugging File Formats</h3>
|
||||
|
||||
<p>This section describes characteristics of debugging information that
|
||||
are independent of the object file format.
|
||||
|
||||
<h4 class="subsection">8.5.1 stabs</h4>
|
||||
|
||||
<p><a name="index-stabs-debugging-info-151"></a><code>stabs</code> started out as special symbols within the <code>a.out</code>
|
||||
format. Since then, it has been encapsulated into other file
|
||||
formats, such as COFF and ELF.
|
||||
|
||||
<p>While <samp><span class="file">dbxread.c</span></samp> does some of the basic stab processing,
|
||||
including for encapsulated versions, <samp><span class="file">stabsread.c</span></samp> does
|
||||
the real work.
|
||||
|
||||
<h4 class="subsection">8.5.2 COFF</h4>
|
||||
|
||||
<p><a name="index-COFF-debugging-info-152"></a>The basic COFF definition includes debugging information. The level
|
||||
of support is minimal and non-extensible, and is not often used.
|
||||
|
||||
<h4 class="subsection">8.5.3 Mips debug (Third Eye)</h4>
|
||||
|
||||
<p><a name="index-ECOFF-debugging-info-153"></a>ECOFF includes a definition of a special debug format.
|
||||
|
||||
<p>The file <samp><span class="file">mdebugread.c</span></samp> implements reading for this format.
|
||||
|
||||
<!-- mention DWARF 1 as a formerly-supported format -->
|
||||
<h4 class="subsection">8.5.4 DWARF 2</h4>
|
||||
|
||||
<p><a name="index-DWARF-2-debugging-info-154"></a>DWARF 2 is an improved but incompatible version of DWARF 1.
|
||||
|
||||
<p>The DWARF 2 reader is in <samp><span class="file">dwarf2read.c</span></samp>.
|
||||
|
||||
<h4 class="subsection">8.5.5 Compressed DWARF 2</h4>
|
||||
|
||||
<p><a name="index-Compressed-DWARF-2-debugging-info-155"></a>Compressed DWARF 2 is not technically a separate debugging format, but
|
||||
merely DWARF 2 debug information that has been compressed. In this
|
||||
format, every object-file section holding DWARF 2 debugging
|
||||
information is compressed and prepended with a header. (The section
|
||||
is also typically renamed, so a section called <code>.debug_info</code> in a
|
||||
DWARF 2 binary would be called <code>.zdebug_info</code> in a compressed
|
||||
DWARF 2 binary.) The header is 12 bytes long:
|
||||
|
||||
<ul>
|
||||
<li>4 bytes: the literal string “ZLIB”
|
||||
<li>8 bytes: the uncompressed size of the section, in big-endian byte
|
||||
order.
|
||||
</ul>
|
||||
|
||||
<p>The same reader is used for both compressed an normal DWARF 2 info.
|
||||
Section decompression is done in <code>zlib_decompress_section</code> in
|
||||
<samp><span class="file">dwarf2read.c</span></samp>.
|
||||
|
||||
<h4 class="subsection">8.5.6 DWARF 3</h4>
|
||||
|
||||
<p><a name="index-DWARF-3-debugging-info-156"></a>DWARF 3 is an improved version of DWARF 2.
|
||||
|
||||
<h4 class="subsection">8.5.7 SOM</h4>
|
||||
|
||||
<p><a name="index-SOM-debugging-info-157"></a>Like COFF, the SOM definition includes debugging information.
|
||||
|
||||
<h3 class="section">8.6 Adding a New Symbol Reader to <span class="sc">gdb</span></h3>
|
||||
|
||||
<p><a name="index-adding-debugging-info-reader-158"></a>If you are using an existing object file format (<code>a.out</code>, COFF, ELF, etc),
|
||||
there is probably little to be done.
|
||||
|
||||
<p>If you need to add a new object file format, you must first add it to
|
||||
BFD. This is beyond the scope of this document.
|
||||
|
||||
<p>You must then arrange for the BFD code to provide access to the
|
||||
debugging symbols. Generally <span class="sc">gdb</span> will have to call swapping
|
||||
routines from BFD and a few other BFD internal routines to locate the
|
||||
debugging information. As much as possible, <span class="sc">gdb</span> should not
|
||||
depend on the BFD internal data structures.
|
||||
|
||||
<p>For some targets (e.g., COFF), there is a special transfer vector used
|
||||
to call swapping routines, since the external data structures on various
|
||||
platforms have different sizes and layouts. Specialized routines that
|
||||
will only ever be implemented by one object file format may be called
|
||||
directly. This interface should be described in a file
|
||||
<samp><span class="file">bfd/lib</span><var>xyz</var><span class="file">.h</span></samp>, which is included by <span class="sc">gdb</span>.
|
||||
|
||||
<h3 class="section">8.7 Memory Management for Symbol Files</h3>
|
||||
|
||||
<p>Most memory associated with a loaded symbol file is stored on
|
||||
its <code>objfile_obstack</code>. This includes symbols, types,
|
||||
namespace data, and other information produced by the symbol readers.
|
||||
|
||||
<p>Because this data lives on the objfile's obstack, it is automatically
|
||||
released when the objfile is unloaded or reloaded. Therefore one
|
||||
objfile must not reference symbol or type data from another objfile;
|
||||
they could be unloaded at different times.
|
||||
|
||||
<p>User convenience variables, et cetera, have associated types. Normally
|
||||
these types live in the associated objfile. However, when the objfile
|
||||
is unloaded, those types are deep copied to global memory, so that
|
||||
the values of the user variables and history items are not lost.
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1 @@
|
|||
<meta http-equiv="refresh" content="0; url=Versions-and-Branches.html#Tags">
|
||||
|
|
@ -0,0 +1,70 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>Target Architecture Definition - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="prev" href="Host-Definition.html#Host-Definition" title="Host Definition">
|
||||
<link rel="next" href="Target-Descriptions.html#Target-Descriptions" title="Target Descriptions">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Target-Architecture-Definition"></a>
|
||||
Next: <a rel="next" accesskey="n" href="Target-Descriptions.html#Target-Descriptions">Target Descriptions</a>,
|
||||
Previous: <a rel="previous" accesskey="p" href="Host-Definition.html#Host-Definition">Host Definition</a>,
|
||||
Up: <a rel="up" accesskey="u" href="index.html#Top">Top</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h2 class="chapter">11 Target Architecture Definition</h2>
|
||||
|
||||
<p><a name="index-target-architecture-definition-192"></a><span class="sc">gdb</span>'s target architecture defines what sort of
|
||||
machine-language programs <span class="sc">gdb</span> can work with, and how it works
|
||||
with them.
|
||||
|
||||
<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 <samp><span class="file">gdbarch.sh</span></samp>.
|
||||
|
||||
<ul class="menu">
|
||||
<li><a accesskey="1" href="OS-ABI-Variant-Handling.html#OS-ABI-Variant-Handling">OS ABI Variant Handling</a>
|
||||
<li><a accesskey="2" href="Initialize-New-Architecture.html#Initialize-New-Architecture">Initialize New Architecture</a>
|
||||
<li><a accesskey="3" href="Registers-and-Memory.html#Registers-and-Memory">Registers and Memory</a>
|
||||
<li><a accesskey="4" href="Pointers-and-Addresses.html#Pointers-and-Addresses">Pointers and Addresses</a>
|
||||
<li><a accesskey="5" href="Address-Classes.html#Address-Classes">Address Classes</a>
|
||||
<li><a accesskey="6" href="Register-Representation.html#Register-Representation">Register Representation</a>
|
||||
<li><a accesskey="7" href="Frame-Interpretation.html#Frame-Interpretation">Frame Interpretation</a>
|
||||
<li><a accesskey="8" href="Inferior-Call-Setup.html#Inferior-Call-Setup">Inferior Call Setup</a>
|
||||
<li><a accesskey="9" href="Adding-support-for-debugging-core-files.html#Adding-support-for-debugging-core-files">Adding support for debugging core files</a>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">Defining Other Architecture Features</a>
|
||||
<li><a href="Adding-a-New-Target.html#Adding-a-New-Target">Adding a New Target</a>
|
||||
</ul>
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,69 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>Target Descriptions Implementation - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="up" href="Target-Descriptions.html#Target-Descriptions" title="Target Descriptions">
|
||||
<link rel="next" href="Adding-Target-Described-Register-Support.html#Adding-Target-Described-Register-Support" title="Adding Target Described Register Support">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Target-Descriptions-Implementation"></a>
|
||||
Next: <a rel="next" accesskey="n" href="Adding-Target-Described-Register-Support.html#Adding-Target-Described-Register-Support">Adding Target Described Register Support</a>,
|
||||
Up: <a rel="up" accesskey="u" href="Target-Descriptions.html#Target-Descriptions">Target Descriptions</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h3 class="section">12.1 Target Descriptions Implementation</h3>
|
||||
|
||||
<p><a name="index-target-descriptions_002c-implementation-435"></a>
|
||||
Before <span class="sc">gdb</span> connects to a new target, or runs a new program on
|
||||
an existing target, it discards any existing target description and
|
||||
reverts to a default gdbarch. Then, after connecting, it looks for a
|
||||
new target description by calling <code>target_find_description</code>.
|
||||
|
||||
<p>A description may come from a user specified file (XML), the remote
|
||||
‘<samp><span class="samp">qXfer:features:read</span></samp>’ packet (also XML), or from any custom
|
||||
<code>to_read_description</code> routine in the target vector. For instance,
|
||||
the remote target supports guessing whether a MIPS target is 32-bit or
|
||||
64-bit based on the size of the ‘<samp><span class="samp">g</span></samp>’ packet.
|
||||
|
||||
<p>If any target description is found, <span class="sc">gdb</span> creates a new gdbarch
|
||||
incorporating the description by calling <code>gdbarch_update_p</code>. Any
|
||||
‘<samp><span class="samp"><architecture></span></samp>’ element is handled first, to determine which
|
||||
architecture's gdbarch initialization routine is called to create the
|
||||
new architecture. Then the initialization routine is called, and has
|
||||
a chance to adjust the constructed architecture based on the contents
|
||||
of the target description. For instance, it can recognize any
|
||||
properties set by a <code>to_read_description</code> routine. Also
|
||||
see <a href="Adding-Target-Described-Register-Support.html#Adding-Target-Described-Register-Support">Adding Target Described Register Support</a>.
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,66 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>Target Descriptions - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="prev" href="Target-Architecture-Definition.html#Target-Architecture-Definition" title="Target Architecture Definition">
|
||||
<link rel="next" href="Target-Vector-Definition.html#Target-Vector-Definition" title="Target Vector Definition">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Target-Descriptions"></a>
|
||||
Next: <a rel="next" accesskey="n" href="Target-Vector-Definition.html#Target-Vector-Definition">Target Vector Definition</a>,
|
||||
Previous: <a rel="previous" accesskey="p" href="Target-Architecture-Definition.html#Target-Architecture-Definition">Target Architecture Definition</a>,
|
||||
Up: <a rel="up" accesskey="u" href="index.html#Top">Top</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h2 class="chapter">12 Target Descriptions</h2>
|
||||
|
||||
<p><a name="index-target-descriptions-434"></a>
|
||||
The target architecture definition (see <a href="Target-Architecture-Definition.html#Target-Architecture-Definition">Target Architecture Definition</a>)
|
||||
contains <span class="sc">gdb</span>'s hard-coded knowledge about an architecture. For
|
||||
some platforms, it is handy to have more flexible knowledge about a specific
|
||||
instance of the architecture—for instance, a processor or development board.
|
||||
<dfn>Target descriptions</dfn> provide a mechanism for the user to tell <span class="sc">gdb</span>
|
||||
more about what their target supports, or for the target to tell <span class="sc">gdb</span>
|
||||
directly.
|
||||
|
||||
<p>For details on writing, automatically supplying, and manually selecting
|
||||
target descriptions, see <a href="../gdb/Target-Descriptions.html#Target-Descriptions">Target Descriptions</a>. This section will cover some related
|
||||
topics about the <span class="sc">gdb</span> internals.
|
||||
|
||||
<ul class="menu">
|
||||
<li><a accesskey="1" href="Target-Descriptions-Implementation.html#Target-Descriptions-Implementation">Target Descriptions Implementation</a>
|
||||
<li><a accesskey="2" href="Adding-Target-Described-Register-Support.html#Adding-Target-Described-Register-Support">Adding Target Described Register Support</a>
|
||||
</ul>
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,60 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>Target Vector Definition - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="prev" href="Target-Descriptions.html#Target-Descriptions" title="Target Descriptions">
|
||||
<link rel="next" href="Native-Debugging.html#Native-Debugging" title="Native Debugging">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Target-Vector-Definition"></a>
|
||||
Next: <a rel="next" accesskey="n" href="Native-Debugging.html#Native-Debugging">Native Debugging</a>,
|
||||
Previous: <a rel="previous" accesskey="p" href="Target-Descriptions.html#Target-Descriptions">Target Descriptions</a>,
|
||||
Up: <a rel="up" accesskey="u" href="index.html#Top">Top</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h2 class="chapter">13 Target Vector Definition</h2>
|
||||
|
||||
<p><a name="index-target-vector-437"></a>
|
||||
The target vector defines the interface between <span class="sc">gdb</span>'s
|
||||
abstract handling of target systems, and the nitty-gritty code that
|
||||
actually exercises control over a process or a serial port.
|
||||
<span class="sc">gdb</span> includes some 30-40 different target vectors; however,
|
||||
each configuration of <span class="sc">gdb</span> includes only a few of them.
|
||||
|
||||
<ul class="menu">
|
||||
<li><a accesskey="1" href="Managing-Execution-State.html#Managing-Execution-State">Managing Execution State</a>
|
||||
<li><a accesskey="2" href="Existing-Targets.html#Existing-Targets">Existing Targets</a>
|
||||
</ul>
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,393 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>Testsuite - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="prev" href="Releasing-GDB.html#Releasing-GDB" title="Releasing GDB">
|
||||
<link rel="next" href="Hints.html#Hints" title="Hints">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Testsuite"></a>
|
||||
Next: <a rel="next" accesskey="n" href="Hints.html#Hints">Hints</a>,
|
||||
Previous: <a rel="previous" accesskey="p" href="Releasing-GDB.html#Releasing-GDB">Releasing GDB</a>,
|
||||
Up: <a rel="up" accesskey="u" href="index.html#Top">Top</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h2 class="chapter">22 Testsuite</h2>
|
||||
|
||||
<p><a name="index-test-suite-492"></a>
|
||||
The testsuite is an important component of the <span class="sc">gdb</span> package.
|
||||
While it is always worthwhile to encourage user testing, in practice
|
||||
this is rarely sufficient; users typically use only a small subset of
|
||||
the available commands, and it has proven all too common for a change
|
||||
to cause a significant regression that went unnoticed for some time.
|
||||
|
||||
<p>The <span class="sc">gdb</span> testsuite uses the DejaGNU testing framework. The
|
||||
tests themselves are calls to various <code>Tcl</code> procs; the framework
|
||||
runs all the procs and summarizes the passes and fails.
|
||||
|
||||
<h3 class="section">22.1 Using the Testsuite</h3>
|
||||
|
||||
<p><a name="index-running-the-test-suite-493"></a>To run the testsuite, simply go to the <span class="sc">gdb</span> object directory (or to the
|
||||
testsuite's objdir) and type <code>make check</code>. This just sets up some
|
||||
environment variables and invokes DejaGNU's <code>runtest</code> script. While
|
||||
the testsuite is running, you'll get mentions of which test file is in use,
|
||||
and a mention of any unexpected passes or fails. When the testsuite is
|
||||
finished, you'll get a summary that looks like this:
|
||||
|
||||
<pre class="smallexample"> === gdb Summary ===
|
||||
|
||||
# of expected passes 6016
|
||||
# of unexpected failures 58
|
||||
# of unexpected successes 5
|
||||
# of expected failures 183
|
||||
# of unresolved testcases 3
|
||||
# of untested testcases 5
|
||||
</pre>
|
||||
<p>To run a specific test script, type:
|
||||
<pre class="example"> make check RUNTESTFLAGS='<var>tests</var>'
|
||||
</pre>
|
||||
<p>where <var>tests</var> is a list of test script file names, separated by
|
||||
spaces.
|
||||
|
||||
<p>If you use GNU make, you can use its <samp><span class="option">-j</span></samp> option to run the
|
||||
testsuite in parallel. This can greatly reduce the amount of time it
|
||||
takes for the testsuite to run. In this case, if you set
|
||||
<code>RUNTESTFLAGS</code> then, by default, the tests will be run serially
|
||||
even under <samp><span class="option">-j</span></samp>. You can override this and force a parallel run
|
||||
by setting the <code>make</code> variable <code>FORCE_PARALLEL</code> to any
|
||||
non-empty value. Note that the parallel <kbd>make check</kbd> assumes
|
||||
that you want to run the entire testsuite, so it is not compatible
|
||||
with some dejagnu options, like <samp><span class="option">--directory</span></samp>.
|
||||
|
||||
<p>The ideal test run consists of expected passes only; however, reality
|
||||
conspires to keep us from this ideal. Unexpected failures indicate
|
||||
real problems, whether in <span class="sc">gdb</span> or in the testsuite. Expected
|
||||
failures are still failures, but ones which have been decided are too
|
||||
hard to deal with at the time; for instance, a test case might work
|
||||
everywhere except on AIX, and there is no prospect of the AIX case
|
||||
being fixed in the near future. Expected failures should not be added
|
||||
lightly, since you may be masking serious bugs in <span class="sc">gdb</span>.
|
||||
Unexpected successes are expected fails that are passing for some
|
||||
reason, while unresolved and untested cases often indicate some minor
|
||||
catastrophe, such as the compiler being unable to deal with a test
|
||||
program.
|
||||
|
||||
<p>When making any significant change to <span class="sc">gdb</span>, you should run the
|
||||
testsuite before and after the change, to confirm that there are no
|
||||
regressions. Note that truly complete testing would require that you
|
||||
run the testsuite with all supported configurations and a variety of
|
||||
compilers; however this is more than really necessary. In many cases
|
||||
testing with a single configuration is sufficient. Other useful
|
||||
options are to test one big-endian (Sparc) and one little-endian (x86)
|
||||
host, a cross config with a builtin simulator (powerpc-eabi,
|
||||
mips-elf), or a 64-bit host (Alpha).
|
||||
|
||||
<p>If you add new functionality to <span class="sc">gdb</span>, please consider adding
|
||||
tests for it as well; this way future <span class="sc">gdb</span> hackers can detect
|
||||
and fix their changes that break the functionality you added.
|
||||
Similarly, if you fix a bug that was not previously reported as a test
|
||||
failure, please add a test case for it. Some cases are extremely
|
||||
difficult to test, such as code that handles host OS failures or bugs
|
||||
in particular versions of compilers, and it's OK not to try to write
|
||||
tests for all of those.
|
||||
|
||||
<p>DejaGNU supports separate build, host, and target machines. However,
|
||||
some <span class="sc">gdb</span> test scripts do not work if the build machine and
|
||||
the host machine are not the same. In such an environment, these scripts
|
||||
will give a result of “UNRESOLVED”, like this:
|
||||
|
||||
<pre class="smallexample"> UNRESOLVED: gdb.base/example.exp: This test script does not work on a remote host.
|
||||
</pre>
|
||||
<h3 class="section">22.2 Testsuite Parameters</h3>
|
||||
|
||||
<p>Several variables exist to modify the behavior of the testsuite.
|
||||
|
||||
<ul>
|
||||
<li><code>TRANSCRIPT</code>
|
||||
|
||||
<p>Sometimes it is convenient to get a transcript of the commands which
|
||||
the testsuite sends to <span class="sc">gdb</span>. For example, if <span class="sc">gdb</span>
|
||||
crashes during testing, a transcript can be used to more easily
|
||||
reconstruct the failure when running <span class="sc">gdb</span> under <span class="sc">gdb</span>.
|
||||
|
||||
<p>You can instruct the <span class="sc">gdb</span> testsuite to write transcripts by
|
||||
setting the DejaGNU variable <code>TRANSCRIPT</code> (to any value)
|
||||
before invoking <code>runtest</code> or <kbd>make check</kbd>. The transcripts
|
||||
will be written into DejaGNU's output directory. One transcript will
|
||||
be made for each invocation of <span class="sc">gdb</span>; they will be named
|
||||
<samp><span class="file">transcript.</span><var>n</var></samp>, where <var>n</var> is an integer. The first
|
||||
line of the transcript file will show how <span class="sc">gdb</span> was invoked;
|
||||
each subsequent line is a command sent as input to <span class="sc">gdb</span>.
|
||||
|
||||
<pre class="smallexample"> make check RUNTESTFLAGS=TRANSCRIPT=y
|
||||
</pre>
|
||||
<p>Note that the transcript is not always complete. In particular, tests
|
||||
of completion can yield partial command lines.
|
||||
|
||||
<li><code>GDB</code>
|
||||
|
||||
<p>Sometimes one wishes to test a different <span class="sc">gdb</span> than the one in the build
|
||||
directory. For example, one may wish to run the testsuite on
|
||||
<samp><span class="file">/usr/bin/gdb</span></samp>.
|
||||
|
||||
<pre class="smallexample"> make check RUNTESTFLAGS=GDB=/usr/bin/gdb
|
||||
</pre>
|
||||
<li><code>GDBSERVER</code>
|
||||
|
||||
<p>When testing a different <span class="sc">gdb</span>, it is often useful to also test a
|
||||
different gdbserver.
|
||||
|
||||
<pre class="smallexample"> make check RUNTESTFLAGS="GDB=/usr/bin/gdb GDBSERVER=/usr/bin/gdbserver"
|
||||
</pre>
|
||||
<li><code>INTERNAL_GDBFLAGS</code>
|
||||
|
||||
<p>When running the testsuite normally one doesn't want whatever is in
|
||||
<samp><span class="file">~/.gdbinit</span></samp> to interfere with the tests, therefore the test harness
|
||||
passes <samp><span class="option">-nx</span></samp> to <span class="sc">gdb</span>. One also doesn't want any windowed
|
||||
version of <span class="sc">gdb</span>, e.g., ‘<samp><span class="samp">gdb -tui</span></samp>’, to run.
|
||||
This is achieved via <code>INTERNAL_GDBFLAGS</code>.
|
||||
|
||||
<pre class="smallexample"> set INTERNAL_GDBFLAGS "-nw -nx"
|
||||
</pre>
|
||||
<p>This is all well and good, except when testing an installed <span class="sc">gdb</span>
|
||||
that has been configured with <samp><span class="option">--with-system-gdbinit</span></samp>. Here one
|
||||
does not want <samp><span class="file">~/.gdbinit</span></samp> loaded but one may want the system
|
||||
<samp><span class="file">.gdbinit</span></samp> file loaded. This can be achieved by pointing <code>$HOME</code>
|
||||
at a directory without a <samp><span class="file">.gdbinit</span></samp> and by overriding
|
||||
<code>INTERNAL_GDBFLAGS</code> and removing <samp><span class="option">-nx</span></samp>.
|
||||
|
||||
<pre class="smallexample"> cd testsuite
|
||||
HOME=`pwd` runtest \
|
||||
GDB=/usr/bin/gdb \
|
||||
GDBSERVER=/usr/bin/gdbserver \
|
||||
INTERNAL_GDBFLAGS=-nw
|
||||
</pre>
|
||||
</ul>
|
||||
|
||||
<p>There are two ways to run the testsuite and pass additional parameters
|
||||
to DejaGnu. The first is with <kbd>make check</kbd> and specifying the
|
||||
makefile variable ‘<samp><span class="samp">RUNTESTFLAGS</span></samp>’.
|
||||
|
||||
<pre class="smallexample"> make check RUNTESTFLAGS=TRANSCRIPT=y
|
||||
</pre>
|
||||
<p>The second is to cd to the <samp><span class="file">testsuite</span></samp> directory and invoke the DejaGnu
|
||||
<samp><span class="command">runtest</span></samp> command directly.
|
||||
|
||||
<pre class="smallexample"> cd testsuite
|
||||
make site.exp
|
||||
runtest TRANSCRIPT=y
|
||||
</pre>
|
||||
<h3 class="section">22.3 Testsuite Configuration</h3>
|
||||
|
||||
<p><a name="index-Testsuite-Configuration-494"></a>
|
||||
It is possible to adjust the behavior of the testsuite by defining
|
||||
the global variables listed below, either in a <samp><span class="file">site.exp</span></samp> file,
|
||||
or in a board file.
|
||||
|
||||
<ul>
|
||||
<li><code>gdb_test_timeout</code>
|
||||
|
||||
<p>Defining this variable changes the default timeout duration used during
|
||||
communication with <span class="sc">gdb</span>. More specifically, the global variable
|
||||
used during testing is <code>timeout</code>, but this variable gets reset to
|
||||
<code>gdb_test_timeout</code> at the beginning of each testcase, making sure
|
||||
that any local change to <code>timeout</code> in a testcase does not affect
|
||||
subsequent testcases.
|
||||
|
||||
<p>This global variable comes in handy when the debugger is slower than
|
||||
normal due to the testing environment, triggering unexpected <code>TIMEOUT</code>
|
||||
test failures. Examples include when testing on a remote machine, or
|
||||
against a system where communications are slow.
|
||||
|
||||
<p>If not specifically defined, this variable gets automatically defined
|
||||
to the same value as <code>timeout</code> during the testsuite initialization.
|
||||
The default value of the timeout is defined in the file
|
||||
<samp><span class="file">gdb/testsuite/config/unix.exp</span></samp> that is part of the <span class="sc">gdb</span>
|
||||
test suite<a rel="footnote" href="#fn-1" name="fnd-1"><sup>1</sup></a>.
|
||||
|
||||
</ul>
|
||||
|
||||
<h3 class="section">22.4 Testsuite Organization</h3>
|
||||
|
||||
<p><a name="index-test-suite-organization-495"></a>The testsuite is entirely contained in <samp><span class="file">gdb/testsuite</span></samp>. While the
|
||||
testsuite includes some makefiles and configury, these are very minimal,
|
||||
and used for little besides cleaning up, since the tests themselves
|
||||
handle the compilation of the programs that <span class="sc">gdb</span> will run. The file
|
||||
<samp><span class="file">testsuite/lib/gdb.exp</span></samp> contains common utility procs useful for
|
||||
all <span class="sc">gdb</span> tests, while the directory <samp><span class="file">testsuite/config</span></samp> contains
|
||||
configuration-specific files, typically used for special-purpose
|
||||
definitions of procs like <code>gdb_load</code> and <code>gdb_start</code>.
|
||||
|
||||
<p>The tests themselves are to be found in <samp><span class="file">testsuite/gdb.*</span></samp> and
|
||||
subdirectories of those. The names of the test files must always end
|
||||
with <samp><span class="file">.exp</span></samp>. DejaGNU collects the test files by wildcarding
|
||||
in the test directories, so both subdirectories and individual files
|
||||
get chosen and run in alphabetical order.
|
||||
|
||||
<p>The following table lists the main types of subdirectories and what they
|
||||
are for. Since DejaGNU finds test files no matter where they are
|
||||
located, and since each test file sets up its own compilation and
|
||||
execution environment, this organization is simply for convenience and
|
||||
intelligibility.
|
||||
|
||||
<dl>
|
||||
<dt><samp><span class="file">gdb.base</span></samp><dd>This is the base testsuite. The tests in it should apply to all
|
||||
configurations of <span class="sc">gdb</span> (but generic native-only tests may live here).
|
||||
The test programs should be in the subset of C that is valid K&R,
|
||||
ANSI/ISO, and C<tt>++</tt> (<code>#ifdef</code>s are allowed if necessary, for instance
|
||||
for prototypes).
|
||||
|
||||
<br><dt><samp><span class="file">gdb.</span><var>lang</var></samp><dd>Language-specific tests for any language <var>lang</var> besides C. Examples are
|
||||
<samp><span class="file">gdb.cp</span></samp> and <samp><span class="file">gdb.java</span></samp>.
|
||||
|
||||
<br><dt><samp><span class="file">gdb.</span><var>platform</var></samp><dd>Non-portable tests. The tests are specific to a specific configuration
|
||||
(host or target), such as HP-UX or eCos. Example is <samp><span class="file">gdb.hp</span></samp>, for
|
||||
HP-UX.
|
||||
|
||||
<br><dt><samp><span class="file">gdb.</span><var>compiler</var></samp><dd>Tests specific to a particular compiler. As of this writing (June
|
||||
1999), there aren't currently any groups of tests in this category that
|
||||
couldn't just as sensibly be made platform-specific, but one could
|
||||
imagine a <samp><span class="file">gdb.gcc</span></samp>, for tests of <span class="sc">gdb</span>'s handling of GCC
|
||||
extensions.
|
||||
|
||||
<br><dt><samp><span class="file">gdb.</span><var>subsystem</var></samp><dd>Tests that exercise a specific <span class="sc">gdb</span> subsystem in more depth. For
|
||||
instance, <samp><span class="file">gdb.disasm</span></samp> exercises various disassemblers, while
|
||||
<samp><span class="file">gdb.stabs</span></samp> tests pathways through the stabs symbol reader.
|
||||
</dl>
|
||||
|
||||
<h3 class="section">22.5 Writing Tests</h3>
|
||||
|
||||
<p><a name="index-writing-tests-496"></a>
|
||||
In many areas, the <span class="sc">gdb</span> tests are already quite comprehensive; you
|
||||
should be able to copy existing tests to handle new cases.
|
||||
|
||||
<p>You should try to use <code>gdb_test</code> whenever possible, since it
|
||||
includes cases to handle all the unexpected errors that might happen.
|
||||
However, it doesn't cost anything to add new test procedures; for
|
||||
instance, <samp><span class="file">gdb.base/exprs.exp</span></samp> defines a <code>test_expr</code> that
|
||||
calls <code>gdb_test</code> multiple times.
|
||||
|
||||
<p>Only use <code>send_gdb</code> and <code>gdb_expect</code> when absolutely
|
||||
necessary. Even if <span class="sc">gdb</span> has several valid responses to
|
||||
a command, you can use <code>gdb_test_multiple</code>. Like <code>gdb_test</code>,
|
||||
<code>gdb_test_multiple</code> recognizes internal errors and unexpected
|
||||
prompts.
|
||||
|
||||
<p>Do not write tests which expect a literal tab character from <span class="sc">gdb</span>.
|
||||
On some operating systems (e.g. OpenBSD) the TTY layer expands tabs to
|
||||
spaces, so by the time <span class="sc">gdb</span>'s output reaches expect the tab is gone.
|
||||
|
||||
<p>The source language programs do <em>not</em> need to be in a consistent
|
||||
style. Since <span class="sc">gdb</span> is used to debug programs written in many different
|
||||
styles, it's worth having a mix of styles in the testsuite; for
|
||||
instance, some <span class="sc">gdb</span> bugs involving the display of source lines would
|
||||
never manifest themselves if the programs used GNU coding style
|
||||
uniformly.
|
||||
|
||||
<p>Some testcase results need more detailed explanation:
|
||||
|
||||
<dl>
|
||||
<dt><code>KFAIL</code><dd>Known problem of <span class="sc">gdb</span> itself. You must specify the <span class="sc">gdb</span> bug
|
||||
report number like in these sample tests:
|
||||
<pre class="smallexample"> kfail "gdb/13392" "continue to marker 2"
|
||||
</pre>
|
||||
<p>or
|
||||
<pre class="smallexample"> setup_kfail gdb/13392 "*-*-*"
|
||||
kfail "continue to marker 2"
|
||||
</pre>
|
||||
<br><dt><code>XFAIL</code><dd>Known problem of environment. This typically includes <span class="sc">gcc</span> but it
|
||||
includes also many other system components which cannot be fixed in the
|
||||
<span class="sc">gdb</span> project. Sample test with sanity check not knowing the specific
|
||||
cause of the problem:
|
||||
<pre class="smallexample"> # On x86_64 it is commonly about 4MB.
|
||||
if {$stub_size > 25000000} {
|
||||
xfail "stub size $stub_size is too large"
|
||||
return
|
||||
}
|
||||
</pre>
|
||||
<p>You should provide bug report number for the failing component of the
|
||||
environment, if such bug report is available:
|
||||
<pre class="smallexample"> if {[test_compiler_info {gcc-[0-3]-*}]
|
||||
|| [test_compiler_info {gcc-4-[0-5]-*}]} {
|
||||
setup_xfail "gcc/46955" *-*-*
|
||||
}
|
||||
gdb_test "python print ttype.template_argument(2)" "&C::c"
|
||||
</pre>
|
||||
</dl>
|
||||
|
||||
<h3 class="section">22.6 Board settings</h3>
|
||||
|
||||
<p>In <span class="sc">gdb</span> testsuite, the tests can be configured or customized in the board
|
||||
file by means of <dfn>Board Settings</dfn>. Each setting should be consulted by
|
||||
test cases that depend on the corresponding feature.
|
||||
|
||||
<p>Here are the supported board settings:
|
||||
|
||||
<dl>
|
||||
<dt><code>gdb,cannot_call_functions</code><dd>The board does not support inferior call, that is, invoking inferior functions
|
||||
in <span class="sc">gdb</span>.
|
||||
<br><dt><code>gdb,can_reverse</code><dd>The board supports reverse execution.
|
||||
<br><dt><code>gdb,no_hardware_watchpoints</code><dd>The board does not support hardware watchpoints.
|
||||
<br><dt><code>gdb,nofileio</code><dd><span class="sc">gdb</span> is unable to intercept target file operations in remote and perform
|
||||
them on the host.
|
||||
<br><dt><code>gdb,noinferiorio</code><dd>The board is unable to provide I/O capability to the inferior.
|
||||
<!-- @item gdb,noresults -->
|
||||
<!-- NEED DOCUMENT. -->
|
||||
<br><dt><code>gdb,nosignals</code><dd>The board does not support signals.
|
||||
<br><dt><code>gdb,skip_huge_test</code><dd>Skip time-consuming tests on the board with slow connection.
|
||||
<br><dt><code>gdb,skip_float_tests</code><dd>Skip tests related to float points on target board.
|
||||
<br><dt><code>gdb,use_precord</code><dd>The board supports process record.
|
||||
<br><dt><code>gdb_server_prog</code><dd>The location of GDBserver. If GDBserver somewhere other than its default
|
||||
location is used in test, specify the location of GDBserver in this variable.
|
||||
The location is a file name of GDBserver that can be either absolute or
|
||||
relative to testsuite subdirectory in build directory.
|
||||
<br><dt><code>in_proc_agent</code><dd>The location of in-process agent. If in-process agent other than its default
|
||||
location is used in test, specify the location of in-process agent in
|
||||
this variable. The location is a file name of in-process agent that can be
|
||||
either absolute or relative to testsuite subdirectory in build directory.
|
||||
<br><dt><code>noargs</code><dd><span class="sc">gdb</span> does not support argument passing for inferior.
|
||||
<br><dt><code>no_long_long</code><dd>The board does not support type <code>long long</code>.
|
||||
<!-- @item use_cygmon -->
|
||||
<!-- NEED DOCUMENT. -->
|
||||
<br><dt><code>use_gdb_stub</code><dd>The tests are running with gdb stub.
|
||||
</dl>
|
||||
|
||||
<div class="footnote">
|
||||
<hr>
|
||||
<h4>Footnotes</h4><p class="footnote"><small>[<a name="fn-1" href="#fnd-1">1</a>]</small> If you are using a board file, it could override
|
||||
the test-suite default; search the board file for "timeout".</p>
|
||||
|
||||
<hr></div>
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1 @@
|
|||
<meta http-equiv="refresh" content="0; url=User-Interface.html#UI%2dIndependent%20Output">
|
||||
|
|
@ -0,0 +1,686 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>User Interface - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="prev" href="Algorithms.html#Algorithms" title="Algorithms">
|
||||
<link rel="next" href="libgdb.html#libgdb" title="libgdb">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="User-Interface"></a>
|
||||
Next: <a rel="next" accesskey="n" href="libgdb.html#libgdb">libgdb</a>,
|
||||
Previous: <a rel="previous" accesskey="p" href="Algorithms.html#Algorithms">Algorithms</a>,
|
||||
Up: <a rel="up" accesskey="u" href="index.html#Top">Top</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h2 class="chapter">4 User Interface</h2>
|
||||
|
||||
<p><span class="sc">gdb</span> has several user interfaces, of which the traditional
|
||||
command-line interface is perhaps the most familiar.
|
||||
|
||||
<h3 class="section">4.1 Command Interpreter</h3>
|
||||
|
||||
<p><a name="index-command-interpreter-58"></a><a name="index-CLI-59"></a>The command interpreter in <span class="sc">gdb</span> is fairly simple. It is designed to
|
||||
allow for the set of commands to be augmented dynamically, and also
|
||||
has a recursive subcommand capability, where the first argument to
|
||||
a command may itself direct a lookup on a different command list.
|
||||
|
||||
<p>For instance, the ‘<samp><span class="samp">set</span></samp>’ command just starts a lookup on the
|
||||
<code>setlist</code> command list, while ‘<samp><span class="samp">set thread</span></samp>’ recurses
|
||||
to the <code>set_thread_cmd_list</code>.
|
||||
|
||||
<p><a name="index-add_005fcmd-60"></a><a name="index-add_005fcom-61"></a>To add commands in general, use <code>add_cmd</code>. <code>add_com</code> adds to
|
||||
the main command list, and should be used for those commands. The usual
|
||||
place to add commands is in the <code>_initialize_</code><var>xyz</var> routines at
|
||||
the ends of most source files.
|
||||
|
||||
<p><a name="index-add_005fsetshow_005fcmd-62"></a><a name="index-add_005fsetshow_005fcmd_005ffull-63"></a>To add paired ‘<samp><span class="samp">set</span></samp>’ and ‘<samp><span class="samp">show</span></samp>’ commands, use
|
||||
<code>add_setshow_cmd</code> or <code>add_setshow_cmd_full</code>. The former is
|
||||
a slightly simpler interface which is useful when you don't need to
|
||||
further modify the new command structures, while the latter returns
|
||||
the new command structures for manipulation.
|
||||
|
||||
<p><a name="index-deprecating-commands-64"></a><a name="index-deprecate_005fcmd-65"></a>Before removing commands from the command set it is a good idea to
|
||||
deprecate them for some time. Use <code>deprecate_cmd</code> on commands or
|
||||
aliases to set the deprecated flag. <code>deprecate_cmd</code> takes a
|
||||
<code>struct cmd_list_element</code> as it's first argument. You can use the
|
||||
return value from <code>add_com</code> or <code>add_cmd</code> to deprecate the
|
||||
command immediately after it is created.
|
||||
|
||||
<p>The first time a command is used the user will be warned and offered a
|
||||
replacement (if one exists). Note that the replacement string passed to
|
||||
<code>deprecate_cmd</code> should be the full name of the command, i.e., the
|
||||
entire string the user should type at the command line.
|
||||
|
||||
<p><a name="UI_002dIndependent-Output"></a>
|
||||
|
||||
<h3 class="section">4.2 UI-Independent Output—the <code>ui_out</code> Functions</h3>
|
||||
|
||||
<!-- This section is based on the documentation written by Fernando -->
|
||||
<!-- Nasser <fnasser@redhat.com>. -->
|
||||
<p><a name="index-g_t_0040code_007bui_005fout_007d-functions-66"></a>The <code>ui_out</code> functions present an abstraction level for the
|
||||
<span class="sc">gdb</span> output code. They hide the specifics of different user
|
||||
interfaces supported by <span class="sc">gdb</span>, and thus free the programmer
|
||||
from the need to write several versions of the same code, one each for
|
||||
every UI, to produce output.
|
||||
|
||||
<h4 class="subsection">4.2.1 Overview and Terminology</h4>
|
||||
|
||||
<p>In general, execution of each <span class="sc">gdb</span> command produces some sort
|
||||
of output, and can even generate an input request.
|
||||
|
||||
<p>Output can be generated for the following purposes:
|
||||
|
||||
<ul>
|
||||
<li>to display a <em>result</em> of an operation;
|
||||
|
||||
<li>to convey <em>info</em> or produce side-effects of a requested
|
||||
operation;
|
||||
|
||||
<li>to provide a <em>notification</em> of an asynchronous event (including
|
||||
progress indication of a prolonged asynchronous operation);
|
||||
|
||||
<li>to display <em>error messages</em> (including warnings);
|
||||
|
||||
<li>to show <em>debug data</em>;
|
||||
|
||||
<li>to <em>query</em> or prompt a user for input (a special case).
|
||||
</ul>
|
||||
|
||||
<p class="noindent">This section mainly concentrates on how to build result output,
|
||||
although some of it also applies to other kinds of output.
|
||||
|
||||
<p>Generation of output that displays the results of an operation
|
||||
involves one or more of the following:
|
||||
|
||||
<ul>
|
||||
<li>output of the actual data
|
||||
|
||||
<li>formatting the output as appropriate for console output, to make it
|
||||
easily readable by humans
|
||||
|
||||
<li>machine oriented formatting–a more terse formatting to allow for easy
|
||||
parsing by programs which read <span class="sc">gdb</span>'s output
|
||||
|
||||
<li>annotation, whose purpose is to help legacy GUIs to identify interesting
|
||||
parts in the output
|
||||
</ul>
|
||||
|
||||
<p>The <code>ui_out</code> routines take care of the first three aspects.
|
||||
Annotations are provided by separate annotation routines. Note that use
|
||||
of annotations for an interface between a GUI and <span class="sc">gdb</span> is
|
||||
deprecated.
|
||||
|
||||
<p>Output can be in the form of a single item, which we call a <dfn>field</dfn>;
|
||||
a <dfn>list</dfn> consisting of identical fields; a <dfn>tuple</dfn> consisting of
|
||||
non-identical fields; or a <dfn>table</dfn>, which is a tuple consisting of a
|
||||
header and a body. In a BNF-like form:
|
||||
|
||||
<dl>
|
||||
<dt><code><table> ==></code><dd><code><header> <body></code>
|
||||
<br><dt><code><header> ==></code><dd><code>{ <column> }</code>
|
||||
<br><dt><code><column> ==></code><dd><code><width> <alignment> <title></code>
|
||||
<br><dt><code><body> ==></code><dd><code>{<row>}</code>
|
||||
</dl>
|
||||
|
||||
<h4 class="subsection">4.2.2 General Conventions</h4>
|
||||
|
||||
<p>Most <code>ui_out</code> routines are of type <code>void</code>, the exceptions are
|
||||
<code>ui_out_stream_new</code> (which returns a pointer to the newly created
|
||||
object) and the <code>make_cleanup</code> routines.
|
||||
|
||||
<p>The first parameter is always the <code>ui_out</code> vector object, a pointer
|
||||
to a <code>struct ui_out</code>.
|
||||
|
||||
<p>The <var>format</var> parameter is like in <code>printf</code> family of functions.
|
||||
When it is present, there must also be a variable list of arguments
|
||||
sufficient used to satisfy the <code>%</code> specifiers in the supplied
|
||||
format.
|
||||
|
||||
<p>When a character string argument is not used in a <code>ui_out</code> function
|
||||
call, a <code>NULL</code> pointer has to be supplied instead.
|
||||
|
||||
<h4 class="subsection">4.2.3 Table, Tuple and List Functions</h4>
|
||||
|
||||
<p><a name="index-list-output-functions-67"></a><a name="index-table-output-functions-68"></a><a name="index-tuple-output-functions-69"></a>This section introduces <code>ui_out</code> routines for building lists,
|
||||
tuples and tables. The routines to output the actual data items
|
||||
(fields) are presented in the next section.
|
||||
|
||||
<p>To recap: A <dfn>tuple</dfn> is a sequence of <dfn>fields</dfn>, each field
|
||||
containing information about an object; a <dfn>list</dfn> is a sequence of
|
||||
fields where each field describes an identical object.
|
||||
|
||||
<p>Use the <dfn>table</dfn> functions when your output consists of a list of
|
||||
rows (tuples) and the console output should include a heading. Use this
|
||||
even when you are listing just one object but you still want the header.
|
||||
|
||||
<p><a name="index-nesting-level-in-_0040code_007bui_005fout_007d-functions-70"></a>Tables can not be nested. Tuples and lists can be nested up to a
|
||||
maximum of five levels.
|
||||
|
||||
<p>The overall structure of the table output code is something like this:
|
||||
|
||||
<pre class="smallexample"> ui_out_table_begin
|
||||
ui_out_table_header
|
||||
...
|
||||
ui_out_table_body
|
||||
ui_out_tuple_begin
|
||||
ui_out_field_*
|
||||
...
|
||||
ui_out_tuple_end
|
||||
...
|
||||
ui_out_table_end
|
||||
</pre>
|
||||
<p>Here is the description of table-, tuple- and list-related <code>ui_out</code>
|
||||
functions:
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>ui_out_table_begin</b> (<var>struct ui_out *uiout, int nbrofcols, int nr_rows, const char *tblid</var>)<var><a name="index-ui_005fout_005ftable_005fbegin-71"></a></var><br>
|
||||
<blockquote><p>The function <code>ui_out_table_begin</code> marks the beginning of the output
|
||||
of a table. It should always be called before any other <code>ui_out</code>
|
||||
function for a given table. <var>nbrofcols</var> is the number of columns in
|
||||
the table. <var>nr_rows</var> is the number of rows in the table.
|
||||
<var>tblid</var> is an optional string identifying the table. The string
|
||||
pointed to by <var>tblid</var> is copied by the implementation of
|
||||
<code>ui_out_table_begin</code>, so the application can free the string if it
|
||||
was <code>malloc</code>ed.
|
||||
|
||||
<p>The companion function <code>ui_out_table_end</code>, described below, marks
|
||||
the end of the table's output.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>ui_out_table_header</b> (<var>struct ui_out *uiout, int width, enum ui_align alignment, const char *colhdr</var>)<var><a name="index-ui_005fout_005ftable_005fheader-72"></a></var><br>
|
||||
<blockquote><p><code>ui_out_table_header</code> provides the header information for a single
|
||||
table column. You call this function several times, one each for every
|
||||
column of the table, after <code>ui_out_table_begin</code>, but before
|
||||
<code>ui_out_table_body</code>.
|
||||
|
||||
<p>The value of <var>width</var> gives the column width in characters. The
|
||||
value of <var>alignment</var> is one of <code>left</code>, <code>center</code>, and
|
||||
<code>right</code>, and it specifies how to align the header: left-justify,
|
||||
center, or right-justify it. <var>colhdr</var> points to a string that
|
||||
specifies the column header; the implementation copies that string, so
|
||||
column header strings in <code>malloc</code>ed storage can be freed after the
|
||||
call.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>ui_out_table_body</b> (<var>struct ui_out *uiout</var>)<var><a name="index-ui_005fout_005ftable_005fbody-73"></a></var><br>
|
||||
<blockquote><p>This function delimits the table header from the table body.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>ui_out_table_end</b> (<var>struct ui_out *uiout</var>)<var><a name="index-ui_005fout_005ftable_005fend-74"></a></var><br>
|
||||
<blockquote><p>This function signals the end of a table's output. It should be called
|
||||
after the table body has been produced by the list and field output
|
||||
functions.
|
||||
|
||||
<p>There should be exactly one call to <code>ui_out_table_end</code> for each
|
||||
call to <code>ui_out_table_begin</code>, otherwise the <code>ui_out</code> functions
|
||||
will signal an internal error.
|
||||
</p></blockquote></div>
|
||||
|
||||
<p>The output of the tuples that represent the table rows must follow the
|
||||
call to <code>ui_out_table_body</code> and precede the call to
|
||||
<code>ui_out_table_end</code>. You build a tuple by calling
|
||||
<code>ui_out_tuple_begin</code> and <code>ui_out_tuple_end</code>, with suitable
|
||||
calls to functions which actually output fields between them.
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>ui_out_tuple_begin</b> (<var>struct ui_out *uiout, const char *id</var>)<var><a name="index-ui_005fout_005ftuple_005fbegin-75"></a></var><br>
|
||||
<blockquote><p>This function marks the beginning of a tuple output. <var>id</var> points
|
||||
to an optional string that identifies the tuple; it is copied by the
|
||||
implementation, and so strings in <code>malloc</code>ed storage can be freed
|
||||
after the call.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>ui_out_tuple_end</b> (<var>struct ui_out *uiout</var>)<var><a name="index-ui_005fout_005ftuple_005fend-76"></a></var><br>
|
||||
<blockquote><p>This function signals an end of a tuple output. There should be exactly
|
||||
one call to <code>ui_out_tuple_end</code> for each call to
|
||||
<code>ui_out_tuple_begin</code>, otherwise an internal <span class="sc">gdb</span> error will
|
||||
be signaled.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: struct cleanup * <b>make_cleanup_ui_out_tuple_begin_end</b> (<var>struct ui_out *uiout, const char *id</var>)<var><a name="index-make_005fcleanup_005fui_005fout_005ftuple_005fbegin_005fend-77"></a></var><br>
|
||||
<blockquote><p>This function first opens the tuple and then establishes a cleanup
|
||||
(see <a href="Misc-Guidelines.html#Misc-Guidelines">Cleanups</a>) to close the tuple.
|
||||
It provides a convenient and correct implementation of the
|
||||
non-portable<a rel="footnote" href="#fn-1" name="fnd-1"><sup>1</sup></a> code sequence:
|
||||
<pre class="smallexample"> struct cleanup *old_cleanup;
|
||||
ui_out_tuple_begin (uiout, "...");
|
||||
old_cleanup = make_cleanup ((void(*)(void *)) ui_out_tuple_end,
|
||||
uiout);
|
||||
</pre>
|
||||
</blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>ui_out_list_begin</b> (<var>struct ui_out *uiout, const char *id</var>)<var><a name="index-ui_005fout_005flist_005fbegin-78"></a></var><br>
|
||||
<blockquote><p>This function marks the beginning of a list output. <var>id</var> points to
|
||||
an optional string that identifies the list; it is copied by the
|
||||
implementation, and so strings in <code>malloc</code>ed storage can be freed
|
||||
after the call.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>ui_out_list_end</b> (<var>struct ui_out *uiout</var>)<var><a name="index-ui_005fout_005flist_005fend-79"></a></var><br>
|
||||
<blockquote><p>This function signals an end of a list output. There should be exactly
|
||||
one call to <code>ui_out_list_end</code> for each call to
|
||||
<code>ui_out_list_begin</code>, otherwise an internal <span class="sc">gdb</span> error will
|
||||
be signaled.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: struct cleanup * <b>make_cleanup_ui_out_list_begin_end</b> (<var>struct ui_out *uiout, const char *id</var>)<var><a name="index-make_005fcleanup_005fui_005fout_005flist_005fbegin_005fend-80"></a></var><br>
|
||||
<blockquote><p>Similar to <code>make_cleanup_ui_out_tuple_begin_end</code>, this function
|
||||
opens a list and then establishes cleanup
|
||||
(see <a href="Misc-Guidelines.html#Misc-Guidelines">Cleanups</a>)
|
||||
that will close the list.
|
||||
</p></blockquote></div>
|
||||
|
||||
<h4 class="subsection">4.2.4 Item Output Functions</h4>
|
||||
|
||||
<p><a name="index-item-output-functions-81"></a><a name="index-field-output-functions-82"></a><a name="index-data-output-83"></a>The functions described below produce output for the actual data
|
||||
items, or fields, which contain information about the object.
|
||||
|
||||
<p>Choose the appropriate function accordingly to your particular needs.
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>ui_out_field_fmt</b> (<var>struct ui_out *uiout, char *fldname, char *format, ...</var>)<var><a name="index-ui_005fout_005ffield_005ffmt-84"></a></var><br>
|
||||
<blockquote><p>This is the most general output function. It produces the
|
||||
representation of the data in the variable-length argument list
|
||||
according to formatting specifications in <var>format</var>, a
|
||||
<code>printf</code>-like format string. The optional argument <var>fldname</var>
|
||||
supplies the name of the field. The data items themselves are
|
||||
supplied as additional arguments after <var>format</var>.
|
||||
|
||||
<p>This generic function should be used only when it is not possible to
|
||||
use one of the specialized versions (see below).
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>ui_out_field_int</b> (<var>struct ui_out *uiout, const char *fldname, int value</var>)<var><a name="index-ui_005fout_005ffield_005fint-85"></a></var><br>
|
||||
<blockquote><p>This function outputs a value of an <code>int</code> variable. It uses the
|
||||
<code>"%d"</code> output conversion specification. <var>fldname</var> specifies
|
||||
the name of the field.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>ui_out_field_fmt_int</b> (<var>struct ui_out *uiout, int width, enum ui_align alignment, const char *fldname, int value</var>)<var><a name="index-ui_005fout_005ffield_005ffmt_005fint-86"></a></var><br>
|
||||
<blockquote><p>This function outputs a value of an <code>int</code> variable. It differs from
|
||||
<code>ui_out_field_int</code> in that the caller specifies the desired <var>width</var> and <var>alignment</var> of the output.
|
||||
<var>fldname</var> specifies
|
||||
the name of the field.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>ui_out_field_core_addr</b> (<var>struct ui_out *uiout, const char *fldname, struct gdbarch *gdbarch, CORE_ADDR address</var>)<var><a name="index-ui_005fout_005ffield_005fcore_005faddr-87"></a></var><br>
|
||||
<blockquote><p>This function outputs an address as appropriate for <var>gdbarch</var>.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>ui_out_field_string</b> (<var>struct ui_out *uiout, const char *fldname, const char *string</var>)<var><a name="index-ui_005fout_005ffield_005fstring-88"></a></var><br>
|
||||
<blockquote><p>This function outputs a string using the <code>"%s"</code> conversion
|
||||
specification.
|
||||
</p></blockquote></div>
|
||||
|
||||
<p>Sometimes, there's a need to compose your output piece by piece using
|
||||
functions that operate on a stream, such as <code>value_print</code> or
|
||||
<code>fprintf_symbol_filtered</code>. These functions accept an argument of
|
||||
the type <code>struct ui_file *</code>, a pointer to a <code>ui_file</code> object
|
||||
used to store the data stream used for the output. When you use one
|
||||
of these functions, you need a way to pass their results stored in a
|
||||
<code>ui_file</code> object to the <code>ui_out</code> functions. To this end,
|
||||
you first create a <code>ui_stream</code> object by calling
|
||||
<code>ui_out_stream_new</code>, pass the <code>stream</code> member of that
|
||||
<code>ui_stream</code> object to <code>value_print</code> and similar functions,
|
||||
and finally call <code>ui_out_field_stream</code> to output the field you
|
||||
constructed. When the <code>ui_stream</code> object is no longer needed,
|
||||
you should destroy it and free its memory by calling
|
||||
<code>ui_out_stream_delete</code>.
|
||||
|
||||
<div class="defun">
|
||||
— Function: struct ui_stream * <b>ui_out_stream_new</b> (<var>struct ui_out *uiout</var>)<var><a name="index-ui_005fout_005fstream_005fnew-89"></a></var><br>
|
||||
<blockquote><p>This function creates a new <code>ui_stream</code> object which uses the
|
||||
same output methods as the <code>ui_out</code> object whose pointer is
|
||||
passed in <var>uiout</var>. It returns a pointer to the newly created
|
||||
<code>ui_stream</code> object.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>ui_out_stream_delete</b> (<var>struct ui_stream *streambuf</var>)<var><a name="index-ui_005fout_005fstream_005fdelete-90"></a></var><br>
|
||||
<blockquote><p>This functions destroys a <code>ui_stream</code> object specified by
|
||||
<var>streambuf</var>.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>ui_out_field_stream</b> (<var>struct ui_out *uiout, const char *fieldname, struct ui_stream *streambuf</var>)<var><a name="index-ui_005fout_005ffield_005fstream-91"></a></var><br>
|
||||
<blockquote><p>This function consumes all the data accumulated in
|
||||
<code>streambuf->stream</code> and outputs it like
|
||||
<code>ui_out_field_string</code> does. After a call to
|
||||
<code>ui_out_field_stream</code>, the accumulated data no longer exists, but
|
||||
the stream is still valid and may be used for producing more fields.
|
||||
</p></blockquote></div>
|
||||
|
||||
<p><strong>Important:</strong> If there is any chance that your code could bail
|
||||
out before completing output generation and reaching the point where
|
||||
<code>ui_out_stream_delete</code> is called, it is necessary to set up a
|
||||
cleanup, to avoid leaking memory and other resources. Here's a
|
||||
skeleton code to do that:
|
||||
|
||||
<pre class="smallexample"> struct ui_stream *mybuf = ui_out_stream_new (uiout);
|
||||
struct cleanup *old = make_cleanup (ui_out_stream_delete, mybuf);
|
||||
...
|
||||
do_cleanups (old);
|
||||
</pre>
|
||||
<p>If the function already has the old cleanup chain set (for other kinds
|
||||
of cleanups), you just have to add your cleanup to it:
|
||||
|
||||
<pre class="smallexample"> mybuf = ui_out_stream_new (uiout);
|
||||
make_cleanup (ui_out_stream_delete, mybuf);
|
||||
</pre>
|
||||
<p>Note that with cleanups in place, you should not call
|
||||
<code>ui_out_stream_delete</code> directly, or you would attempt to free the
|
||||
same buffer twice.
|
||||
|
||||
<h4 class="subsection">4.2.5 Utility Output Functions</h4>
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>ui_out_field_skip</b> (<var>struct ui_out *uiout, const char *fldname</var>)<var><a name="index-ui_005fout_005ffield_005fskip-92"></a></var><br>
|
||||
<blockquote><p>This function skips a field in a table. Use it if you have to leave
|
||||
an empty field without disrupting the table alignment. The argument
|
||||
<var>fldname</var> specifies a name for the (missing) filed.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>ui_out_text</b> (<var>struct ui_out *uiout, const char *string</var>)<var><a name="index-ui_005fout_005ftext-93"></a></var><br>
|
||||
<blockquote><p>This function outputs the text in <var>string</var> in a way that makes it
|
||||
easy to be read by humans. For example, the console implementation of
|
||||
this method filters the text through a built-in pager, to prevent it
|
||||
from scrolling off the visible portion of the screen.
|
||||
|
||||
<p>Use this function for printing relatively long chunks of text around
|
||||
the actual field data: the text it produces is not aligned according
|
||||
to the table's format. Use <code>ui_out_field_string</code> to output a
|
||||
string field, and use <code>ui_out_message</code>, described below, to
|
||||
output short messages.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>ui_out_spaces</b> (<var>struct ui_out *uiout, int nspaces</var>)<var><a name="index-ui_005fout_005fspaces-94"></a></var><br>
|
||||
<blockquote><p>This function outputs <var>nspaces</var> spaces. It is handy to align the
|
||||
text produced by <code>ui_out_text</code> with the rest of the table or
|
||||
list.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>ui_out_message</b> (<var>struct ui_out *uiout, int verbosity, const char *format, ...</var>)<var><a name="index-ui_005fout_005fmessage-95"></a></var><br>
|
||||
<blockquote><p>This function produces a formatted message, provided that the current
|
||||
verbosity level is at least as large as given by <var>verbosity</var>. The
|
||||
current verbosity level is specified by the user with the ‘<samp><span class="samp">set
|
||||
verbositylevel</span></samp>’ command.<a rel="footnote" href="#fn-2" name="fnd-2"><sup>2</sup></a>
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>ui_out_wrap_hint</b> (<var>struct ui_out *uiout, char *indent</var>)<var><a name="index-ui_005fout_005fwrap_005fhint-96"></a></var><br>
|
||||
<blockquote><p>This function gives the console output filter (a paging filter) a hint
|
||||
of where to break lines which are too long. Ignored for all other
|
||||
output consumers. <var>indent</var>, if non-<code>NULL</code>, is the string to
|
||||
be printed to indent the wrapped text on the next line; it must remain
|
||||
accessible until the next call to <code>ui_out_wrap_hint</code>, or until an
|
||||
explicit newline is produced by one of the other functions. If
|
||||
<var>indent</var> is <code>NULL</code>, the wrapped text will not be indented.
|
||||
</p></blockquote></div>
|
||||
|
||||
<div class="defun">
|
||||
— Function: void <b>ui_out_flush</b> (<var>struct ui_out *uiout</var>)<var><a name="index-ui_005fout_005fflush-97"></a></var><br>
|
||||
<blockquote><p>This function flushes whatever output has been accumulated so far, if
|
||||
the UI buffers output.
|
||||
</p></blockquote></div>
|
||||
|
||||
<h4 class="subsection">4.2.6 Examples of Use of <code>ui_out</code> functions</h4>
|
||||
|
||||
<p><a name="index-using-_0040code_007bui_005fout_007d-functions-98"></a><a name="index-g_t_0040code_007bui_005fout_007d-functions_002c-usage-examples-99"></a>This section gives some practical examples of using the <code>ui_out</code>
|
||||
functions to generalize the old console-oriented code in
|
||||
<span class="sc">gdb</span>. The examples all come from functions defined on the
|
||||
<samp><span class="file">breakpoints.c</span></samp> file.
|
||||
|
||||
<p>This example, from the <code>breakpoint_1</code> function, shows how to
|
||||
produce a table.
|
||||
|
||||
<p>The original code was:
|
||||
|
||||
<pre class="smallexample"> if (!found_a_breakpoint++)
|
||||
{
|
||||
annotate_breakpoints_headers ();
|
||||
|
||||
annotate_field (0);
|
||||
printf_filtered ("Num ");
|
||||
annotate_field (1);
|
||||
printf_filtered ("Type ");
|
||||
annotate_field (2);
|
||||
printf_filtered ("Disp ");
|
||||
annotate_field (3);
|
||||
printf_filtered ("Enb ");
|
||||
if (addressprint)
|
||||
{
|
||||
annotate_field (4);
|
||||
printf_filtered ("Address ");
|
||||
}
|
||||
annotate_field (5);
|
||||
printf_filtered ("What\n");
|
||||
|
||||
annotate_breakpoints_table ();
|
||||
}
|
||||
</pre>
|
||||
<p>Here's the new version:
|
||||
|
||||
<pre class="smallexample"> nr_printable_breakpoints = ...;
|
||||
|
||||
if (addressprint)
|
||||
ui_out_table_begin (ui, 6, nr_printable_breakpoints, "BreakpointTable");
|
||||
else
|
||||
ui_out_table_begin (ui, 5, nr_printable_breakpoints, "BreakpointTable");
|
||||
|
||||
if (nr_printable_breakpoints > 0)
|
||||
annotate_breakpoints_headers ();
|
||||
if (nr_printable_breakpoints > 0)
|
||||
annotate_field (0);
|
||||
ui_out_table_header (uiout, 3, ui_left, "number", "Num"); /* 1 */
|
||||
if (nr_printable_breakpoints > 0)
|
||||
annotate_field (1);
|
||||
ui_out_table_header (uiout, 14, ui_left, "type", "Type"); /* 2 */
|
||||
if (nr_printable_breakpoints > 0)
|
||||
annotate_field (2);
|
||||
ui_out_table_header (uiout, 4, ui_left, "disp", "Disp"); /* 3 */
|
||||
if (nr_printable_breakpoints > 0)
|
||||
annotate_field (3);
|
||||
ui_out_table_header (uiout, 3, ui_left, "enabled", "Enb"); /* 4 */
|
||||
if (addressprint)
|
||||
{
|
||||
if (nr_printable_breakpoints > 0)
|
||||
annotate_field (4);
|
||||
if (print_address_bits <= 32)
|
||||
ui_out_table_header (uiout, 10, ui_left, "addr", "Address");/* 5 */
|
||||
else
|
||||
ui_out_table_header (uiout, 18, ui_left, "addr", "Address");/* 5 */
|
||||
}
|
||||
if (nr_printable_breakpoints > 0)
|
||||
annotate_field (5);
|
||||
ui_out_table_header (uiout, 40, ui_noalign, "what", "What"); /* 6 */
|
||||
ui_out_table_body (uiout);
|
||||
if (nr_printable_breakpoints > 0)
|
||||
annotate_breakpoints_table ();
|
||||
</pre>
|
||||
<p>This example, from the <code>print_one_breakpoint</code> function, shows how
|
||||
to produce the actual data for the table whose structure was defined
|
||||
in the above example. The original code was:
|
||||
|
||||
<pre class="smallexample"> annotate_record ();
|
||||
annotate_field (0);
|
||||
printf_filtered ("%-3d ", b->number);
|
||||
annotate_field (1);
|
||||
if ((int)b->type > (sizeof(bptypes)/sizeof(bptypes[0]))
|
||||
|| ((int) b->type != bptypes[(int) b->type].type))
|
||||
internal_error ("bptypes table does not describe type #%d.",
|
||||
(int)b->type);
|
||||
printf_filtered ("%-14s ", bptypes[(int)b->type].description);
|
||||
annotate_field (2);
|
||||
printf_filtered ("%-4s ", bpdisps[(int)b->disposition]);
|
||||
annotate_field (3);
|
||||
printf_filtered ("%-3c ", bpenables[(int)b->enable]);
|
||||
...
|
||||
</pre>
|
||||
<p>This is the new version:
|
||||
|
||||
<pre class="smallexample"> annotate_record ();
|
||||
ui_out_tuple_begin (uiout, "bkpt");
|
||||
annotate_field (0);
|
||||
ui_out_field_int (uiout, "number", b->number);
|
||||
annotate_field (1);
|
||||
if (((int) b->type > (sizeof (bptypes) / sizeof (bptypes[0])))
|
||||
|| ((int) b->type != bptypes[(int) b->type].type))
|
||||
internal_error ("bptypes table does not describe type #%d.",
|
||||
(int) b->type);
|
||||
ui_out_field_string (uiout, "type", bptypes[(int)b->type].description);
|
||||
annotate_field (2);
|
||||
ui_out_field_string (uiout, "disp", bpdisps[(int)b->disposition]);
|
||||
annotate_field (3);
|
||||
ui_out_field_fmt (uiout, "enabled", "%c", bpenables[(int)b->enable]);
|
||||
...
|
||||
</pre>
|
||||
<p>This example, also from <code>print_one_breakpoint</code>, shows how to
|
||||
produce a complicated output field using the <code>print_expression</code>
|
||||
functions which requires a stream to be passed. It also shows how to
|
||||
automate stream destruction with cleanups. The original code was:
|
||||
|
||||
<pre class="smallexample"> annotate_field (5);
|
||||
print_expression (b->exp, gdb_stdout);
|
||||
</pre>
|
||||
<p>The new version is:
|
||||
|
||||
<pre class="smallexample"> struct ui_stream *stb = ui_out_stream_new (uiout);
|
||||
struct cleanup *old_chain = make_cleanup_ui_out_stream_delete (stb);
|
||||
...
|
||||
annotate_field (5);
|
||||
print_expression (b->exp, stb->stream);
|
||||
ui_out_field_stream (uiout, "what", local_stream);
|
||||
</pre>
|
||||
<p>This example, also from <code>print_one_breakpoint</code>, shows how to use
|
||||
<code>ui_out_text</code> and <code>ui_out_field_string</code>. The original code
|
||||
was:
|
||||
|
||||
<pre class="smallexample"> annotate_field (5);
|
||||
if (b->dll_pathname == NULL)
|
||||
printf_filtered ("<any library> ");
|
||||
else
|
||||
printf_filtered ("library \"%s\" ", b->dll_pathname);
|
||||
</pre>
|
||||
<p>It became:
|
||||
|
||||
<pre class="smallexample"> annotate_field (5);
|
||||
if (b->dll_pathname == NULL)
|
||||
{
|
||||
ui_out_field_string (uiout, "what", "<any library>");
|
||||
ui_out_spaces (uiout, 1);
|
||||
}
|
||||
else
|
||||
{
|
||||
ui_out_text (uiout, "library \"");
|
||||
ui_out_field_string (uiout, "what", b->dll_pathname);
|
||||
ui_out_text (uiout, "\" ");
|
||||
}
|
||||
</pre>
|
||||
<p>The following example from <code>print_one_breakpoint</code> shows how to
|
||||
use <code>ui_out_field_int</code> and <code>ui_out_spaces</code>. The original
|
||||
code was:
|
||||
|
||||
<pre class="smallexample"> annotate_field (5);
|
||||
if (b->forked_inferior_pid != 0)
|
||||
printf_filtered ("process %d ", b->forked_inferior_pid);
|
||||
</pre>
|
||||
<p>It became:
|
||||
|
||||
<pre class="smallexample"> annotate_field (5);
|
||||
if (b->forked_inferior_pid != 0)
|
||||
{
|
||||
ui_out_text (uiout, "process ");
|
||||
ui_out_field_int (uiout, "what", b->forked_inferior_pid);
|
||||
ui_out_spaces (uiout, 1);
|
||||
}
|
||||
</pre>
|
||||
<p>Here's an example of using <code>ui_out_field_string</code>. The original
|
||||
code was:
|
||||
|
||||
<pre class="smallexample"> annotate_field (5);
|
||||
if (b->exec_pathname != NULL)
|
||||
printf_filtered ("program \"%s\" ", b->exec_pathname);
|
||||
</pre>
|
||||
<p>It became:
|
||||
|
||||
<pre class="smallexample"> annotate_field (5);
|
||||
if (b->exec_pathname != NULL)
|
||||
{
|
||||
ui_out_text (uiout, "program \"");
|
||||
ui_out_field_string (uiout, "what", b->exec_pathname);
|
||||
ui_out_text (uiout, "\" ");
|
||||
}
|
||||
</pre>
|
||||
<p>Finally, here's an example of printing an address. The original code:
|
||||
|
||||
<pre class="smallexample"> annotate_field (4);
|
||||
printf_filtered ("%s ",
|
||||
hex_string_custom ((unsigned long) b->address, 8));
|
||||
</pre>
|
||||
<p>It became:
|
||||
|
||||
<pre class="smallexample"> annotate_field (4);
|
||||
ui_out_field_core_addr (uiout, "Address", b->address);
|
||||
</pre>
|
||||
<h3 class="section">4.3 Console Printing</h3>
|
||||
|
||||
<h3 class="section">4.4 TUI</h3>
|
||||
|
||||
<div class="footnote">
|
||||
<hr>
|
||||
<h4>Footnotes</h4><p class="footnote"><small>[<a name="fn-1" href="#fnd-1">1</a>]</small> The function cast is not portable ISO C.</p>
|
||||
|
||||
<p class="footnote"><small>[<a name="fn-2" href="#fnd-2">2</a>]</small> As of this writing (April 2001),
|
||||
setting verbosity level is not yet implemented, and is always returned
|
||||
as zero. So calling <code>ui_out_message</code> with a <var>verbosity</var>
|
||||
argument more than zero will cause the message to never be printed.</p>
|
||||
|
||||
<hr></div>
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,130 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>Values - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="prev" href="libgdb.html#libgdb" title="libgdb">
|
||||
<link rel="next" href="Stack-Frames.html#Stack-Frames" title="Stack Frames">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Values"></a>
|
||||
Next: <a rel="next" accesskey="n" href="Stack-Frames.html#Stack-Frames">Stack Frames</a>,
|
||||
Previous: <a rel="previous" accesskey="p" href="libgdb.html#libgdb">libgdb</a>,
|
||||
Up: <a rel="up" accesskey="u" href="index.html#Top">Top</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h2 class="chapter">6 Values</h2>
|
||||
|
||||
<h3 class="section">6.1 Values</h3>
|
||||
|
||||
<p><a name="index-values-102"></a><a name="index-g_t_0040code_007bvalue_007d-structure-103"></a><span class="sc">gdb</span> uses <code>struct value</code>, or <dfn>values</dfn>, as an internal
|
||||
abstraction for the representation of a variety of inferior objects
|
||||
and <span class="sc">gdb</span> convenience objects.
|
||||
|
||||
<p>Values have an associated <code>struct type</code>, that describes a virtual
|
||||
view of the raw data or object stored in or accessed through the
|
||||
value.
|
||||
|
||||
<p>A value is in addition discriminated by its lvalue-ness, given its
|
||||
<code>enum lval_type</code> enumeration type:
|
||||
|
||||
<p><a name="index-g_t_0040code_007blval_005ftype_007d-enumeration_002c-for-values_002e-104"></a>
|
||||
<dl>
|
||||
<dt><code>not_lval</code><dd>This value is not an lval. It can't be assigned to.
|
||||
|
||||
<br><dt><code>lval_memory</code><dd>This value represents an object in memory.
|
||||
|
||||
<br><dt><code>lval_register</code><dd>This value represents an object that lives in a register.
|
||||
|
||||
<br><dt><code>lval_internalvar</code><dd>Represents the value of an internal variable.
|
||||
|
||||
<br><dt><code>lval_internalvar_component</code><dd>Represents part of a <span class="sc">gdb</span> internal variable. E.g., a
|
||||
structure field.
|
||||
|
||||
<p><a name="index-computed-values-105"></a><br><dt><code>lval_computed</code><dd>These are “computed” values. They allow creating specialized value
|
||||
objects for specific purposes, all abstracted away from the core value
|
||||
support code. The creator of such a value writes specialized
|
||||
functions to handle the reading and writing to/from the value's
|
||||
backend data, and optionally, a “copy operator” and a
|
||||
“destructor”.
|
||||
|
||||
<p>Pointers to these functions are stored in a <code>struct lval_funcs</code>
|
||||
instance (declared in <samp><span class="file">value.h</span></samp>), and passed to the
|
||||
<code>allocate_computed_value</code> function, as in the example below.
|
||||
|
||||
<pre class="smallexample"> static void
|
||||
nil_value_read (struct value *v)
|
||||
{
|
||||
/* This callback reads data from some backend, and stores it in V.
|
||||
In this case, we always read null data. You'll want to fill in
|
||||
something more interesting. */
|
||||
|
||||
memset (value_contents_all_raw (v),
|
||||
value_offset (v),
|
||||
TYPE_LENGTH (value_type (v)));
|
||||
}
|
||||
|
||||
static void
|
||||
nil_value_write (struct value *v, struct value *fromval)
|
||||
{
|
||||
/* Takes the data from FROMVAL and stores it in the backend of V. */
|
||||
|
||||
to_oblivion (value_contents_all_raw (fromval),
|
||||
value_offset (v),
|
||||
TYPE_LENGTH (value_type (fromval)));
|
||||
}
|
||||
|
||||
static struct lval_funcs nil_value_funcs =
|
||||
{
|
||||
nil_value_read,
|
||||
nil_value_write
|
||||
};
|
||||
|
||||
struct value *
|
||||
make_nil_value (void)
|
||||
{
|
||||
struct type *type;
|
||||
struct value *v;
|
||||
|
||||
type = make_nils_type ();
|
||||
v = allocate_computed_value (type, &nil_value_funcs, NULL);
|
||||
|
||||
return v;
|
||||
}
|
||||
</pre>
|
||||
<p>See the implementation of the <code>$_siginfo</code> convenience variable in
|
||||
<samp><span class="file">infrun.c</span></samp> as a real example use of lval_computed.
|
||||
|
||||
</dl>
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,217 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>Versions and Branches - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="prev" href="Porting-GDB.html#Porting-GDB" title="Porting GDB">
|
||||
<link rel="next" href="Start-of-New-Year-Procedure.html#Start-of-New-Year-Procedure" title="Start of New Year Procedure">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Versions-and-Branches"></a>
|
||||
Next: <a rel="next" accesskey="n" href="Start-of-New-Year-Procedure.html#Start-of-New-Year-Procedure">Start of New Year Procedure</a>,
|
||||
Previous: <a rel="previous" accesskey="p" href="Porting-GDB.html#Porting-GDB">Porting GDB</a>,
|
||||
Up: <a rel="up" accesskey="u" href="index.html#Top">Top</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h2 class="chapter">19 Versions and Branches</h2>
|
||||
|
||||
<h3 class="section">19.1 Versions</h3>
|
||||
|
||||
<p><span class="sc">gdb</span>'s version is determined by the file
|
||||
<samp><span class="file">gdb/version.in</span></samp> and takes one of the following forms:
|
||||
|
||||
<dl>
|
||||
<dt><var>major</var>.<var>minor</var><dt><var>major</var>.<var>minor</var>.<var>patchlevel</var><dd>an official release (e.g., 6.2 or 6.2.1)
|
||||
<br><dt><var>major</var>.<var>minor</var>.<var>patchlevel</var>.<var>YYYY</var><var>MM</var><var>DD</var><dd>a snapshot taken at <var>YYYY</var>-<var>MM</var>-<var>DD</var>-gmt (e.g.,
|
||||
6.1.50.20020302, 6.1.90.20020304, or 6.1.0.20020308)
|
||||
<br><dt><var>major</var>.<var>minor</var>.<var>patchlevel</var>.<var>YYYY</var><var>MM</var><var>DD</var>-cvs<dd>a <span class="sc">cvs</span> check out drawn on <var>YYYY</var>-<var>MM</var>-<var>DD</var> (e.g.,
|
||||
6.1.50.20020302-cvs, 6.1.90.20020304-cvs, or 6.1.0.20020308-cvs)
|
||||
<br><dt><var>major</var>.<var>minor</var>.<var>patchlevel</var>.<var>YYYY</var><var>MM</var><var>DD</var> (<var>vendor</var>)<dd>a vendor specific release of <span class="sc">gdb</span>, that while based on<br>
|
||||
<var>major</var>.<var>minor</var>.<var>patchlevel</var>.<var>YYYY</var><var>MM</var><var>DD</var>,
|
||||
may include additional changes
|
||||
</dl>
|
||||
|
||||
<p><span class="sc">gdb</span>'s mainline uses the <var>major</var> and <var>minor</var> version
|
||||
numbers from the most recent release branch, with a <var>patchlevel</var>
|
||||
of 50. At the time each new release branch is created, the mainline's
|
||||
<var>major</var> and <var>minor</var> version numbers are updated.
|
||||
|
||||
<p><span class="sc">gdb</span>'s release branch is similar. When the branch is cut, the
|
||||
<var>patchlevel</var> is changed from 50 to 90. As draft releases are
|
||||
drawn from the branch, the <var>patchlevel</var> is incremented. Once the
|
||||
first release (<var>major</var>.<var>minor</var>) has been made, the
|
||||
<var>patchlevel</var> is set to 0 and updates have an incremented
|
||||
<var>patchlevel</var>.
|
||||
|
||||
<p>For snapshots, and <span class="sc">cvs</span> check outs, it is also possible to
|
||||
identify the <span class="sc">cvs</span> origin:
|
||||
|
||||
<dl>
|
||||
<dt><var>major</var>.<var>minor</var>.50.<var>YYYY</var><var>MM</var><var>DD</var><dd>drawn from the <span class="sc">head</span> of mainline <span class="sc">cvs</span> (e.g., 6.1.50.20020302)
|
||||
<br><dt><var>major</var>.<var>minor</var>.90.<var>YYYY</var><var>MM</var><var>DD</var><dt><var>major</var>.<var>minor</var>.91.<var>YYYY</var><var>MM</var><var>DD</var> <small class="dots">...</small><dd>drawn from a release branch prior to the release (e.g.,
|
||||
6.1.90.20020304)
|
||||
<br><dt><var>major</var>.<var>minor</var>.0.<var>YYYY</var><var>MM</var><var>DD</var><dt><var>major</var>.<var>minor</var>.1.<var>YYYY</var><var>MM</var><var>DD</var> <small class="dots">...</small><dd>drawn from a release branch after the release (e.g., 6.2.0.20020308)
|
||||
</dl>
|
||||
|
||||
<p>If the previous <span class="sc">gdb</span> version is 6.1 and the current version is
|
||||
6.2, then, substituting 6 for <var>major</var> and 1 or 2 for <var>minor</var>,
|
||||
here's an illustration of a typical sequence:
|
||||
|
||||
<pre class="smallexample"> <HEAD>
|
||||
|
|
||||
6.1.50.20020302-cvs
|
||||
|
|
||||
+--------------------------.
|
||||
| <gdb_6_2-branch>
|
||||
| |
|
||||
6.2.50.20020303-cvs 6.1.90 (draft #1)
|
||||
| |
|
||||
6.2.50.20020304-cvs 6.1.90.20020304-cvs
|
||||
| |
|
||||
6.2.50.20020305-cvs 6.1.91 (draft #2)
|
||||
| |
|
||||
6.2.50.20020306-cvs 6.1.91.20020306-cvs
|
||||
| |
|
||||
6.2.50.20020307-cvs 6.2 (release)
|
||||
| |
|
||||
6.2.50.20020308-cvs 6.2.0.20020308-cvs
|
||||
| |
|
||||
6.2.50.20020309-cvs 6.2.1 (update)
|
||||
| |
|
||||
6.2.50.20020310-cvs <branch closed>
|
||||
|
|
||||
6.2.50.20020311-cvs
|
||||
|
|
||||
+--------------------------.
|
||||
| <gdb_6_3-branch>
|
||||
| |
|
||||
6.3.50.20020312-cvs 6.2.90 (draft #1)
|
||||
| |
|
||||
</pre>
|
||||
<h3 class="section">19.2 Release Branches</h3>
|
||||
|
||||
<p><a name="index-Release-Branches-487"></a>
|
||||
<span class="sc">gdb</span> draws a release series (6.2, 6.2.1, <small class="dots">...</small>) from a
|
||||
single release branch, and identifies that branch using the <span class="sc">cvs</span>
|
||||
branch tags:
|
||||
|
||||
<pre class="smallexample"> gdb_<var>major</var>_<var>minor</var>-<var>YYYY</var><var>MM</var><var>DD</var>-branchpoint
|
||||
gdb_<var>major</var>_<var>minor</var>-branch
|
||||
gdb_<var>major</var>_<var>minor</var>-<var>YYYY</var><var>MM</var><var>DD</var>-release
|
||||
</pre>
|
||||
<p><em>Pragmatics: To help identify the date at which a branch or
|
||||
release is made, both the branchpoint and release tags include the
|
||||
date that they are cut (</em><var>YYYY</var><var>MM</var><var>DD</var><em>) in the tag. The
|
||||
branch tag, denoting the head of the branch, does not need this.</em>
|
||||
|
||||
<h3 class="section">19.3 Vendor Branches</h3>
|
||||
|
||||
<p><a name="index-vendor-branches-488"></a>
|
||||
To avoid version conflicts, vendors are expected to modify the file
|
||||
<samp><span class="file">gdb/version.in</span></samp> to include a vendor unique alphabetic identifier
|
||||
(an official <span class="sc">gdb</span> release never uses alphabetic characters in
|
||||
its version identifier). E.g., ‘<samp><span class="samp">6.2widgit2</span></samp>’, or ‘<samp><span class="samp">6.2 (Widgit
|
||||
Inc Patch 2)</span></samp>’.
|
||||
|
||||
<h3 class="section">19.4 Experimental Branches</h3>
|
||||
|
||||
<p><a name="index-experimental-branches-489"></a>
|
||||
|
||||
<h4 class="subsection">19.4.1 Guidelines</h4>
|
||||
|
||||
<p><span class="sc">gdb</span> permits the creation of branches, cut from the <span class="sc">cvs</span>
|
||||
repository, for experimental development. Branches make it possible
|
||||
for developers to share preliminary work, and maintainers to examine
|
||||
significant new developments.
|
||||
|
||||
<p>The following are a set of guidelines for creating such branches:
|
||||
|
||||
<dl>
|
||||
<dt><em>a branch has an owner</em><dd>The owner can set further policy for a branch, but may not change the
|
||||
ground rules. In particular, they can set a policy for commits (be it
|
||||
adding more reviewers or deciding who can commit).
|
||||
|
||||
<br><dt><em>all commits are posted</em><dd>All changes committed to a branch shall also be posted to
|
||||
<a href="mailto:gdb-patches@sourceware.org">the <span class="sc">gdb</span> patches mailing list</a>. While commentary on such changes are encouraged, people
|
||||
should remember that the changes only apply to a branch.
|
||||
|
||||
<br><dt><em>all commits are covered by an assignment</em><dd>This ensures that all changes belong to the Free Software Foundation,
|
||||
and avoids the possibility that the branch may become contaminated.
|
||||
|
||||
<br><dt><em>a branch is focused</em><dd>A focused branch has a single objective or goal, and does not contain
|
||||
unnecessary or irrelevant changes. Cleanups, where identified, being
|
||||
be pushed into the mainline as soon as possible.
|
||||
|
||||
<br><dt><em>a branch tracks mainline</em><dd>This keeps the level of divergence under control. It also keeps the
|
||||
pressure on developers to push cleanups and other stuff into the
|
||||
mainline.
|
||||
|
||||
<br><dt><em>a branch shall contain the entire </em><span class="sc">gdb</span><em> module</em><dd>The <span class="sc">gdb</span> module <code>gdb</code> should be specified when creating a
|
||||
branch (branches of individual files should be avoided). See <a href="Tags.html#Tags">Tags</a>.
|
||||
|
||||
<br><dt><em>a branch shall be branded using </em><samp><span class="file">version.in</span></samp><dd>The file <samp><span class="file">gdb/version.in</span></samp> shall be modified so that it identifies
|
||||
the branch <var>owner</var> and branch <var>name</var>, e.g.,
|
||||
‘<samp><span class="samp">6.2.50.20030303_owner_name</span></samp>’ or ‘<samp><span class="samp">6.2 (Owner Name)</span></samp>’.
|
||||
|
||||
</dl>
|
||||
|
||||
<h4 class="subsection">19.4.2 Tags</h4>
|
||||
|
||||
<p><a name="Tags"></a>To simplify the identification of <span class="sc">gdb</span> branches, the following
|
||||
branch tagging convention is strongly recommended:
|
||||
|
||||
<dl>
|
||||
<dt><var>owner</var><code>_</code><var>name</var><code>-</code><var>YYYYMMDD</var><code>-branchpoint</code><dt><var>owner</var><code>_</code><var>name</var><code>-</code><var>YYYYMMDD</var><code>-branch</code><dd>The branch point and corresponding branch tag. <var>YYYYMMDD</var> is the
|
||||
date that the branch was created. A branch is created using the
|
||||
sequence: <a name="experimental-branch-tags"></a>
|
||||
<pre class="smallexample"> cvs rtag <var>owner</var>_<var>name</var>-<var>YYYYMMDD</var>-branchpoint gdb
|
||||
cvs rtag -b -r <var>owner</var>_<var>name</var>-<var>YYYYMMDD</var>-branchpoint \
|
||||
<var>owner</var>_<var>name</var>-<var>YYYYMMDD</var>-branch gdb
|
||||
</pre>
|
||||
<br><dt><var>owner</var><code>_</code><var>name</var><code>-</code><var>yyyymmdd</var><code>-mergepoint</code><dd>The tagged point, on the mainline, that was used when merging the branch
|
||||
on <var>yyyymmdd</var>. To merge in all changes since the branch was cut,
|
||||
use a command sequence like:
|
||||
<pre class="smallexample"> cvs rtag <var>owner</var>_<var>name</var>-<var>yyyymmdd</var>-mergepoint gdb
|
||||
cvs update \
|
||||
-j<var>owner</var>_<var>name</var>-<var>YYYYMMDD</var>-branchpoint
|
||||
-j<var>owner</var>_<var>name</var>-<var>yyyymmdd</var>-mergepoint
|
||||
</pre>
|
||||
<p class="noindent">Similar sequences can be used to just merge in changes since the last
|
||||
merge.
|
||||
|
||||
</dl>
|
||||
|
||||
<p class="noindent">For further information on <span class="sc">cvs</span>, see
|
||||
<a href="http://www.gnu.org/software/cvs/">Concurrent Versions System</a>.
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1 @@
|
|||
<meta http-equiv="refresh" content="0; url=Versions-and-Branches.html#experimental%20branch%20tags">
|
||||
|
|
@ -0,0 +1 @@
|
|||
<meta http-equiv="refresh" content="0; url=Functions-and-Variable-to-Analyze-Frames.html#frame%5falign">
|
||||
|
|
@ -0,0 +1 @@
|
|||
<meta http-equiv="refresh" content="0; url=Defining-Other-Architecture-Features.html#gdbarch%5fbreakpoint%5ffrom%5fpc">
|
||||
|
|
@ -0,0 +1 @@
|
|||
<meta http-equiv="refresh" content="0; url=Defining-Other-Architecture-Features.html#gdbarch%5fdummy%5fid">
|
||||
|
|
@ -0,0 +1 @@
|
|||
<meta http-equiv="refresh" content="0; url=Defining-Other-Architecture-Features.html#gdbarch%5fpush%5fdummy%5fcall">
|
||||
|
|
@ -0,0 +1 @@
|
|||
<meta http-equiv="refresh" content="0; url=Defining-Other-Architecture-Features.html#gdbarch%5fpush%5fdummy%5fcode">
|
||||
|
|
@ -0,0 +1 @@
|
|||
<meta http-equiv="refresh" content="0; url=Defining-Other-Architecture-Features.html#gdbarch%5freturn%5fvalue">
|
||||
|
|
@ -0,0 +1 @@
|
|||
<meta http-equiv="refresh" content="0; url=Defining-Other-Architecture-Features.html#gdbarch%5fstabs%5fargument%5fhas%5faddr">
|
||||
|
|
@ -0,0 +1,370 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="#Top">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled "GNU
|
||||
Free Documentation License".-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
This file documents the internals of the GNU debugger <span class="sc">gdb</span>.
|
||||
|
||||
<p>Copyright © 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
<p>Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled “GNU
|
||||
Free Documentation License”.
|
||||
|
||||
<div class="contents">
|
||||
<h2>Table of Contents</h2>
|
||||
<ul>
|
||||
<li><a name="toc_Top" href="index.html#Top">Scope of this Document</a>
|
||||
<li><a name="toc_Summary" href="Summary.html#Summary">1 Summary</a>
|
||||
<ul>
|
||||
<li><a href="Requirements.html#Requirements">1.1 Requirements</a>
|
||||
<li><a href="Contributors.html#Contributors">1.2 Contributors</a>
|
||||
</li></ul>
|
||||
<li><a name="toc_Overall-Structure" href="Overall-Structure.html#Overall-Structure">2 Overall Structure</a>
|
||||
<ul>
|
||||
<li><a href="Overall-Structure.html#Overall-Structure">2.1 The Symbol Side</a>
|
||||
<li><a href="Overall-Structure.html#Overall-Structure">2.2 The Target Side</a>
|
||||
<li><a href="Overall-Structure.html#Overall-Structure">2.3 Configurations</a>
|
||||
<li><a href="Overall-Structure.html#Overall-Structure">2.4 Source Tree Structure</a>
|
||||
</li></ul>
|
||||
<li><a name="toc_Algorithms" href="Algorithms.html#Algorithms">3 Algorithms</a>
|
||||
<ul>
|
||||
<li><a href="Algorithms.html#Algorithms">3.1 Prologue Analysis</a>
|
||||
<li><a href="Algorithms.html#Algorithms">3.2 Breakpoint Handling</a>
|
||||
<li><a href="Algorithms.html#Algorithms">3.3 Single Stepping</a>
|
||||
<li><a href="Algorithms.html#Algorithms">3.4 Signal Handling</a>
|
||||
<li><a href="Algorithms.html#Algorithms">3.5 Thread Handling</a>
|
||||
<li><a href="Algorithms.html#Algorithms">3.6 Inferior Function Calls</a>
|
||||
<li><a href="Algorithms.html#Algorithms">3.7 Longjmp Support</a>
|
||||
<li><a href="Algorithms.html#Algorithms">3.8 Watchpoints</a>
|
||||
<ul>
|
||||
<li><a href="Algorithms.html#Algorithms">3.8.1 Watchpoints and Threads</a>
|
||||
<li><a href="Algorithms.html#Algorithms">3.8.2 x86 Watchpoints</a>
|
||||
</li></ul>
|
||||
<li><a href="Algorithms.html#Algorithms">3.9 Checkpoints</a>
|
||||
<li><a href="Algorithms.html#Algorithms">3.10 Observing changes in <span class="sc">gdb</span> internals</a>
|
||||
</li></ul>
|
||||
<li><a name="toc_User-Interface" href="User-Interface.html#User-Interface">4 User Interface</a>
|
||||
<ul>
|
||||
<li><a href="User-Interface.html#User-Interface">4.1 Command Interpreter</a>
|
||||
<li><a href="User-Interface.html#User-Interface">4.2 UI-Independent Output—the <code>ui_out</code> Functions</a>
|
||||
<ul>
|
||||
<li><a href="User-Interface.html#User-Interface">4.2.1 Overview and Terminology</a>
|
||||
<li><a href="User-Interface.html#User-Interface">4.2.2 General Conventions</a>
|
||||
<li><a href="User-Interface.html#User-Interface">4.2.3 Table, Tuple and List Functions</a>
|
||||
<li><a href="User-Interface.html#User-Interface">4.2.4 Item Output Functions</a>
|
||||
<li><a href="User-Interface.html#User-Interface">4.2.5 Utility Output Functions</a>
|
||||
<li><a href="User-Interface.html#User-Interface">4.2.6 Examples of Use of <code>ui_out</code> functions</a>
|
||||
</li></ul>
|
||||
<li><a href="User-Interface.html#User-Interface">4.3 Console Printing</a>
|
||||
<li><a href="User-Interface.html#User-Interface">4.4 TUI</a>
|
||||
</li></ul>
|
||||
<li><a name="toc_libgdb" href="libgdb.html#libgdb">5 libgdb</a>
|
||||
<ul>
|
||||
<li><a href="libgdb.html#libgdb">5.1 libgdb 1.0</a>
|
||||
<li><a href="libgdb.html#libgdb">5.2 libgdb 2.0</a>
|
||||
<li><a href="libgdb.html#libgdb">5.3 The <code>libgdb</code> Model</a>
|
||||
<li><a href="libgdb.html#libgdb">5.4 CLI support</a>
|
||||
<li><a href="libgdb.html#libgdb">5.5 <code>libgdb</code> components</a>
|
||||
</li></ul>
|
||||
<li><a name="toc_Values" href="Values.html#Values">6 Values</a>
|
||||
<ul>
|
||||
<li><a href="Values.html#Values">6.1 Values</a>
|
||||
</li></ul>
|
||||
<li><a name="toc_Stack-Frames" href="Stack-Frames.html#Stack-Frames">7 Stack Frames</a>
|
||||
<ul>
|
||||
<li><a href="Stack-Frames.html#Stack-Frames">7.1 Selecting an Unwinder</a>
|
||||
<li><a href="Stack-Frames.html#Stack-Frames">7.2 Unwinding the Frame ID</a>
|
||||
<li><a href="Stack-Frames.html#Stack-Frames">7.3 Unwinding Registers</a>
|
||||
</li></ul>
|
||||
<li><a name="toc_Symbol-Handling" href="Symbol-Handling.html#Symbol-Handling">8 Symbol Handling</a>
|
||||
<ul>
|
||||
<li><a href="Symbol-Handling.html#Symbol-Handling">8.1 Symbol Reading</a>
|
||||
<li><a href="Symbol-Handling.html#Symbol-Handling">8.2 Partial Symbol Tables</a>
|
||||
<li><a href="Symbol-Handling.html#Symbol-Handling">8.3 Types</a>
|
||||
<ul>
|
||||
<li><a href="Symbol-Handling.html#Symbol-Handling">Fundamental Types (e.g., <code>FT_VOID</code>, <code>FT_BOOLEAN</code>).</a>
|
||||
<li><a href="Symbol-Handling.html#Symbol-Handling">Type Codes (e.g., <code>TYPE_CODE_PTR</code>, <code>TYPE_CODE_ARRAY</code>).</a>
|
||||
<li><a href="Symbol-Handling.html#Symbol-Handling">Builtin Types (e.g., <code>builtin_type_void</code>, <code>builtin_type_char</code>).</a>
|
||||
</li></ul>
|
||||
<li><a href="Symbol-Handling.html#Symbol-Handling">8.4 Object File Formats</a>
|
||||
<ul>
|
||||
<li><a href="Symbol-Handling.html#Symbol-Handling">8.4.1 a.out</a>
|
||||
<li><a href="Symbol-Handling.html#Symbol-Handling">8.4.2 COFF</a>
|
||||
<li><a href="Symbol-Handling.html#Symbol-Handling">8.4.3 ECOFF</a>
|
||||
<li><a href="Symbol-Handling.html#Symbol-Handling">8.4.4 XCOFF</a>
|
||||
<li><a href="Symbol-Handling.html#Symbol-Handling">8.4.5 PE</a>
|
||||
<li><a href="Symbol-Handling.html#Symbol-Handling">8.4.6 ELF</a>
|
||||
<li><a href="Symbol-Handling.html#Symbol-Handling">8.4.7 SOM</a>
|
||||
</li></ul>
|
||||
<li><a href="Symbol-Handling.html#Symbol-Handling">8.5 Debugging File Formats</a>
|
||||
<ul>
|
||||
<li><a href="Symbol-Handling.html#Symbol-Handling">8.5.1 stabs</a>
|
||||
<li><a href="Symbol-Handling.html#Symbol-Handling">8.5.2 COFF</a>
|
||||
<li><a href="Symbol-Handling.html#Symbol-Handling">8.5.3 Mips debug (Third Eye)</a>
|
||||
<li><a href="Symbol-Handling.html#Symbol-Handling">8.5.4 DWARF 2</a>
|
||||
<li><a href="Symbol-Handling.html#Symbol-Handling">8.5.5 Compressed DWARF 2</a>
|
||||
<li><a href="Symbol-Handling.html#Symbol-Handling">8.5.6 DWARF 3</a>
|
||||
<li><a href="Symbol-Handling.html#Symbol-Handling">8.5.7 SOM</a>
|
||||
</li></ul>
|
||||
<li><a href="Symbol-Handling.html#Symbol-Handling">8.6 Adding a New Symbol Reader to <span class="sc">gdb</span></a>
|
||||
<li><a href="Symbol-Handling.html#Symbol-Handling">8.7 Memory Management for Symbol Files</a>
|
||||
</li></ul>
|
||||
<li><a name="toc_Language-Support" href="Language-Support.html#Language-Support">9 Language Support</a>
|
||||
<ul>
|
||||
<li><a href="Language-Support.html#Language-Support">9.1 Adding a Source Language to <span class="sc">gdb</span></a>
|
||||
</li></ul>
|
||||
<li><a name="toc_Host-Definition" href="Host-Definition.html#Host-Definition">10 Host Definition</a>
|
||||
<ul>
|
||||
<li><a href="Host-Definition.html#Host-Definition">10.1 Adding a New Host</a>
|
||||
<li><a href="Host-Definition.html#Host-Definition">10.2 Host Conditionals</a>
|
||||
</li></ul>
|
||||
<li><a name="toc_Target-Architecture-Definition" href="Target-Architecture-Definition.html#Target-Architecture-Definition">11 Target Architecture Definition</a>
|
||||
<ul>
|
||||
<li><a href="OS-ABI-Variant-Handling.html#OS-ABI-Variant-Handling">11.1 Operating System ABI Variant Handling</a>
|
||||
<li><a href="Initialize-New-Architecture.html#Initialize-New-Architecture">11.2 Initializing a New Architecture</a>
|
||||
<ul>
|
||||
<li><a href="How-an-Architecture-is-Represented.html#How-an-Architecture-is-Represented">11.2.1 How an Architecture is Represented</a>
|
||||
<li><a href="Looking-Up-an-Existing-Architecture.html#Looking-Up-an-Existing-Architecture">11.2.2 Looking Up an Existing Architecture</a>
|
||||
<li><a href="Creating-a-New-Architecture.html#Creating-a-New-Architecture">11.2.3 Creating a New Architecture</a>
|
||||
</li></ul>
|
||||
<li><a href="Registers-and-Memory.html#Registers-and-Memory">11.3 Registers and Memory</a>
|
||||
<li><a href="Pointers-and-Addresses.html#Pointers-and-Addresses">11.4 Pointers Are Not Always Addresses</a>
|
||||
<li><a href="Address-Classes.html#Address-Classes">11.5 Address Classes</a>
|
||||
<li><a href="Register-Representation.html#Register-Representation">11.6 Register Representation</a>
|
||||
<ul>
|
||||
<li><a href="Raw-and-Cooked-Registers.html#Raw-and-Cooked-Registers">11.6.1 Raw and Cooked Registers</a>
|
||||
<li><a href="Register-Architecture-Functions-_0026-Variables.html#Register-Architecture-Functions-_0026-Variables">11.6.2 Functions and Variables Specifying the Register Architecture</a>
|
||||
<li><a href="Register-Information-Functions.html#Register-Information-Functions">11.6.3 Functions Giving Register Information</a>
|
||||
<li><a href="Register-and-Memory-Data.html#Register-and-Memory-Data">11.6.4 Using Different Register and Memory Data Representations</a>
|
||||
<li><a href="Register-Caching.html#Register-Caching">11.6.5 Register Caching</a>
|
||||
</li></ul>
|
||||
<li><a href="Frame-Interpretation.html#Frame-Interpretation">11.7 Frame Interpretation</a>
|
||||
<ul>
|
||||
<li><a href="All-About-Stack-Frames.html#All-About-Stack-Frames">11.7.1 All About Stack Frames</a>
|
||||
<li><a href="Frame-Handling-Terminology.html#Frame-Handling-Terminology">11.7.2 Frame Handling Terminology</a>
|
||||
<li><a href="Prologue-Caches.html#Prologue-Caches">11.7.3 Prologue Caches</a>
|
||||
<li><a href="Functions-and-Variable-to-Analyze-Frames.html#Functions-and-Variable-to-Analyze-Frames">11.7.4 Functions and Variable to Analyze Frames</a>
|
||||
<li><a href="Functions-to-Access-Frame-Data.html#Functions-to-Access-Frame-Data">11.7.5 Functions to Access Frame Data</a>
|
||||
<li><a href="Analyzing-Stacks_002d_002d_002dFrame-Sniffers.html#Analyzing-Stacks_002d_002d_002dFrame-Sniffers">11.7.6 Analyzing Stacks—Frame Sniffers</a>
|
||||
</li></ul>
|
||||
<li><a href="Inferior-Call-Setup.html#Inferior-Call-Setup">11.8 Inferior Call Setup</a>
|
||||
<ul>
|
||||
<li><a href="About-Dummy-Frames.html#About-Dummy-Frames">11.8.1 About Dummy Frames</a>
|
||||
<li><a href="Functions-Creating-Dummy-Frames.html#Functions-Creating-Dummy-Frames">11.8.2 Functions Creating Dummy Frames</a>
|
||||
</li></ul>
|
||||
<li><a href="Adding-support-for-debugging-core-files.html#Adding-support-for-debugging-core-files">11.9 Adding support for debugging core files</a>
|
||||
<li><a href="Defining-Other-Architecture-Features.html#Defining-Other-Architecture-Features">11.10 Defining Other Architecture Features</a>
|
||||
<li><a href="Adding-a-New-Target.html#Adding-a-New-Target">11.11 Adding a New Target</a>
|
||||
</li></ul>
|
||||
<li><a name="toc_Target-Descriptions" href="Target-Descriptions.html#Target-Descriptions">12 Target Descriptions</a>
|
||||
<ul>
|
||||
<li><a href="Target-Descriptions-Implementation.html#Target-Descriptions-Implementation">12.1 Target Descriptions Implementation</a>
|
||||
<li><a href="Adding-Target-Described-Register-Support.html#Adding-Target-Described-Register-Support">12.2 Adding Target Described Register Support</a>
|
||||
</li></ul>
|
||||
<li><a name="toc_Target-Vector-Definition" href="Target-Vector-Definition.html#Target-Vector-Definition">13 Target Vector Definition</a>
|
||||
<ul>
|
||||
<li><a href="Managing-Execution-State.html#Managing-Execution-State">13.1 Managing Execution State</a>
|
||||
<li><a href="Existing-Targets.html#Existing-Targets">13.2 Existing Targets</a>
|
||||
<ul>
|
||||
<li><a href="Existing-Targets.html#Existing-Targets">13.2.1 File Targets</a>
|
||||
<li><a href="Existing-Targets.html#Existing-Targets">13.2.2 Standard Protocol and Remote Stubs</a>
|
||||
<li><a href="Existing-Targets.html#Existing-Targets">13.2.3 ROM Monitor Interface</a>
|
||||
<li><a href="Existing-Targets.html#Existing-Targets">13.2.4 Custom Protocols</a>
|
||||
<li><a href="Existing-Targets.html#Existing-Targets">13.2.5 Transport Layer</a>
|
||||
<li><a href="Existing-Targets.html#Existing-Targets">13.2.6 Builtin Simulator</a>
|
||||
</li></ul>
|
||||
</li></ul>
|
||||
<li><a name="toc_Native-Debugging" href="Native-Debugging.html#Native-Debugging">14 Native Debugging</a>
|
||||
<ul>
|
||||
<li><a href="Native-Debugging.html#Native-Debugging">14.1 ptrace</a>
|
||||
<li><a href="Native-Debugging.html#Native-Debugging">14.2 /proc</a>
|
||||
<li><a href="Native-Debugging.html#Native-Debugging">14.3 win32</a>
|
||||
<li><a href="Native-Debugging.html#Native-Debugging">14.4 shared libraries</a>
|
||||
<li><a href="Native-Debugging.html#Native-Debugging">14.5 Native Conditionals</a>
|
||||
</li></ul>
|
||||
<li><a name="toc_Support-Libraries" href="Support-Libraries.html#Support-Libraries">15 Support Libraries</a>
|
||||
<ul>
|
||||
<li><a href="Support-Libraries.html#Support-Libraries">15.1 BFD</a>
|
||||
<li><a href="Support-Libraries.html#Support-Libraries">15.2 opcodes</a>
|
||||
<li><a href="Support-Libraries.html#Support-Libraries">15.3 readline</a>
|
||||
<li><a href="Support-Libraries.html#Support-Libraries">15.4 libiberty</a>
|
||||
<ul>
|
||||
<li><a href="Support-Libraries.html#Support-Libraries">15.4.1 <code>obstacks</code> in <span class="sc">gdb</span></a>
|
||||
</li></ul>
|
||||
<li><a href="Support-Libraries.html#Support-Libraries">15.5 gnu-regex</a>
|
||||
<li><a href="Support-Libraries.html#Support-Libraries">15.6 Array Containers</a>
|
||||
<li><a href="Support-Libraries.html#Support-Libraries">15.7 include</a>
|
||||
</li></ul>
|
||||
<li><a name="toc_Coding-Standards" href="Coding-Standards.html#Coding-Standards">16 Coding Standards</a>
|
||||
<ul>
|
||||
<li><a href="Coding-Standards.html#Coding-Standards">16.1 <span class="sc">gdb</span> C Coding Standards</a>
|
||||
<ul>
|
||||
<li><a href="Coding-Standards.html#Coding-Standards">16.1.1 ISO C</a>
|
||||
<li><a href="Coding-Standards.html#Coding-Standards">16.1.2 Formatting</a>
|
||||
<li><a href="Coding-Standards.html#Coding-Standards">16.1.3 Comments</a>
|
||||
<li><a href="Coding-Standards.html#Coding-Standards">16.1.4 C Usage</a>
|
||||
<li><a href="Coding-Standards.html#Coding-Standards">16.1.5 Function Prototypes</a>
|
||||
<li><a href="Coding-Standards.html#Coding-Standards">16.1.6 File Names</a>
|
||||
<li><a href="Coding-Standards.html#Coding-Standards">16.1.7 Include Files</a>
|
||||
</li></ul>
|
||||
<li><a href="Coding-Standards.html#Coding-Standards">16.2 <span class="sc">gdb</span> Python Coding Standards</a>
|
||||
<ul>
|
||||
<li><a href="Coding-Standards.html#Coding-Standards">16.2.1 <span class="sc">gdb</span>-specific exceptions</a>
|
||||
</li></ul>
|
||||
</li></ul>
|
||||
<li><a name="toc_Misc-Guidelines" href="Misc-Guidelines.html#Misc-Guidelines">17 Misc Guidelines</a>
|
||||
<ul>
|
||||
<li><a href="Misc-Guidelines.html#Misc-Guidelines">17.1 Cleanups</a>
|
||||
<li><a href="Misc-Guidelines.html#Misc-Guidelines">17.2 Per-architecture module data</a>
|
||||
<li><a href="Misc-Guidelines.html#Misc-Guidelines">17.3 Wrapping Output Lines</a>
|
||||
<li><a href="Misc-Guidelines.html#Misc-Guidelines">17.4 Memory Management</a>
|
||||
<li><a href="Misc-Guidelines.html#Misc-Guidelines">17.5 Compiler Warnings</a>
|
||||
<li><a href="Misc-Guidelines.html#Misc-Guidelines">17.6 Internal Error Recovery</a>
|
||||
<li><a href="Misc-Guidelines.html#Misc-Guidelines">17.7 Command Names</a>
|
||||
<li><a href="Misc-Guidelines.html#Misc-Guidelines">17.8 Clean Design and Portable Implementation</a>
|
||||
</li></ul>
|
||||
<li><a name="toc_Porting-GDB" href="Porting-GDB.html#Porting-GDB">18 Porting <span class="sc">gdb</span></a>
|
||||
<li><a name="toc_Versions-and-Branches" href="Versions-and-Branches.html#Versions-and-Branches">19 Versions and Branches</a>
|
||||
<ul>
|
||||
<li><a href="Versions-and-Branches.html#Versions-and-Branches">19.1 Versions</a>
|
||||
<li><a href="Versions-and-Branches.html#Versions-and-Branches">19.2 Release Branches</a>
|
||||
<li><a href="Versions-and-Branches.html#Versions-and-Branches">19.3 Vendor Branches</a>
|
||||
<li><a href="Versions-and-Branches.html#Versions-and-Branches">19.4 Experimental Branches</a>
|
||||
<ul>
|
||||
<li><a href="Versions-and-Branches.html#Versions-and-Branches">19.4.1 Guidelines</a>
|
||||
<li><a href="Versions-and-Branches.html#Versions-and-Branches">19.4.2 Tags</a>
|
||||
</li></ul>
|
||||
</li></ul>
|
||||
<li><a name="toc_Start-of-New-Year-Procedure" href="Start-of-New-Year-Procedure.html#Start-of-New-Year-Procedure">20 Start of New Year Procedure</a>
|
||||
<li><a name="toc_Releasing-GDB" href="Releasing-GDB.html#Releasing-GDB">21 Releasing <span class="sc">gdb</span></a>
|
||||
<ul>
|
||||
<li><a href="Releasing-GDB.html#Releasing-GDB">21.1 Branch Commit Policy</a>
|
||||
<li><a href="Releasing-GDB.html#Releasing-GDB">21.2 Obsoleting code</a>
|
||||
<li><a href="Releasing-GDB.html#Releasing-GDB">21.3 Before the Branch</a>
|
||||
<ul>
|
||||
<li><a href="Releasing-GDB.html#Releasing-GDB">21.3.1 Review the bug data base</a>
|
||||
<li><a href="Releasing-GDB.html#Releasing-GDB">21.3.2 Check all cross targets build</a>
|
||||
</li></ul>
|
||||
<li><a href="Releasing-GDB.html#Releasing-GDB">21.4 Cut the Branch</a>
|
||||
<li><a href="Releasing-GDB.html#Releasing-GDB">21.5 Stabilize the branch</a>
|
||||
<li><a href="Releasing-GDB.html#Releasing-GDB">21.6 Create a Release</a>
|
||||
<ul>
|
||||
<li><a href="Releasing-GDB.html#Releasing-GDB">21.6.1 Create a release candidate</a>
|
||||
<li><a href="Releasing-GDB.html#Releasing-GDB">21.6.2 Sanity check the tar ball</a>
|
||||
<li><a href="Releasing-GDB.html#Releasing-GDB">21.6.3 Make a release candidate available</a>
|
||||
<li><a href="Releasing-GDB.html#Releasing-GDB">21.6.4 Make a formal release available</a>
|
||||
<li><a href="Releasing-GDB.html#Releasing-GDB">21.6.5 Cleanup</a>
|
||||
</li></ul>
|
||||
<li><a href="Releasing-GDB.html#Releasing-GDB">21.7 Post release</a>
|
||||
</li></ul>
|
||||
<li><a name="toc_Testsuite" href="Testsuite.html#Testsuite">22 Testsuite</a>
|
||||
<ul>
|
||||
<li><a href="Testsuite.html#Testsuite">22.1 Using the Testsuite</a>
|
||||
<li><a href="Testsuite.html#Testsuite">22.2 Testsuite Parameters</a>
|
||||
<li><a href="Testsuite.html#Testsuite">22.3 Testsuite Configuration</a>
|
||||
<li><a href="Testsuite.html#Testsuite">22.4 Testsuite Organization</a>
|
||||
<li><a href="Testsuite.html#Testsuite">22.5 Writing Tests</a>
|
||||
<li><a href="Testsuite.html#Testsuite">22.6 Board settings</a>
|
||||
</li></ul>
|
||||
<li><a name="toc_Hints" href="Hints.html#Hints">23 Hints</a>
|
||||
<ul>
|
||||
<li><a href="Getting-Started.html#Getting-Started">23.1 Getting Started</a>
|
||||
<li><a href="Debugging-GDB.html#Debugging-GDB">23.2 Debugging <span class="sc">gdb</span> with itself</a>
|
||||
<li><a href="Debugging-GDB.html#Debugging-GDB">23.3 Submitting Patches</a>
|
||||
<li><a href="Debugging-GDB.html#Debugging-GDB">23.4 Build Script</a>
|
||||
</li></ul>
|
||||
<li><a name="toc_GDB-Observers" href="GDB-Observers.html#GDB-Observers">Appendix A <span class="sc">gdb</span> Currently available observers</a>
|
||||
<ul>
|
||||
<li><a href="GDB-Observers.html#GDB-Observers">A.1 Implementation rationale</a>
|
||||
<li><a href="GDB-Observers.html#GDB-Observers">A.2 Debugging</a>
|
||||
<li><a href="GDB-Observers.html#GDB-Observers">A.3 <code>normal_stop</code> Notifications</a>
|
||||
</li></ul>
|
||||
<li><a name="toc_GNU-Free-Documentation-License" href="GNU-Free-Documentation-License.html#GNU-Free-Documentation-License">Appendix B GNU Free Documentation License</a>
|
||||
<li><a name="toc_Concept-Index" href="Concept-Index.html#Concept-Index">Concept Index</a>
|
||||
<li><a name="toc_Function-and-Variable-Index" href="Function-and-Variable-Index.html#Function-and-Variable-Index">Function and Variable Index</a>
|
||||
</li></ul>
|
||||
</div>
|
||||
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="Top"></a>
|
||||
Next: <a rel="next" accesskey="n" href="Summary.html#Summary">Summary</a>,
|
||||
Up: <a rel="up" accesskey="u" href="../index.html#dir">(dir)</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<!-- Perhaps this should be the title of the document (but only for info, -->
|
||||
<!-- not for TeX). Existing GNU manuals seem inconsistent on this point. -->
|
||||
<h2 class="unnumbered">Scope of this Document</h2>
|
||||
|
||||
<p>This document documents the internals of the GNU debugger, <span class="sc">gdb</span>. It
|
||||
includes description of <span class="sc">gdb</span>'s key algorithms and operations, as well
|
||||
as the mechanisms that adapt <span class="sc">gdb</span> to specific hosts and targets.
|
||||
|
||||
<ul class="menu">
|
||||
<li><a accesskey="1" href="Summary.html#Summary">Summary</a>
|
||||
<li><a accesskey="2" href="Overall-Structure.html#Overall-Structure">Overall Structure</a>
|
||||
<li><a accesskey="3" href="Algorithms.html#Algorithms">Algorithms</a>
|
||||
<li><a accesskey="4" href="User-Interface.html#User-Interface">User Interface</a>
|
||||
<li><a accesskey="5" href="libgdb.html#libgdb">libgdb</a>
|
||||
<li><a accesskey="6" href="Values.html#Values">Values</a>
|
||||
<li><a accesskey="7" href="Stack-Frames.html#Stack-Frames">Stack Frames</a>
|
||||
<li><a accesskey="8" href="Symbol-Handling.html#Symbol-Handling">Symbol Handling</a>
|
||||
<li><a accesskey="9" href="Language-Support.html#Language-Support">Language Support</a>
|
||||
<li><a href="Host-Definition.html#Host-Definition">Host Definition</a>
|
||||
<li><a href="Target-Architecture-Definition.html#Target-Architecture-Definition">Target Architecture Definition</a>
|
||||
<li><a href="Target-Descriptions.html#Target-Descriptions">Target Descriptions</a>
|
||||
<li><a href="Target-Vector-Definition.html#Target-Vector-Definition">Target Vector Definition</a>
|
||||
<li><a href="Native-Debugging.html#Native-Debugging">Native Debugging</a>
|
||||
<li><a href="Support-Libraries.html#Support-Libraries">Support Libraries</a>
|
||||
<li><a href="Coding-Standards.html#Coding-Standards">Coding Standards</a>
|
||||
<li><a href="Misc-Guidelines.html#Misc-Guidelines">Misc Guidelines</a>
|
||||
<li><a href="Porting-GDB.html#Porting-GDB">Porting GDB</a>
|
||||
<li><a href="Versions-and-Branches.html#Versions-and-Branches">Versions and Branches</a>
|
||||
<li><a href="Start-of-New-Year-Procedure.html#Start-of-New-Year-Procedure">Start of New Year Procedure</a>
|
||||
<li><a href="Releasing-GDB.html#Releasing-GDB">Releasing GDB</a>
|
||||
<li><a href="Testsuite.html#Testsuite">Testsuite</a>
|
||||
<li><a href="Hints.html#Hints">Hints</a>
|
||||
|
||||
<li><a href="GDB-Observers.html#GDB-Observers">GDB Observers</a>: <span class="sc">gdb</span> Currently available observers
|
||||
<li><a href="GNU-Free-Documentation-License.html#GNU-Free-Documentation-License">GNU Free Documentation License</a>: The license for this documentation
|
||||
<li><a href="Concept-Index.html#Concept-Index">Concept Index</a>
|
||||
<li><a href="Function-and-Variable-Index.html#Function-and-Variable-Index">Function and Variable Index</a>
|
||||
</ul>
|
||||
|
||||
</body></html>
|
||||
|
||||
|
|
@ -0,0 +1,153 @@
|
|||
<html lang="en">
|
||||
<head>
|
||||
<title>libgdb - GDB Internals</title>
|
||||
<meta http-equiv="Content-Type" content="text/html">
|
||||
<meta name="description" content="GDB Internals">
|
||||
<meta name="generator" content="makeinfo 4.11">
|
||||
<link title="Top" rel="start" href="index.html#Top">
|
||||
<link rel="prev" href="User-Interface.html#User-Interface" title="User Interface">
|
||||
<link rel="next" href="Values.html#Values" title="Values">
|
||||
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage">
|
||||
<!--
|
||||
Copyright (C) 1990-2013 Free Software Foundation, Inc.
|
||||
Contributed by Cygnus Solutions. Written by John Gilmore.
|
||||
Second Edition by Stan Shebs.
|
||||
|
||||
Permission is granted to copy, distribute and/or modify this document
|
||||
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||||
any later version published by the Free Software Foundation; with no
|
||||
Invariant Sections, with no Front-Cover Texts, and with no Back-Cover
|
||||
Texts. A copy of the license is included in the section entitled ``GNU
|
||||
Free Documentation License''.-->
|
||||
<meta http-equiv="Content-Style-Type" content="text/css">
|
||||
<style type="text/css"><!--
|
||||
pre.display { font-family:inherit }
|
||||
pre.format { font-family:inherit }
|
||||
pre.smalldisplay { font-family:inherit; font-size:smaller }
|
||||
pre.smallformat { font-family:inherit; font-size:smaller }
|
||||
pre.smallexample { font-size:smaller }
|
||||
pre.smalllisp { font-size:smaller }
|
||||
span.sc { font-variant:small-caps }
|
||||
span.roman { font-family:serif; font-weight:normal; }
|
||||
span.sansserif { font-family:sans-serif; font-weight:normal; }
|
||||
--></style>
|
||||
</head>
|
||||
<body>
|
||||
<div class="node">
|
||||
<p>
|
||||
<a name="libgdb"></a>
|
||||
Next: <a rel="next" accesskey="n" href="Values.html#Values">Values</a>,
|
||||
Previous: <a rel="previous" accesskey="p" href="User-Interface.html#User-Interface">User Interface</a>,
|
||||
Up: <a rel="up" accesskey="u" href="index.html#Top">Top</a>
|
||||
<hr>
|
||||
</div>
|
||||
|
||||
<h2 class="chapter">5 libgdb</h2>
|
||||
|
||||
<h3 class="section">5.1 libgdb 1.0</h3>
|
||||
|
||||
<p><a name="index-g_t_0040code_007blibgdb_007d-100"></a><code>libgdb</code> 1.0 was an abortive project of years ago. The theory was
|
||||
to provide an API to <span class="sc">gdb</span>'s functionality.
|
||||
|
||||
<h3 class="section">5.2 libgdb 2.0</h3>
|
||||
|
||||
<p><a name="index-g_t_0040code_007blibgdb_007d-101"></a><code>libgdb</code> 2.0 is an ongoing effort to update <span class="sc">gdb</span> so that is
|
||||
better able to support graphical and other environments.
|
||||
|
||||
<p>Since <code>libgdb</code> development is on-going, its architecture is still
|
||||
evolving. The following components have so far been identified:
|
||||
|
||||
<ul>
|
||||
<li>Observer - <samp><span class="file">gdb-events.h</span></samp>.
|
||||
<li>Builder - <samp><span class="file">ui-out.h</span></samp>
|
||||
<li>Event Loop - <samp><span class="file">event-loop.h</span></samp>
|
||||
<li>Library - <samp><span class="file">gdb.h</span></samp>
|
||||
</ul>
|
||||
|
||||
<p>The model that ties these components together is described below.
|
||||
|
||||
<h3 class="section">5.3 The <code>libgdb</code> Model</h3>
|
||||
|
||||
<p>A client of <code>libgdb</code> interacts with the library in two ways.
|
||||
|
||||
<ul>
|
||||
<li>As an observer (using <samp><span class="file">gdb-events</span></samp>) receiving notifications from
|
||||
<code>libgdb</code> of any internal state changes (break point changes, run
|
||||
state, etc).
|
||||
<li>As a client querying <code>libgdb</code> (using the <samp><span class="file">ui-out</span></samp> builder) to
|
||||
obtain various status values from <span class="sc">gdb</span>.
|
||||
</ul>
|
||||
|
||||
<p>Since <code>libgdb</code> could have multiple clients (e.g., a GUI supporting
|
||||
the existing <span class="sc">gdb</span> CLI), those clients must co-operate when
|
||||
controlling <code>libgdb</code>. In particular, a client must ensure that
|
||||
<code>libgdb</code> is idle (i.e. no other client is using <code>libgdb</code>)
|
||||
before responding to a <samp><span class="file">gdb-event</span></samp> by making a query.
|
||||
|
||||
<h3 class="section">5.4 CLI support</h3>
|
||||
|
||||
<p>At present <span class="sc">gdb</span>'s CLI is very much entangled in with the core of
|
||||
<code>libgdb</code>. Consequently, a client wishing to include the CLI in
|
||||
their interface needs to carefully co-ordinate its own and the CLI's
|
||||
requirements.
|
||||
|
||||
<p>It is suggested that the client set <code>libgdb</code> up to be bi-modal
|
||||
(alternate between CLI and client query modes). The notes below sketch
|
||||
out the theory:
|
||||
|
||||
<ul>
|
||||
<li>The client registers itself as an observer of <code>libgdb</code>.
|
||||
<li>The client create and install <code>cli-out</code> builder using its own
|
||||
versions of the <code>ui-file</code> <code>gdb_stderr</code>, <code>gdb_stdtarg</code> and
|
||||
<code>gdb_stdout</code> streams.
|
||||
<li>The client creates a separate custom <code>ui-out</code> builder that is only
|
||||
used while making direct queries to <code>libgdb</code>.
|
||||
</ul>
|
||||
|
||||
<p>When the client receives input intended for the CLI, it simply passes it
|
||||
along. Since the <code>cli-out</code> builder is installed by default, all
|
||||
the CLI output in response to that command is routed (pronounced rooted)
|
||||
through to the client controlled <code>gdb_stdout</code> et. al. streams.
|
||||
At the same time, the client is kept abreast of internal changes by
|
||||
virtue of being a <code>libgdb</code> observer.
|
||||
|
||||
<p>The only restriction on the client is that it must wait until
|
||||
<code>libgdb</code> becomes idle before initiating any queries (using the
|
||||
client's custom builder).
|
||||
|
||||
<h3 class="section">5.5 <code>libgdb</code> components</h3>
|
||||
|
||||
<h4 class="subheading">Observer - <samp><span class="file">gdb-events.h</span></samp></h4>
|
||||
|
||||
<p><samp><span class="file">gdb-events</span></samp> provides the client with a very raw mechanism that can
|
||||
be used to implement an observer. At present it only allows for one
|
||||
observer and that observer must, internally, handle the need to delay
|
||||
the processing of any event notifications until after <code>libgdb</code> has
|
||||
finished the current command.
|
||||
|
||||
<h4 class="subheading">Builder - <samp><span class="file">ui-out.h</span></samp></h4>
|
||||
|
||||
<p><samp><span class="file">ui-out</span></samp> provides the infrastructure necessary for a client to
|
||||
create a builder. That builder is then passed down to <code>libgdb</code>
|
||||
when doing any queries.
|
||||
|
||||
<h4 class="subheading">Event Loop - <samp><span class="file">event-loop.h</span></samp></h4>
|
||||
|
||||
<!-- There could be an entire section on the event-loop -->
|
||||
<p><samp><span class="file">event-loop</span></samp>, currently non-re-entrant, provides a simple event
|
||||
loop. A client would need to either plug its self into this loop or,
|
||||
implement a new event-loop that <span class="sc">gdb</span> would use.
|
||||
|
||||
<p>The event-loop will eventually be made re-entrant. This is so that
|
||||
<span class="sc">gdb</span> can better handle the problem of some commands blocking
|
||||
instead of returning.
|
||||
|
||||
<h4 class="subheading">Library - <samp><span class="file">gdb.h</span></samp></h4>
|
||||
|
||||
<p><samp><span class="file">libgdb</span></samp> is the most obvious component of this system. It provides
|
||||
the query interface. Each function is parameterized by a <code>ui-out</code>
|
||||
builder. The result of the query is constructed using that builder
|
||||
before the query function returns.
|
||||
|
||||
</body></html>
|
||||
|
||||
Loading…
Add table
Add a link
Reference in a new issue