I'm getting screen and screens full of section mismatches from my test builds of the current kernel to the point where it's sometimes more meaningful messages get hidden by the bulk of mismatches. This is the first round of fixes with more to come.
Ralf
drivers/gpu/drm/radeon/radeon_clocks.c | 4 ++-- drivers/leds/leds-lp5521.c | 4 ++-- drivers/leds/leds-lp5523.c | 4 ++-- drivers/misc/ioc4.c | 2 +- drivers/net/3c509.c | 2 +- drivers/net/3c59x.c | 2 +- drivers/net/depca.c | 25 +++++++++++++------------ drivers/net/hp100.c | 2 +- drivers/net/ne3210.c | 12 +++++++----- drivers/net/tulip/de4x5.c | 2 +- drivers/scsi/sim710.c | 2 +- drivers/tty/serial/Kconfig | 2 +- 12 files changed, 33 insertions(+), 30 deletions(-)
WARNING: drivers/gpu/drm/radeon/radeon.o(.text+0x5d1fc): Section mismatch in reference from the function radeon_get_clock_info() to the function .devinit.text:radeon_read_clocks_OF() The function radeon_get_clock_info() references the function __devinit radeon_read_clocks_OF(). This is often because radeon_get_clock_info lacks a __devinit annotation or the annotation of radeon_read_clocks_OF is wrong.
Signed-off-by: Ralf Baechle ralf@linux-mips.org To: David Airlie airlied@linux.ie Cc: dri-devel@lists.freedesktop.org Cc: linux-kernel@vger.kernel.org Cc: linux-mips@linux-mips.org --- drivers/gpu/drm/radeon/radeon_clocks.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_clocks.c b/drivers/gpu/drm/radeon/radeon_clocks.c index 2d48e7a..dcd0863e 100644 --- a/drivers/gpu/drm/radeon/radeon_clocks.c +++ b/drivers/gpu/drm/radeon/radeon_clocks.c @@ -96,7 +96,7 @@ uint32_t radeon_legacy_get_memory_clock(struct radeon_device *rdev) * Read XTAL (ref clock), SCLK and MCLK from Open Firmware device * tree. Hopefully, ATI OF driver is kind enough to fill these */ -static bool __devinit radeon_read_clocks_OF(struct drm_device *dev) +static bool radeon_read_clocks_OF(struct drm_device *dev) { struct radeon_device *rdev = dev->dev_private; struct device_node *dp = rdev->pdev->dev.of_node; @@ -166,7 +166,7 @@ static bool __devinit radeon_read_clocks_OF(struct drm_device *dev) return true; } #else -static bool __devinit radeon_read_clocks_OF(struct drm_device *dev) +static bool radeon_read_clocks_OF(struct drm_device *dev) { return false; }
See commit:
commit 948252cb9e01d65a89ecadf67be5018351eee15e Author: David S. Miller davem@davemloft.net Date: Tue May 31 19:27:48 2011 -0700
Revert "net: fix section mismatches"
This reverts commit e5cb966c0838e4da43a3b0751bdcac7fe719f7b4.
It causes new build regressions with gcc-4.2 which is pretty common on non-x86 platforms.
Reported-by: James Bottomley James.Bottomley@HansenPartnership.com Signed-off-by: David S. Miller davem@davemloft.net
and postings that led to this revert including:
On Mon, Jun 27, 2011 at 10:12:57PM -0700, David Miller wrote:
commit 948252cb9e01d65a89ecadf67be5018351eee15e Author: David S. Miller davem@davemloft.net Date: Tue May 31 19:27:48 2011 -0700
Revert "net: fix section mismatches" This reverts commit e5cb966c0838e4da43a3b0751bdcac7fe719f7b4. It causes new build regressions with gcc-4.2 which is pretty common on non-x86 platforms. Reported-by: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: David S. Miller <davem@davemloft.net>and postings that led to this revert including:
Thanks for the pointers; I looked into it a bit deeper and found that the construct which hppa64-linux-gcc 4.2.4 doesn't like is the combination of const and __devinitconst __devinitdata.
My patches are minimalistic and don't do any constification and seem to work fine for PA-RISC.
A possible alternative to allow the use of Michał's reverted patch would be to conditionalize the definition of __devinitconst. There is no user of __devexitconst so I left that unchanged.
Ralf
Signed-off-by: Ralf Baechle ralf@linux-mips.org
include/linux/init.h | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/include/linux/init.h b/include/linux/init.h index 577671c..e12fd85 100644 --- a/include/linux/init.h +++ b/include/linux/init.h @@ -84,7 +84,15 @@ /* Used for HOTPLUG */ #define __devinit __section(.devinit.text) __cold #define __devinitdata __section(.devinit.data) +#if defined __GNUC__ && (__GNUC__ == 4) && (__GNUC_MINOR__ == 2) +/* + * GCC 4.2 will sometimes throw an error if the combination of const and + * __devinitconst is being used. As a workaround make __devinitconst a noop + */ +#define __devinitconst +#else #define __devinitconst __section(.devinit.rodata) +#endif #define __devexit __section(.devexit.text) __exitused __cold #define __devexitdata __section(.devexit.data) #define __devexitconst __section(.devexit.rodata)
On Wed, 2011-06-29 at 14:07 +0100, Ralf Baechle wrote:
On Mon, Jun 27, 2011 at 10:12:57PM -0700, David Miller wrote:
commit 948252cb9e01d65a89ecadf67be5018351eee15e Author: David S. Miller davem@davemloft.net Date: Tue May 31 19:27:48 2011 -0700
Revert "net: fix section mismatches" This reverts commit e5cb966c0838e4da43a3b0751bdcac7fe719f7b4. It causes new build regressions with gcc-4.2 which is pretty common on non-x86 platforms. Reported-by: James Bottomley <James.Bottomley@HansenPartnership.com> Signed-off-by: David S. Miller <davem@davemloft.net>and postings that led to this revert including:
Thanks for the pointers; I looked into it a bit deeper and found that the construct which hppa64-linux-gcc 4.2.4 doesn't like is the combination of const and __devinitconst __devinitdata.
My patches are minimalistic and don't do any constification and seem to work fine for PA-RISC.
A possible alternative to allow the use of Michał's reverted patch would be to conditionalize the definition of __devinitconst. There is no user of __devexitconst so I left that unchanged.
To be honest, my own take on this is that, apart from the compiler cockups trying to do read only annotations, which affect various versions of gcc not just the parisc ones, the _devX annotations are pretty pointless. They only really do something in the non-hotplug case, so since 95% of the world seems to use hotplug now and the other 5% doesn't care that much about the odd page of memory (which you rarely get, since modules sections are accumulated per module, not aggregate), I'd just favour stripping __init and __exit where there's a problem.
I think we should simply concentrate on __init and __exit; that's where most of the discard value lies and stop expending huge efforts on the __devX stuff which adds huge complexity for no real gain.
James
On Wed, Jun 29, 2011 at 08:58:19AM -0500, James Bottomley wrote:
I think we should simply concentrate on __init and __exit; that's where most of the discard value lies and stop expending huge efforts on the __devX stuff which adds huge complexity for no real gain.
I have long felt that those __devX markings should just go away as they cause nothing but problems and have no real gain as you point out.
greg k-h
On Wed, Jun 29, 2011 at 08:14:24AM -0700, Greg KH wrote:
On Wed, Jun 29, 2011 at 08:58:19AM -0500, James Bottomley wrote:
I think we should simply concentrate on __init and __exit; that's where most of the discard value lies and stop expending huge efforts on the __devX stuff which adds huge complexity for no real gain.
I have long felt that those __devX markings should just go away as they cause nothing but problems and have no real gain as you point out.
The suggestion to do that has been floated around before but seems to have missed sufficient thrust. I'm all for it; the manual tagging with __devX has not been very efficient on developer time. I just want to see meaningful warnings again over all that noise the current mechanisn may produce.
Ralf
On Wed, 2011-06-29 at 17:19 +0100, Ralf Baechle wrote:
On Wed, Jun 29, 2011 at 08:14:24AM -0700, Greg KH wrote:
On Wed, Jun 29, 2011 at 08:58:19AM -0500, James Bottomley wrote:
I think we should simply concentrate on __init and __exit; that's where most of the discard value lies and stop expending huge efforts on the __devX stuff which adds huge complexity for no real gain.
I have long felt that those __devX markings should just go away as they cause nothing but problems and have no real gain as you point out.
The suggestion to do that has been floated around before but seems to have missed sufficient thrust. I'm all for it; the manual tagging with __devX has not been very efficient on developer time. I just want to see meaningful warnings again over all that noise the current mechanisn may produce.
For me, just go ahead and fix the actual problems: so _init sections and _exit sections that are used from the main body, just strip the annotations, don't try to change them for _devX ones.
Thanks,
James
dri-devel@lists.freedesktop.org
-
David Miller -
Greg KH -
James Bottomley -
Ralf Baechle