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.
On Sunday 30 October 2005 15:03, Martin J. Bligh wrote:
> 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
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
On Sunday 30 October 2005 15:03, Martin J. Bligh wrote:
> 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
>
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)
> 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
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.
Signed-off-by: Andi Kleen <[email protected]>
diff -u linux-2.6.14-git2/arch/i386/pci/fixup.c-o linux-2.6.14-git2/arch/i386/pci/fixup.c
--- linux-2.6.14-git2/arch/i386/pci/fixup.c-o 2005-10-30 16:09:41.000000000 +0100
+++ linux-2.6.14-git2/arch/i386/pci/fixup.c 2005-10-30 16:42:32.000000000 +0100
@@ -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 Kleen <[email protected]> wrote (on Sunday, October 30, 2005 16:28:29 +0100):
> On Sunday 30 October 2005 15:03, Martin J. Bligh wrote:
>> 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
>
> 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.
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.
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.
On Sunday 30 October 2005 17:17, Roland Dreier wrote:
> 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
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):
> 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
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.