1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
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
|
