more on mips-elf test installed

more on mips-elf test installed

[Joel Sherrill]

Hi,

I now appear to have all the parts installed correctly but
I am getting this weird error:

/opt/gnucross/lib/gcc-lib/mips-elf/3.2.1/../../../../mips-elf/bin/ld:
/opt/gnucross/lib/gcc-lib/mips-elf/3.2.1/../../../../mips-elf/lib/crt0.o:
Relocations in generic ELF (EM: 0)^M
/opt/gnucross/lib/gcc-lib/mips-elf/3.2.1/../../../../mips-elf/lib/crt0.o:
could not read symbols: File in wrong format^M
collect2: ld returned 1 exit status^M
compiler exited with status 1
output is:
/opt/gnucross/lib/gcc-lib/mips-elf/3.2.1/../../../../mips-elf/bin/ld:
/opt/gnucross/lib/gcc-lib/mips-elf/3.2.1/../../../../mips-elf/lib/crt0.o:
Relocations in generic ELF (EM: 0)^M

When I do a file on that crt0.o, I get

/opt/gnucross/lib/gcc-lib/mips-elf/3.2.1/../../../../mips-elf/lib/crt0.o:
ELF 32-bit MSB relocatable, no machine, version 1, stripped

Even when I try a simple main(){}, I get the same error so it is not
specific to the gcc test suite. :(

Any ideas?

Thanks.

--joel sherrill

problem running test_installed suite was Re: more on mips-elf test installed

[Joel Sherrill]

Hi again,

I have verified that my toolset tests much better when in the
build tree than with test_installed and I have tracked the
difference down to this:

Executing on host: gcc /usr/share/dejagnu/testglue.c  -c    -o
/usr3/ftp_archive/gnu/gcc/ss/b-3.2.1/r-arm-elf/testglue.o    (timeout =
300)

Notice that testglue.c is being compiled by the NATIVE compiler -- not
the cross!!!  What needs to be set to make runtest use the correct 
compiler on testglue.c?

Thanks.

--joel

Joel Sherrill wrote:
> 
> Hi,
> 
> I now appear to have all the parts installed correctly but
> I am getting this weird error:
> 
> /opt/gnucross/lib/gcc-lib/mips-elf/3.2.1/../../../../mips-elf/bin/ld:
> /opt/gnucross/lib/gcc-lib/mips-elf/3.2.1/../../../../mips-elf/lib/crt0.o:
> Relocations in generic ELF (EM: 0)^M
> /opt/gnucross/lib/gcc-lib/mips-elf/3.2.1/../../../../mips-elf/lib/crt0.o:
> could not read symbols: File in wrong format^M
> collect2: ld returned 1 exit status^M
> compiler exited with status 1
> output is:
> /opt/gnucross/lib/gcc-lib/mips-elf/3.2.1/../../../../mips-elf/bin/ld:
> /opt/gnucross/lib/gcc-lib/mips-elf/3.2.1/../../../../mips-elf/lib/crt0.o:
> Relocations in generic ELF (EM: 0)^M
> 
> When I do a file on that crt0.o, I get
> 
> /opt/gnucross/lib/gcc-lib/mips-elf/3.2.1/../../../../mips-elf/lib/crt0.o:
> ELF 32-bit MSB relocatable, no machine, version 1, stripped
> 
> Even when I try a simple main(){}, I get the same error so it is not
> specific to the gcc test suite. :(
> 
> Any ideas?
> 
> Thanks.
> 
> --joel sherrill

Re: problem running test_installed suite was Re: more on mips-elf test installed

[Ben Elliston]

>>>>> "Joel" == Joel Sherrill <joel.sherrill@OARcorp.com> writes:

  Joel> Executing on host: gcc /usr/share/dejagnu/testglue.c  -c    -o
  Joel> /usr3/ftp_archive/gnu/gcc/ss/b-3.2.1/r-arm-elf/testglue.o    (timeout =
  Joel> 300)

  Joel> Notice that testglue.c is being compiled by the NATIVE
  Joel> compiler -- not the cross!!!  What needs to be set to make
  Joel> runtest use the correct compiler on testglue.c?

What target_board have you told DejaGnu you're testing on?

Ben

Re: problem running test_installed suite was Re: more on mips-elf test installed

[Joel Sherrill]

Ben Elliston wrote:
> 
> >>>>> "Joel" == Joel Sherrill <joel.sherrill@OARcorp.com> writes:
> 
>   Joel> Executing on host: gcc /usr/share/dejagnu/testglue.c  -c    -o
>   Joel> /usr3/ftp_archive/gnu/gcc/ss/b-3.2.1/r-arm-elf/testglue.o    (timeout =
>   Joel> 300)
> 
>   Joel> Notice that testglue.c is being compiled by the NATIVE
>   Joel> compiler -- not the cross!!!  What needs to be set to make
>   Joel> runtest use the correct compiler on testglue.c?
> 
> What target_board have you told DejaGnu you're testing on?

I have been trying two configurations with the same results:

mips-elf with DejaGNU target board mips-sim
arm-elf with DejaGNU target board arm-sim

Both produce vey good test results when I test inside the tree
but if I run the tests from somewhere else, testglue.c is always
compiled with the native "gcc".  The tests that do not link against
testglue.c all appear to be passing.

Inside the tree, I do this:

make RUNTESTFLAGS="--target_board=${sim}" check check-gcc check-g++

Outside the tree, I do this:

${gccpath}/contrib/test_installed --srcdir=${gccpath} \
    --with-gcc=${1}-gcc \
    --without-g++ \
    --without-g77 \
    --with-target=${sim}

where $1 is the gcc target which gets mapped to a simulator target
a few lines above in the wrapper script I am using.

My test_installed is modified to take the --with-target option so
runtest ends up being invoked like this:

runtest --tool gcc -v --target_board arm-sim

I am sure it is a 1-liner somewhere.  I think runtest or the gcc test
suite scripts assume some variable besides GCC_UNDER_TEST is set to 
tell it about the compiler to test.

I ran into this months ago and asked on the list with no fix.  I would
really like to nail this one shut. :)

Thanks.

> Ben

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

Re: problem running test_installed suite was Re: more on mips-elf test installed

[Daniel Jacobowitz]

On Mon, Dec 16, 2002 at 08:34:20AM -0600, Joel Sherrill wrote:
> 
> 
> Ben Elliston wrote:
> > 
> > >>>>> "Joel" == Joel Sherrill <joel.sherrill@OARcorp.com> writes:
> > 
> >   Joel> Executing on host: gcc /usr/share/dejagnu/testglue.c  -c    -o
> >   Joel> /usr3/ftp_archive/gnu/gcc/ss/b-3.2.1/r-arm-elf/testglue.o    (timeout =
> >   Joel> 300)
> > 
> >   Joel> Notice that testglue.c is being compiled by the NATIVE
> >   Joel> compiler -- not the cross!!!  What needs to be set to make
> >   Joel> runtest use the correct compiler on testglue.c?
> > 
> > What target_board have you told DejaGnu you're testing on?
> 
> I have been trying two configurations with the same results:
> 
> mips-elf with DejaGNU target board mips-sim
> arm-elf with DejaGNU target board arm-sim
> 
> Both produce vey good test results when I test inside the tree
> but if I run the tests from somewhere else, testglue.c is always
> compiled with the native "gcc".  The tests that do not link against
> testglue.c all appear to be passing.
> 
> Inside the tree, I do this:
> 
> make RUNTESTFLAGS="--target_board=${sim}" check check-gcc check-g++
> 
> Outside the tree, I do this:
> 
> ${gccpath}/contrib/test_installed --srcdir=${gccpath} \
>     --with-gcc=${1}-gcc \
>     --without-g++ \
>     --without-g77 \
>     --with-target=${sim}
> 
> where $1 is the gcc target which gets mapped to a simulator target
> a few lines above in the wrapper script I am using.
> 
> My test_installed is modified to take the --with-target option so
> runtest ends up being invoked like this:
> 
> runtest --tool gcc -v --target_board arm-sim
> 
> I am sure it is a 1-liner somewhere.  I think runtest or the gcc test
> suite scripts assume some variable besides GCC_UNDER_TEST is set to 
> tell it about the compiler to test.

build_wrapper (in libgloss.exp) uses target_compile.  That won't
respect GCC_UNDER_TEST.  Try CC_FOR_TARGET?

Andrew removed the ability to import CC_FOR_TARGET from the environment
(why?) but you can run "runtest --tool gcc -v --target_board arm-sim \
CC_FOR_TARGET=arm-elf-gcc"

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: problem running test_installed suite was Re: more on mips-elf test installed

[Joel Sherrill]

Daniel Jacobowitz wrote:
> 
> On Mon, Dec 16, 2002 at 08:34:20AM -0600, Joel Sherrill wrote:
> >
> >
> > Ben Elliston wrote:
> > >
> > > >>>>> "Joel" == Joel Sherrill <joel.sherrill@OARcorp.com> writes:
> > >
> > >   Joel> Executing on host: gcc /usr/share/dejagnu/testglue.c  -c    -o
> > >   Joel> /usr3/ftp_archive/gnu/gcc/ss/b-3.2.1/r-arm-elf/testglue.o    (timeout =
> > >   Joel> 300)
> > >
> > >   Joel> Notice that testglue.c is being compiled by the NATIVE
> > >   Joel> compiler -- not the cross!!!  What needs to be set to make
> > >   Joel> runtest use the correct compiler on testglue.c?
> > >
> > > What target_board have you told DejaGnu you're testing on?
> >
> > I have been trying two configurations with the same results:
> >
> > mips-elf with DejaGNU target board mips-sim
> > arm-elf with DejaGNU target board arm-sim
> >
> > Both produce vey good test results when I test inside the tree
> > but if I run the tests from somewhere else, testglue.c is always
> > compiled with the native "gcc".  The tests that do not link against
> > testglue.c all appear to be passing.
> >
> > Inside the tree, I do this:
> >
> > make RUNTESTFLAGS="--target_board=${sim}" check check-gcc check-g++
> >
> > Outside the tree, I do this:
> >
> > ${gccpath}/contrib/test_installed --srcdir=${gccpath} \
> >     --with-gcc=${1}-gcc \
> >     --without-g++ \
> >     --without-g77 \
> >     --with-target=${sim}
> >
> > where $1 is the gcc target which gets mapped to a simulator target
> > a few lines above in the wrapper script I am using.
> >
> > My test_installed is modified to take the --with-target option so
> > runtest ends up being invoked like this:
> >
> > runtest --tool gcc -v --target_board arm-sim
> >
> > I am sure it is a 1-liner somewhere.  I think runtest or the gcc test
> > suite scripts assume some variable besides GCC_UNDER_TEST is set to
> > tell it about the compiler to test.
> 
> build_wrapper (in libgloss.exp) uses target_compile.  That won't
> respect GCC_UNDER_TEST.  Try CC_FOR_TARGET?
> 
> Andrew removed the ability to import CC_FOR_TARGET from the environment
> (why?) but you can run "runtest --tool gcc -v --target_board arm-sim \
> CC_FOR_TARGET=arm-elf-gcc"

I don't know why it doesn't import CC_FOR_TARGET and couldn't even see
how it got the right compiler when run in the build tree. :(

Thanks.  That appears to be working -- at least testglue.c is compiled
by
the right compiler anyway.  I had tried  "CC_FOR_TARGET=arm-elf-gcc
runtest ..."
but obviously that didn't work.

I am running the test suite now and if that goes well should have a
patch
to contrib/test_installed.  

Thanks.

> --
> Daniel Jacobowitz
> MontaVista Software                         Debian GNU/Linux Developer

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel@OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

Re: problem running test_installed suite was Re: more on mips-elf test installed

[Joel Sherrill]

Joel Sherrill wrote:
> 
> Daniel Jacobowitz wrote:
> >

> Thanks.  That appears to be working -- at least testglue.c is compiled
> by
> the right compiler anyway.  I had tried  "CC_FOR_TARGET=arm-elf-gcc
> runtest ..."
> but obviously that didn't work.
> 
> I am running the test suite now and if that goes well should have a
> patch
> to contrib/test_installed.

Well, it got further but I still have about 4000 more failures in the
installed test run than the in build tree version.  I see this failure
more than once:

Executing on host: arm-elf-gcc
/usr3/ftp_archive/gnu/gcc/ss/b-3.2.1/gcc-3.2.1/gcc/testsuite/gcc.c-torture/execute/20000112-1.c
testglue.o  -w  -O2  -DSTACK_SIZE=16384       -Wl,-wrap,exit
-Wl,-wrap,main -Wl,-wrap,abort -lm   -o
/usr3/ftp_archive/gnu/gcc/ss/b-3.2.1/r-arm-elf/20000112-1.x2    (timeout
= 800)
pid is 13355 -13355
output is
PASS: gcc.c-torture/execute/20000112-1.c compilation,  -O2
Simulator -run missing.
FAIL: gcc.c-torture/execute/20000112-1.c execution,  -O2

Which I take to mean that it can't figure out the simulator.

The next place the script uses the wrong gcc is during linkage.exp.

output is
cc -c 
/usr3/ftp_archive/gnu/gcc/ss/b-3.2.1/gcc-3.2.1/gcc/testsuite/gcc.misc-tests/linkage-y.c
>&/dev/null
doing compile

I notice another difference is that when run in tree, it skips 
the unsupported tests and doesn't for the installed run:

Executing on host: arm-elf-gcc
/usr3/ftp_archive/gnu/gcc/ss/b-3.2.1/gcc-3.2.1/gcc/testsuite/gcc.dg/20020122-2.c  
-O2 -fprefetch-loop-arrays -march=athlon -DSTACK_SIZE=16384 -S    -o
20020122-2.s    (timeout = 800)
pid is 26700 -26700
cc1: bad value (athlon) for -march= switch^M
cc1: warning: -fprefetch-loop-arrays not supported for this target (try
-march switches)^M

I see about 200 failure just trying to compile code that requires a 
particular -march switch or has inline assembly.  It looks like there
are a handful of other switches that aren't set.  The site.exp is:

set tmpdir "/usr3/ftp_archive/gnu/gcc/ss/b-3.2.1/r-arm-elf"
set srcdir
"/usr3/ftp_archive/gnu/gcc/ss/b-3.2.1/gcc-3.2.1/gcc/testsuite"
set GCC_UNDER_TEST "arm-elf-gcc"
set GXX_UNDER_TEST "no"
set G77_UNDER_TEST "no"

Is there more that has to be set that test_installed is not setting?

Thanks.

--joel sherrill