|
| <prev next> |
Re: [PATCH] x86_64: Work around Re: 2.6.14-git1 (and -git2) build failure o: msg#00156linux.ports.x86-64.general
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. |
|
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| Previous by Date: | Re: [PATCH] x86_64: Work around Re: 2.6.14-git1 (and -git2) build failure on AMD64: 00156, Andi Kleen |
|---|---|
| Next by Date: | Re: [stable] Re: 4GB memory and Intel Dual-Core system: 00156, Chris Wright |
| Previous by Thread: | Re: [PATCH] x86_64: Work around Re: 2.6.14-git1 (and -git2) build failure on AMD64i: 00156, Andi Kleen |
| Indexes: | [Date] [Thread] [Top] [All Lists] |
| News | FAQ | advertise |