1 files changed, 0 insertions, 103 deletions
diff --git a/gdb/=rt-ans2 b/gdb/=rt-ans2
deleted file mode 100644
index cd5f9fa..0000000
--- a/gdb/=rt-ans2
+++ /dev/null
@@ -1,103 +0,0 @@
-BABYL OPTIONS:
-Version: 5
-Labels:
-Note:   This is the header of an rmail file.
-Note:   If you are seeing it in rmail,
-Note:    it means the file has no messages in it.
-
-1,answered,,
-Received: by PREP.AI.MIT.EDU; Tue, 26 May 87 14:03:00 EDT
-Received: by po2.andrew.cmu.edu (5.54/3.15) id <AA00274> for rms@PREP.AI.MIT.EDU; Tue, 26 May 87 13:12:52 EDT
-Received: via switchmail; Tue, 26 May 87 13:12:49 edt
-Received: FROM mooncrest VIA qmail
-          ID </cmu/common/mailqs/q004/QF.mooncrest.20b9cce3.d0134>;
-          Tue, 26 May 87 13:12:08 edt
-Received: FROM mooncrest VIA qmail
-          ID </cmu/itc/kazar/.Outgoing/QF.mooncrest.20b9ccb0.1b570>;
-          Tue, 26 May 87 13:11:14 edt
-Message-Id: <0UiQmky00UkA06w0Ci@andrew.cmu.edu>
-X-Trace: MS Version 3.24 on ibm032 host mooncrest, by kazar (71).
-Date: Tue, 26 May 87 13:11:12 edt
-From: kazar#@andrew.cmu.edu (Mike Kazar)
-To: rms@PREP.AI.MIT.EDU (Richard M. Stallman)
-Subject: Re: Fwd: RT diffs for gdb version 2.1
-Cc: zs01#@andrew.cmu.edu (Zalman Stern)
-In-Reply-To: <4UiN0ly00Vs8Njw0PC@andrew.cmu.edu>
-
-*** EOOH ***
-X-Trace: MS Version 3.24 on ibm032 host mooncrest, by kazar (71).
-Date: Tue, 26 May 87 13:11:12 edt
-From: kazar#@andrew.cmu.edu (Mike Kazar)
-To: rms@PREP.AI.MIT.EDU (Richard M. Stallman)
-Subject: Re: Fwd: RT diffs for gdb version 2.1
-Cc: zs01#@andrew.cmu.edu (Zalman Stern)
-In-Reply-To: <4UiN0ly00Vs8Njw0PC@andrew.cmu.edu>
-
-I'm afraid that neither of your proposed simplifications to the gdb RT port
-actually work.
-
-First, the trace table problem.  The fundamental problem is that gdb expects
-to be able to pass in a frame pointer and get that frame's parent.  This is
-the purpose of FRAME_CHAIN, a macro whose one parameter is the frame whose
-parent is desired.
-
-This is simply insufficient information with which to compute the preceding
-frame's address.  In order to truly appreciate how bad things are, let me
-describe the procedure involved in going from a set of saved registers
-(including the pc), say after a core dump occurs, to the address of the
-preceding frame.  I assure you that you'll be shocked by its complexity....
-
-I start off knowing only one thing: the PC of the guy who pushed the last
-stack frame.  At the time of a core dump, this is in the saved PC, and for
-other stack frames, it is in register R15 (the return address is put in R15
-by the procedure call sequence).  My first goal is to compute the frame
-register number!  Not the contents of the frame register, but the register
-number itself, because the RT calling convention lets you change frame
-pointers from procedure to procedure!  So, I scan for the trace table, based
-on the PC, and obtain a structure that gives the frame register number (for
-both of our C compilers, this is R13, but it doesn't have to be), the number
-of arguments to the procedure, the space used by the locals and the number of
-registers saved by the procedure prolog.  This enables me to take the frame
-pointer, compute the offset of the saved registers off of this frame pointer
-and essentially restore the registers to the state they were at the time this
-procedure was called.  R15 now contains *its* callers PC, and I can redo this
-procedure again to back up another frame.
-
-In essence, in order to compute the preceding frame's address, I need more
-than just the current frame's address.  I need the full machine state at the
-time of the call, including all of the registers since I don't know which one
-will even turn out to be the frame pointer for the preceding procedure.
-
-This is why I put in the frame caching code.  Note that even were I to assume
-that the frame pointer is always in R13 (and this is almost certainly a
-mistake; IBM will surely eventually come up with a compiler where the frame
-pointer is NOT r13), I still either need r15 or the PC (depending upon which
-frame we're dealing with) in order to compute the preceding frame address.
-
-As for the _foo v.s. _.foo issue, there are two problems.  First, we can not
-simply ignore _foo symbols, since an _foo symbol is only "junk" if there is
-(possibly later) an _.foo symbol.  We might be able to have the processing
-for the "_.foo" change the value in the symbol table placed under the name
-_foo.  I do not know if this will work, since I do not know what processing
-is done when a symbol is first encountered, and how much can be done a second
-time.  The second problem is that sometimes we need to see what is in the
-variable named _foo, and we can't if it actually refers to _.foo.  I
-personally might be willing to live with this loss of functionality, but
-other people probably would not.
-
-As for initialize.h, we simply have no guarantees that IBM won't again change
-the junk they stick in front of procedures in the text segment.  Already,
-depending upon which compiler (and we use both), pcc puts a funny string (and
-maybe an integer, too) in front of every procedure, while the metaware hc
-compiler puts a funny string in front of the first procedure in a file, but
-nothing in front of the others.  IBM has made it clear to us that they feel
-free to change this at any time, so I feel quite strongly that it would be a
-mistake to assume that they've finished playing around with junk at the start
-of the text.  BTW, for all I know, some of these magic text strings disappear
-when you compile with -O.  They certainly *should*.
-
-	Mike
-
-
-
-
-\ No newline at end of file