![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to =rt-ans2 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GNU Debugger] / gdb|
Return to =rt-ans2 CVS log | Up to [GNU Debugger] / gdb |
1.1 root 1: BABYL OPTIONS:
2: Version: 5
3: Labels:
4: Note: This is the header of an rmail file.
5: Note: If you are seeing it in rmail,
6: Note: it means the file has no messages in it.
7:
8: 1,answered,,
9: Received: by PREP.AI.MIT.EDU; Tue, 26 May 87 14:03:00 EDT
10: Received: by po2.andrew.cmu.edu (5.54/3.15) id <AA00274> for [email protected]; Tue, 26 May 87 13:12:52 EDT
11: Received: via switchmail; Tue, 26 May 87 13:12:49 edt
12: Received: FROM mooncrest VIA qmail
13: ID </cmu/common/mailqs/q004/QF.mooncrest.20b9cce3.d0134>;
14: Tue, 26 May 87 13:12:08 edt
15: Received: FROM mooncrest VIA qmail
16: ID </cmu/itc/kazar/.Outgoing/QF.mooncrest.20b9ccb0.1b570>;
17: Tue, 26 May 87 13:11:14 edt
18: Message-Id: <[email protected]>
19: X-Trace: MS Version 3.24 on ibm032 host mooncrest, by kazar (71).
20: Date: Tue, 26 May 87 13:11:12 edt
21: From: kazar#@andrew.cmu.edu (Mike Kazar)
22: To: [email protected] (Richard M. Stallman)
23: Subject: Re: Fwd: RT diffs for gdb version 2.1
24: Cc: zs01#@andrew.cmu.edu (Zalman Stern)
25: In-Reply-To: <[email protected]>
26:
27: *** EOOH ***
28: X-Trace: MS Version 3.24 on ibm032 host mooncrest, by kazar (71).
29: Date: Tue, 26 May 87 13:11:12 edt
30: From: kazar#@andrew.cmu.edu (Mike Kazar)
31: To: [email protected] (Richard M. Stallman)
32: Subject: Re: Fwd: RT diffs for gdb version 2.1
33: Cc: zs01#@andrew.cmu.edu (Zalman Stern)
34: In-Reply-To: <[email protected]>
35:
36: I'm afraid that neither of your proposed simplifications to the gdb RT port
37: actually work.
38:
39: First, the trace table problem. The fundamental problem is that gdb expects
40: to be able to pass in a frame pointer and get that frame's parent. This is
41: the purpose of FRAME_CHAIN, a macro whose one parameter is the frame whose
42: parent is desired.
43:
44: This is simply insufficient information with which to compute the preceding
45: frame's address. In order to truly appreciate how bad things are, let me
46: describe the procedure involved in going from a set of saved registers
47: (including the pc), say after a core dump occurs, to the address of the
48: preceding frame. I assure you that you'll be shocked by its complexity....
49:
50: I start off knowing only one thing: the PC of the guy who pushed the last
51: stack frame. At the time of a core dump, this is in the saved PC, and for
52: other stack frames, it is in register R15 (the return address is put in R15
53: by the procedure call sequence). My first goal is to compute the frame
54: register number! Not the contents of the frame register, but the register
55: number itself, because the RT calling convention lets you change frame
56: pointers from procedure to procedure! So, I scan for the trace table, based
57: on the PC, and obtain a structure that gives the frame register number (for
58: both of our C compilers, this is R13, but it doesn't have to be), the number
59: of arguments to the procedure, the space used by the locals and the number of
60: registers saved by the procedure prolog. This enables me to take the frame
61: pointer, compute the offset of the saved registers off of this frame pointer
62: and essentially restore the registers to the state they were at the time this
63: procedure was called. R15 now contains *its* callers PC, and I can redo this
64: procedure again to back up another frame.
65:
66: In essence, in order to compute the preceding frame's address, I need more
67: than just the current frame's address. I need the full machine state at the
68: time of the call, including all of the registers since I don't know which one
69: will even turn out to be the frame pointer for the preceding procedure.
70:
71: This is why I put in the frame caching code. Note that even were I to assume
72: that the frame pointer is always in R13 (and this is almost certainly a
73: mistake; IBM will surely eventually come up with a compiler where the frame
74: pointer is NOT r13), I still either need r15 or the PC (depending upon which
75: frame we're dealing with) in order to compute the preceding frame address.
76:
77: As for the _foo v.s. _.foo issue, there are two problems. First, we can not
78: simply ignore _foo symbols, since an _foo symbol is only "junk" if there is
79: (possibly later) an _.foo symbol. We might be able to have the processing
80: for the "_.foo" change the value in the symbol table placed under the name
81: _foo. I do not know if this will work, since I do not know what processing
82: is done when a symbol is first encountered, and how much can be done a second
83: time. The second problem is that sometimes we need to see what is in the
84: variable named _foo, and we can't if it actually refers to _.foo. I
85: personally might be willing to live with this loss of functionality, but
86: other people probably would not.
87:
88: As for initialize.h, we simply have no guarantees that IBM won't again change
89: the junk they stick in front of procedures in the text segment. Already,
90: depending upon which compiler (and we use both), pcc puts a funny string (and
91: maybe an integer, too) in front of every procedure, while the metaware hc
92: compiler puts a funny string in front of the first procedure in a file, but
93: nothing in front of the others. IBM has made it clear to us that they feel
94: free to change this at any time, so I feel quite strongly that it would be a
95: mistake to assume that they've finished playing around with junk at the start
96: of the text. BTW, for all I know, some of these magic text strings disappear
97: when you compile with -O. They certainly *should*.
98:
99: Mike
100:
101:
102:
103:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.