linux-next: powerpc build failure

linux-next: powerpc build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 544 bytes --]

Hi all,

Today's linux-next build (powerpc allyesconfig) failed like this:

vmlinux.o: In function `ipx_ioctl':
/scratch/sfr/next/net/ipx/af_ipx.c:1830: relocation truncated to fit: R_PPC64_REL24 against symbol `._mcount' defined in .text section in vmlinux.o

(and lots more similar)

I am assuming that this has something to do with how big vmlinux is for
allyesconfig and the addition of -pg to KBUILD_CFLAGS for ftrace.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: powerpc build failure

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> Today's linux-next build (powerpc allyesconfig) failed like this:
> 
> vmlinux.o: In function `ipx_ioctl':
> /scratch/sfr/next/net/ipx/af_ipx.c:1830: relocation truncated to fit: R_PPC64_REL24 against symbol `._mcount' defined in .text section in vmlinux.o
> 
> (and lots more similar)
> 
> I am assuming that this has something to do with how big vmlinux is 
> for allyesconfig and the addition of -pg to KBUILD_CFLAGS for ftrace.

could this be a tool chain limitation perhaps, or a gcc bug? Or does the 
allyesconfig size go beyond some fundamental hardware limitation. (i 
doubt it's the latter)

	Ingo

Re: linux-next: powerpc build failure

[Paul Mackerras]

Ingo Molnar writes:

> could this be a tool chain limitation perhaps, or a gcc bug? Or does the 
> allyesconfig size go beyond some fundamental hardware limitation. (i 
> doubt it's the latter)

Direct unconditional branches, including procedure calls, can only
reach +/- 32MB from the address of the branch on powerpc.  So if the
image grows to more than 32MB of text there is a problem unless the
linker is smart enough to insert trampolines.  I don't know whether
GNU ld is that smart.  I'm cc'ing Alan Modra who would know the answer
to that.

Paul.

Re: linux-next: powerpc build failure

[Alan Modra]

On Thu, Jun 12, 2008 at 11:38:19AM +1000, Paul Mackerras wrote:
> Direct unconditional branches, including procedure calls, can only
> reach +/- 32MB from the address of the branch on powerpc.  So if the
> image grows to more than 32MB of text there is a problem unless the
> linker is smart enough to insert trampolines.  I don't know whether
> GNU ld is that smart.

It is, but you need to pass --relax to enable generation of the
trampolines.

-- 
Alan Modra
Australia Development Lab, IBM

Re: linux-next: powerpc build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 931 bytes --]

On Thu, 12 Jun 2008 15:03:35 +0930 Alan Modra <amodra@bigpond.net.au> wrote:
>
> On Thu, Jun 12, 2008 at 11:38:19AM +1000, Paul Mackerras wrote:
> > Direct unconditional branches, including procedure calls, can only
> > reach +/- 32MB from the address of the branch on powerpc.  So if the
> > image grows to more than 32MB of text there is a problem unless the
> > linker is smart enough to insert trampolines.  I don't know whether
> > GNU ld is that smart.
> 
> It is, but you need to pass --relax to enable generation of the
> trampolines.

So I tried this (added --relax to LDFLAGS_vmlinux if CONFIG FTRACE was
set) and got this;

/usr/bin/ld: --relax and -r may not be used together

So, I will disable FTRACE on powerpc for now by removing HAVE_FTRACE from
being selected in arch/powerpc/Kconfig.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: powerpc build failure

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> > It is, but you need to pass --relax to enable generation of the 
> > trampolines.
> 
> So I tried this (added --relax to LDFLAGS_vmlinux if CONFIG FTRACE was 
> set) and got this;
> 
> /usr/bin/ld: --relax and -r may not be used together
> 
> So, I will disable FTRACE on powerpc for now by removing HAVE_FTRACE 
> from being selected in arch/powerpc/Kconfig.

ugh, please do that hack only privately in your allyesconfig testing and 
do not commit that change to linux-next!

It's not an ftrace bug, this problem is a limitation/bug of the powerpc 
architecture and it appears to me that any kernel feature that brings 
the allyesconfig text size above 32MB on powerpc will trigger this build 
failure.

A few months ago arch/x86 triggered an allyesconfig text size limitation 
at 40MB image size (on 64-bit) and we fixed it instead of disabling the 
feature/driver that happened to bring the image size above 40MB. See 
these commits:

 -------->
 commit 88f3aec7afd9ae3e6f6d221801996b69aad1e3a4
 Author: Ingo Molnar <mingo@elte.hu>
 Date:   Thu Feb 21 11:04:11 2008 +0100

    x86: fix spontaneous reboot with allyesconfig bzImage

 commit 85eb69a16aab5a394ce043c2131319eae35e6493
 Author: Ingo Molnar <mingo@elte.hu>
 Date:   Thu Feb 21 12:50:51 2008 +0100

    x86: increase the kernel text limit to 512 MB
 <--------

	Ingo

Re: linux-next: powerpc build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 426 bytes --]

