Re: Build problems; Please help

Re: Build problems; Please help

[Phil Edwards]

Nick Clifton <nickc@cygnus.com>:
> : Why is it building the multilib: even when I pass the option
> : --disable-multilib to configure.
>
> This is because the configure option that you want is:
>
>      --enable-multilib=no

I thought --enable-foo=no and --diable-foo were the same thing, by
autoconf definition?

I have to kill multilibs because of the NLS stuff, and I use the --disable
form all the time.


Phil

Re: Build problems; Please help

[Philipp Thomas]

* Phil Edwards (pedwards@disaster.jaj.com) [20000724 23:55]:

> I have to kill multilibs because of the NLS stuff,

Care to expand a bit? As the NLS stuff is my responsibility, I'd like to
know.

Philipp

-- 
Philipp Thomas <pthomas@suse.de>
Development, SuSE GmbH, Schanzaecker Str. 10, D-90443 Nuremberg, Germany

#define NINODE  50              /* number of in core inodes */
#define NPROC   30              /* max number of processes */
 	-- Version 7 UNIX for PDP 11, /usr/include/sys/param.h

Re: Build problems; Please help

[Jagat Brahma]

Hi Nick,

>There are two ways to tell the assembler that is being given Thumb
>instructions - via a command line switch or via a pseudo op in the
>assembly source code itself.  GAS supports both methods, but the
>command line switch is less flexible, since it implies that the entire
>source file only contains Thumb instructions, which would prohibit
>mixing ARM and Thumb instructions in the same file.
>
>Thus gcc prefers to use the pseudo op method.  What it should be doing
>is placing a:
>
>   .code 16
>
>pseudo op at the start of the assembly code for every function that it
>compiles.  This in turn should tell the assembler to expect Thumb
>instructions and then everything should work.

I am learning...

>It would appear that in your case that this ".code 16" directive is
>not being emitted, and this is the real bug.  Can you check the
>assembler output of gcc, so see what the function introduction looks
>like ?

I didn't see that  directive (.code 16). I have attached the intermediate
files and the commands used to compile, with this mail so that you can
also take a look at the file. It did compile properly when I added that
directive before the function definition. 

So that's the real Bug.

mail me if you need anything else

Happy Hacking
JP Brahma

Re: Build problems; Please help

[Nick Clifton]

Hi Jagat,

: Since the gcc does produce thumb code for -mthumb option AND the
: assembler 'gas' does not recognize the thumb code except being told 
: explicitely (through -mthumb option), I would think that there is a
: problem with the assembler was built and *not with the gcc*. Don't
: you think so ?

No.  The assembler is capable of recognising both ARM and Thumb
instructions, it just needs to be told which instructions it should be
recognising.  It defaults to recognising ARM instructions, so it only
really needs to be told when it is being given Thumb instructions.

There are two ways to tell the assembler that is being given Thumb
instructions - via a command line switch or via a pseudo op in the
assembly source code itself.  GAS supports both methods, but the
command line switch is less flexible, since it implies that the entire
source file only contains Thumb instructions, which would prohibit
mixing ARM and Thumb instructions in the same file.

Thus gcc prefers to use the pseudo op method.  What it should be doing
is placing a:

   .code 16

pseudo op at the start of the assembly code for every function that it
compiles.  This in turn should tell the assembler to expect Thumb
instructions and then everything should work.

It would appear that in your case that this ".code 16" directive is
not being emitted, and this is the real bug.  Can you check the
assembler output of gcc, so see what the function introduction looks
like ?

Cheers
	Nick

RE: Build problems; Please help

[Jagat Brahma]

Hi Nick,

>The contents of asm specs are controlled by the definition of the
>macro ASM_SPEC, which in this case is defined in config/arm/semi.h.

Thanks for the info. 

>Well no, because this is not the right way to fix the problem.  The
>assembler should not need to be told that it is being passed Thumb
>instructions.  Instead there should be directives in the code to tell
>it that the following instructions are Thumb instructions and not ARM
>instructions (which is its default).

Since the gcc does produce thumb code for -mthumb option AND the assembler
'gas' does not recognize the thumb code except being told
explicitely(through
-mthumb option), I would think that there is a problem with the assembler
was
built and *not with the gcc*. Don't you think so ? 

