On Thu, 31 Jul 2008 17:16:03 +1000 Stephen Rothwell wrote:

> Hi Dave,
>
> linux-next builds (sparc32 defconfig) have been failing for some time
> like this:
>
> .tmp_kallsyms2.o(.rodata+0x0): In function `kallsyms_addresses':
> : relocation truncated to fit: R_SPARC_32 _text
> .tmp_kallsyms2.o(.rodata+0x4): In function `kallsyms_addresses':
> : relocation truncated to fit: R_SPARC_32 _text
> .tmp_kallsyms2.o(.rodata+0x8): In function `kallsyms_addresses':
> : relocation truncated to fit: R_SPARC_32 _text
>
> (several more)
>
> I finally bisected it down to this commit:
>
> commit f9247273cb69ba101877e946d2d83044409cc8c5
> Author: Steven Whitehouse
> Date: Thu Jul 24 17:22:13 2008 +0100
>
> UFS: add const to parser token table
>
> Reverting this commit and the followup commit:
>
> commit fb2e405fc1fc8b20d9c78eaa1c7fd5a297efde43
> Author: Adrian Bunk
> Date: Fri Jul 25 02:55:49 2008 +0300
>
> fix fs/nfs/nfsroot.c compilation
>
> allows the sparc32 build to succeed. This is toolchain specific as a
> different cross toolchain I have does not get this error.
>
> Failing toolchain:
>
> $ gcc-3.4.5-glibc-2.3.6/sparc64-unknown-linux-gnu/bin/sparc64-unknown-linux-gnu-gcc --version
> sparc64-unknown-linux-gnu-gcc (GCC) 3.4.5
> $ gcc-3.4.5-glibc-2.3.6/sparc64-unknown-linux-gnu/bin/sparc64-unknown-linux-gnu-ld --version
> GNU ld version 2.15
>
> An OK toolchain:
> $ cross/bin/sparc64-linux-gcc --version
> sparc64-linux-gcc (GCC) 4.2.4
> $ cross/bin/sparc64-linux-ld --version
> GNU ld (GNU Binutils) 2.18
>
> Both these commits are actually in Linus' tree, now.

gee. nfsroot.c is now effectively doing `const __initconst' which
might be upsetting the compiler. And perhaps one of the forty-odd
other users of match_table_t needs __initconst or somesuch.

Yes, I'd second a revert-and-try-again-later on that one.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Hi,

On Thu, 2008-07-31 at 00:35 -0700, Andrew Morton wrote:
> On Thu, 31 Jul 2008 17:16:03 +1000 Stephen Rothwell wrote:
>
> > Hi Dave,
> >
> > linux-next builds (sparc32 defconfig) have been failing for some time
> > like this:
> >
> > .tmp_kallsyms2.o(.rodata+0x0): In function `kallsyms_addresses':
> > : relocation truncated to fit: R_SPARC_32 _text
> > .tmp_kallsyms2.o(.rodata+0x4): In function `kallsyms_addresses':
> > : relocation truncated to fit: R_SPARC_32 _text
> > .tmp_kallsyms2.o(.rodata+0x8): In function `kallsyms_addresses':
> > : relocation truncated to fit: R_SPARC_32 _text
> >
> > (several more)
> >
> > I finally bisected it down to this commit:
> >
> > commit f9247273cb69ba101877e946d2d83044409cc8c5
> > Author: Steven Whitehouse
> > Date: Thu Jul 24 17:22:13 2008 +0100
> >
> > UFS: add const to parser token table
> >
> > Reverting this commit and the followup commit:
> >
> > commit fb2e405fc1fc8b20d9c78eaa1c7fd5a297efde43
> > Author: Adrian Bunk
> > Date: Fri Jul 25 02:55:49 2008 +0300
> >
> > fix fs/nfs/nfsroot.c compilation
> >
> > allows the sparc32 build to succeed. This is toolchain specific as a
> > different cross toolchain I have does not get this error.
> >
> > Failing toolchain:
> >
> > $ gcc-3.4.5-glibc-2.3.6/sparc64-unknown-linux-gnu/bin/sparc64-unknown-linux-gnu-gcc --version
> > sparc64-unknown-linux-gnu-gcc (GCC) 3.4.5
> > $ gcc-3.4.5-glibc-2.3.6/sparc64-unknown-linux-gnu/bin/sparc64-unknown-linux-gnu-ld --version
> > GNU ld version 2.15
> >
> > An OK toolchain:
> > $ cross/bin/sparc64-linux-gcc --version
> > sparc64-linux-gcc (GCC) 4.2.4
> > $ cross/bin/sparc64-linux-ld --version
> > GNU ld (GNU Binutils) 2.18
> >
> > Both these commits are actually in Linus' tree, now.
>
> gee. nfsroot.c is now effectively doing `const __initconst' which
> might be upsetting the compiler. And perhaps one of the forty-odd
> other users of match_table_t needs __initconst or somesuch.
>
According to my find & grep there is only the one place which has marked
out the match_table_t for a different section.

