new port's validation

new port's validation

[Florent DEFAY]

Hi,

I am working on a new port.

The arch is a 16 bit machine.

The current state should enable any compilation. Libgcc is compiled.
The cc1 is working.

Now I try to validate. My method is to launch make check-gcc.
But many tests go wrong for two main reasons:
some tests need to include standard header files, but we do not need
to implement a libc
some tests are too long or use too large arrays and it is impossible
with the memory of the machine

Do you know better methods to validate GCC for such an arch?
Should we implement a libc since there is no OS?
Please, I need advice.

Regards.

Florent

Re: new port's validation

[Ian Lance Taylor]

Florent DEFAY <spira.inhabitant@gmail.com> writes:

> some tests need to include standard header files, but we do not need
> to implement a libc

I don't know of a good way to handle this scenario.  Most tests do not
use any header files, and it's reasonably easy to ignore the ones which
do.  Or, it's also usually pretty easy to port newlib, which will at
least get you through the compilation tests.

> some tests are too long or use too large arrays and it is impossible
> with the memory of the machine

You can define STACK_SIZE while running the tests.  That will disable
some large tests.  I think this can be done in your site.exp file or
your board support file by setting target_info gcc,stack_size.  See
gcc/testsuite/lib/gcc.exp for other target_info fields of interest.

The testsuite also supports a dg-require framework.  For example, a test
marked with

/* { dg-require-effective-target int32plus } */

should not be run on a target with 16-bit ints.  Poke around in
gcc/testsuite/lib/target-supports-exp.

I don't know if there is any documentation for this stuff, but there may
be.

Ian

Re: new port's validation

[Florent DEFAY]

Thank you.

> You can define STACK_SIZE while running the tests.  That will disable
> some large tests.  I think this can be done in your site.exp file or
> your board support file by setting target_info gcc,stack_size.  See
> gcc/testsuite/lib/gcc.exp for other target_info fields of interest.

I cannot find any site.exp file. Can you give me a tree example for
another arch?
I did not find anything looking like defining target_info in .exp files but only
using target_info. Where should I add a board support file?

> The testsuite also supports a dg-require framework.  For example, a test
> marked with
>
> /* { dg-require-effective-target int32plus } */
>
> should not be run on a target with 16-bit ints.

How to tell the testsuite that my target is 16-bit? I found that in
target-supports.exp:
proc check_effective_target_int32plus { } {
    return [check_no_compiler_messages int32plus object {
        int dummy[sizeof (int) >= 4 ? 1 : -1];
    }]
}

Is it cross-compiled and executed code? Because execution is not
configured (simulator not configured).


Regards.

Florent

Re: new port's validation

[Ian Lance Taylor]

Florent DEFAY <spira.inhabitant@gmail.com> writes:

>> You can define STACK_SIZE while running the tests.  That will disable
>> some large tests.  I think this can be done in your site.exp file or
>> your board support file by setting target_info gcc,stack_size.  See
>> gcc/testsuite/lib/gcc.exp for other target_info fields of interest.
>
> I cannot find any site.exp file. Can you give me a tree example for
> another arch?

When run "make check-gcc" it will create a site.exp file.  If there is
an existing site.exp file, it will be edited to preserve whatever values
are already there.


> I did not find anything looking like defining target_info in .exp files but only
> using target_info. Where should I add a board support file?

I've never figured out how this is supposed to work cleanly, if indeed
such a thing was ever defined.  I just add new files to the baseboards
directory in the dejagnu tree, e.g., /usr/share/dejagnu/baseboards.


>> The testsuite also supports a dg-require framework.  For example, a test
>> marked with
>>
>> /* { dg-require-effective-target int32plus } */
>>
>> should not be run on a target with 16-bit ints.
>
> How to tell the testsuite that my target is 16-bit? I found that in
> target-supports.exp:
> proc check_effective_target_int32plus { } {
>     return [check_no_compiler_messages int32plus object {
>         int dummy[sizeof (int) >= 4 ? 1 : -1];
>     }]
> }
>
> Is it cross-compiled and executed code? Because execution is not
> configured (simulator not configured).

That code is not executed, it is simply cross-compiled.  The compilation
will fail if sizeof(int) < 4 because dummy[-1] is a compilation error.

Ian

Re: new port's validation

[Michael Meissner]

On Fri, Apr 24, 2009 at 02:16:34PM +0200, Florent DEFAY wrote:
> Hi,
> 
> I am working on a new port.
> 
> The arch is a 16 bit machine.
> 
> The current state should enable any compilation. Libgcc is compiled.
> The cc1 is working.
> 
> Now I try to validate. My method is to launch make check-gcc.
> But many tests go wrong for two main reasons:
> some tests need to include standard header files, but we do not need
> to implement a libc
> some tests are too long or use too large arrays and it is impossible
> with the memory of the machine
> 
> Do you know better methods to validate GCC for such an arch?
> Should we implement a libc since there is no OS?
> Please, I need advice.

When I was doing embedded work in the past, I usually did a port of newlib so
that the standard header files, abort, printf, existed.  There are various
switches you can set to reduce which tests get run.  I would look for another
16-bit bit embedded system, and set things up the same way.  Look at
doc/sourcebuild.texi and the target-support.exp file in testsuite/lib.

-- 
Michael Meissner, IBM
4 Technology Place Drive, MS 2203A, Westford, MA, 01886, USA
meissner@linux.vnet.ibm.com