Subject: Compile error with current CVS kernel

From: Adrian Bunk <[email-masked]>
Date: Mon, 12 Mar 2001 22:56:40 +0100 (CET)

Hi,

I checked out the kernel source from oss.sgi.com at about two hours ago,
but the build for my DECstation 5000/240 failed with:

mipsel-linux-gcc -I /home/bunk/Ringo/linux/include/asm/gcc -D__KERNEL__ -I/home/bunk/Ringo/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -G 0 -mno-abicalls -fno-pic -mcpu=r3000 -mips1 -pipe  -c strnlen_user.S -o strnlen_user.o
mipsel-linux-gcc -I /home/bunk/Ringo/linux/include/asm/gcc -D__KERNEL__ -I/home/bunk/Ringo/linux/include -Wall -Wstrict-prototypes -O2 -fomit-frame-pointer -fno-strict-aliasing -G 0 -mno-abicalls -fno-pic -mcpu=r3000 -mips1 -pipe    -c -o r3k_dump_tlb.o r3k_dump_tlb.c
rm -f lib.a
mipsel-linux-ar  rcs lib.a csum_partial.o csum_partial_copy.o rtc-std.o rtc-no.o memcpy.o memset.o watch.o strlen_user.o strncpy_user.o strnlen_user.o r3k_dump_tlb.o
make[2]: Leaving directory `/home/bunk/Ringo/linux/arch/mips/lib'
make[1]: Leaving directory `/home/bunk/Ringo/linux/arch/mips/lib'
sed -e 's/@@OUTPUT_FORMAT@@/elf32-littlemips/' \
    -e 's/@@LOADADDR@@/0x80040000/' <arch/mips/ld.script.in >arch/mips/ld.script
mipsel-linux-ld -static -G 0 -T arch/mips/ld.script arch/mips/kernel/head.o arch/mips/kernel/init_task.o init/main.o init/version.o \
        --start-group \
        arch/mips/kernel/kernel.o arch/mips/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o arch/mips/math-emu/fpu_emulator.o arch/mips/dec/dec.o \
        drivers/block/block.o drivers/char/char.o drivers/misc/misc.o drivers/net/net.o drivers/media/media.o  drivers/scsi/scsidrv.o drivers/video/video.o drivers/tc/tc.a \
        net/network.o \
        arch/mips/lib/lib.a /home/bunk/Ringo/linux/lib/lib.a arch/mips/dec/prom/rexlib.a \
        --end-group \
        -o vmlinux
mipsel-linux-nm vmlinux | grep -v '\(compiled\)\|\(\.o$\)\|\( [aUw] \)\|\(\.\.ng$\)\|\(LASH[RL]DI\)' | sort > System.map
make[1]: Entering directory `/home/bunk/Ringo/linux/arch/mips/boot'
gcc -o elf2ecoff elf2ecoff.c
./elf2ecoff /home/bunk/Ringo/linux/vmlinux vmlinux.ecoff -a
wrote 20 byte file header.
wrote 56 byte a.out header.
wrote 240 bytes of section headers.
wrote 4 byte pad.
writing 1848 bytes...
Intersegment gap (-2147239736 bytes) too large.
make[1]: *** [vmlinux.ecoff] Error 1
make[1]: Leaving directory `/home/bunk/Ringo/linux/arch/mips/boot'
make: *** [boot] Error 2

I'm using for cross-compiling from i386:

$ mipsel-linux-ld -v
GNU ld version 2.10.91 (with BFD 2.10.91.0.2)
$ mipsel-linux-gcc -v
Reading specs from /usr/lib/gcc-lib/mipsel-linux/egcs-2.91.66/specs
gcc version egcs-2.91.66 19990314 (egcs-1.1.2 release)
$ gcc -v
Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.3/specs
gcc version 2.95.3 20010219 (prerelease)
$

cu
Adrian

-- 

Nicht weil die Dinge schwierig sind wagen wir sie nicht,
sondern weil wir sie nicht wagen sind sie schwierig.

