This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project. See the GDB home page for more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: 4.17.86 on Unixware 7.0.1



   Date: Mon, 22 Mar 1999 15:37:44 -0600
   From: Robert Lipe <robertl@sco.com>

   SCO has a Really Nice debugger, but I have too many cerebral macros that
   emit GDB keystrokes. [ Old dogs, new tricks. ] I'm wagering (hoping!)
   that I can fix GDB faster than I can learn a new debugger. :-)

Heh, that's what Rich Title said about DDE when he went to work at HP;
just look at where that ended up! :-)

   As of last Friday, I could make this a dwarf-2 target without a lot of
   bloodshed.   OTOH, I could drop in GAS and make this a stabs/dwarf-1/dwarf-2
   target with probably even less effort.

   If I thought that the problem was the debugging info was invalid, I'd
   probably go that way immediately.

Stabs are certainly the "ol' reliable" - dwarf2 is better, but it still
has some problems.

   >    If anyone can offer me hints on where to start looking (Would you guess
   >    these to be dwarf-specific?  X86-specific?  Unixware-specific? Test
   > 
   > Probably Unixware, since Linux GDB runs fine (modulo threads and hw
   > watchpoints :-) ), 

   Ehich, other than GDB interface, are exactly the two features that
   inspired this exercise. :-)   The snapshot I'm using from 970817
   doesn't support either of those.

970817?  That's from almost two years ago!?

   > and dwarf errors tend not to cause massive failure,
   > unless the debug info is entirely missing.

   I just spun a build on a RH5.2 system.  It fared better on a 'make
   check' with "only" 182 unexpected failures.  Details available upon
   request.   Since the procfs looks completely different, this may not
   be the ideal reference target, but it does boost my confidence that
   it's not just generic x86 wierdness.

If it's the newest code, 182 is not out of line :-(.  The last results
I got from an internal Linux run is 106 fails, there are some testsuite
patches not yet in a snap.  BTW, while Linux has a /proc it still uses
ptrace for debug...

								Stan