Tools issue

Tools issue

[Adrian.Hulse]

I am experiencing some strange behaviour dependent on the tools I use and I
was wondering if anyone on this list, has experienced similar problems or
may know the answer to my problem.

To date I have been using the following tools from the SGI site to
successfully compile and boot a 2.4.12 little endian mips kernel :

binutils-mipsel-linux-2.8.1-2.i386.rpm
egcs-mipsel-linux-1.1.2-4.i386.rpm

As an experiment I decided to try the "toolchain-20011020" tools also from
the SGI site to compile the exact same kernel, but the compile fails with
the following 2 errors :

ctfb.c:1158: warning: duplicate `const'
{standard input}:11123: Error: expression too complex
{standard input}:11123: Fatal Error: internal Error, line 1980,
../../tools-20011020/gas/config/tc-mips.c
make[3]: ***[ctfb.o] Error 2

int-handler.s:59: Error: missing ')'
int-handler.s:59: Error: illegal operands `lui'
int-handler.s:60: Error: missing ')'
int-handler.s:60: Error: illegal operands `sb'
make[1]: *** [ int-handler.o ] Error 1

I can get around the first error by just disabling CONFIG_FB_CT in the
config and recompiling. Note the monta vista toolchain also fails in the
same file, with I think the same error.
I can get around the second error by one of two methods :
a, just comment it out because all it's doing is lighting up an led
according to the interrupt received
b, by changing a parenthesised define to non-parenthesised form :

int-handler.S
<l59>     lui  t1, %hi(TSDB_LED_ADDR)
<l60>     sb   t0, %lo(TSDB_LDE_ADDR)(t1)

Failed define :
#define   TSDB_LED_ADDR  (KSEG1 + TSDB_LB_PCU_APERTURE + 0x05100020)

Compilable define :
#define   TSDB_LED_ADDR  KSEG1 + TSDB_LB_PCU_APERTURE + 0x05100020

So with the above 2 kludges I can get the kernel to compile, but now when I
come to boot it, the board it just locks failing somewhere in console_init
( currently investigating ).

Anyone else seen anything like this and know of a solution to the problem ?
Or to paraphrase Dominic Sweetman, maybe i should just stay with the "pick
your own version folklore" method of picking tools :).

Thx

Re: Tools issue

[Ralf Baechle]

On Thu, Feb 14, 2002 at 01:42:31PM -0800, Adrian.Hulse@taec.toshiba.com wrote:

> I am experiencing some strange behaviour dependent on the tools I use and I
> was wondering if anyone on this list, has experienced similar problems or
> may know the answer to my problem.
> 
> To date I have been using the following tools from the SGI site to
> successfully compile and boot a 2.4.12 little endian mips kernel :
> 
> binutils-mipsel-linux-2.8.1-2.i386.rpm
> egcs-mipsel-linux-1.1.2-4.i386.rpm
> 
> As an experiment I decided to try the "toolchain-20011020" tools also from
> the SGI site to compile the exact same kernel, but the compile fails with
> the following 2 errors :
> 
> ctfb.c:1158: warning: duplicate `const'
> {standard input}:11123: Error: expression too complex
> {standard input}:11123: Fatal Error: internal Error, line 1980,
> ../../tools-20011020/gas/config/tc-mips.c
> make[3]: ***[ctfb.o] Error 2

Can you post the compiler generated assembler that is causing this
error?

What kernel version is this?

> int-handler.s:59: Error: missing ')'
> int-handler.s:59: Error: illegal operands `lui'
> int-handler.s:60: Error: missing ')'
> int-handler.s:60: Error: illegal operands `sb'
> make[1]: *** [ int-handler.o ] Error 1
> 
> I can get around the first error by just disabling CONFIG_FB_CT in the
> config and recompiling. Note the monta vista toolchain also fails in the
> same file, with I think the same error.
> I can get around the second error by one of two methods :
> a, just comment it out because all it's doing is lighting up an led
> according to the interrupt received
> b, by changing a parenthesised define to non-parenthesised form :
> 
> int-handler.S
> <l59>     lui  t1, %hi(TSDB_LED_ADDR)
> <l60>     sb   t0, %lo(TSDB_LDE_ADDR)(t1)
> 
> Failed define :
> #define   TSDB_LED_ADDR  (KSEG1 + TSDB_LB_PCU_APERTURE + 0x05100020)
> 
> Compilable define :
> #define   TSDB_LED_ADDR  KSEG1 + TSDB_LB_PCU_APERTURE + 0x05100020
> 
> So with the above 2 kludges I can get the kernel to compile, but now when I
> come to boot it, the board it just locks failing somewhere in console_init
> ( currently investigating ).

Binutils 2.8.x are definately buggy; 2.9.5.x on oss are the oldest
version that's sortof working ...

> Anyone else seen anything like this and know of a solution to the problem ?
> Or to paraphrase Dominic Sweetman, maybe i should just stay with the "pick
> your own version folklore" method of picking tools :).

I hope that for binutils we can solve that problem when 2.9.12 gets
released; as for gcc it seems Maciej's 2.95.3 version is already pretty
close to what we want.  C++ users may disagree ;-)  Somewhat longer term
Algorithmics's toolchain should resolve the situation.

  Ralf

Re: Tools issue

[Johannes Stezenbach]

On Fri, Feb 15, 2002 at 03:49:58AM +0100, Ralf Baechle wrote:
> On Thu, Feb 14, 2002 at 01:42:31PM -0800, Adrian.Hulse@taec.toshiba.com wrote:
> 
> > int-handler.s:59: Error: missing ')'
> > int-handler.s:59: Error: illegal operands `lui'
> > int-handler.s:60: Error: missing ')'
> > int-handler.s:60: Error: illegal operands `sb'
> > make[1]: *** [ int-handler.o ] Error 1 
...
> > int-handler.S
> > <l59>     lui  t1, %hi(TSDB_LED_ADDR)
> > <l60>     sb   t0, %lo(TSDB_LDE_ADDR)(t1)
> > 
> > Failed define :
> > #define   TSDB_LED_ADDR  (KSEG1 + TSDB_LB_PCU_APERTURE + 0x05100020)
> > 
> > Compilable define :
> > #define   TSDB_LED_ADDR  KSEG1 + TSDB_LB_PCU_APERTURE + 0x05100020
...
> > Anyone else seen anything like this and know of a solution to the problem ?
> > Or to paraphrase Dominic Sweetman, maybe i should just stay with the "pick
> > your own version folklore" method of picking tools :).

I had a similar problem with binutils-2.11.92.0.12.3, but
Thiemo Seufer posted a patch on the binutils mailing list.
Should be fixed in binutils CVS.
It seems that it worked with the binutils-2.10.91.0.2 recommended
here: http://www.junsun.net/linux/porting-howto/

> I hope that for binutils we can solve that problem when 2.9.12 gets
> released; as for gcc it seems Maciej's 2.95.3 version is already pretty
> close to what we want.  C++ users may disagree ;-)  Somewhat longer term
> Algorithmics's toolchain should resolve the situation.

;-)

Regards,
Johannes