Re: multi-arch notes (long); Was: Multi-arching tm_print_insn?

[Andrew Cagney <ac131313 at cygnus dot com>]

Oops,

There was a reason for changing the subject line.  I've attatched some
old notes.

	Andrew
Target specific commands.

Some *-tdep.c files define target specific commands (the mips-tdep.c
has plenty of examples).  If we start adding all of those commands in
then we will get caos.


Choices are:

	o	delete them

	o	make them context sensative
		(Don't mode me in.) so that they
		are only applicable when the
		relevant target is active

	o	re-do the syntax to be target
		specific (vis `sim *' that exists
		today).



================================================================


Shared library support and target VS host confusion.

A number of valid targets only build native:

hppa1.1-hp-hpux native somsolib.[hc] require native files
hppa1.1-hp-hpux10.20 native ditto
hppa1.1-hp-hpux10.30 native ditto
hppa1.1-hp-hpux11.00 native ditto
hppa1.1-hp-hpux9 native ditto

sparc-sun-solaris2 native Problems with procfs
sparc-sun-sunos native Problems in solib.c

In all cases the problem comes about because the shared library code
assumes that certain headers/functions are present on the build
machine.  Long term this should be fixed (however, this will be very
long term).

In the case of these targets the shared library code is also hobbled
by containing certain target specific conditionals.  Shared library
support as a target specific issue is complex a shared library
mechansim tends to depend on both the target architecture and the
object file format.


================================================================


Subject: Sketch of OO issues for multi-arch
Date: 21 Oct 1998 08:15:42 -0700
From:  (Andrew Cagney)
Organization: Cygnus Solutions news/mail gateway
To: 
Newsgroups: 


[This should be sgml'd or some-such]


Background.

Part of the multi-arch support within GDB is moving the target
architecture vectors away from hardwired code to a more OO like
arrangement.

A pragmatic restriction on GDB is that it be compilable with an ISO C
compiler so much of the framework being discussed below is required as
a mechanism that works around the lack of an OO language :-)



The status quo:

[Ref: devo/gdb/config/mips/tm-*]

The MIPS tm-*.h files probably best illustrate the two very similar
(but subtly different) techniques being used to build up target-arch
descriptions in the current GDB.

The first technique is to include a fairly generic mips/tm-*.h file
which provides fairly broad mips target definitions and then refine a
subset of those definitions to match the specific mips target of
interest.

The second technique (effectively the reverse of the first) is to
define some target specific macro and then include other tm-* files
which fill in missing parts using the target specific information.

[Ref: devo/gdb/*-tdep.c]

In addition to the target definitions, a target specific *-tdep.c file
is built.  Along with a number of target specific functions, this file
contains static pool of target-arch specific variables.

Finally, this file, using the __initialize* function, initialize any
complicated local objects.



Stages:

(Just a reminder)

The initial multi-arch implementation will only allow one
architectural instance at any time.  Consequently the first multi-arch
work will not need to worry about parameterizing all architecture
methods with the current architecture.  That will be implemented in a
later stage.

Eg:
        void f (int parm);
vs      void f (struct target *, int parm);



The proposals:



Overview (no surprises here):

Per the architecture document, all target specific architectural
information is moved into a struct.  Macro's that were previously
hard-wired to a specific targets definition are replaced with function
calls (via the struct) to the currently selected target code.



Detail - is it in here?



Initialization - registering a target-arch

Both bfd/ and opcodes/ contain a hardwired table of known
architectures customized (using #ifdef) for the toolchain being build.
sim/common/ in a similar fashion has a hardwired table of known
devices.

GDB, on the other hand, for the target-remote modules, uses a
`registrary' approach - each target-remote remote-*.c file registers
its interface during initialization.

My experience from sim/common/ + sim/ppc/ suggests that for
target-arch the target-remote registrary approach would be best.

Each *-tdep.c target-arch would register itself as being responsible
for one or more BFD archures.



Initialization - creating target-arch structures.

Each target may have associated with it a significant number of
architectural variants (For the MIPS, I've lost count!) and each of
these variants would need a separate, different, target-arch
structure.

Several mechanisms for creating these architectures were considered:
making them static; creating them all at initialization time; creating
them on-demand.

The last is to be used.  Only when a user selects a target-arch
(implicitly with `file ...', explicitly with `set architecture ..')
will the full target-arch struct be created an populated.

The registrary would also track which target-arch structures have
already been created - thus avoiding duplication.



Creation - inheritance by stealth

As noted in the intro, the existing tm-*.h mechanism uses #include
along with #ifdef and #undef#define to create static target-arch
inheritance. (tm-vr5000.h inherits tm-mips64.h inherits tm-mips.h?).

In a similar fashion, a given target-arch struct will be created by the
more specific architecture code first obtaining a target-arch struct
from a less specific architecture and then refining it to the specific
targets needs.

For instance, we would expect to see either of the initialization
sequences:

        vr5000:
                obj = create mips-64
                refine vr5000 aspects of obj

        mips-64:
                obj = create mips
                refine 64 bit aspects of obj

        mips:
                obj = create obj
                refine mips aspects of obj

and:

        vr5000:
                obj = create mips
                refine mips-64 aspects of obj
                refine vr5000 aspects of obj

(`refine mips-64 aspects of obj' would be an operation common to a
number of mips targets).
 
[Nothing original here, sim/common/ implements this successfully.  The
two alternatives roughly correspond to the techniques currently being
used by the existing tm-*.h #include maze]



Method invocation:

Some of the target-arch struct members will be function pointers vis:

        struct target_arch {
          ..

          int (*arch_op) (struct target_arch *, int parm);
          ..
        }

The `arch_op' being invoked using the mechanism:

        arch->arch_op (arch, ...);

For convenience, macro's (I could make them functions) will be
available that simplify this vis:

        #define ARCH_OP(a,p) (a)->arch_op ((a), p)

Notice that I've shown ARCH_OP parameterized with the current
architecture.

During the initial phase, ARCH_OP's definition will not be fully
parameterized vis:

        extern struct target_arch target_arch;
        #define ARCH_OP(p) (target_arch->arch_op) (p)

For optional functions, a predicate such as ``ARCH_OP_P(a)'' will be
available:

        if (ARCH_OP_P ())
          ARCH_OP (arg);

Pragmatics: In the longer term, when methods are parameterized with
their object, simplistic macros such as `#define ARCH_OP
(target_arch->arch_op)' which allow tests like if(ARCH_OP) will be
broken.

[Don't stake your life on my naming schema, don't stake your life on
that parameter]



target-arch specific data:

Some target-arch methods use external data (such as the target-remote
or the register file).

Since, initially, only one target can be active at any time this isn't
an issue.

Longer term, when everything becomes parameterized, there will be a
need to pass into target-arch methods the target-vector et.al. objects
that they are to act on.

It may turn out to be easier to have a single object that contains
each of the current target-specific comonents vis:

        struct target {
          ...
          struct target_arch *arch;
          struct target_remote *remote;
          ...
        }

each target-arch method parameterized with this super object.

[Note: this is an observation of an issue and not a commitment to a
specific solution].


================================================================


Date: Tue, 27 Oct 1998 15:33:46 +1100 (WET)
From: Andrew Cagney <>
To: The Wet Fish <>
Subject: Possible multi-arch testing extension ...

Hello,

This provides an overview of an additional work item that could be added
to the multi-arch GDB project.

The current intention is to test multi-arch functionality by extending
the existing GDB testsuite with a single multi-arch test.  That test
would put GDB through its paces in a very rudimentary way - simply
confirming that the same GDB was capable of talking to several different
targets.

Orthogonal to this is the suggestion that the GDB testsuite be modified
so that it can be used to run the full testsuite for all (some sub-set)
of compiled in GDB targets.  It's important to note several issues this
possibility raises:

	o	The overall build environment isn't geared
		up for this.

		For instance, only a single target (or target) group
		are supported by GCC.

		Consequently to fully exercise a multi-arch GDB
		a number of pre-installed compilers would be needed.
		A typical test-run would continue to be focused
		on a specific target.


	o	There are two ways of covering the arch-X-test matrix.

		arch-X-test: for all arch ; do for all test ; do ...
			and
		test-X-arch: for all test; do for all arch ; do ...

		Provided the testing framework allows you to limit
		a test-run to a specific test or a specific target these
		two alternatives are pretty much equivalent.

So.

The additional work item is to investigate ways of changing the GDB test
framework so that it allows the running of the full testsuite against a
number of targets.  newlib may well prove to be a useful source of
idea's.

At the conclusion of this work, a single GDB binary could be
demonstrated running the full testsuite for two different architectures.

For the moment I'll treat this as `further work'.


================================================================


Simulators.

Only one builtin simulator target will be supported.  This project is
not about supporting multiple internal simulators.

Multiple simulator targets from a single gdb will, eventually, be
supported through the use of separate simulator programs and a remote
serial protocol.

This isn't part of the initial work-plan and is left as a things to
do.


----------------------------------------------------------------

CALL_DUMMY, FIX_CALL_DUMMY, CALL_DUMMY_START_OFFSET,
CALL_DUMMY_LOCATION, PC_IN_CALL_DUMMY et.al.

GDB has two very different mechanisms for implementing inferior
function calls - the old (a bunch of macro's including CALL_DUMMY) and
the new (see blockframe.c).

Key among the differences are: saving the current context locally
instead of on the target stack; and restarting by setting the PC to
the function entry point instead of hacking up a dummy function call
somewhere in the target memory.

Multi-arch must support both - trying to rewrite the old is not within
the scope of this project.

Changes required - the new code is a `done'.  The old code will
require the migration of macro's out of inferior.h into valops.c.

CALL_DUMMY_LOCATION should be changed to an enum; CALL_DUMMY needs to
be a char*; SIZEOF_CALL_DUMMY needed; ...


----------------------------------------------------------------


@item BELIEVE_PCC_PROMOTION
@item BELIEVE_PCC_PROMOTION_TYPE

Minor changes required.

coffread.c - the #if can be replaced with an if()else. defs.h - a
default value of zero should be provided. stabsread.c - the suplying
of a default value should be moved to defs.h, the #if mess should be
re-aranged to a set of if()else.


----------------------------------------------------------------


@item CPLUS_MARKER

Changes required.

Since almost all uses of CPLUS_MARKER appear as an initialization
element of static array's the first thought is to replace those static
arrays with dynamic ones. Further investigation, however, suggests
that it will be easier to just rewrite the code using those arrays to
explicitly test against the CPLUS_MARKER character.

cp-valprint.c - Need to rewrite the test in cp_is_vtbl_ptr_type() so
that it explictily tests for CPLUS_MARKER=='.'.  Better might be to
use that common struct.

demangle.c - rewrite is_cplus_marker() to test for c==CPLUS_MARKER
explicitily.

Long term, since this is dynamic, there is no reason for not adding a
command to gdb so that the user can set/query it.  Might even serve as
an excuse for the demangle.c tweeks that need to be made.


----------------------------------------------------------------


@item DECR_PC_AFTER_BREAK et.al.

No changes required.

In the short term this can just be another target variable.  In the
longer term it would probably be a good idea to push this whole
problem into the target so that GDB never knows about post breapoint
pc decrementing.


----------------------------------------------------------------


@item EXTRA_FRAME_INFO
@item INIT_EXTRA_FRAME_INFO
@item INIT_FRAME_PC_FIRST
@item INIT_FRAME_PC

Changes required.

Per target data being stored in `struct frame_info'.  In OO terms, a
target specific frame object inheriting from the generic frame_info
object.

Will need to replace that data with a reference to target specific
data.  Will need functions for all those INIT_*FRAME* operations.


----------------------------------------------------------------


@item GCC_COMPILED_FLAG_SYMBOL
@item GCC2_COMPILED_FLAG_SYMBOL

Changes required.

Make these target specific pointers.  symtab.h - delete the default
definitions of *_COMPILED_FLAG_SYMBOL.


----------------------------------------------------------------


@item GDB_TARGET_IS_HPPA
@item GDB_TARGET_IS_MACH386
@item GDB_TARGET_IS_SUN3
@item GDB_TARGET_IS_SUN386
@item IBM6000_TARGET

Later, much later.

These will be the first against the wall when the revolution comes.
Or, to put it another way, we'll wear these until they can be deleted
at the end of multi-arch conversion.


----------------------------------------------------------------


@item GET_LONGJMP_TARGET

Changes required.

Delete default definition of GET_LONGJMP_TARGET from infrun.c.  Add a
function that returns a default value.  Always implement
GET_LONGJMP_TARGET for all *-tdep.c's.

Will encounter namespace problems - get_longjmp_target() is overloaded
-> need to rename target specific versions of this function.


----------------------------------------------------------------


@item IN_SOLIB_TRAMPOLINE pc name

This is dead.  It was replaced by:

@item IN_SOLIB_CALL_TRAMPOLINE
@item IN_SOLIB_RETURN_TRAMPOLINE


----------------------------------------------------------------


@item KERNEL_DEBUGGING

Later.  This is for an obscure (well I think it is) target that will
hopefully allow everything to go away.


----------------------------------------------------------------


@item NO_HIF_SUPPORT

Later.  This is for an obscure target.


----------------------------------------------------------------


@item PC_REGNUM
@item PS_REGNUM
@item TARGET_WRITE_PC et.al.
@item NPC_REGNUM
@item NNPC_REGNUM
@item MAX_REGISTER_RAW_SIZE
@item REGISTER_VIRTUAL_TYPE
@item NUM_REGS
@item MAX_REGISTER_VIRTUAL_SIZE
@item REGISTER_RAW_SIZE
@item REGISTER_VIRTUAL_SIZE
@item REGISTER_BYTE
@item PRINT_REGISTER_HOOK (regno)

Arrrrh.  Ah, that feels better.

Date: Mon, 26 Oct 1998 16:44:25 +1100 (WET)
From: Andrew Cagney <>
To: 
Subject: registers part of target-arch object

[With additional edits]

An FYI more than anything.

Most of the architecture specific code is `static' in that it doesn't
change for a given target.
Select a specific architecture and one can define a set of functions
that describe that architecture's functionality.

The quirk with this is the `register set'.  At present targets describe
registers in an implementation specific way - the target-arch's assume
that GDB has some physical block of of memory that contains all
registers.

In adding multi-arch support I've two alternatives:

	o	stick with this existing code (at least
		in the short term).

	o	come up with some new and exciting
		register description.


My intention is to stick with the existing code.  In particular:


	o	have each target architecture continue to describe
		registers at this implementation specific way.

		This limits the potential damage to all the target
		config/*/tm-* that will need converting.


	o	bind the register data 1-1 to the target architecture
		it belongs to.  This limits GDB to one active instance
		of a specific target. (GDB can't simultaneously to
		several physical targets of the same architecture
		aka unrestricted mixed-arch support).

		This limits the potential damage to the generic
		gdb register code (such as valops.c).


The consequences of the second point are especially important:


	o	It leaves GDB with the restriction of an architecture
		being bound to a single physical target at any time.
		(VS actively debugging several targets each with
		the same architecture.)
		

	o	It doesn't stop GDB being attached to several
		physical targets, each with a different architecture.


	o	It doesn't stop GDB being modified so that a
		target architecture contains an internal mechanism
		that switchs between target interfaces.

		It is only that externally there appears to be a single
		register interface.
		

	o	It doesn't attempt to address the issue of how the
		overall GDB architecture should be should be changed
		that it fully supports mixed-architectures.

		That issue is beyond the scope of the current work.


The overall consequences are:


	o	limited collateral damage

		We're not trying to rewrite the register code
		at the same time as we introduce multi-arch.


	o	register re-design becomes feasible

		Once the multi-arch framework is in place
		significant cross-architecture changes such
		as a new register mechanism become feasible.


	o	mixed-arch unhindered.

		As per the revised multi-arch objectives:
		``The objective is to add multi-arch support in a way
		that doesn't hinder the following goals [multi-arch]''

		We've made significant improvements without
		commiting ourselves to a specific mixed-arch design.


================================================================


Turns out that defining TARGET_{FETCH,STORE}_PC does not oblivate the
need for PC_REGNUM.  See write_register_gen.



parse.c:std_regs[].  Hmm, this should just be thrown back at the
target.  For moment just disable it...


I think value_ptr should go!



GET_SAVED_REGISTER should define the function to call not just flip
the code.


enum target_signal doesn't get correctly exposed for everything to work.


================================================================

Phase two:


VARIABLES_INSIDE_BLOCK: Only sparc and convex.

SUN_FIXED_LBRAC_BUG: Only sparc/m78k.

PCC_SOL_BROKEN: Only convex

DISABLE_UNSETTABLE_BREAK: I some config/*/tm-*.h's are including
"solib.h" which is in turn defining DISABLE_UNSETTABLE_BREAK.  An
example of this is tm-sunos.h.  Interestingly, many config/nm-*.h's
also include "solib.h" which suggests that shared library support as a
pure target operation isn't quite there yet. :-(.  In the long run, a
revamping of the shared library stuff so that it is truely based on
the selected target is needed, in the mean time, limiting shared
library to single-arch GDB's will be easier.



================================================================

Phase three:

SYMBOL_RELOADING_DEFAULT: Delete.  No longer defined in current
sources.

SHIFT_INST_REGS: Only used by *old* m88k targets. Called from infrun.c
and infcmd.c.  In both cases it can probably be re-vamped so that it
totally goes away.

PROLOGUE_FIRSTLINE_OVERLAP: This is only applicable to the convex
target which we don't even try to build!

BREAKPOINT, BIG_BREAKPOINT, LITTLE_BREAKPOINT: Delete this, replace
them with BREAKPOINT_FROM_PC.

REMOTE_BREAKPOINT, BIG_REMOTE_BREAKPOINT, LITTLE_REMOTE_BREAKPOINT:
Targets that use this are not supported (sh, m68k, h830).

USE_STRUCT_CONVENTION: Function of type use_struct_convention_fn.

PRINT_TYPELESS_INTEGER: Don't bother fixing this one.

OS9K_VARIABLES_INSIDE_BLOCK: I think that this is dead.

PC_LOAD_SEGMENT: Specific xcoff (rs6000).  Is actually an object file
macro.  Should be re-written so that all object file handlers provide
a similar module.

CORE_ADDR: This does not specify a type that exactly fits a target
address.  Consequently, a 64 bit unsigned integer will be sufficient,
in the short term, as the CORE_ADDR address.  Longer term we want some
sort of object.

CHILL_PRODUCER, GCC_PRODUCER, GPLUS_PRODUCER, LCC_PRODUCER: These
macro's don't have anything to do with the target.  Rather they are
concerned with object file formats and and identifying characteristics
of same.  Perhaphs they are better placed in BFD?

END_OF_TEXT_DEFAULT: This macro is really specific to the GOULD
architecture.  It may well be possible to put this off until when it
isn't needed.




================================================================


Not documented:

MAX_REGISTER_RAW_SIZE
REGISTER_VIRTUAL_TYPE
NUM_REGS
VALUE_OF_TRAPPED_INTERNALVAR
CALL_DUMMY_START_OFFSET
FRAME_ARGS_SKIP
MAX_REGISTER_VIRTUAL_SIZE
REGISTER_RAW_SIZE
REGISTER_VIRTUAL_SIZE
REGISTER_BYTE
SET_TRAPPED_INTERNALVAR
FRAME_ARGS_ADDRESS
FRAME_LOCALS_ADDRESS
FIX_CALL_DUMMY
STORE_STRUCT_RETURN
SAVED_PC_AFTER_CALL

================================================================

Check list:

Registers
Types
Call Dummy
Registrary

A0_REGNUM
A2_REGNUM
A3_REGNUM
ADDR_BITS_REMOVE
AS_PROC_NAME_FMT
ATTACH_DETACH
BADVADDR_REGNUM
BELIEVE_PCC_PROMOTION
BIG_ENDIAN
BPT_ELEM_SZ
BREAKPOINT_FROM_PC
BROKEN_SIGINFO_H
CALL_DUMMY
CALL_DUMMY_ADDRESS
CALL_DUMMY_BREAKPOINT_OFFSET
CALL_DUMMY_LENGTH
CALL_DUMMY_LOCATION
CALL_DUMMY_START_OFFSET
CANNOT_STORE_REGISTER
CAUSE_REGNUM
CHILD_PREPARE_TO_STORE
CHILD_SPECIAL_WAITSTATUS
COERCE_FLOAT_TO_DOUBLE
CONVERT_FROM_FUNC_PTR_ADDR
CPLUS_MARKER
CR_REGNUM
CTL_PROC_NAME_FMT
CTR_REGNUM
D2_REGNUM
D3_REGNUM
DECR_PC_AFTER_BREAK
DEFAULT_LR_SAVE
DEFAULT_MIPS_TYPE
DEFAULT_PROMPT
DO_REGISTERS_INFO
DWARF_REG_TO_REGNUM
Dest_Reg
E0_REGNUM
ECOFF_REG_TO_REGNUM
ELF_MAKE_MSYMBOL_SPECIAL
ELF_OBJECT_FORMAT
EXTRACT_RETURN_VALUE
EXTRACT_STRUCT_VALUE_ADDRESS
EXTRA_FRAME_INFO
FAULTED_USE_SIGINFO
FCRCS_REGNUM
FCRIR_REGNUM
FETCH_INFERIOR_REGISTERS
FIFO_BPT_CNT
FIFO_BPT_TBL
FIRST_COP0_REG
FIRST_EMBED_REGNUM
FIRST_SP_REGNUM
FIRST_VEC_REG
FIVE_ARG_PTRACE
FIX_CALL_DUMMY
FP0_REGNUM
FPA0_REGNUM
FPLAST_REGNUM
FP_REGNUM
FRAMELESS_FUNCTION_INVOCATION
FRAME_ARGS_ADDRESS
FRAME_ARGS_SKIP
FRAME_CHAIN
FRAME_CHAIN_VALID
FRAME_CHAIN_VALID_ALTERNATE
FRAME_FIND_SAVED_REGS
FRAME_LOCALS_ADDRESS
FRAME_NUM_ARGS
FRAME_SAVED_PC
FUNCTION_START_OFFSET
GDBINIT_FILENAME
GDB_COMM_AREA
GDB_COMM_SIZE
GDB_TARGET_IS_MIPS64
GDB_TARGET_MASK_DISAS_PC
GDB_TARGET_POWERPC
GDB_TARGET_UNMASK_DISAS_PC
GET_LONGJMP_TARGET
GET_SAVED_REGISTER
GP0_REGNUM
HANDLE_SVR4_EXEC_EMULATORS
HAVE_NONSTEPPABLE_WATCHPOINT
HAVE_SIGSETMASK
HAVE_TERMIO
HAVE_TERMIOS
HI_REGNUM
HOST_BYTE_ORDER
IBM6000_TARGET
IEEE_FLOAT
IGNORE_HELPER_CALL
INIT_EXTRA_FRAME_INFO
INIT_FRAME_PC
INIT_FRAME_PC_FIRST
INNER_THAN
IN_SIGTRAMP
IN_SOLIB_CALL_TRAMPOLINE
IN_SOLIB_RETURN_TRAMPOLINE
IS_MIPS16_ADDR
JB_ELEMENT_SIZE
JB_G1
JB_NPC
JB_O0
JB_ONSSTACK
JB_PC
JB_PSR
JB_SIGMASK
JB_SP
JB_WBCNT
KERNEL_U_ADDR
KERNEL_U_SIZE
LAR_REGNUM
LAST_DEVICE
LAST_EMBED_REGNUM
LAST_SP_REGNUM
LIR_REGNUM
LO_REGNUM
LR_REGNUM
LSEEK_NOT_LINEAR
MACHINE_CPROC_FP_OFFSET
MACHINE_CPROC_PC_OFFSET
MACHINE_CPROC_SP_OFFSET
MAKE_MIPS16_ADDR
MAP_PROC_NAME_FMT
MAX_REGISTER_RAW_SIZE
MAX_REGISTER_VIRTUAL_SIZE
MDR_REGNUM
MIPS16_INSTLEN
MIPS_DEFAULT_FPU_TYPE
MIPS_EABI
MIPS_EFI_SYMBOL_NAME
MIPS_FPU_DOUBLE_REGSIZE
MIPS_FPU_SINGLE_REGSIZE
MIPS_INSTLEN
MIPS_LAST_ARG_REGNUM
MIPS_LAST_FP_ARG_REGNUM
MIPS_NUMREGS
MIPS_NUM_ARG_REGS
MIPS_REGSIZE
MQ_REGNUM
MSYMBOL_IS_SPECIAL
MSYMBOL_SIZE
NBPG
NM_NEWS_MIPS_H
NM_RS6000LYNX_H
NULL
NUM_COP0_REGS
NUM_CORE_REGS
NUM_REGS
NUM_VIF_REGS
NUM_VU_INTEGER_REGS
NUM_VU_REGS
ONE_PROCESS_WRITETEXT
OP_LDFPR
OP_LDGPR
PCB_OFFSET
PC_IN_CALL_DUMMY
PC_LOAD_SEGMENT
PC_REGNUM
POP_FRAME
PRID_REGNUM
PRINT_EXTRA_FRAME_INFO
PROCESS_LINENUMBER_HOOK
PRSVADDR_BROKEN
PSW_REGNUM
PS_REGNUM
PTRACE_ARG3_TYPE
PTRACE_ATTACH
PTRACE_DETACH
PUSH_ARGUMENTS
PUSH_DUMMY_FRAME
PUSH_RETURN_ADDRESS
R5900_128BIT_GPR_HACK
RA_REGNUM
REGISTER_BYTE
REGISTER_BYTES
REGISTER_CONVERTIBLE
REGISTER_CONVERT_FROM_TYPE
REGISTER_CONVERT_TO_RAW
REGISTER_CONVERT_TO_TYPE
REGISTER_CONVERT_TO_VIRTUAL
REGISTER_NAMES
REGISTER_NAME_ALIAS_HOOK
REGISTER_RAW_SIZE
REGISTER_SIZE
REGISTER_U_ADDR
REGISTER_VIRTUAL_SIZE
REGISTER_VIRTUAL_TYPE
REG_STRUCT_HAS_ADDR
REQUEST_QUIT
ROOTED_P
SAVED_BYTES
SAVED_FP
SAVED_PC
SAVED_PC_AFTER_CALL
SETPGRP_ARGS
SETUP_ARBITRARY_FRAME
SIGCONTEXT_PC_OFFSET
SIGFRAME_BASE
SIGFRAME_FPREGSAVE_OFF
SIGFRAME_PC_OFF
SIGFRAME_REGSAVE_OFF
SIGFRAME_REG_SIZE
SIGWINCH_HANDLER
SIGWINCH_HANDLER_BODY
SIG_FRAME_FP_OFFSET
SIG_FRAME_LR_OFFSET
SIG_FRAME_PC_OFFSET
SKIP_PROLOGUE
SKIP_TRAMPOLINE_CODE
SLASH_CHAR
SLASH_P
SLASH_STRING
SOFTWARE_SINGLE_STEP
SOFTWARE_SINGLE_STEP_P
SOFUN_ADDRESS_MAYBE_MISSING
SOLIB_ADD
SOLIB_CREATE_INFERIOR_HOOK
SP_REGNUM
SR_REGNUM
STAB_REG_TO_REGNUM
STACK_END_ADDR
START_INFERIOR_TRAPS_EXPECTED
STATIC_TRANSFORM_NAME
STATUS_PROC_NAME_FMT
STEP_SKIPS_DELAY
STEP_SKIPS_DELAY_P
STOPPED_BY_WATCHPOINT
STORE_RETURN_VALUE
STORE_STRUCT_RETURN
T9_REGNUM
TABULAR_REGISTER_OUTPUT
TARGET_BYTE_ORDER
TARGET_BYTE_ORDER_SELECTABLE
TARGET_CAN_USE_HARDWARE_WATCHPOINT
TARGET_HAS_HARDWARE_WATCHPOINTS
TARGET_KEEP_SECTION
TARGET_LONG_BIT
TARGET_LONG_LONG_BIT
TARGET_MIPS
TARGET_MN10300
TARGET_MONITOR_PROMPT
TARGET_PTR_BIT
TARGET_READ_FP
TARGET_READ_PC
TARGET_READ_SP
TARGET_REDEFINE_DEFAULT_OPS
TARGET_SYMFILE_POSTREAD
TARGET_VIRTUAL_FRAME_POINTER
TARGET_WRITE_FP
TARGET_WRITE_SP
TEXT_SEGMENT_BASE
TM_MIPS_H
TM_PPCLE_EABI_H
TM_PPCLE_SIM_H
TM_PPC_AIX_H
TM_PPC_EABI_H
TM_PPC_NW_H
TM_PPC_SIM_H
TM_PRINT_INSN_MACH
TM_RS6000LYNX_H
TM_RS6000_AIX4_H
TM_TXVU_H
TOC_REGNUM
TRACE_CLEAR
TRACE_FLAVOR
TRACE_FLAVOR_SIZE
TRACE_SET
TXVU_CPU_NUM
TXVU_SET_CPU_HELP_STRING
TXVU_VIF_BRK_MASK
TXVU_VU_BRK_MASK
UNMAKE_MIPS16_ADDR
UNUSED_REGNUM
UPAGES
USE_GENERIC_DUMMY_FRAMES
USE_O_NOCTTY
USE_PROC_FS
USE_STRUCT_CONVENTION
USG
U_REGS_OFFSET
V0_REGNUM
VIF0_PC_REGNUM
VIF1_PC_REGNUM
VU0_PC_REGNUM
VU0_RA_REGNUM
VU0_SP_REGNUM
VU1_PC_REGNUM
VU1_RA_REGNUM
VU1_SP_REGNUM
VX_NUM_REGS
XER_REGNUM
XM_RS6000LYNX_H
ZERO_REGNUM
_BSD_COMPAT
setpgrp
target_insert_watchpoint
target_remove_watchpoint
vfork