Re: Testsuite Organization Proposal

[toddpw@wrs.com (Todd Whitesel)]

> I'd like to propose a semi-formalization of the current testsuite
> organization, basically just reflecting current practice, but with
> enough precision to guide further additions.  The testsuite is key for

I think anything along these lines is a MARVELOUS idea.

Might there be cookbook instructions for isolating a single test out of the
testsuite and running it manually? Anyone hoping to do more than 'make check'
pretty much needs to know how to do this. I tried asking some gcc people for
help on this, but they quickly gave up, claiming the gcc/gdb testsuites were
structured unlike each other and that they wouldn't be able to help me.

-- 
Todd Whitesel
toddpw @ wrs.com
From shebs@cygnus.com Mon Jun 14 17:12:00 1999
From: Stan Shebs <shebs@cygnus.com>
To: toddpw@wrs.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: Testsuite Organization Proposal
Date: Mon, 14 Jun 1999 17:12:00 -0000
Message-id: <199906150012.RAA06502@andros.cygnus.com>
References: <199906150003.RAA18448@alabama.wrs.com>
X-SW-Source: 1999-q2/msg00165.html
Content-length: 996

   From: toddpw@wrs.com (Todd Whitesel)
   Date: Mon, 14 Jun 1999 17:03:49 -0700 (PDT)

   Might there be cookbook instructions for isolating a single test out of the
   testsuite and running it manually? Anyone hoping to do more than 'make check'
   pretty much needs to know how to do this. I tried asking some gcc people for
   help on this, but they quickly gave up, claiming the gcc/gdb testsuites were
   structured unlike each other and that they wouldn't be able to help me.

Running a single file is easy:

	cd <objdir>/gdb/testsuite
	make check RUNTESTFLAGS='bitfields.exp logical.exp'

I think DejaGNU actually allows full regexps as arguments for finding
which test files to run, I haven't experimented much myself.

Don't think there's any way to run a single test in a file, there's
usually a bunch of setup to get to a particular test.  In fact, I
would want to keep .exp files down in size so that it's not too slow
to run just one of them, 50-100 tests/file or so.

								Stan
From tm@netcom.com Mon Jun 14 17:24:00 1999
From: Toshiyasu Morita <tm@netcom.com>
To: jtc@redback.com
Cc: gdb@sourceware.cygnus.com
Subject: Re: breakpoint extension for remote protocol, take II
Date: Mon, 14 Jun 1999 17:24:00 -0000
Message-id: <199906150023.RAA14961@netcom16.netcom.com>
References: <5mzp222x5d.fsf@jtc.redbacknetworks.com>
X-SW-Source: 1999-q2/msg00166.html
Content-length: 729

> 
> >>>>> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
> Andrew> Have you considered what to do when there is a choice of
> Andrew> software breakpoints?  Jim Ingham's pointed out to me that in
> Andrew> the case of the MIPS/MIPS16 and ARM/THUMB the breakpoint might
> Andrew> be 2 bytes or 4 bytes in size (and the value different in each
> Andrew> case).
> 
> I was unaware processors with multiple software breakpoints existed.
> I assume that the 2 byte breakpoint instructions have to be inserted
> in "high-density" code segments and 4 byte breakpoints insns have to
> be inserted in "low-density" segments.

Is there a four-byte sequence which is an illegal instruction in both
MIPS16 and MIPS32 modes?

Toshi
From jtc@redback.com Mon Jun 14 17:34:00 1999
From: jtc@redback.com (J.T. Conklin)
To: Stan Shebs <shebs@cygnus.com>
Cc: gdb@sourceware.cygnus.com
Subject: Re: breakpoint extension for remote protocol, take II
Date: Mon, 14 Jun 1999 17:34:00 -0000
Message-id: <5mvhcq2tg7.fsf@jtc.redbacknetworks.com>
References: <199906142359.QAA06291@andros.cygnus.com>
X-SW-Source: 1999-q2/msg00167.html
Content-length: 1751

>>>>> "Stan" == Stan Shebs <shebs@cygnus.com> writes:
Stan>    Bleh.  But that's what the 'q' escape is for.  IMO, all
Stan>    experimental protocol extensions should be using 'q';
Stan>    likewise, GDB should never use 'q' itself.
Stan>
Stan> You mean like with qOffsets, that's been standardly issued by
Stan> GDB for years? :-)
Stan>
Stan> Actually, I don't ever remember hearing that 'q' was supposed to
Stan> be experimental, and the existing docs don't seem to say so
Stan> either.

Although I've had that (mis-)interpretation for years, you are right.
There is nothing that indicates that that 'q' is intended to be used
for experimental commands.  

Stan> At this point we would have to pick a different char I
Stan> think, and be very disciplined about not allowing any usages of
Stan> it into the standard sources, so that it really can be for
Stan> experimentation.

Agreed.

I'll try to weasel out of this mistake by arguing that there *should*
be letter reserved for experimental, and other non-standard commands.
The remote protocol is used beyond the cannonical implementations of
remote.c and the sample stubs provided with GDB.  Since the protocol
is relatively simple, it's not surprising that it has been extended.
And without a well developed specification and/or an organization to
register protocol extensions, it's not surprising that there have been
or could be collisions in those extensions.

Stan> In general, we have a sizeable documentation gap with the remote
Stan> protocol; it's become so ubiquitous it ought to have its own
Stan> RFC... :-)

Agreed again.  Even if the remote protocol is replaced with something
better :-), the old protocol won't go away for a long while.

	--jtc

-- 
J.T. Conklin
RedBack Networks
From brendan@dgs.monash.edu.au Mon Jun 14 17:42:00 1999
From: Brendan Simon <brendan@dgs.monash.edu.au>
To: Zubin Burjor Sethna <sethnaz@sg.adi-limited.com.au>
Cc: gdb@sourceware.cygnus.com
Subject: Re: gdb + wiggler
Date: Mon, 14 Jun 1999 17:42:00 -0000
Message-id: <3765A0D6.B8B414F6@dgs.monash.edu.au>
References: <6006B52C37ABD211AB0900805FFE9D7916933C@exchange.sg.adisys.com.au>
X-SW-Source: 1999-q2/msg00168.html
Content-length: 577

Zubin Burjor Sethna wrote:

> Hi
>
> Has anyone had any success using the gdb from the ecos tool chain with a
> wiggler? A wiggler is a debugging interface for BDM and the target I am
> using is MPC860? I tried the wiggler support in the ecos gdb but all I got
> were core dumps. Do I need any additonal drivers than what is supplied with
> gdb?
>
> Thanks
>
> Zubin

YES.  You need the wigglers.dll.  You can get it as part of the demo utilities
from the macraigor web site.  It only works with MS-Windows unfortunately. No
Linux/Unix as far as I am aware :(

Brendan Simon.