diff options
Diffstat (limited to 'gdb/=rt-ans2')
| -rw-r--r-- | gdb/=rt-ans2 | 103 |
1 files changed, 103 insertions, 0 deletions
diff --git a/gdb/=rt-ans2 b/gdb/=rt-ans2 new file mode 100644 index 0000000..cd5f9fa --- /dev/null +++ b/gdb/=rt-ans2 @@ -0,0 +1,103 @@ +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 |