Hi Ingo,

On Thu, 12 Jun 2008 09:16:12 +0200 Ingo Molnar <mingo@elte.hu> wrote:
>
> ugh, please do that hack only privately in your allyesconfig testing and 
> do not commit that change to linux-next!

See my other email, I have removed the ftrace disabling patch and
reverted one of Sam Ravnborg's instead.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: powerpc build failure

[Ingo Molnar]

* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> On Thu, 12 Jun 2008 09:16:12 +0200 Ingo Molnar <mingo@elte.hu> wrote:
> >
> > ugh, please do that hack only privately in your allyesconfig testing 
> > and do not commit that change to linux-next!
> 
> See my other email, I have removed the ftrace disabling patch and 
> reverted one of Sam Ravnborg's instead.

thanks.

	Ingo

Re: linux-next: powerpc build failure

[Benjamin Herrenschmidt]

On Thu, 2008-06-12 at 17:05 +1000, Stephen Rothwell wrote:
> So I tried this (added --relax to LDFLAGS_vmlinux if CONFIG FTRACE was
> set) and got this;
> 
> /usr/bin/ld: --relax and -r may not be used together
> 
> So, I will disable FTRACE on powerpc for now by removing HAVE_FTRACE
> from
> being selected in arch/powerpc/Kconfig.

So we completely lose ftrace for the sake of a config that nobody
sane ever uses (allyesconfig) ? :-)

Cheers,
Ben.

Re: linux-next: powerpc build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 911 bytes --]

On Thu, 12 Jun 2008 17:05:05 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> So, I will disable FTRACE on powerpc for now by removing HAVE_FTRACE from
> being selected in arch/powerpc/Kconfig.

That got rid of the initial errors, but now it fails for relocations
on .memcmp and some others.

