2.6.14-git1 (and -git2) build failure on AMD64

CC arch/x86_64/pci/../../i386/pci/fixup.o
arch/x86_64/pci/../../i386/pci/fixup.c: In function `pci_fixup_i450nx':
arch/x86_64/pci/../../i386/pci/fixup.c:13: error: pci_fixup_i450nx causes a section type conflict make[1]: *** [arch/x86_64/pci/../../i386/pci/fixup.o] Error 1
make: *** [arch/x86_64/pci] Error 2

Config: http://ftp.kernel.org/pub/linux/kernel/people/mbligh/config/abat/amd64

Fixed by:

    http://lkml.org/lkml/2005/10/29/12

You .config breaks because it has
# CONFIG_HOTPLUG is not set

- R.

What compiler do you use? I cannot make sense of the error - as far as I can see the function only has a single section attribute. But gcc 4.0.2 reports the same error for me on a different function.

-Andi

--Andi Kleen <[email protected]> wrote (on Sunday, October 30, 2005 16:28:29 +0100):

Looks like it's 3.4.0 on that box.

Andi> What compiler do you use? I cannot make sense of the error - Andi> as far as I can see the function only has a single section Andi> attribute. But gcc 4.0.2 reports the same error for me on a Andi> different function.

Yes, the gcc error is very strange. The underlying cause is that (with CONFIG_HOTPLUG=n so __devinit is not just defined away to nothing) having toshiba_ohci1394_dmi_table[] declared __devinit makes gcc think it has to put the array in a section along with code. But instead of complaining about the array declaration, gcc complains about some random function earlier in the file -- and which function it picks to complain about seems to change depending on gcc version and the phase of the moon.

- R.

I think it's a gcc bug. Anyways, this should work around it.

Linus, can you please apply it?

---

Work around gcc bug that causes build failures like
(exact function it is reported on varies with compiler version and optimization level)

with !CONFIG_HOTPLUG. It makes the !CONFIG_HOTPLUG case act like CONFIG_HOTPLUG. This wastes a bit of memory, but is not too bad.

The sections are legitimate, but gcc somehow gets confused.

Compiling with -O3 seems to also help at least with gcc 4, but I'm not sure it'll help everything. Splitting up the file might a different option.

diff -u linux-2.6.14-git2/arch/i386/pci/fixup.c-o linux-2.6.14-git2/arch/i386/pci/fixup.c
@@ -8,6 +8,9 @@
 #include <linux/init.h>
 #include "pci.h"
 
+/* Works around a gcc bug which gets confused with so many section switches */
+#undef __devinit
+#define __devinit
 
 static void __devinit pci_fixup_i450nx(struct pci_dev *d)
 {

Andi> Linus, can you please apply it?

No, please don't apply this. The correct fix is to mark toshiba_ohci1394_dmi_table[] as __devinitdata in that file, as in the patch I posted here:

    http://lkml.org/lkml/2005/10/29/12

- R.

While not correct I don't see how it should guarantee it will work around that gcc bug on all possible gcc versions (which show different behaviour) My patch is more conservative and safer.

-Andi

Andi> While not correct I don't see how it should guarantee it Andi> will work around that gcc bug on all possible gcc versions Andi> (which show different behaviour) My patch is more Andi> conservative and safer.

What's the gcc bug? The current fixup.c code is asking gcc to put toshiba_ohci1394_dmi_table[] in the .init.text section. This makes gcc think that .init.text contains writable data. Then some other declaration in the file asks gcc to put a function in .init.text. gcc correctly complains that text and writable data can't share a section.

If we fix toshiba_ohci1394_dmi_table[] to go into .init.data as is intended, then gcc is happy.

The only thing remotely like a gcc bug is that the diagnostic gcc prints does not flag toshiba_ohci1394_dmi_table[] as the problem.

Admittedly I have only tested gcc 4.0 and gcc 3.4, but given that no one reported this problem before toshiba_ohci1394_dmi_table[] was added, and that the __devinit declaration of an array is obviously wrong and would cause exactly this sort of section conflict, I think we should at least try the correct fix.

- R.

--Roland Dreier <[email protected]> wrote (on Sunday, October 30, 2005 08:17:39 -0800):

Tested, fixes it for me. Linus - this is still broken in -git4, any chance you could pick this one up? Makes nasty red marks across my shiny green test matrix ;-)

Thanks,

M.