> Yes, I'd second a revert-and-try-again-later on that one.
It looks like there is no simple solution, so I guess we'll have to do
that The only other alternative would be to remove the __initconst
which isn't ideal either,

Steve.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Linus,

Please consider reverting the two commits:

> > commit f9247273cb69ba101877e946d2d83044409cc8c5
> > Author: Steven Whitehouse
> > Date: Thu Jul 24 17:22:13 2008 +0100
> >
> > UFS: add const to parser token table
> >

> >
> > commit fb2e405fc1fc8b20d9c78eaa1c7fd5a297efde43
> > Author: Adrian Bunk
> > Date: Fri Jul 25 02:55:49 2008 +0300
> >
> > fix fs/nfs/nfsroot.c compilation

It appears that they cause a compile problem (as per below explanation)
on sparc, even though they appear to be ok on other architectures. I'll
redo the patch to avoid the problem and resubmit but it seems best just
to revert in the mean time. Sorry to be a pain,

Steve.

On Thu, 2008-07-31 at 00:35 -0700, Andrew Morton wrote:
> On Thu, 31 Jul 2008 17:16:03 +1000 Stephen Rothwell wrote:
>
> > Hi Dave,
> >
> > linux-next builds (sparc32 defconfig) have been failing for some time
> > like this:
> >
> > .tmp_kallsyms2.o(.rodata+0x0): In function `kallsyms_addresses':
> > : relocation truncated to fit: R_SPARC_32 _text
> > .tmp_kallsyms2.o(.rodata+0x4): In function `kallsyms_addresses':
> > : relocation truncated to fit: R_SPARC_32 _text
> > .tmp_kallsyms2.o(.rodata+0x8): In function `kallsyms_addresses':
> > : relocation truncated to fit: R_SPARC_32 _text
> >
> > (several more)
> >
> > I finally bisected it down to this commit:
> >
> > commit f9247273cb69ba101877e946d2d83044409cc8c5
> > Author: Steven Whitehouse
> > Date: Thu Jul 24 17:22:13 2008 +0100
> >
> > UFS: add const to parser token table
> >
> > Reverting this commit and the followup commit:
> >
> > commit fb2e405fc1fc8b20d9c78eaa1c7fd5a297efde43
> > Author: Adrian Bunk
> > Date: Fri Jul 25 02:55:49 2008 +0300
> >
> > fix fs/nfs/nfsroot.c compilation
> >
> > allows the sparc32 build to succeed. This is toolchain specific as a
> > different cross toolchain I have does not get this error.
> >
> > Failing toolchain:
> >
> > $ gcc-3.4.5-glibc-2.3.6/sparc64-unknown-linux-gnu/bin/sparc64-unknown-linux-gnu-gcc --version
> > sparc64-unknown-linux-gnu-gcc (GCC) 3.4.5
> > $ gcc-3.4.5-glibc-2.3.6/sparc64-unknown-linux-gnu/bin/sparc64-unknown-linux-gnu-ld --version
> > GNU ld version 2.15
> >
> > An OK toolchain:
> > $ cross/bin/sparc64-linux-gcc --version
> > sparc64-linux-gcc (GCC) 4.2.4
> > $ cross/bin/sparc64-linux-ld --version
> > GNU ld (GNU Binutils) 2.18
> >
> > Both these commits are actually in Linus' tree, now.
>
> gee. nfsroot.c is now effectively doing `const __initconst' which
> might be upsetting the compiler. And perhaps one of the forty-odd
> other users of match_table_t needs __initconst or somesuch.
>
> Yes, I'd second a revert-and-try-again-later on that one.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/