Re: Adding target specific tests

Re: Adding target specific tests

[Michael Elizabeth Chastain]

gdb.altivec is my favorite.
gdb.powerpc is my second choice.
gdb.regs and gdb.abi don't sound good to me.

I kinda like this:

  gdb.base, gdb.gdb, gdb.mi, gdb.threads, gdb.trace
  gdb.arch.altivec, gdb.arch.hp
  gdb.format.stabs
  gdb.lang.asm, gdb.lang.c++, gdb.lang.chill, gdb.lang.disasm,
  gdb.lang.fortran, gdb.lang.java

But that would fail the 8.3 uniqueness test.

Or this:

  gdb.base
  gdb.gdb
  gdb.mi
  gdb.threads
  gdb.trace
  gdb.arch/
    altivec
    hp
  gdb.format/
    stabs
  gdb.lang/
    asm
    c++
    chill
    disasm
    fortran
    java

... but that might mess up somebody's scripts somewhere.

Indeed, any directory reorganization would impair my ability to
compare 5.2 with 5.3 when it comes time to release 5.3.

Michael C

Re: Adding target specific tests

[Eli Zaretskii]

> Date: Fri, 26 Apr 2002 13:54:40 -0500
> From: Michael Elizabeth Chastain <mec@shout.net>
> 
> I kinda like this:
> 
>   gdb.base, gdb.gdb, gdb.mi, gdb.threads, gdb.trace
>   gdb.arch.altivec, gdb.arch.hp
>   gdb.format.stabs
>   gdb.lang.asm, gdb.lang.c++, gdb.lang.chill, gdb.lang.disasm,
>   gdb.lang.fortran, gdb.lang.java
> 
> But that would fail the 8.3 uniqueness test.

Actually, names with multiple dots are even worse than 8+3 uniqueness.

Adding target specific tests

[Elena Zannoni]

I am about to add 2 new testfiles to the gdb testsuite. Both are
specific to Altivec. One is a generic test for the ABI (function calls
and return values), the other deals with the AltiVec registers.

Where should I put them?
I was thinking of adding a gdb.altivec directory to gdb/testsuite.
Or a gdb.powerpc?
Or a gdb.regs and a gdb.abi?

I really don't know what the best solution would be. These tests
certainly cannot go in gdb.base.

Ideas? Opinions?

Elena

Re: Adding target specific tests

[Stan Shebs]

Elena Zannoni wrote:
> 
> I am about to add 2 new testfiles to the gdb testsuite. Both are
> specific to Altivec. One is a generic test for the ABI (function calls
> and return values), the other deals with the AltiVec registers.
> 
> Where should I put them?

I would suggest a gdb.arch or gdb.target for random target
specific tests, and put the altivec tests directly in it,
unless you anticipate scores or hundreds of altivec test
files a la gdb.hp.

Stan

Re: Adding target specific tests

[Fernando Nasser]

Stan Shebs wrote:
> 
> Elena Zannoni wrote:
> >
> > I am about to add 2 new testfiles to the gdb testsuite. Both are
> > specific to Altivec. One is a generic test for the ABI (function calls
> > and return values), the other deals with the AltiVec registers.
> >
> > Where should I put them?
> 
> I would suggest a gdb.arch or gdb.target for random target
> specific tests, and put the altivec tests directly in it,
> unless you anticipate scores or hundreds of altivec test
> files a la gdb.hp.
> 

That is not a bad idea.  I liked the gdb.altivec one because 
we could configure or not that directory, but we can perhaps do
the same with the files in a gdb.target (or gdb.arch) directory.

I would like to configure them out to avoid lots of 
UNSUPPORTED tests.  I would add a guard (testing for the 
right target) anyway.

P.S.: Question: how would the GDB testsuite handle multiarched
targets?  We will need to "set arch" to one architecture, run
the tests, set arch to another, re-run the tests (all?).
I guess our tests for target will have to stop being on a
configuration triplet and start using a gdb command to set
the arch and confirm that it is available).  All the 
xfail/kfail mechanism would have to change as well...

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: Adding target specific tests

[Elena Zannoni]

Fernando Nasser writes:
 > Stan Shebs wrote:
 > > 
 > > Elena Zannoni wrote:
 > > >
 > > > I am about to add 2 new testfiles to the gdb testsuite. Both are
 > > > specific to Altivec. One is a generic test for the ABI (function calls
 > > > and return values), the other deals with the AltiVec registers.
 > > >
 > > > Where should I put them?
 > > 
 > > I would suggest a gdb.arch or gdb.target for random target
 > > specific tests, and put the altivec tests directly in it,
 > > unless you anticipate scores or hundreds of altivec test
 > > files a la gdb.hp.
 > > 
 > 
 > That is not a bad idea.  I liked the gdb.altivec one because 
 > we could configure or not that directory, but we can perhaps do
 > the same with the files in a gdb.target (or gdb.arch) directory.

The altivec tests are enabled only for the altivec triplets.

 > 
 > I would like to configure them out to avoid lots of 
 > UNSUPPORTED tests.  I would add a guard (testing for the 
 > right target) anyway.
 > 

Yes, that's what I did.

 > P.S.: Question: how would the GDB testsuite handle multiarched
 > targets?  We will need to "set arch" to one architecture, run
 > the tests, set arch to another, re-run the tests (all?).
 > I guess our tests for target will have to stop being on a
 > configuration triplet and start using a gdb command to set
 > the arch and confirm that it is available).  All the 
 > xfail/kfail mechanism would have to change as well...
 > 

Good question. I wonder if we could use something analogous to the
site.exp management of multilibs. 

Elena


 > -- 
 > Fernando Nasser
 > Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
 > 2323 Yonge Street, Suite #300
 > Toronto, Ontario   M4P 2C9