* a29k-pinsn.c: Renamed from am29k-pinsn.c.
* a29k-tdep.c: Renamed from am29k-tdep.c.
* remote-eb.c, config/a29k/tm-ultra3.h: Include renamed tm-a29k.h.
* remote-monitor.c, remote-st2000.c, config/a29k/{nm-ultra3.h,
tm-a29k.h, xm-ultra3.h}, config/romp/rtbsd.mh, doc/gdbinv-s.texi,
testsuite/gdb.t15/funcargs.exp, testsuite/gdb.t17/callfuncs.exp:
Map '29k' to 'a29k'.
* config/a29k/{a29k-kern.mt, a29k-udi.mt, a29k.mt, ultra3.mt}
(TDEPFILES): Use renamed a29k-pinsn.o and a29k-tdep.o.
* config/a29k/{a29k-udi.mt, a29k.mt} (TM_FILE): Use renamed
tm-a29k.h.
* config/a29k/a29k-udi.mt (MT_CFLAGS): Remove TARGET_AM29K
define that does not appear anywhere else in the gdb source tree.
* doc/gdbinit.texinfo: Document renaming of tm-29k.h to tm-a29k.h.
+Mon Mar 29 15:03:25 1993 Fred Fish (fnf@cygnus.com)
+
+ * config/a29k/tm-a29k.h: Renamed from config/a29k/tm-29k.h.
+ * a29k-pinsn.c: Renamed from am29k-pinsn.c.
+ * a29k-tdep.c: Renamed from am29k-tdep.c.
+ * remote-eb.c, config/a29k/tm-ultra3.h: Include renamed tm-a29k.h.
+ * remote-monitor.c, remote-st2000.c, config/a29k/{nm-ultra3.h,
+ tm-a29k.h, xm-ultra3.h}, config/romp/rtbsd.mh, doc/gdbinv-s.texi,
+ testsuite/gdb.t15/funcargs.exp, testsuite/gdb.t17/callfuncs.exp:
+ Map '29k' to 'a29k'.
+ * config/a29k/{a29k-kern.mt, a29k-udi.mt, a29k.mt, ultra3.mt}
+ (TDEPFILES): Use renamed a29k-pinsn.o and a29k-tdep.o.
+ * config/a29k/{a29k-udi.mt, a29k.mt} (TM_FILE): Use renamed
+ tm-a29k.h.
+ * config/a29k/a29k-udi.mt (MT_CFLAGS): Remove TARGET_AM29K
+ define that does not appear anywhere else in the gdb source tree.
+ * doc/gdbinit.texinfo: Document renaming of tm-29k.h to tm-a29k.h.
+
Mon Mar 29 13:55:29 1993 Jim Kingdon (kingdon@cygnus.com)
* xcoffread.c (sort_syms, compare_symbols): Remove.
* xcoffread.c: Nuke NAMES_HAVE_DOT define (not used).
-Fri Mar 26 11:29:30 1993 Jim Kingdon (kingdon@cygnus.com)
-
- * breakpoint.{c,h}: Add exp_string to struct breakpoint and use
- it in breakpoint_re_set.
-
Sun Mar 28 11:24:37 1993 Peter Schauer (pes@regent.e-technik.tu-muenchen.de)
* breakpoint.c (breakpoint_re_set_one): Fix storage leak.
Fri Mar 26 11:29:30 1993 Jim Kingdon (kingdon@cygnus.com)
+ * breakpoint.{c,h}: Add exp_string to struct breakpoint and use
+ it in breakpoint_re_set.
* breakpoint.c (watch_command, enable_breakpoint): Fetch lazy values.
* rs6000-tdep.c (single_step): Misc cleanups (CORE_ADDR not int,
}
/* Print one instruction from MEMADDR on STREAM.
- Return the size of the instruction (always 4 on am29k). */
+ Return the size of the instruction (always 4 on a29k). */
int
print_insn (memaddr, stream)
CORE_ADDR memaddr;
/* Initialize the frame. In addition to setting "extra" frame info,
we also set ->frame because we use it in a nonstandard way, and ->pc
because we need to know it to get the other stuff. See the diagram
- of stacks and the frame cache in tm-29k.h for more detail. */
+ of stacks and the frame cache in tm-a29k.h for more detail. */
static void
init_frame_info (innermost_frame, fci)
int innermost_frame;
# As compared to ordinary remote 29K debugging, this changes the register
# numbering a bit, to hold kernel regs, and adds support for looking at
# the upage.
-TDEPFILES= exec.o am29k-pinsn.o am29k-tdep.o remote-mm.o remote-adapt.o
+TDEPFILES= exec.o a29k-pinsn.o a29k-tdep.o remote-mm.o remote-adapt.o
TM_FILE= tm-ultra3.h
MT_CFLAGS = -DKERNEL_DEBUGGING -DNO_HIF_SUPPORT
# Target: AMD 29000 on EB29K board over a serial line.
-TDEPFILES= exec.o am29k-pinsn.o remote-udi.o am29k-tdep.o udip2soc.o udr.o
-TM_FILE= tm-29k.h
+TDEPFILES= exec.o a29k-pinsn.o remote-udi.o a29k-tdep.o udip2soc.o udr.o
+TM_FILE= tm-a29k.h
# The following is for ../include/a.out.encap.h
-MT_CFLAGS = -Da29k -DREMOTE -DTARGET=TARGET_AM29K -DAMD_COFF
+MT_CFLAGS = -Da29k -DREMOTE -DAMD_COFF
# Adapt (remote-adapt.c),
# or a MiniMon debugger (remote-mm.c).
# Or run native on an Ultracomputer.
-TDEPFILES= exec.o am29k-pinsn.o am29k-tdep.o remote-eb.o remote-mm.o remote-adapt.o
-TM_FILE= tm-29k.h
+TDEPFILES= exec.o a29k-pinsn.o a29k-tdep.o remote-eb.o remote-mm.o remote-adapt.o
+TM_FILE= tm-a29k.h
MT_CFLAGS = -DNO_HIF_SUPPORT
-/* Host definitions for GDB running on a 29k NYU Ultracomputer
+/* Host definitions for GDB running on an a29k NYU Ultracomputer
Copyright (C) 1986, 1987, 1989, 1991, 1992 Free Software Foundation, Inc.
Contributed by David Wood (wood@lab.ultra.nyu.edu).
accessed through EBMON software running on the PC, which we
use as we'd use a remote stub (see remote-eb.c).
- If gdb is ported to other 29k machines/systems, the
+ If gdb is ported to other a29k machines/systems, the
machine/system-specific parts should be removed from this file (a
la tm-68k.h). */
#define DECR_PC_AFTER_BREAK 0
/* Nonzero if instruction at PC is a return instruction.
- On the 29k, this is a "jmpi l0" instruction. */
+ On the a29k, this is a "jmpi l0" instruction. */
#define ABOUT_TO_RETURN(pc) \
((read_memory_integer (pc, 4) & 0xff0000ff) == 0xc0000080)
\f
/* Store the address of the place in which to copy the structure the
subroutine will return. This is called from call_function. */
-/* On the 29k the LRP points to the part of the structure beyond the first
+/* On the a29k the LRP points to the part of the structure beyond the first
16 words. */
#define STORE_STRUCT_RETURN(ADDR, SP) \
write_register (LRP_REGNUM, (ADDR) + 16 * 4);
/* Should call_function allocate stack space for a struct return? */
-/* On the 29k objects over 16 words require the caller to allocate space. */
+/* On the a29k objects over 16 words require the caller to allocate space. */
#define USE_STRUCT_CONVENTION(gcc_p, type) (TYPE_LENGTH (type) > 16 * 4)
/* Extract from an array REGBUF containing the (raw) register state
TYPE_LENGTH (TYPE)); \
}
\f
-/* The am29k user's guide documents well what the stacks look like.
+/* The a29k user's guide documents well what the stacks look like.
But what isn't so clear there is how this interracts with the
symbols, or with GDB.
In the following saved_msp, saved memory stack pointer (which functions
before trying to print arguments or anything.
The following diagram attempts to depict what is going on in memory
- (see also the _am29k user's guide_) and also how that interacts with
+ (see also the _a29k user's guide_) and also how that interacts with
GDB frames. We arbitrarily pick fci->frame to point the same place
as the register stack pointer; since we set it ourself in
INIT_EXTRA_FRAME_INFO, and access it only through the FRAME_*
(1) as a "magic cookie" which uniquely identifies frames (even over
calls to the inferior), (2) (in PC_IN_CALL_DUMMY [ON_STACK])
as the value of SP_REGNUM before the dummy frame was pushed. These
- two meanings would be incompatible for the 29k if we defined
+ two meanings would be incompatible for the a29k if we defined
CALL_DUMMY_LOCATION == ON_STACK (but we don't, so don't worry about it).
Also note that "lr1" below, while called a frame pointer
in the user's guide, has only one function: To determine whether
However, if FRAME_CHAIN_VALID returns zero,
it means the given frame is the outermost one and has no caller. */
-/* On the 29k, the nominal address of a frame is the address on the
+/* On the a29k, the nominal address of a frame is the address on the
register stack of the return address (the one next to the incoming
arguments, not down at the bottom so nominal address == stack pointer).
However, that doesn't work for us, so when creating the innermost
frame we set ->frame ourselves in INIT_EXTRA_FRAME_INFO. */
-/* These are mostly dummies for the 29k because INIT_FRAME_PC
+/* These are mostly dummies for the a29k because INIT_FRAME_PC
sets prev->frame instead. */
#define FRAME_CHAIN(thisframe) ((thisframe)->frame + (thisframe)->rsize)
#define FRAME_ARGS_SKIP 0
/* Provide our own get_saved_register. HAVE_REGISTER_WINDOWS is insufficient
- because registers get renumbered on the 29k without getting saved. */
+ because registers get renumbered on the a29k without getting saved. */
#define GET_SAVED_REGISTER
\f
the msp, it won't end up larger than mfp_dummy (it is needed in the
case where margs and struct_ret do not add up to at least 16 words).
struct ret: This area is allocated by GDB if the return value is more
- than 16 words. struct ret_16 is not used on the 29k.
+ than 16 words. struct ret_16 is not used on the a29k.
margs: Pushed by GDB. The call dummy copies the first 16 words to
args_out_dummy.
retaddr_sproc: Contains the PC at the time we call the function.
into a call sequence of the above form stored at DUMMYNAME. */
/* Currently this stuffs in the address of the function that we are calling.
- Since different 29k systems use different breakpoint instructions, it
+ Since different a29k systems use different breakpoint instructions, it
also stuffs BREAKPOINT in the right place (to avoid having to
duplicate CALL_DUMMY in each tm-*.h file). */
/* FIXME memcpy ((char *)(dummyname) + BREAKPT_INSN, break_insn, 4); */ \
}
-/* 29k architecture has separate data & instruction memories -- wired to
+/* a29k architecture has separate data & instruction memories -- wired to
different pins on the chip -- and can't execute the data memory.
Also, there should be space after text_end;
we won't get a SIGSEGV or scribble on data space. */
along with this program; if not, write to the Free Software
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. */
-/* This file includes tm-29k.h, but predefines REGISTER_NAMES and
- related macros. The file supports a 29k running our flavor of
+/* This file includes tm-a29k.h, but predefines REGISTER_NAMES and
+ related macros. The file supports a a29k running our flavor of
Unix on our Ultra3 PE Boards. */
/* Byte order is configurable, but this machine runs big-endian. */
#endif
#endif /* !KERNEL_DEBUGGING */
-#include "a29k/tm-29k.h"
+#include "a29k/tm-a29k.h"
-/**** The following are definitions that override those in tm-29k.h ****/
+/**** The following are definitions that override those in tm-a29k.h ****/
/* This sequence of words is the instructions
mtsrim cr, 15
# Target: AMD 29000 running Unix on New York Univerisity processor board.
-TDEPFILES= am29k-pinsn.o am29k-tdep.o
+TDEPFILES= a29k-pinsn.o a29k-tdep.o
TM_FILE= tm-ultra3.h
# SYM1 is some OS they have.
MT_CFLAGS = -DSYM1
-/* Host definitions for GDB running on a 29k NYU Ultracomputer
+/* Host definitions for GDB running on an a29k NYU Ultracomputer
Copyright (C) 1986, 1987, 1989, 1991 Free Software Foundation, Inc.
Contributed by David Wood (wood@lab.ultra.nyu.edu).
/* Here at NYU we have what we call an ULTRA3 PE board. So
ifdefs for ULTRA3 are my doing. At this point in time,
- I don't know of any other Unixi running on the 29k. */
+ I don't know of any other Unixi running on the a29k. */
#define HOST_BYTE_ORDER BIG_ENDIAN
remote-mm.c
@item NO_JOB_CONTROL
signals.h
-@item NO_MALLOC_CHECK
-utils.c
-@item NO_MMALLOC
-utils.c
-@item NO_MMALLOC
-objfiles.c
@item NO_MMALLOC
-utils.c
+GDB will use the @code{mmalloc} library for memory allocation for symbol
+reading, unless this symbol is defined. Define it on systems
+on which @code{mmalloc} does not
+work for some reason. One example is the DECstation, where its RPC
+library can't cope with our redefinition of @code{malloc} to call
+@code{mmalloc}. When defining @code{NO_MMALLOC}, you will also have
+to override the setting of @code{MMALLOC_LIB} to empty, in the Makefile.
+Therefore, this define is usually set on the command line by overriding
+@code{MMALLOC_DISABLE} in @file{config/*.mh}, rather than by defining
+it in @file{xm-*.h}.
+@item NO_MMALLOC_CHECK
+Define this if you are using @code{mmalloc}, but don't want the overhead
+of checking the heap with @code{mmcheck}.
@item NO_SIGINTERRUPT
remote-adapt.c
@item NO_SINGLE_STEP
@item REGISTER_BYTES
remote.c
@item REGISTER_NAMES
-tm-29k.h
+tm-a29k.h
@item REG_STACK_SEGMENT
exec.c
@item REG_STRUCT_HAS_ADDR
xcoffread.c
@item NO_HIF_SUPPORT
remote-mm.c
-@item NO_JOB_CONTROL
-signals.h
-@item NO_MALLOC_CHECK
-utils.c
-@item NO_MMALLOC
-utils.c
-@item NO_MMALLOC
-objfiles.c
-@item NO_MMALLOC
-utils.c
@item NO_SIGINTERRUPT
remote-adapt.c
@item NO_SINGLE_STEP
@item REGISTER_BYTES
remote.c
@item REGISTER_NAMES
-tm-29k.h
+tm-a29k.h
@item REG_STACK_SEGMENT
exec.c
@item REG_STRUCT_HAS_ADDR
@cindex UDI
@cindex AMD29K via UDI
@value{GDBN} supports AMD's UDI (``Universal Debugger Interface'')
-protocol for debugging the 29k processor family. To use this
+protocol for debugging the a29k processor family. To use this
configuration with AMD targets running the MiniMON monitor, you need the
program @code{MONTIP}, available from AMD at no charge. You can also
-use @value{GDBN} with the UDI conformant 29k simulator program
+use @value{GDBN} with the UDI conformant a29k simulator program
@code{ISSTIP}, also available from AMD.
@table @code
@item target udi @var{keyword}
@kindex udi
-Select the UDI interface to a remote 29K board or simulator, where
+Select the UDI interface to a remote a29k board or simulator, where
@var{keyword} is an entry in the AMD configuration file @file{udi_soc}.
This file contains keyword entries which specify parameters used to
-connect to 29k targets. If the @file{udi_soc} file is not in your
+connect to a29k targets. If the @file{udi_soc} file is not in your
working directory, you must set the environment variable @samp{UDICONF}
to its pathname.
@end table
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. */
/* This is like remote.c but is for an esoteric situation--
- having a 29k board in a PC hooked up to a unix machine with
+ having a a29k board in a PC hooked up to a unix machine with
a serial line, and running ctty com1 on the PC, through which
the unix machine can run ebmon. Not to mention that the PC
has PC/NFS, so it can access the same executables that gdb can,
#define TM_FILE_OVERRIDE
#include "defs.h"
#include <string.h>
-#include "a29k/tm-29k.h"
+#include "a29k/tm-a29k.h"
#include "inferior.h"
#include "wait.h"
as mentioned in the following comment (left in for comic relief):
"This is like remote.c but is for an esoteric situation--
- having a 29k board in a PC hooked up to a unix machine with
+ having an a29k board in a PC hooked up to a unix machine with
a serial line, and running ctty com1 on the PC, through which
the unix machine can run ebmon. Not to mention that the PC
has PC/NFS, so it can access the same executables that gdb can,
as mentioned in the following comment (left in for comic relief):
"This is like remote.c but is for an esoteric situation--
- having a 29k board in a PC hooked up to a unix machine with
+ having an a29k board in a PC hooked up to a unix machine with
a serial line, and running ctty com1 on the PC, through which
the unix machine can run ebmon. Not to mention that the PC
has PC/NFS, so it can access the same executables that gdb can,
projects / external / binutils.git / commitdiff