![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to =rt-answers CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GNU Debugger] / gdb|
Return to =rt-answers CVS log | Up to [GNU Debugger] / gdb |
1.1 root 1: X-Trace: MS Version 3.24 on ibm032 host dublin.itc.cmu.edu, by zs01 (623).
2: Date: Mon, 25 May 87 10:30:10 edt
3: From: zs01#@andrew.cmu.edu (Zalman Stern)
4: To: [email protected] (Richard M. Stallman)
5: Subject: Re: RT diffs for gdb version 2.1
6: Cc: kazar#@andrew.cmu.edu (Mike Kazar), zs01#@andrew.cmu.edu (Zalman Stern)
7: In-Reply-To: <[email protected]>
8:
9: Richard,
10:
11: First I will cover the easy questions.
12:
13: Either of our fixes to environ.c (i.e. with respect to version 1.9 which was
14: broken) will work. As I understand it, the intent of init_environ is to fill
15: in the environment and leave a little extra space for later additions. I do
16: not understand why you would want to only leave the extra space when the
17: original size was within 10 elements of the final size.
18:
19: add_com returning something is probably left over from a fix I put in which
20: is superceeded by the "user" class to distinguish command lists from function
21: pointers. I should have removed it.
22:
23: We use csh instead of sh because I got tired of putting up with sh's crapping
24: out on large environments.
25:
26: The change to inferior_args involves putting an explicit initializer of NULL
27: on it, and testing it for NULL before freeing it. I guess most
28: implementations of free ignore NULL pointers. The one we have on our Sun-2's
29: does not.
30:
31: I can't remember why the alloca's were moved out of the variable
32: initializations. It may have been to avoid a compiler problem. In any event,
33: ignoring this modification shouldn't hurt.
34:
35: Now for the hard ones...
36:
37: The RT is a very different architecture from either a Sun or a VAX. It does
38: not use a self-describing stack frame and it does not use the same
39: conventions for symbols within object modules. There are also certain
40: subtleties to the way it lays out its address space that cause problems. Many
41: people at the ITC, including myself, are very impressed with the quality of
42: the port Mike did in spite of these obstacles. You may feel that these
43: problems are not worth effort. I have attempted to describe the differences
44: involved with the RT in case you choose to address them. If not, we are still
45: quite happy with the debugger we have and thank you for providing us with the
46: code...
47:
48: Both the 68k family and the VAX have a frame pointer and a stack pointer.
49: Using these to values and the information on the stack, one can do a complete
50: stack trace. The RT on the other hand has only a stack pointer and a very
51: loose concept of a frame pointer. The stack pointer will point just below a
52: section of the stack dedicated to the maximum number of outgoing parameters
53: minus 4 (the first 4 are in registers). The frame pointer will point
54: somewhere in the stack where the compiler has deemed it optimal for
55: addressing locals and parameters. There are variable length fields in the
56: stack frame, such as the register save areas. In all, the thing looks like
57: so:
58:
59:
60: Higher Address
61: -----------------
62:
63: a) Incoming args 5 through N <---- Previous sp was here
64: (part of previous function's stack frame)
65: b) Four words to save register passed arguments.
66: c) Four words of linkage area (reserved).
67: d) 1 word static link.
68: e) 1 - 16 words of register save area.
69: (Variable length, return address is at the top of this since it was in
70: r15)
71: f) 0 -8 words of floating point reg. save area. (Variable length)
72: g) Local variables (variable length)
73: h) Outgoing arguments, words 5 - N <---- Current sp points to bottom of this.
74:
75: Lower Address
76: ----------------
77:
78: These and the stack contents are not enough to get back to the previous stack
79: frame because you do not know how far back it is to the register save area.
80: The code works because each function has been compiled to know how to pop its
81: stack frame (i.e. it has embedded constants). In order to facilitate
82: debugging, there is a trace table at the end of each function containing all
83: the necessary information. (Namely the offset from the frame pointer to the
84: top of the stack frame b in the above diagram) The trace table is located by
85: starting at the beginning of the function and looking for the illegal
86: instruction sequence 0xdf07df. Since the RT does not have 32bit constants in
87: the instruction stream, this actually works. In general, the iar and the
88: stack pointer are needed to do frame manipulations. The cache is necessary
89: because finding the trace table is very expensive. In short, the machinery
90: present in gdb was not up to handling this system, so we added what we
91: thought would work. It is interesting to note that similar calling
92: conventions are used on other RISC machines, notably the MIPS R2000. If you
93: wish to take advantage of these high performance machines, you will have to
94: do something like what we have done.
95:
96: The POP_DUMMY_FRAME problem is related to this. The RT stores return address
97: in r15. We can not use this location to store the current iar since we must
98: store r15 for later restoration. This rules out using the same function for
99: popping both kinds of frames. There is also some hassle involved in getting
100: the stack and frame pointers correct, but I think this might be fixed by
101: generating an appropriate trace back table for the dummy function.
102:
103: The other problem we faced is the non-standard use of symbols within object
104: modules. The RT defines two symbols for a function foo. There is "_.foo"
105: which corresponds to the actual code in the text segment (just like "_foo" on
106: a Sun or VAX), and "_foo" which points to the data area for the function in
107: the data segment. The first word of the data area contains a pointer to the
108: code. A function pointer (i.e. int (*foo)()) points to the data area (_foo),
109: not the code (_.foo). This is what the TYPE_CODE_PTR modification in valops.c
110: is for. Since both of these symbols are used for certain things, we cannot
111: simply remove the dots. This is a bogus IBM feature and we do not like it any
112: better than you do. We have to live with it if we want a working debugger.
113:
114: The "fix" to find_pc_misc function handles a special case on the RT where
115: certain functions are in the high end of the address space. The RT uses the
116: top 4 bits of an address as a segment number. The text segment is seg. 0, the
117: data segment is seg. 1, and the kernel is mapped into seg. 14. Certain kernel
118: functions (i.e. floating point functions) are directly callable by user code
119: and so occur in the misc_function_vector. I realize this is bogus.
120:
121: The initialization code will not run because both the RT compilers (pcc and
122: hc) output ascii data in the text section preceding the first function. Pcc
123: outputs the name of each function before the function. Hc outputs the name of
124: the source file at the beginning of the object module. Coding around this may
125: be possible, but what is the point? I see no reason for this hackery. I have
126: had problems getting it to work not only on the RT, but on the Sun-3. It is
127: guaranteed to be a portability headache on many other machines as well. If
128: you intend for gdb to only work when compiled with gcc, I suppose you may be
129: able to use this method.
130:
131: I strongly agree with your statements that cleaner solutions are better in
132: every way. Unfortunately, we did not write gdb, nor is the system we are
133: working with particularly supportive of symbolic debugging. We were faced
134: with the task of both figuring out gdb, and hacking our way around a
135: contorted system (featuring among other things, a plethora of compiler bugs).
136: The fact that our version of gdb is the only working symbolic debugger on the
137: IBM RT (despite much effort by IBM) is proof that we have done something
138: right. I am willing to discuss what would make this port better. However, it
139: is not our intent to maintain or rewrite gdb. We merely wish to use it, and
140: if not a terrible hassle, let other people use it too. Mike and I would
141: prefer a copyright assignment. I would appreciate it if you would send me
142: info on what we need to do.
143:
144: -Z-
145:
146:
147:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.