The assembler is built from the binutils-2.10 package. I built the 'gas'
binary though a separate make(not part of the gcc make). And since there
was not target for arm-wrs-vxworks, I created a new target 'arm-wrs-vxworks'
with the same properties as 'arm-coff' target and built the binutils
package.
May be the new target was not created properly, though I did it carefully. 

There is a target in binutils package called *-*-vxworks. But it is for aout
format and i wanted a coff format. So I could not use it. 

May be a new target called 'arm-wrs-vxworks' shoould be added to the
binutils 
package with the proper settings.

>This is supposed to be controlled by the definition of the ASM_APP_OFF
>macro in config/arm/arm.h.  This is a grungy way to do it, but it does
>work.  Or at least it does for other ARM targets.
>
>I do not know why it is not working for you.  Maybe ASM_APP_OFF is
>being redefined somewhere after its definition in arm.h ?

Yes, there a define for ARM_APP_OFF which a test for THUMB targets. And I
think
it is working fine(with the above reasoning). 


Regards
JP Brahma

Re: Build problems; Please help

[Nick Clifton]

Hi Jagat,

:    Some More Updates on Build Problem. The assembler error was being 
: generated because the -mthumb option to gcc was not being passed
: down to the assembler.  Because the specs file didn't have that
: specified. So I added the line 
: 
: %{mthumb:-mthumb}
: 
: to the asm specs in the file
: /home/jbrahma/local/zip/build-egcs/gcc/specs 
: 
: But I don't know how the specs file is generated from the source
: files.  So If somebody know where to put the patch in the sources,
: please mail me.

The contents of asm specs are controlled by the definition of the
macro ASM_SPEC, which in this case is defined in config/arm/semi.h.


: May be this patch should be also applied to the CVS.  

Well no, because this is not the right way to fix the problem.  The
assembler should not need to be told that it is being passed Thumb
instructions.  Instead there should be directives in the code to tell
it that the following instructions are Thumb instructions and not ARM
instructions (which is its default).

This is supposed to be controlled by the definition of the ASM_APP_OFF
macro in config/arm/arm.h.  This is a grungy way to do it, but it does
work.  Or at least it does for other ARM targets.

I do not know why it is not working for you.  Maybe ASM_APP_OFF is
being redefined somewhere after its definition in arm.h ?

Cheers
	Nick

Re: Build problems; Please help

[Philipp Thomas]

* Phil Edwards (pedwards@disaster.jaj.com) [20000726 19:26]:

> Are there any particular config flags that you'd like tested in conjunction
> with --enable-nls?

Nope, just do a normal build. NLS support is turned on by default if not
doing a canadian cross build, so just don't use --disable-nls and all should
be well.

Philipp

-- 
Philipp Thomas <pthomas@suse.de>
Development, SuSE GmbH, Schanzaecker Str. 10, D-90443 Nuremberg, Germany

#define NINODE  50              /* number of in core inodes */
#define NPROC   30              /* max number of processes */
 	-- Version 7 UNIX for PDP 11, /usr/include/sys/param.h

Re: Build problems; Please help

[Phil Edwards]

Philipp Thomas <pthomas@suse.de>:
> * Phil Edwards (pedwards@disaster.jaj.com) [20000725 17:39]:
> > Errr... When I enable multilibs, bootstrap fails.  When I turn it off,
> > bootstrap works.  That's about all I know.  :-)
> > 
> > I'm using sparc-sun-solaris2.8, and the last time I tried a bootstrap,
> > the build died somewhere in a 'po' directory.  Since I was concentrating
> > on something else at the time, I tracked it down to NLS and didn't look
> > any closer.
>
> Do you by chance still have the make log? I'd be really interested to track
> this down.

The .o's, but not the make log; sorry.

Like I said, it's been many days, so this may not be a /recent/ failure.
As soon as our firewall stops being uppity with me, I'll be getting a
fresh checkout.  And I will definitely try a bootstrap with NLS turned on,
and let you know how it goes.  (Even when multilibs works, we'll probably
leave NLS turned off to avoid overhead, just because the users here are
the kind that would be "actively disinterested" in it.)

Are there any particular config flags that you'd like tested in conjunction
with --enable-nls?


Phil

Re: Build problems; Please help

[Philipp Thomas]

* Phil Edwards (pedwards@disaster.jaj.com) [20000725 17:39]:

> Errr... When I enable multilibs, bootstrap fails.  When I turn it off,
> bootstrap works.  That's about all I know.  :-)
> 
> I'm using sparc-sun-solaris2.8, and the last time I tried a bootstrap,
> the build died somewhere in a 'po' directory.  Since I was concentrating
> on something else at the time, I tracked it down to NLS and didn't look
> any closer.

