ron@rdk386.uucp (Ron Kuris) (04/10/90)
Well, I am about ready to release the final version of 'gdb', the GNU symbolic debugger for SCO Xenix 386. Can someone recommend the best place to send these sources? We're looking at about 130K of patches, and I'm still a novice at Usenet, so where would be the best place for this code? alt.sources? Or should I mail a moderator? Also, I heard rumor that there is a place that you should mail GNU based patches to for correct distribution. Is this true, and if so, should I send it there only, or also post to the net? Inquiring minds want to know. I've also seen several messages inquiring about the format of the Xenix OMF symbol table. Those who want this information should mail me a reliable path from my site (I tried mailing several times to a few of you and it keeps bouncing near Lawrence Livermore Labs). I AM working on a document describing this information in detail, and may post it to the net at a later time. For those that have the preliminary gdb version, you definitely want this one. Several bugs were found (try assigning a variable a new value in the one you have!). It now supports psymtabs, which means the startup time is very quick. It just reads the table of contents rather than all the debugging information. Performance is great compared to sdb. Single stepping is nearly instantaneous compared to the 1 second delay that sdb gives you. Note that only 386 executables are supported (sorry all you 286 lovers out there). Hacking the segment stuff was difficult as it is without worrying about multiple text/data segments. The nice thing about this debugger is you don't worry about segments. The debugger understands that addresses less than _etext are text addresses; all others must be data. This makes the program appear linear (even tho its not, really). It does limit you when and if the stack runs underneath _etext, but this is several megabytes of stack on my machine. I can't see this happening even on very sophisticated programs. -- ...!pyramid!unify!rdk386!ron -or- ...!ames!pacbell!sactoh0!siva!rdk386!ron It's not how many mistakes you make, its how quickly you recover from them. -- -- ...!pyramid!unify!rdk386!ron -or- ...!ames!pacbell!sactoh0!siva!rdk386!ron It's not how many mistakes you make, its how quickly you recover from them.