diff options
Diffstat (limited to 'gdb/=rt-answers')
| -rw-r--r-- | gdb/=rt-answers | 147 |
1 files changed, 0 insertions, 147 deletions
diff --git a/gdb/=rt-answers b/gdb/=rt-answers deleted file mode 100644 index b23cfee926..0000000000 --- a/gdb/=rt-answers +++ /dev/null @@ -1,147 +0,0 @@ -X-Trace: MS Version 3.24 on ibm032 host dublin.itc.cmu.edu, by zs01 (623). -Date: Mon, 25 May 87 10:30:10 edt -From: zs01#@andrew.cmu.edu (Zalman Stern) -To: rms@PREP.AI.MIT.EDU (Richard M. Stallman) -Subject: Re: RT diffs for gdb version 2.1 -Cc: kazar#@andrew.cmu.edu (Mike Kazar), zs01#@andrew.cmu.edu (Zalman Stern) -In-Reply-To: <8705250107.AA13256@prep.ai.mit.edu> - -Richard, - -First I will cover the easy questions. - -Either of our fixes to environ.c (i.e. with respect to version 1.9 which was -broken) will work. As I understand it, the intent of init_environ is to fill -in the environment and leave a little extra space for later additions. I do -not understand why you would want to only leave the extra space when the -original size was within 10 elements of the final size. - -add_com returning something is probably left over from a fix I put in which -is superceeded by the "user" class to distinguish command lists from function -pointers. I should have removed it. - -We use csh instead of sh because I got tired of putting up with sh's crapping -out on large environments. - -The change to inferior_args involves putting an explicit initializer of NULL -on it, and testing it for NULL before freeing it. I guess most -implementations of free ignore NULL pointers. The one we have on our Sun-2's -does not. - -I can't remember why the alloca's were moved out of the variable -initializations. It may have been to avoid a compiler problem. In any event, -ignoring this modification shouldn't hurt. - -Now for the hard ones... - -The RT is a very different architecture from either a Sun or a VAX. It does -not use a self-describing stack frame and it does not use the same -conventions for symbols within object modules. There are also certain -subtleties to the way it lays out its address space that cause problems. Many -people at the ITC, including myself, are very impressed with the quality of -the port Mike did in spite of these obstacles. You may feel that these -problems are not worth effort. I have attempted to describe the differences -involved with the RT in case you choose to address them. If not, we are still -quite happy with the debugger we have and thank you for providing us with the -code... - -Both the 68k family and the VAX have a frame pointer and a stack pointer. -Using these to values and the information on the stack, one can do a complete -stack trace. The RT on the other hand has only a stack pointer and a very -loose concept of a frame pointer. The stack pointer will point just below a -section of the stack dedicated to the maximum number of outgoing parameters -minus 4 (the first 4 are in registers). The frame pointer will point -somewhere in the stack where the compiler has deemed it optimal for -addressing locals and parameters. There are variable length fields in the -stack frame, such as the register save areas. In all, the thing looks like -so: - - -Higher Address ------------------ - -a) Incoming args 5 through N <---- Previous sp was here - (part of previous function's stack frame) -b) Four words to save register passed arguments. -c) Four words of linkage area (reserved). -d) 1 word static link. -e) 1 - 16 words of register save area. - (Variable length, return address is at the top of this since it was in -r15) -f) 0 -8 words of floating point reg. save area. (Variable length) -g) Local variables (variable length) -h) Outgoing arguments, words 5 - N <---- Current sp points to bottom of this. - -Lower Address ----------------- - -These and the stack contents are not enough to get back to the previous stack -frame because you do not know how far back it is to the register save area. -The code works because each function has been compiled to know how to pop its -stack frame (i.e. it has embedded constants). In order to facilitate -debugging, there is a trace table at the end of each function containing all -the necessary information. (Namely the offset from the frame pointer to the -top of the stack frame b in the above diagram) The trace table is located by -starting at the beginning of the function and looking for the illegal -instruction sequence 0xdf07df. Since the RT does not have 32bit constants in -the instruction stream, this actually works. In general, the iar and the -stack pointer are needed to do frame manipulations. The cache is necessary -because finding the trace table is very expensive. In short, the machinery -present in gdb was not up to handling this system, so we added what we -thought would work. It is interesting to note that similar calling -conventions are used on other RISC machines, notably the MIPS R2000. If you -wish to take advantage of these high performance machines, you will have to -do something like what we have done. - -The POP_DUMMY_FRAME problem is related to this. The RT stores return address -in r15. We can not use this location to store the current iar since we must -store r15 for later restoration. This rules out using the same function for -popping both kinds of frames. There is also some hassle involved in getting -the stack and frame pointers correct, but I think this might be fixed by -generating an appropriate trace back table for the dummy function. - -The other problem we faced is the non-standard use of symbols within object -modules. The RT defines two symbols for a function foo. There is "_.foo" -which corresponds to the actual code in the text segment (just like "_foo" on -a Sun or VAX), and "_foo" which points to the data area for the function in -the data segment. The first word of the data area contains a pointer to the -code. A function pointer (i.e. int (*foo)()) points to the data area (_foo), -not the code (_.foo). This is what the TYPE_CODE_PTR modification in valops.c -is for. Since both of these symbols are used for certain things, we cannot -simply remove the dots. This is a bogus IBM feature and we do not like it any -better than you do. We have to live with it if we want a working debugger. - -The "fix" to find_pc_misc function handles a special case on the RT where -certain functions are in the high end of the address space. The RT uses the -top 4 bits of an address as a segment number. The text segment is seg. 0, the -data segment is seg. 1, and the kernel is mapped into seg. 14. Certain kernel -functions (i.e. floating point functions) are directly callable by user code -and so occur in the misc_function_vector. I realize this is bogus. - -The initialization code will not run because both the RT compilers (pcc and -hc) output ascii data in the text section preceding the first function. Pcc -outputs the name of each function before the function. Hc outputs the name of -the source file at the beginning of the object module. Coding around this may -be possible, but what is the point? I see no reason for this hackery. I have -had problems getting it to work not only on the RT, but on the Sun-3. It is -guaranteed to be a portability headache on many other machines as well. If -you intend for gdb to only work when compiled with gcc, I suppose you may be -able to use this method. - -I strongly agree with your statements that cleaner solutions are better in -every way. Unfortunately, we did not write gdb, nor is the system we are -working with particularly supportive of symbolic debugging. We were faced -with the task of both figuring out gdb, and hacking our way around a -contorted system (featuring among other things, a plethora of compiler bugs). -The fact that our version of gdb is the only working symbolic debugger on the -IBM RT (despite much effort by IBM) is proof that we have done something -right. I am willing to discuss what would make this port better. However, it -is not our intent to maintain or rewrite gdb. We merely wish to use it, and -if not a terrible hassle, let other people use it too. Mike and I would -prefer a copyright assignment. I would appreciate it if you would send me -info on what we need to do. - --Z- - - - |
