Re: Testsuite Organization Proposal

Re: Testsuite Organization Proposal

[Jimmy Guo]

>   > gdb.base        This is the base testsuite.  The tests in it should
>   >                 apply to all configurations of GDB (but generic
>   >                 native-only tests may live here).  The test programs
>   >                 should be in a subset of C that is valid K&R, ANSI/ISO,
>   >                 and C++ (ifdefs are allowed).
>
>   I'd kind of like to see gdb.base contain no C++ tests.  There are
>   targets out there that don't have a C++ compiler.
>
>Yes, gdb.base shouldn't contain any C++ tests.  I think the main offender
>right now is smoke.exp, and I'm wondering if it should be in there at all,
>since its purpose in life was for HP to use in their internal process
>before doing checkins, and I don't think anybody at HP uses it that way
>anymore.

How about moving the C++ part of smoke.exp and smoke.cc to gdb.c++?
I'm about to provide a patch for the gdb.base suite as the part of the
test suite merge effort between HP's tree and Cygnus tree, with
assistance from Stan.  This could be a time we split up smoke.exp.

- Jimmy Guo, guo@cup.hp.com

Re: Testsuite Organization Proposal

[Stan Shebs]

   Date: Thu, 24 Jun 1999 15:02:04 -0700 (PDT)
   From: Jimmy Guo <guo@cup.hp.com>

   How about moving the C++ part of smoke.exp and smoke.cc to gdb.c++?
   I'm about to provide a patch for the gdb.base suite as the part of the
   test suite merge effort between HP's tree and Cygnus tree, with
   assistance from Stan.  This could be a time we split up smoke.exp.

Does anybody at HP or elsewhere use this file as a smoke test?  I'm
pretty sure nobody at Cygnus does.  The tests are generally redundant,
so you're losing much test coverage by dropping it.  If it really is
useful, then splitting up is OK too.

								Stan

Re: Testsuite Organization Proposal

[Jimmy Guo]

>   How about moving the C++ part of smoke.exp and smoke.cc to gdb.c++?
>   I'm about to provide a patch for the gdb.base suite as the part of the
>   test suite merge effort between HP's tree and Cygnus tree, with
>   assistance from Stan.  This could be a time we split up smoke.exp.
>
>Does anybody at HP or elsewhere use this file as a smoke test?  I'm
>pretty sure nobody at Cygnus does.  The tests are generally redundant,
>so you're losing much test coverage by dropping it.  If it really is
>useful, then splitting up is OK too.
>
>								Stan

Stan,

I've removed smoke.c smoke.cc smoke.exp from HP tree, and adjusted
Makefile.in accordingly (to remove the executables associated with this
test from the EXECUTABLES list).

The change will appear in the gdb.base/ patch file which is coming
soon.  And I will provide you with an updated list of file rename /
moves.

- Jimmy Guo, guo@cup.hp.com

Re: Testsuite Organization Proposal

[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.