---

From: Ralf Baechle <[email-masked]>
Date: Tue, 13 Mar 2001 00:15:20 +0100

On Mon, Mar 12, 2001 at 10:56:40PM +0100, Adrian Bunk wrote:

Send me the output of ``mipsel-linux-objdump -p -h vmlinux''.

  Ralf

---

From: "Houten K.H.C. van (Karel)" <[email-masked]>
Date: Tue, 13 Mar 2001 08:46:43 +0100

Hi Rald, Adrian,

Ralf wrote:
>> [about failing cross-compile ...]
>

I get the same error on a native compile:
gcc version 2.95.3 19991030 (Maciej's src)
binutils version 2.11.90 (from CVS)
kernel source 2.4.0-test9 (from oss CVS)

I've attached my objdump output.
Hope this helps.

Regards,
Karel.

vmlinux:     file format elf32-bigmips

Program Header:
0x70000000 off    0x00000000001a11e0 vaddr 0xffffffff881981e0 paddr 
0xffffffff881981e0 align 2**2
         filesz 0x0000000000000018 memsz 0x0000000000000018 flags r--
    LOAD off    0x0000000000000000 vaddr 0x0000000000001000 paddr 
0x0000000000001000 align 2**12
         filesz 0x000000000000a184 memsz 0x000000000000a184 flags r--
    LOAD off    0x000000000000b000 vaddr 0xffffffff88002000 paddr 
0xffffffff88002000 align 2**12
         filesz 0x00000000001acd10 memsz 0x00000000001d25a4 flags rwx
private flags = 101: [no abi set] [mips1] [32bitmode]

Sections:
Idx Name          Size      VMA               LMA               File off  Algn
  0 .text         00180020  ffffffff88002000  ffffffff88002000  0000b000  2**13
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .fixup        000011e8  ffffffff88182020  ffffffff88182020  0018b020  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 __ex_table    00001fa8  ffffffff88183210  ffffffff88183210  0018c210  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  3 __dbe_table   00000000  ffffffff881851b8  ffffffff881851b8  0018e1b8  2**0
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .text.init    0000e124  ffffffff88186000  ffffffff88186000  0018f000  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  5 .data.init    0000382c  ffffffff88194124  ffffffff88194124  0019d124  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  6 .setup.init   000000d8  ffffffff88197950  ffffffff88197950  001a0950  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  7 .initcall.init 00000068  ffffffff88197a28  ffffffff88197a28  001a0a28  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  8 .data.cacheline_aligned 000001e0  ffffffff88198000  ffffffff88198000  
001a1000  2**5
                  CONTENTS, ALLOC, LOAD, DATA
  9 .reginfo      00000018  ffffffff881981e0  ffffffff881981e0  001a11e0  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA, LINK_ONCE_SAME_SIZE
 10 .data         00016b10  ffffffff88198200  ffffffff88198200  001a1200  2**4
                  CONTENTS, ALLOC, LOAD, DATA
 11 .sbss         000002c4  ffffffff881aed10  ffffffff881aed10  001b7d10  2**3
                  ALLOC
 12 .bss          000255c4  ffffffff881aefe0  ffffffff881aefe0  001b7d1c  2**4
                  ALLOC
 13 .mdebug       000a6b78  0000000000000000  0000000000000000  001b7d1c  2**2
                  CONTENTS, READONLY, DEBUGGING
 14 .note         00001af4  0000000000000000  0000000000000000  0025e894  2**0
                  CONTENTS, READONLY
 15 .kstrtab      00007c24  0000000000001b00  0000000000001b00  00000b00  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
 16 __ksymtab     00001a60  0000000000009724  0000000000009724  00008724  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
Karel van Houten

----------------------------------------------------------
The box said "Requires Windows 95 or better."
I can't understand why it won't work on my Linux computer. 
----------------------------------------------------------

---

From: Ralf Baechle <[email-masked]>
Date: Tue, 13 Mar 2001 14:53:30 +0100

> I've attached my objdump output.

Not necessary, Adrian already sent his output.  The fix isn't difficult
either, it's just putting .modinfo into the linker script also.  The
question is still why newer ld is placing sections be default so absurdly
which is what I'm currently enquiring.

  Ralf

---

From: Ralf Baechle <[email-masked]>
Date: Tue, 13 Mar 2001 15:22:36 +0100

> Hope this helps.

Against my low blood pressure - yes ...

>          filesz 0x000000000000a184 memsz 0x000000000000a184 flags r--

This PT_LOAD entry shouldn't even exist ...

>                   CONTENTS, ALLOC, LOAD, READONLY, DATA

That's scary - these sections are explicitly mentioned in the linker
script and yet ld places them near address zero.  Oh pleassure, oh
garbage.

This can probably be fixed by changing the ldscript; can experiment what
it takes to get your ld to place all sections with a LOAD attribute placed
next to each other?  My ld behaves fine.

  Ralf

---

From: Karel van Houten <[email-masked]>
Date: Tue, 13 Mar 2001 19:18:05 +0100 (MET)

Hi Ralf,

> next to each other?  My ld behaves fine.

Can you point me to a binutils version and/or patches that should
behave OK for native compiles?

-- 
Karel van Houten

---

From: Karel van Houten <[email-masked]>
Date: Tue, 13 Mar 2001 19:38:59 +0100 (MET)

Hi,

Ralf wrote:
> Karel wrote:
> It's not native vs. crosscompile; this problem with binutils hits in both
> cases and only older versions (which aren't suitable for use with
> glibc 2.2 ...) are not affected.

I've just finished compiling gcc 3.0, from CVS, and am now trying
to rebuild the kernel with this compiler (same binutils, from cvs).
Keith mentioned he did succeed in building a kernel with these...

-- 
Karel van Houten

---

From: Karel van Houten <[email-masked]>
Date: Tue, 13 Mar 2001 19:40:37 +0100 (MET)

While I wrote my previous mail:

{standard input}: Assembler messages:
{standard input}:1993: Error: expression too complex
{standard input}:1993: Fatal error: internal Error, line 1823, ./config/tc-mips.c
make[3]: *** [vgacon.o] Error 1

Again.... :-(

-- 
Karel van Houten

---

From: Pete Popov <[email-masked]>
Date: Tue, 13 Mar 2001 13:15:19 -0800

> make[3]: *** [vgacon.o] Error 1

We encountered this exact problem a few days ago. One of our engineers
tracked it down to the combination of complex macros and inline
functions in arch/mips/io.h.  He pinpointed precisely the problem to a
rare gcc "bug", which is not likely to get fixed anytime soon. I believe
a patch was already submitted to Ralf, but it will have to get tested.

Pete

---

From: Ralf Baechle <[email-masked]>
Date: Tue, 13 Mar 2001 19:27:11 +0100

Ralf

---

From: Adrian Bunk <[email-masked]>
Date: Wed, 21 Mar 2001 18:39:48 +0100 (CET)

Hi Ralf,

the latest CVS kernel still doesn't build, but the error message has
changed:

<--  snip  -->

...
mipsel-linux-nm vmlinux | grep -v '\(compiled\)\|\(\.o$\)\|\( [aUw]
\)\|\(\.\.ng$\)\|\(LASH[RL]DI\)' | sort > System.map
make[1]: Entering directory `/home/bunk/Ringo/linux/arch/mips/boot'
gcc -o elf2ecoff elf2ecoff.c
./elf2ecoff /home/bunk/Ringo/linux/vmlinux vmlinux.ecoff -a
Sections ordering prevents a.out conversion.
make[1]: *** [vmlinux.ecoff] Error 1
make[1]: Leaving directory `/home/bunk/Ringo/linux/arch/mips/boot'
make: *** [boot] Error 2

<--  snip  -->

cu
Adrian

--