Do you by chance still have the make log? I'd be really interested to track
this down.

Philipp

-- 
Philipp Thomas <pthomas@suse.de>
Development, SuSE GmbH, Schanzaecker Str. 10, D-90443 Nuremberg, Germany

#define NINODE  50              /* number of in core inodes */
#define NPROC   30              /* max number of processes */
 	-- Version 7 UNIX for PDP 11, /usr/include/sys/param.h

RE: Build problems; Please help

[Jagat Brahma]

>Your problem is that __arm__ is being defined in Thumb mode.  The
>-mthumb switch tells gcc to produce Thumb opcodes.  The libgcc support
>file gcc/longlong.h however, has an inlined version of the umul_ppmm
>function, which contains ARM instructions.   This inlined version
>therefore, should be used in ARM mode, not Thumb mode.  The inclusion
>f the inclined version is dependent upon the preprocessor symbol
>__arm__ being defined.  This symbol is supposed to be defined in ARM
>mode, but not in Thumb mode.
>
>I suspect that this is happening because your configuration is
>including gcc/config/arm/vxarm.h which unilaterally defines __arm__ in
>CPP_PREDEFINES.  I would suggest that you try removing the definition
>from there and allowing the CPP_SPEC code in arm.h to handle defining
>this macro.

   Some More Updates on Build Problem. The assembler error was being
generated
because the -mthumb option to gcc was not being passed down to the
assembler.
Because the specs file didn't have that specified. So I added the line

%{mthumb:-mthumb}

to the asm specs in the file /home/jbrahma/local/zip/build-egcs/gcc/specs

The diff is
-------------------------------------------------
*** /home/jbrahma/local/zip/build-egcs/gcc/specs       Tue Jul 25 15:29:48
2000
--- /home/jbrahma/local/zip/build-egcs/gcc/specs.bak   Tue Jul 25 15:43:44
2000
***************
*** 1,5 ****
  *asm:
! %{mbig-endian:-EB} %{mcpu=*:-m%*} %{march=*:-m%*} %{mapcs-*:-mapcs-%*}
%{mapcs-float:-mfloat} %{msoft-float:-mno-fpu}
%{mthumb-interwork:-mthumb-interwork} %{mthumb:-mthumb}
  
  *asm_final:
  
--- 1,5 ----
  *asm:
! %{mbig-endian:-EB} %{mcpu=*:-m%*} %{march=*:-m%*} %{mapcs-*:-mapcs-%*}
%{mapcs-float:-mfloat} %{msoft-float:-mno-fpu}
%{mthumb-interwork:-mthumb-interwork}
  
  *asm_final:
-------------------------------------------------

But I don't know how the specs file is generated from the source files.
So If somebody know where to put the patch in the sources, please mail
me. May be this patch should be also applied to the CVS. 

Thanks

JP Brahma

RE: Build problems; Please help

[Jagat Brahma]

Thanks for all the help. The below patch did solve part of the problem.
I had to remove the configure option --with-cpu=strongarm110 to get rid
of the assembler error totally. 


Thanks again
JP Brahma