Next guess:  I have reverted commit
a7815807f749669d3e06529b2d448390f2ef0f9d ("kbuild: simplify vmlinux link
stage") and powerpc allmodconfig builds again.  (even with FTRACE reenabled)

[For those that came in late (Sam):  a powerpc allyesconfig build was
getting errors like this:

net/ipx/af_ipx.c:1830: relocation truncated to fit: R_PPC64_REL24 against symbol `._mcount' defined in .text section in vmlinux.o

which I surmised was caused by ftrace adding -pg to KBUILD_CFLAGS.]

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: powerpc build failure

[Sam Ravnborg]

On Thu, Jun 12, 2008 at 05:24:03PM +1000, Stephen Rothwell wrote:
> On Thu, 12 Jun 2008 17:05:05 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > So, I will disable FTRACE on powerpc for now by removing HAVE_FTRACE from
> > being selected in arch/powerpc/Kconfig.
> 
> That got rid of the initial errors, but now it fails for relocations
> on .memcmp and some others.
> 
> Next guess:  I have reverted commit
> a7815807f749669d3e06529b2d448390f2ef0f9d ("kbuild: simplify vmlinux link
> stage") and powerpc allmodconfig builds again.  (even with FTRACE reenabled)
> 
> [For those that came in late (Sam):  a powerpc allyesconfig build was
> getting errors like this:
> 
> net/ipx/af_ipx.c:1830: relocation truncated to fit: R_PPC64_REL24 against symbol `._mcount' defined in .text section in vmlinux.o
> 
> which I surmised was caused by ftrace adding -pg to KBUILD_CFLAGS.]

I do not get if this was fixed by the revert of the kbuild patch or
this was a ftrace bug?

I have the following pending (awaiting testing feedback from Jeff Dike).

	Sam

diff --git a/arch/um/Makefile b/arch/um/Makefile
index 06cbc09..4eb0b07 100644
--- a/arch/um/Makefile
+++ b/arch/um/Makefile
@@ -104,7 +104,7 @@ archprepare: $(ARCH_SYMLINKS) $(ARCH_DIR)/include/user_constants.h
 prepare: $(ARCH_DIR)/include/kern_constants.h
 
 LINK-$(CONFIG_LD_SCRIPT_STATIC) += -static
-LINK-$(CONFIG_LD_SCRIPT_DYN) += -rpath /lib -rpath /usr/lib
+LINK-$(CONFIG_LD_SCRIPT_DYN) += -L/lib -L/usr/lib
 
 CFLAGS_NO_HARDENING := $(call cc-option, -fno-PIC,) $(call cc-option, -fno-pic,) \
 	$(call cc-option, -fno-stack-protector,) \
@@ -118,7 +118,13 @@ CPPFLAGS_vmlinux.lds = -U$(SUBARCH) -DSTART=$(START) -DELF_ARCH=$(ELF_ARCH) \
 
 # The wrappers will select whether using "malloc" or the kernel allocator.
 LDFLAGS_vmlinux := $(LINK-y) --wrap malloc --wrap free --wrap calloc
-KBUILD_VMLINUX_EXTRA := -lutil
+KBUILD_VMLINUX_EXTRA := \
+$(shell $(CC) -print-file-name=crt1.o)        \
+$(shell $(CC) -print-file-name=crti.o)        \
+$(shell $(CC) -print-file-name=libgcc_s.so)   \
+$(shell $(CC) -print-file-name=ld-linux.so.2) \
+$(shell $(CC) -print-file-name=libutil.so)    \
+$(shell $(CC) -print-file-name=libc.so)
 
 # When cleaning we don't include .config, so we don't include
 # TT or skas makefiles and don't clean skas_ptregs.h.
diff --git a/scripts/link-vmlinux.sh b/scripts/link-vmlinux.sh
index b9ecff5..e8fc6ab 100644
--- a/scripts/link-vmlinux.sh
+++ b/scripts/link-vmlinux.sh
@@ -95,8 +95,7 @@ mksysmap()
 tell LD vmlinux.o
 ${LD} ${LDFLAGS} ${LDFLAGS_vmlinux} -r -o vmlinux.o      \
 	${KBUILD_VMLINUX_INIT}                           \
-        --start-group ${KBUILD_VMLINUX_MAIN} --end-group \
-	${KBUILD_VMLINUX_EXTRA}
+        --start-group ${KBUILD_VMLINUX_MAIN} --end-group
 
 # modpost vmlinux.o
 ${MAKE} -f ${srctree}/scripts/Makefile.modpost vmlinux.o
@@ -121,19 +120,19 @@ fi
 
 # First stage of fully linked vmlinux
 tell LD ${VMLINUX}
-${LD} ${LDFLAGS} ${LDFLAGS_vmlinux} -o ${VMLINUX} \
-      -T ${KBUILD_VMLINUX_LDS} vmlinux.o
+${LD} ${LDFLAGS} ${LDFLAGS_vmlinux} ${KBUILD_VMLINUX_EXTRA} \
+        -o ${VMLINUX} -T ${KBUILD_VMLINUX_LDS} vmlinux.o
 
 if [ "${CONFIG_KALLSYMS}" = "y" ]; then
 
 	# Do an extra pass to link in kallsyms data
 	${NM} -n .tmp_vmlinux | scripts/kallsyms > .tmp_kallsyms.S
-        ${CC} ${KBUILD_AFLAGS} ${KBUILD_CPPFLAGS} -c -o .tmp_kallsyms.o \
-	      .tmp_kallsyms.S
+        ${CC} ${KBUILD_AFLAGS} ${AFLAGS_KERNEL} ${KBUILD_CPPFLAGS} -c \
+	      -o .tmp_kallsyms.o .tmp_kallsyms.S
         # link in kalll symbols
 	tell LD vmlinux
-        ${LD} ${LDFLAGS} ${LDFLAGS_vmlinux} -o vmlinux \
-         -T ${KBUILD_VMLINUX_LDS} vmlinux.o .tmp_kallsyms.o
+        ${LD} ${LDFLAGS} ${LDFLAGS_vmlinux} ${KBUILD_VMLINUX_EXTRA} \
+	      -o vmlinux -T ${KBUILD_VMLINUX_LDS} vmlinux.o .tmp_kallsyms.o
 fi
 
 tell SYSMAP System.map

Re: linux-next: powerpc build failure

[Alan Modra]

On Thu, Jun 12, 2008 at 05:05:05PM +1000, Stephen Rothwell wrote:
> /usr/bin/ld: --relax and -r may not be used together

Can't you arrange so that --relax is only used on the final link?  Of
course, if you have mashed all the input .text sections together with
"ld -r", resulting in one monster .text then --relax quite likely
won't help.  ld can't break apart an input section to insert
trampolines in the middle.

-- 
Alan Modra
Australia Development Lab, IBM

linux-next: powerpc build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2475 bytes --]

