AW: Cross Compiler again

AW: Cross Compiler again

[Andre.Messerschmidt]

> I regularly use gcc 3.0.1 to build the latest oss cvs kernels without
> obvious incident.
> 
I am using a 2.4.2 Kernel from Montavista, which is not working with gcc
3.0.1.
Maybe it would be wise to upgrade. Does anybody know if there are any
problems using a MIPS 5Kc with the current kernel?

regards 
Andre

Re: Cross Compiler again

[Daniel Jacobowitz]

On Thu, Nov 22, 2001 at 06:13:46PM +0100, Andre.Messerschmidt@infineon.com wrote:
> > I regularly use gcc 3.0.1 to build the latest oss cvs kernels without
> > obvious incident.
> > 
> I am using a 2.4.2 Kernel from Montavista, which is not working with gcc
> 3.0.1.
> Maybe it would be wise to upgrade. Does anybody know if there are any
> problems using a MIPS 5Kc with the current kernel?

If you simply fix the one declaration it complains about (it involves
adding 'volatile' to one of the two declarations of xtime) then this
kernel actually will work under GCC 3.0.1.  We haven't QA'd it, but I
use it routinely for testing.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: Cross Compiler again

[Ralf Baechle]

On Thu, Nov 22, 2001 at 06:13:46PM +0100, Andre.Messerschmidt@infineon.com wrote:

> > I regularly use gcc 3.0.1 to build the latest oss cvs kernels without
> > obvious incident.
> > 
> I am using a 2.4.2 Kernel from Montavista, which is not working with gcc
> 3.0.1.

General rule for the kernel is don't use gcc 3.x.  It's not only buggier
than the older compilers, it also produces worse code.  In particular it's
know to misscompile certain drivers on other architectures.  I'm still
using egcs 1.1.2 which is known to be a very solid compiler.  That may seem
to be a bit overly conservative to some; for those I recommend a compiler
derived from 2.95.3.

> Maybe it would be wise to upgrade. Does anybody know if there are any
> problems using a MIPS 5Kc with the current kernel?

Nothing that's known.

  Ralf

Re: Cross Compiler again

[Maciej W. Rozycki]

On Mon, 26 Nov 2001, Ralf Baechle wrote:

> General rule for the kernel is don't use gcc 3.x.  It's not only buggier
> than the older compilers, it also produces worse code.  In particular it's
> know to misscompile certain drivers on other architectures.  I'm still
> using egcs 1.1.2 which is known to be a very solid compiler.  That may seem
> to be a bit overly conservative to some; for those I recommend a compiler
> derived from 2.95.3.

 I'll just add that I'm particularly happy with 2.95.3 with a set of
patches.  I'm using it for one about year and a half now (it was 2.95.2
then, but MIPS changes are the same) and the last fix I made was in April. 
No problems since then both for the kernel and the userland.  The C++
backend is unchecked, though.  An RPM package is available at
'ftp://ftp.ds2.pg.gda.pl/pub/macro/'; you may extract patches and build it
manually if you don't use RPM. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

AW: Cross Compiler again

[Andre.Messerschmidt]

> -G 0.
Thanks that helped for the relocation error.
init/main.o(.text.init+0x7d8): relocation truncated to fit: R_MIPS_GPREL16
execute_command

But I still get a lot of undefined references.
arch/mips/kernel/kernel.o(.debug+0x32e14): undefined reference to `L_E660'
arch/mips/kernel/kernel.o(.debug+0x60e7c): undefined reference to `L_E549'
arch/mips/kernel/kernel.o(.debug+0x8d097): undefined reference to `L_E8015'
arch/mips/kernel/kernel.o(.debug+0x8d0b9): undefined reference to `L_E8015'
arch/mips/kernel/kernel.o(.debug+0x8d168): undefined reference to `L_E8015'
arch/mips/kernel/kernel.o(.debug+0x8d18a): undefined reference to `L_E8015'
...

I believe there is still something wrong with my glibc, but I need to check
that.

> What compiler are you using?  All compilers I've ever released did default
> to -G 0.
I compiled my own gcc using Bradley D. LaRonde's howto.

regards
Andre

Re: Cross Compiler again

[Daniel Jacobowitz]

On Mon, Nov 26, 2001 at 05:27:38PM +0100, Andre.Messerschmidt@infineon.com wrote:
> 
> > -G 0.
> Thanks that helped for the relocation error.
> init/main.o(.text.init+0x7d8): relocation truncated to fit: R_MIPS_GPREL16
> execute_command
> 
> But I still get a lot of undefined references.
> arch/mips/kernel/kernel.o(.debug+0x32e14): undefined reference to `L_E660'
> arch/mips/kernel/kernel.o(.debug+0x60e7c): undefined reference to `L_E549'
> arch/mips/kernel/kernel.o(.debug+0x8d097): undefined reference to `L_E8015'
> arch/mips/kernel/kernel.o(.debug+0x8d0b9): undefined reference to `L_E8015'
> arch/mips/kernel/kernel.o(.debug+0x8d168): undefined reference to `L_E8015'
> arch/mips/kernel/kernel.o(.debug+0x8d18a): undefined reference to `L_E8015'
> ...
> 
> I believe there is still something wrong with my glibc, but I need to check
> that.