>Your problem is that __arm__ is being defined in Thumb mode.  The
>-mthumb switch tells gcc to produce Thumb opcodes.  The libgcc support
>file gcc/longlong.h however, has an inlined version of the umul_ppmm
>function, which contains ARM instructions.   This inlined version
>therefore, should be used in ARM mode, not Thumb mode.  The inclusion
>f the inclined version is dependent upon the preprocessor symbol
>__arm__ being defined.  This symbol is supposed to be defined in ARM
>mode, but not in Thumb mode.
>
>I suspect that this is happening because your configuration is
>including gcc/config/arm/vxarm.h which unilaterally defines __arm__ in
>CPP_PREDEFINES.  I would suggest that you try removing the definition
>from there and allowing the CPP_SPEC code in arm.h to handle defining
>this macro.
>
>ie:
>
>Index: gcc/config/arm/vxarm.h
>===================================================================
>RCS file: /cvs/gcc/egcs/gcc/config/arm/vxarm.h,v
>retrieving revision 1.3
>diff -p -r1.3 vxarm.h
>*** vxarm.h	2000/02/15 16:36:34	1.3
>--- vxarm.h	2000/07/25 00:20:52
>*************** Boston, MA 02111-1307, USA.  */
>*** 39,45 ****
>    %{!mcpu*:%{!march=*:-DCPU=ARM710A}} \
>  "
>  #undef  CPP_PREDEFINES
>! #define CPP_PREDEFINES  "-D__vxworks -D__arm__ -Acpu(arm) -Amachine(arm)"
>  
>  /* VxWorks does all the library stuff itself.  */
>  
>--- 39,45 ----
>    %{!mcpu*:%{!march=*:-DCPU=ARM710A}} \
>  "
>  #undef  CPP_PREDEFINES
>! #define CPP_PREDEFINES  "-D__vxworks -Acpu(arm) -Amachine(arm)"
>  
>  /* VxWorks does all the library stuff itself.  */
>
>
>
>: Again it tries to build the multilib with --enable-multilib=no.
>: Here is the configure script that I used.
>: 
>: ../egcs-20000717/configure --prefix=/home/jbrahma/local
>: --target=arm-wrs-vxworks \
>: --with-newlib --disable-biendian --enable-languages="c c++"
>: --enable-multilib=no \
>: --with-cpu=strongarm110
>
>I suspect (but I am not sure) that disabling multilibs only works at
>the top level, ie for disabling building mutlilibbed version of
>newlib, libstdc++ etc.  I think that you cannot disable the building
>of multilib'ed versions of libgcc.a if they are specified in the
>relevant t- file.
>
>My suggestion: edit the t- file and remove the multilibs that you do
>not want.  (I do not know which t- file you are using, because you say
>that you have created a new target in configure.in.  I suspect however
>that it will probably be t-arm-coff.  If you do have a new target in
>configure.in, then I would suggest changing the defintion of
>tmake_file to, say t-arm-vxworks, and then copying t-arm-coff to this
>file, and then edititing it to your hearts content.


The target arm-wrs-vxworks was already present in the egcs code.
But it was missing in binutils package. So I made a copy of the
target arm-coff and built the binutils package so that the compiler
picks up the binutils binaries from the right place.


>
>Cheers
>	Nick
>

Re: Build problems; Please help

[Phil Edwards]

Philipp Thomas <pthomas@suse.de>:
> * Phil Edwards (pedwards@disaster.jaj.com) [20000724 23:55]:
>
> > I have to kill multilibs because of the NLS stuff,
>
> Care to expand a bit? As the NLS stuff is my responsibility, I'd like to
> know.

Errr... When I enable multilibs, bootstrap fails.  When I turn it off,
bootstrap works.  That's about all I know.  :-)

I'm using sparc-sun-solaris2.8, and the last time I tried a bootstrap,
the build died somewhere in a 'po' directory.  Since I was concentrating
on something else at the time, I tracked it down to NLS and didn't look
any closer.  I haven't tried in almost a week, though, since libstdc++-v3
won't build on non-Linux platforms.


Phil

Re: Build problems; Please help

[Nick Clifton]

Hi Jagat,

: Here is the output

: ====================================================
: /home/jbrahma/local/zip/build-egcs/gcc/xgcc

: -I../../egcs-20000717/gcc/../include  -mthumb -DL_muldi3

: /var/tmp/ccAGbkAf.s: Assembler messages:
: /var/tmp/ccAGbkAf.s:95: Error: bad instruction `push {r4,r5,r6,r7,lr}'
: -----------------------------------------------------------------

: -----------------------libgcc2.s---------------------------------
:     .global ___muldi3
:     .thumb_func
: ___muldi3:
: line 95:>>>>    push    {r4, r5, r6, r7, lr}
:     @ Inlined umul_ppmm
:     mov r5, r0, lsr #16
:     mov r7, r2, lsr #16

: -----------------------------------------
: Moreover if I remove the option -mthumb it works.

Your problem is that __arm__ is being defined in Thumb mode.  The
-mthumb switch tells gcc to produce Thumb opcodes.  The libgcc support
file gcc/longlong.h however, has an inlined version of the umul_ppmm
function, which contains ARM instructions.   This inlined version
therefore, should be used in ARM mode, not Thumb mode.  The inclusion
of the inclined version is dependent upon the preprocessor symbol
__arm__ being defined.  This symbol is supposed to be defined in ARM
mode, but not in Thumb mode.

I suspect that this is happening because your configuration is
including gcc/config/arm/vxarm.h which unilaterally defines __arm__ in
CPP_PREDEFINES.  I would suggest that you try removing the definition
from there and allowing the CPP_SPEC code in arm.h to handle defining
this macro.

ie:

Index: gcc/config/arm/vxarm.h
===================================================================
RCS file: /cvs/gcc/egcs/gcc/config/arm/vxarm.h,v
retrieving revision 1.3
diff -p -r1.3 vxarm.h
*** vxarm.h	2000/02/15 16:36:34	1.3
--- vxarm.h	2000/07/25 00:20:52
*************** Boston, MA 02111-1307, USA.  */
*** 39,45 ****
    %{!mcpu*:%{!march=*:-DCPU=ARM710A}} \
  "
  #undef  CPP_PREDEFINES
! #define CPP_PREDEFINES  "-D__vxworks -D__arm__ -Acpu(arm) -Amachine(arm)"
  
  /* VxWorks does all the library stuff itself.  */
  
--- 39,45 ----
    %{!mcpu*:%{!march=*:-DCPU=ARM710A}} \
  "
  #undef  CPP_PREDEFINES
! #define CPP_PREDEFINES  "-D__vxworks -Acpu(arm) -Amachine(arm)"
  
  /* VxWorks does all the library stuff itself.  */
  


: Again it tries to build the multilib with --enable-multilib=no.
: Here is the configure script that I used.
: 
: ../egcs-20000717/configure --prefix=/home/jbrahma/local
: --target=arm-wrs-vxworks \
: --with-newlib --disable-biendian --enable-languages="c c++"
: --enable-multilib=no \
: --with-cpu=strongarm110

I suspect (but I am not sure) that disabling multilibs only works at
the top level, ie for disabling building mutlilibbed version of
newlib, libstdc++ etc.  I think that you cannot disable the building
of multilib'ed versions of libgcc.a if they are specified in the
relevant t- file.

My suggestion: edit the t- file and remove the multilibs that you do
not want.  (I do not know which t- file you are using, because you say
that you have created a new target in configure.in.  I suspect however
that it will probably be t-arm-coff.  If you do have a new target in
configure.in, then I would suggest changing the defintion of
tmake_file to, say t-arm-vxworks, and then copying t-arm-coff to this
file, and then edititing it to your hearts content.

Cheers
	Nick

RE: Build problems; Please help

[Jagat Brahma]

>Hi Jagat,
>
>: I have build gas as part of the package binutils. It is build and
>: it is picking up the assembler that is build for the arm. Here is
>: the output with -v flag to the gcc.
>
>:  cc1 /var/tmp/ccmGXaHg.i -mthumb -g -g1 -O2 -version -fno-inline -o
>: /var/tmp/ccH7l0Fp.s
>
>: as -o libgcc/thumb/_divdi3.o /var/tmp/ccH7l0Fp.s
>
>: /var/tmp/ccH7l0Fp.s:353: Error: bad instruction `push {r4,r5,r6,r7,lr}'
>: : -------------------------------------------------
>: This shows that it is picking up the correct assembler binary.
>
>OK - I was wrong, sorry.
>
>Presumably then the compiler is producing a bad assembler output,
>which is then being rejected.  Can you show us what the assembler
>output around line 353 looks like ?



Here is the output
(the actual line number in the prev mail was a typo the actual line
number is 95)

====================================================
/home/jbrahma/local/zip/build-egcs/gcc/xgcc
-B/home/jbrahma/local/zip/build-egcs/gcc/
-B/home/jbrahma/local/arm-wrs-vxworks/bin/
-I/home/jbrahma/local/arm-wrs-vxworks/include -O2
-DCROSS_COMPILE -DIN_GCC  -DSVR4  -g -O2 -isystem
./include  -Dinhibit_libc -fno-inline -g1 -DHAVE_GTHR_DEFAULT
-DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I.
-I../../egcs-20000717/gcc -I../../egcs-20000717/gcc/config
-I../../egcs-20000717/gcc/../include  -mthumb -DL_muldi3
-c ../../egcs-20000717/gcc/libgcc2.c -o libgcc/thumb/_muldi3.o
/var/tmp/ccAGbkAf.s: Assembler messages:
/var/tmp/ccAGbkAf.s:95: Error: bad instruction `push {r4,r5,r6,r7,lr}'
make[2]: *** [libgcc/thumb/_muldi3.o] Error 1
make[2]: Leaving directory `/home/jbrahma/local/zip/build-egcs/gcc'
-----------------------------------------------------------------
-----------------------libgcc2.s---------------------------------
.stabn 162,0,0,0
    .align  0
.stabs "__muldi3:F(17,7)",36,0,187,___muldi3
.stabs "u:P(17,7)",64,0,186,0
.stabs "v:P(17,7)",64,0,186,2
    .global ___muldi3
    .thumb_func
___muldi3:
line 95:>>>>    push    {r4, r5, r6, r7, lr}
    @ Inlined umul_ppmm
    mov r5, r0, lsr #16
    mov r7, r2, lsr #16
    bic r4, r0, r5, lsl #16
    bic lr, r2, r7, lsl #16
    mul ip, r4, lr
    mul lr, r5, lr
    mul r4, r7, r4
    mul r7, r5, r7
    adds    r4, lr, r4
    addcs   r7, r7, #65536
    adds    ip, ip, r4, lsl #16
    adc r7, r7, r4, lsr #16
-----------------------------------------
Moreover if I remove the option -mthumb it works.

Again it tries to build the multilib with --enable-multilib=no.
Here is the configure script that I used.

../egcs-20000717/configure --prefix=/home/jbrahma/local
--target=arm-wrs-vxworks \
--with-newlib --disable-biendian --enable-languages="c c++"
--enable-multilib=no \
--with-cpu=strongarm110


Thanks

JP Brahma

________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

Re: Build problems; Please help

[Mike Stump]

> From: "Jagat Brahma" <jpbrahma@hotmail.com>
> To: gcc@gcc.gnu.org
> Date: Mon, 24 Jul 2000 20:23:39 GMT

>    I have been trying to build the latest egcs snapshot for
> *arm-wrs-vxworks* target on a
> *sparc-sun-solaris2.6* host. Somehow I am facing compilation errors(!!) that
> I have no
> clue how to solve.

I suspect you are trying to assemble arm instructions with a sparc
assembler.  You can confirm this by using -v.  If it finds as out of
the path, and if the as in your path is a sparc assembler, this would
account for the problems.

I normally put all the sources together to build, when one does this,
gcc find /gas/as[.-]new and uses it over as in the path.

If you get and install binutils with the same --prefix argument to the
compiler, before you compile up the compiler, I think it will also
work.

RE: Build problems; Please help

[Jagat Brahma]

Hi,

   Thanks for the reply.

I have build gas as part of the package binutils. It is build and
it is picking up the assembler that is build for the arm. Here is
the output with -v flag to the gcc.
-----
  /home/jbrahma/local/zip/build-egcs/gcc/xgcc  <snipped> -o 
libgcc/thumb/_divdi3.o -v
  Reading specs from /home/jbrahma/local/zip/build-egcs/gcc/specs
   gcc version 2.96 20000717 (experimental)
  /home/jbrahma/local/zip/build-egcs/gcc/cpp -lang-c -v
  -I/home/jbrahma/local/arm-wrs-vxworks/include -I.
  -I../../egcs-20000717/gcc -I../../egcs-20000717/gcc/config
  -I../../egcs-20000717/gcc/../include
  -iprefix 
/home/jbrahma/local/zip/build-egcs/gcc/../lib/gcc-lib/arm-wrs-vxworks/2.96/
  -isystem /home/jbrahma/local/arm-wrs-vxworks/bin/include
  -isystem /home/jbrahma/local/zip/build-egcs/gcc/include
  -D__GNUC__=2 -D__GNUC_MINOR__=96 -D__GNUC_PATCHLEVEL__=0 -D__vxworks 
-D__arm__
  -D__vxworks -D__arm__ -Acpu(arm) -Amachine(arm) -D__CHAR_UNSIGNED__ 
-D__OPTIMIZE__
  -g -g1 -D__ARM_ARCH_3__ -D__APCS_32__ -D__ARMEL__ -D__THUMBEL__ 
-DCPU=ARM710A
  -Dthumb -D__thumb__ -DCROSS_COMPILE -DIN_GCC -DSVR4 -Dinhibit_libc 
-DHAVE_GTHR_DEFAULT
  -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -DL_divdi3
  -isystem ./include ../../egcs-20000717/gcc/libgcc2.c /var/tmp/ccmGXaHg.i
  GNU CPP version 2.96 20000717 (experimental) (cpplib) (ARM/VxWorks)

<snipped>

  /home/jbrahma/local/zip/build-egcs/gcc/cc1 /var/tmp/ccmGXaHg.i -quiet 
-dumpbase
  libgcc2.c -mthumb -g -g1 -O2 -O2 -version -fno-inline -o 
/var/tmp/ccH7l0Fp.s
  GNU C version 2.96 20000717 (experimental) (arm-wrs-vxworks) compiled by 
GNU C version 2.8.1.
  /home/jbrahma/local/arm-wrs-vxworks/bin/as -o libgcc/thumb/_divdi3.o 
/var/tmp/ccH7l0Fp.s
  /var/tmp/ccH7l0Fp.s: Assembler messages:
  /var/tmp/ccH7l0Fp.s:353: Error: bad instruction `push {r4,r5,r6,r7,lr}'

-------------------------------------------------
This shows that it is picking up the correct assembler binary.

And here is the --version output of the gas binary
-----------------------------------------------------------
  /home/jbrahma/local/arm-wrs-vxworks/bin/as --version
  GNU assembler 2.10
  Copyright
<snip>
  This assembler was configured for a target of `arm-wrs-vxworks'.
-----------------------------------------------------------

Since there was no target for arm-wrs-vxworks in binutils, I copied the
configure parameters for the new target and build it. I have also tried
with an assembler binary built with arm-coff. That too gave the same
error message.


Thanks
JP Brahma


________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

Re: Build problems; Please help

[Nick Clifton]

Hi Jagat,

: /var/tmp/ccemnK8B.s: Assembler messages:
: /var/tmp/ccemnK8B.s:95: Error: bad instruction `push {r4,r5,r6,r7,lr}'

This error is occuriung because you do not have gas for the ARM
built.  So the output of gcc is being assembled by the host system's
assembler, which of course does not understand ARM opcodes.

Check to see that gas/as-new has been built in your build directory
and that gcc/as is a symbolic link to this executable.  If either of
these tests fail, then try running 'make clean-gas all-gas' at the top
level before continuing with your build of gcc.


: Why is it building the multilib: even when I pass the option
: --disable-multilib to configure.

This is because the configure option that you want is:

     --enable-multilib=no


Cheers
	Nick

Build problems; Please help

[Jagat Brahma]

Hi,
   I have been trying to build the latest egcs snapshot for
*arm-wrs-vxworks* target on a
*sparc-sun-solaris2.6* host. Somehow I am facing compilation errors(!!) that
I have no
clue how to solve.

My configure script is
../egcs-20000717/configure --prefix=/home/jbrahma/local
--target=arm-wrs-vxworks --with-newlib --with-headers=/vobs/OS/wind/target/h
--with-libs="/vobs/OS/wind/host/sun4-solaris2/lib " --disable-biendian
--enable-languages="c c++" --disable-multilib


The error that I get is
--------------------------------------------------------
/home/jbrahma/local/zip/build-egcs/gcc/xgcc
-B/home/jbrahma/local/zip/build-egcs/gcc/  \
-B/home/jbrahma/local/arm-wrs-vxworks/bin/
-I/home/jbrahma/local/arm-wrs-vxworks/include -O2  \
-DCROSS_COMPILE -DIN_GCC  -DSVR4  -g -O2 -isystem ./include  -Dinhibit_libc
-fno-inline -g1  \
-DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I.
\
-I../../egcs-20000717/gcc -I../../egcs-20000717/gcc/config
-I../../egcs-20000717/gcc/../include  \
-mthumb -DL_muldi3 -c ../../egcs-20000717/gcc/libgcc2.c -o
libgcc/thumb/_muldi3.o
/var/tmp/ccemnK8B.s: Assembler messages:
/var/tmp/ccemnK8B.s:95: Error: bad instruction `push {r4,r5,r6,r7,lr}'
make[2]: *** [libgcc/thumb/_muldi3.o] Error 1
make[2]: Leaving directory `/home/jbrahma/local/zip/build-egcs/gcc'
make[1]: *** [stmp-multilib] Error 2
make[1]: Leaving directory `/home/jbrahma/local/zip/build-egcs/gcc'
make: *** [all-gcc] Error 2
---------------------------------

I don't know why the assembler is complaining. Why is it building the
multilib
even when I pass the option --disable-multilib to configure. Is it that I am
missing
a patch / a configure options / something totally different. I tried
searching the
mailing list archive. But I couldn't find something that is related to this.

Any help is greatly appreciated.

JP Brahma


________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com