This is the mail archive of the gdb-testers@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 12:00:03 -0600
   From: Robert Lipe <robertl@sco.com>

Hi, long time no hear - are you working for SCO now?

   I did have to override --host on 4.17.86 becuase it doesn't recognize
   Unixware7 as a valid host.   I thought that treating it as an earlier
   version of unixware was the thing to do.   The testsuite results make
   me wonder if that was wise.

How well does it work when you interact with it normally?  The list of
failures suggest that inferior processes aren't actually under much
control.

   I've excluded the "PASS:" lines from the testsuite summary.  I was using
   EGCS 1.1.1 as the host compiler for both GDB and for the testsuite.  I'm
   hoping that a GDB expert will recognize these failures as some known x86
   phenomenon. :-)   This is a elf+dwarf1 (currently) target.

The "1" part in "dwarf1" isn't going to help with C++ results much,
and I'm not sure how much attention it's getting in egcs.

   As an aside, I see the testsuite complaining that it can't find the 
   corefiles.   Unixware has long named core dumps as 'core.<pid>' where
   <pid> is the PID of the dumping process.   Is there support for this
   in the harness that I need to "turn on"?

I have a vague memory of this having been done at one time, but I just
looked at gdb.base/corefile.exp and didn't see anything plausible.
There's a loop near the top of corefile.exp that tries several corefile
name possibilities, this seems worthy of tweaking:

	foreach i "${objdir}/${subdir}/core ${objdir}/${subdir}/core.coremaker.c ${binfile}.core" {
 
   If anyone can offer me hints on where to start looking (Would you guess
   these to be dwarf-specific?  X86-specific?  Unixware-specific? Test
   harness problem?) I'll roll up my sleeves and help dig in.

Probably Unixware, since Linux GDB runs fine (modulo threads and hw
watchpoints :-) ), and dwarf errors tend not to cause massive failure,
unless the debug info is entirely missing.

   I suppose that wiring in GAS and telling the tests to be built with
   '-gstabs' might be the easiest way to [dis]prove that first datapoint.
   What's the syntax for doing that in the GDB testsuite?

To experiment, try a make CFLAGS_FOR_TARGET=-gstabs.  A more permanent
wiring is to set variables in site.exp.

								Stan