I don't know what compiler you're using, but it isn't working right :)
I suspect you're running afoul of the change in debugging format
between binutils 2.10 and 2.11.2.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

AW: Cross Compiler again

[Andre.Messerschmidt]

> Shit in, shit out.  You must be invoking the compiler with some option for
> GP relative optimization.  Won't work.
> 
A typical gcc call is like this:
gcc -Wall -Wstrict-prototypes -O2 -mno-abicalls -fno-pic -mcpu=r4000 -D_32_
-mips2 -Wa,--trap -pipe -c foo.c -o foo.o

Is there any option missing that might me defaulting to such an
optimization?
I have played with the different -O# options without success.

regards
Andre

Re: Cross Compiler again

[Ralf Baechle]

On Mon, Nov 26, 2001 at 02:38:39PM +0100, Andre.Messerschmidt@infineon.com wrote:

> > Shit in, shit out.  You must be invoking the compiler with some option for
> > GP relative optimization.  Won't work.
> > 
> A typical gcc call is like this:
> gcc -Wall -Wstrict-prototypes -O2 -mno-abicalls -fno-pic -mcpu=r4000 -D_32_
> -mips2 -Wa,--trap -pipe -c foo.c -o foo.o
> 
> Is there any option missing that might me defaulting to such an
> optimization?

-G 0.

> I have played with the different -O# options without success.

What compiler are you using?  All compilers I've ever released did default
to -G 0.

  Ralf

RE: Cross Compiler again

[Andre.Messerschmidt]

> If you simply fix the one declaration it complains about (it involves
> adding 'volatile' to one of the two declarations of xtime) then this
> kernel actually will work under GCC 3.0.1.  We haven't QA'd it, but I
> use it routinely for testing.
> 
Thanks. Compiling now works, but the linker complains about undefined
references:

init/main.o: In function `init':
init/main.c:794: relocation truncated to fit: R_MIPS_GPREL16 execute_command
init/main.o: In function `parse_options':
init/main.o(.text.init+0x7d8): relocation truncated to fit: R_MIPS_GPREL16
execute_command
arch/mips/kernel/kernel.o(.debug+0x32e14): undefined reference to `L_E660'
arch/mips/kernel/kernel.o(.debug+0x60e7c): undefined reference to `L_E549'
arch/mips/kernel/kernel.o(.debug+0x8d097): undefined reference to `L_E8015'
arch/mips/kernel/kernel.o(.debug+0x8d0b9): undefined reference to `L_E8015'
arch/mips/kernel/kernel.o(.debug+0x8d168): undefined reference to `L_E8015'
arch/mips/kernel/kernel.o(.debug+0x8d18a): undefined reference to `L_E8015'
arch/mips/kernel/kernel.o(.debug+0x8d31f): undefined reference to `L_E8867'
arch/mips/kernel/kernel.o(.debug+0x8d3b6): undefined reference to `L_E8015'
arch/mips/kernel/kernel.o(.debug+0x8d3d8): undefined reference to `L_E8015'
arch/mips/kernel/kernel.o(.debug+0x8d52d): undefined reference to `L_E8867'
arch/mips/kernel/kernel.o(.debug+0x8d5c4): undefined reference to `L_E8015'
arch/mips/kernel/kernel.o(.debug+0x8d5e6): undefined reference to `L_E8015'
arch/mips/kernel/kernel.o(.debug+0x8d6f2): undefined reference to `L_E8867'
arch/mips/kernel/kernel.o(.debug+0x8d718): undefined reference to `L_E8015'
arch/mips/kernel/kernel.o(.debug+0x8d762): undefined reference to `L_E8015'
arch/mips/kernel/kernel.o(.debug+0x172bec): undefined reference to `L_E8153'
arch/mips/kernel/kernel.o(.debug+0x19dea0): undefined reference to `L_E111'
arch/mips/kernel/kernel.o(.debug+0x19debe): undefined reference to `L_E1321'
arch/mips/kernel/kernel.o(.debug+0x1f64f2): undefined reference to `L_E7978'
arch/mips/kernel/kernel.o(.debug+0x1f662a): undefined reference to `L_E7978'

It goes on like this for 800 lines. Does anyone know why this happens?

regards
Andre

Re: Cross Compiler again

[Ralf Baechle]

On Mon, Nov 26, 2001 at 09:59:52AM +0100, Andre.Messerschmidt@infineon.com wrote:

