Return to =rt-ans2 CVS log

Up to [GNU Debugger] / gdb

Annotation of gdb/=rt-ans2, revision 1.1

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.