Return to =rt-answers CVS log

Up to [GNU Debugger] / gdb

Annotation of gdb/=rt-answers, revision 1.1

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.