> init/main.o: In function `init':
> init/main.c:794: relocation truncated to fit: R_MIPS_GPREL16 execute_command
                                                ^^^^^^^^^^^^^^

Shit in, shit out.  You must be invoking the compiler with some option for
GP relative optimization.  Won't work.

  Ralf

RE: Cross Compiler again

[Andre.Messerschmidt]

> May I ask why you want dwarf? FWIW, gcc 2.96 in my RedHat 7.1 mips port
> supports dwarf, but not as default. I don't know how well it works with
> dwarf. Yes, both cross compiler running on RedHat/x86 7.1/7.2 and
> native compiler are provided in my mips port.
> 
I need dwarf support because my debugger only supports dwarf. (It is an
integrated simulation environment, where I cannot change the debugger to
gdb).

Do you have a download link for your mips port?

regards
Andre

Re: Cross Compiler again

[H . J . Lu]

On Thu, Nov 22, 2001 at 01:42:32PM +0100, Andre.Messerschmidt@infineon.com wrote:
> 
> > May I ask why you want dwarf? FWIW, gcc 2.96 in my RedHat 7.1 mips port
> > supports dwarf, but not as default. I don't know how well it works with
> > dwarf. Yes, both cross compiler running on RedHat/x86 7.1/7.2 and
> > native compiler are provided in my mips port.
> > 
> I need dwarf support because my debugger only supports dwarf. (It is an
> integrated simulation environment, where I cannot change the debugger to
> gdb).
> 
> Do you have a download link for your mips port?
> 
> regards
> Andre

My mini-port of RedHat 7.1 is at

ftp://oss.sgi.com/pub/linux/mips/redhat/7.1/

you should be able to put a small RedHat 7.1 on the mips/mipsel box and
compile the rest of RedHat 7.1 yourselves.

Here are something you should know:

1. The cross compiler hosted on RedHat 7.1/ia32 is provided as a
toolchain rpm. The binary rpms for the mips and mipsel cross compilers
are included. You may need glibc 2.2.3-11 or above to use those
rpms. The glibc x86 binary rpms under RPMS/i386 should be ok.
2. You have to find a way to put those rpms on your machine. I use
network boot and NFS root to do it.
3. install.tar.bz2 has some scripts to prepare NFS root and install
RedHat 7.1 on a hard drive.
4. baseline.tar.bz2 contains the cross build tree.
5. Since everything is cross compiled from x86, which is little endian,
many data files for mips, which is big endian, are either missing or
wrong. To get those data files for mips, you have to rebuild/install
the folowing rpms:

cracklib
glibc

natively on Linux/mips.

Thanks.


H.J.

Cross Compiler again

[Andre.Messerschmidt]

Hi.

For my environment I need a compiler that supports dwarf debug information.
Sadly my precompiled version does not have this support so I tried it on my
own, using Bradley D. LaRonde's  HowTo. 
All went well but I had to learn that GCC 3.0.1 is not able to compile a
current kernel. So I tried version 2.95.3, but I ran into the same problem
that I had last time I tried such a thing. When compiling glibc the process
failed because of a missing -D__PIC__ option. I was told that this has to do
with a non-MIPS compiler that is used, but the compiler used is my previous
build static version of gcc. 
I don't know what else may be wrong or where to look. Can anybody enlighten
me?

Or has anybody a precompiled gcc with dwarf support for download (That is
able to compile a current kernel, of course. ;-) )?

Best regards
--
Andre Messerschmidt

Application Engineer
Infineon Technologies AG

Re: Cross Compiler again

[H . J . Lu]

On Thu, Nov 22, 2001 at 10:08:44AM +0100, Andre.Messerschmidt@infineon.com wrote:
> Hi.
> 
> For my environment I need a compiler that supports dwarf debug information.
> Sadly my precompiled version does not have this support so I tried it on my
> own, using Bradley D. LaRonde's  HowTo. 
> All went well but I had to learn that GCC 3.0.1 is not able to compile a
> current kernel. So I tried version 2.95.3, but I ran into the same problem
> that I had last time I tried such a thing. When compiling glibc the process
> failed because of a missing -D__PIC__ option. I was told that this has to do
> with a non-MIPS compiler that is used, but the compiler used is my previous
> build static version of gcc. 
> I don't know what else may be wrong or where to look. Can anybody enlighten
> me?
> 
> Or has anybody a precompiled gcc with dwarf support for download (That is
> able to compile a current kernel, of course. ;-) )?
> 

May I ask why you want dwarf? FWIW, gcc 2.96 in my RedHat 7.1 mips port
supports dwarf, but not as default. I don't know how well it works with
dwarf. Yes, both cross compiler running on RedHat/x86 7.1/7.2 and
native compiler are provided in my mips port.


H.J.

Re: Cross Compiler again

[Bradley D. LaRonde]

----- Original Message -----
From: <Andre.Messerschmidt@infineon.com>
To: <linux-mips@oss.sgi.com>
Sent: Thursday, November 22, 2001 4:08 AM
Subject: Cross Compiler again


> All went well but I had to learn that GCC 3.0.1 is not able to compile a
> current kernel.

I regularly use gcc 3.0.1 to build the latest oss cvs kernels without
obvious incident.

Regards,
Brad

Re: Cross Compiler again

[Bradley D. LaRonde]

----- Original Message -----
From: <Andre.Messerschmidt@infineon.com>
To: <linux-mips@oss.sgi.com>
Sent: Thursday, November 22, 2001 4:08 AM
Subject: Cross Compiler again


> All went well but I had to learn that GCC 3.0.1 is not able to compile a
> current kernel.

I regularly use gcc 3.0.1 to build the latest oss cvs kernels without
obvious incident.

Regards,
Brad