Hi Paul,

Today's linux-next build (powerpc allyesconfig) failed like this:

drivers/built-in.o: In function `get_dma_ops':
arch/powerpc/include/asm/dma-mapping.h:97: relocation truncated to fit: R_PPC64_REL24 against symbol `.ftrace_likely_update' defined in .text section in kernel/built-in.o
drivers/built-in.o: In function `init_shadow_tids':
drivers/infiniband/hw/ipath/ipath_init_chip.c:457: relocation truncated to fit: R_PPC64_REL24 against symbol `.vfree' defined in .text section in mm/built-in.o
drivers/built-in.o: In function `bringup_link':
drivers/infiniband/hw/ipath/ipath_init_chip.c:186: relocation truncated to fit: R_PPC64_REL24 against symbol `.ftrace_likely_update' defined in .text section in kernel/built-in.o
drivers/built-in.o: In function `eeh_readq':
arch/powerpc/include/asm/eeh.h:145: relocation truncated to fit: R_PPC64_REL24 against symbol `.eeh_check_failure' defined in .text section in arch/powerpc/platforms/built-in.o
arch/powerpc/include/asm/eeh.h:145: relocation truncated to fit: R_PPC64_REL24 against symbol `.eeh_check_failure' defined in .text section in arch/powerpc/platforms/built-in.o
drivers/built-in.o: In function `create_port0_egr':
drivers/infiniband/hw/ipath/ipath_init_chip.c:92: relocation truncated to fit: R_PPC64_REL24 against symbol `.vmalloc' defined in .text section in mm/built-in.o
drivers/infiniband/hw/ipath/ipath_init_chip.c:114: relocation truncated to fit: R_PPC64_REL24 against symbol `.vfree' defined in .text section in mm/built-in.o
drivers/built-in.o: In function `enable_chip':
drivers/infiniband/hw/ipath/ipath_init_chip.c:477: relocation truncated to fit: R_PPC64_REL24 against symbol `.init_waitqueue_head' defined in .text section in kernel/built-in.o
drivers/built-in.o: In function `eeh_readq':
arch/powerpc/include/asm/eeh.h:145: relocation truncated to fit: R_PPC64_REL24 against symbol `.eeh_check_failure' defined in .text section in arch/powerpc/platforms/built-in.o
drivers/built-in.o: In function `eeh_readl':
arch/powerpc/include/asm/eeh.h:137: relocation truncated to fit: R_PPC64_REL24 against symbol `.eeh_check_failure' defined in .text section in arch/powerpc/platforms/built-in.o
drivers/built-in.o: In function `get_dma_ops':
arch/powerpc/include/asm/dma-mapping.h:97: additional relocation overflows omitted from the output

I have no idea why.
-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: powerpc build failure

[Paul Mackerras]

Stephen Rothwell writes:

> Today's linux-next build (powerpc allyesconfig) failed like this:
> 
> drivers/built-in.o: In function `get_dma_ops':
> arch/powerpc/include/asm/dma-mapping.h:97: relocation truncated to fit: R_PPC64_REL24 against symbol `.ftrace_likely_update' defined in .text section in kernel/built-in.o

Is kernel/built-in.o getting to have more than 32MB of text perhaps?

Paul.

Re: linux-next: powerpc build failure

[Peter Teoh]

On Wed, Nov 26, 2008 at 10:34 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Paul,
>
> Today's linux-next build (powerpc allyesconfig) failed like this:
>
> drivers/built-in.o: In function `get_dma_ops':
> arch/powerpc/include/asm/dma-mapping.h:97: relocation truncated to fit: R_PPC64_REL24 against symbol `.ftrace_likely_update' defined in .text section in kernel/built-in.o
> drivers/built-in.o: In function `init_shadow_tids':
> drivers/infiniband/hw/ipath/ipath_init_chip.c:457: relocation truncated to fit: R_PPC64_REL24 against symbol `.vfree' defined in .text section in mm/built-in.o

Not sure if my guess is correct, but the explanation for the
"relocation truncated to fit" error is here:

http://www.gossamer-threads.com/lists/linux/kernel/156801?search_string=%26quot%3Brelocation%20truncated%20to%20fit%3A%20%26quot%3B;#156801

and solved here:

http://www.gossamer-threads.com/lists/linux/kernel/156815?search_string=%26quot%3Brelocation%20truncated%20to%20fit%3A%20%26quot%3B;#156815

as well.

Perhaps u have a clue now?

-- 
Regards,
Peter Teoh

Ernest Hemingway - "Never mistake motion for action."

linux-next: powerpc build failure

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 497 bytes --]

Hi Paul,

Today's linux-next tree build (powerpc ppc64_defconfig) failed like this:

  UPD     include/linux/compile.h
arch/powerpc/mm/built-in.o: In function `ht64_insert_pte':
hash_native_64.c:(.text+0x4756): undefined reference to `_PAGE_HPTE_SUB0'

I have reverted commit 2d9a973b0fee245af43b73412a08e88bc955644d
("powerpc: Free a PTE bit on ppc64 with 64K pages") for now.

-- 
Cheers,
Stephen Rothwell                    sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: linux-next: powerpc build failure

[Benjamin Herrenschmidt]

On Tue, 2008-06-10 at 16:54 +1000, Stephen Rothwell wrote:
> Hi Paul,
> 
> Today's linux-next tree build (powerpc ppc64_defconfig) failed like this:
> 
>   UPD     include/linux/compile.h
> arch/powerpc/mm/built-in.o: In function `ht64_insert_pte':
> hash_native_64.c:(.text+0x4756): undefined reference to `_PAGE_HPTE_SUB0'
> 
> I have reverted commit 2d9a973b0fee245af43b73412a08e88bc955644d
> ("powerpc: Free a PTE bit on ppc64 with 64K pages") for now.

Yup, that's the way to go. It's broken, I'll have to do things a bit
differently, I "forgot" our 64K SPU hack when using 4K pages assumes
we have the same PTE format :-( I'll have to implement a separate low
level asm function for hashing 64K pages on a 4K kernel.

Ben.