gdb for SCO Xenix

[Ron Kuris]

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.