Re: embedded MIPS multilib selection or isa level setting error

[Joel Sherrill <joel dot sherrill at OARcorp dot com>]

Ian Lance Taylor wrote:
> 
>    Date: Mon, 17 Apr 2000 12:14:04 -0500
>    From: Joel Sherrill <joel.sherrill@OARcorp.com>
> 
>    > This is documented.  The -mcpu option affects only scheduling, not
>    > code generation.
> 
>    So when targetting the 4650, do I need to specify both "-m4650"
>    and "-mcpu=4650"?  Somehow this does not make sense to me.
> 
> -m4650 implies -mcpu=4650.  Check the gcc documentation.
> 
>    Besides it still is giving the same result.  I can compile
>    main.c separately (-c) and the error changes to:
> 
>    /opt/rtems/mips64orion-rtems/bin/ld: main.o:
>      ISA mismatch (-mips3) with previous modules (-mips1)
> 
>    So that proves you correct.  So is the object in single/ incorrectly
>    isa level 1?
> 
> Perhaps.  I don't know just what objects the linker is picking up.
> Linking with -Wl,-t should show you that.

Sorry.  I cut and pasted the one-liners when the full thing would have
been more 
useful:

[joel@britain mips-test]$ mips64orion-rtems-gcc -m4650 main.c -c
[joel@britain mips-test]$ mips64orion-rtems-gcc -m4650 main.c  -lc
-Wl,-t
/opt/rtems/mips64orion-rtems/bin/ld: /tmp/cc3xLwlU.o: ISA mismatch
(-mips3) with previous modules (-mips1)
Bad value: failed to merge target specific data of file /tmp/cc3xLwlU.o
/opt/rtems/mips64orion-rtems/bin/ld: warning: cannot find entry symbol
_start; defaulting to 0000000000400000
/opt/rtems/mips64orion-rtems/bin/ld: link errors found, deleting
executable `a.out'
/opt/rtems/mips64orion-rtems/bin/ld: mode elf32ebmip
/opt/rtems/mips64orion-rtems/lib/single/crt0.o
/tmp/cc3xLwlU.o
(/opt/rtems/mips64orion-rtems/lib/single/libc.a)strlen.o
(/opt/rtems/lib/gcc-lib/mips64orion-rtems/2.95.2/single/libgcc.a)__main.o
(/opt/rtems/lib/gcc-lib/mips64orion-rtems/2.95.2/single/libgcc.a)_ctors.o
collect2: ld returned 1 exit status       

main.c is: just enough to require the C library and sometimes libgcc

int main(int argc, char **argv)
{
  int x,y;
  strlen( "invoke something in libc" );
  return x % y;
}          

The output of mips64orion-rtems-objdump -f for main.o and the selected
crt0.o is
below:

[joel@britain mips-test]$ mips64orion-rtems-objdump -f main.o

main.o:     file format elf32-bigmips
architecture: mips:4650, flags 0x00000011:
HAS_RELOC, HAS_SYMS
start address 0x0000000000000000

<rion-rtems-objdump -f /opt/rtems/mips64orion-rtems/lib/single/crt0.o

/opt/rtems/mips64orion-rtems/lib/single/crt0.o:     file format
elf32-bigmips
architecture: mips:3000, flags 0x00000010:
HAS_SYMS
start address 0x0000000000000000     

<ms/lib/gcc-lib/mips64orion-rtems/2.95.2/crtbegin.o

/opt/rtems/lib/gcc-lib/mips64orion-rtems/2.95.2/single/crtbegin.o:    
file format elf32-bigmips
architecture: mips:3000, flags 0x00000010:
HAS_SYMS
start address 0x0000000000000000  

I think this starts to point at something wrong in the way the support
libraries
were built based on the multilib specification. 


> 
> Ian

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