Linux 4.9.180 build fails with gcc 9 and 'cleanup_module' specifies less restrictive attribute than its target …
I have at least these 2 instances:
In file included from /tmp/e2/build/linux-4.9.180/include/drm/drm_vma_manager.h:28, from /tmp/e2/build/linux-4.9.180/include/drm/drmP.h:78, from /tmp/e2/build/linux-4.9.180/include/drm/drm_modeset_helper.h:26, from /tmp/e2/build/linux-4.9.180/include/drm/drm_atomic_helper.h:33, from /tmp/e2/build/linux-4.9.180/drivers/gpu/drm/tilcdc/tilcdc_drv.c:24: /tmp/e2/build/linux-4.9.180/include/linux/module.h:138:7: error: 'cleanup_module' specifies less restrictive attribute than its target 'tilcdc_drm_fini': 'cold' [-Werror=missing-attributes] 138 | void cleanup_module(void) __attribute__((alias(#exitfn))); | ^~~~~~~~~~~~~~ /tmp/e2/build/linux-4.9.180/drivers/gpu/drm/tilcdc/tilcdc_drv.c:757:1: note: in expansion of macro 'module_exit' 757 | module_exit(tilcdc_drm_fini); | ^~~~~~~~~~~ /tmp/e2/build/linux-4.9.180/drivers/gpu/drm/tilcdc/tilcdc_drv.c:748:20: note: 'cleanup_module' target declared here 748 | static void __exit tilcdc_drm_fini(void) | ^~~~~~~~~~~~~~~ In file included from /tmp/e2/build/linux-4.9.180/include/drm/drm_vma_manager.h:28, from /tmp/e2/build/linux-4.9.180/include/drm/drmP.h:78, from /tmp/e2/build/linux-4.9.180/include/drm/drm_modeset_helper.h:26, from /tmp/e2/build/linux-4.9.180/include/drm/drm_atomic_helper.h:33, from /tmp/e2/build/linux-4.9.180/drivers/gpu/drm/tilcdc/tilcdc_drv.c:24: /tmp/e2/build/linux-4.9.180/include/linux/module.h:132:6: error: 'init_module' specifies less restrictive attribute than its target 'tilcdc_drm_init': 'cold' [-Werror=missing-attributes] 132 | int init_module(void) __attribute__((alias(#initfn))); | ^~~~~~~~~~~ /tmp/e2/build/linux-4.9.180/drivers/gpu/drm/tilcdc/tilcdc_drv.c:756:1: note: in expansion of macro 'module_init' 756 | module_init(tilcdc_drm_init); | ^~~~~~~~~~~ /tmp/e2/build/linux-4.9.180/drivers/gpu/drm/tilcdc/tilcdc_drv.c:740:19: note: 'init_module' target declared here 740 | static int __init tilcdc_drm_init(void) | ^~~~~~~~~~~~~~~
In file included from /tmp/e2/build/linux-4.9.180/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c:17: /tmp/e2/build/linux-4.9.180/include/linux/module.h:138:7: error: 'cleanup_module' specifies less restrictive attribute than its target 'mpc52xx_lpbfifo_driver_exit': 'cold' [-Werror=missing-attributes] 138 | void cleanup_module(void) __attribute__((alias(#exitfn))); | ^~~~~~~~~~~~~~ /tmp/e2/build/linux-4.9.180/include/linux/device.h:1360:1: note: in expansion of macro 'module_exit' 1360 | module_exit(__driver##_exit); | ^~~~~~~~~~~ /tmp/e2/build/linux-4.9.180/include/linux/platform_device.h:228:2: note: in expansion of macro 'module_driver' 228 | module_driver(__platform_driver, platform_driver_register, \ | ^~~~~~~~~~~~~ /tmp/e2/build/linux-4.9.180/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c:581:1: note: in expansion of macro 'module_platform_driver' 581 | module_platform_driver(mpc52xx_lpbfifo_driver); | ^~~~~~~~~~~~~~~~~~~~~~ In file included from /tmp/e2/build/linux-4.9.180/arch/powerpc/include/asm/io.h:27, from /tmp/e2/build/linux-4.9.180/include/linux/io.h:25, from /tmp/e2/build/linux-4.9.180/include/linux/irq.h:24, from /tmp/e2/build/linux-4.9.180/arch/powerpc/include/asm/hardirq.h:5, from /tmp/e2/build/linux-4.9.180/include/linux/hardirq.h:8, from /tmp/e2/build/linux-4.9.180/include/linux/interrupt.h:12, from /tmp/e2/build/linux-4.9.180/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c:12: /tmp/e2/build/linux-4.9.180/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c:581:24: note: 'cleanup_module' target declared here 581 | module_platform_driver(mpc52xx_lpbfifo_driver); | ^~~~~~~~~~~~~~~~~~~~~~ /tmp/e2/build/linux-4.9.180/include/linux/device.h:1356:20: note: in definition of macro 'module_driver' 1356 | static void __exit __driver##_exit(void) \ | ^~~~~~~~ /tmp/e2/build/linux-4.9.180/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c:581:1: note: in expansion of macro 'module_platform_driver' 581 | module_platform_driver(mpc52xx_lpbfifo_driver); | ^~~~~~~~~~~~~~~~~~~~~~ In file included from /tmp/e2/build/linux-4.9.180/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c:17: /tmp/e2/build/linux-4.9.180/include/linux/module.h:132:6: error: 'init_module' specifies less restrictive attribute than its target 'mpc52xx_lpbfifo_driver_init': 'cold' [-Werror=missing-attributes] 132 | int init_module(void) __attribute__((alias(#initfn))); | ^~~~~~~~~~~ /tmp/e2/build/linux-4.9.180/include/linux/device.h:1355:1: note: in expansion of macro 'module_init' 1355 | module_init(__driver##_init); \ | ^~~~~~~~~~~ /tmp/e2/build/linux-4.9.180/include/linux/platform_device.h:228:2: note: in expansion of macro 'module_driver' 228 | module_driver(__platform_driver, platform_driver_register, \ | ^~~~~~~~~~~~~ /tmp/e2/build/linux-4.9.180/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c:581:1: note: in expansion of macro 'module_platform_driver' 581 | module_platform_driver(mpc52xx_lpbfifo_driver); | ^~~~~~~~~~~~~~~~~~~~~~ In file included from /tmp/e2/build/linux-4.9.180/arch/powerpc/include/asm/io.h:27, from /tmp/e2/build/linux-4.9.180/include/linux/io.h:25, from /tmp/e2/build/linux-4.9.180/include/linux/irq.h:24, from /tmp/e2/build/linux-4.9.180/arch/powerpc/include/asm/hardirq.h:5, from /tmp/e2/build/linux-4.9.180/include/linux/hardirq.h:8, from /tmp/e2/build/linux-4.9.180/include/linux/interrupt.h:12, from /tmp/e2/build/linux-4.9.180/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c:12: /tmp/e2/build/linux-4.9.180/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c:581:24: note: 'init_module' target declared here 581 | module_platform_driver(mpc52xx_lpbfifo_driver); | ^~~~~~~~~~~~~~~~~~~~~~ /tmp/e2/build/linux-4.9.180/include/linux/device.h:1351:19: note: in definition of macro 'module_driver' 1351 | static int __init __driver##_init(void) \ | ^~~~~~~~ /tmp/e2/build/linux-4.9.180/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c:581:1: note: in expansion of macro 'module_platform_driver' 581 | module_platform_driver(mpc52xx_lpbfifo_driver); | ^~~~~~~~~~~~~~~~~~~~~~
So this needs a6e60d84989fa0e91db7f236eda40453b0e44afa, which needs c0d9782f5b6d7157635ae2fd782a4b27d55a6013, which can't be applied cleanly because a3f8a30f3f0079c7edfc72e329eee8594fb3e3cb is missing in 4.9.
I have applied a6e60d84989fa0e91db7f236eda40453b0e44afa and modified it to directly use __attribute__((__copy__(initfn))) and (exitfn), which fixes the build for me.
Greetings,
Eike
On Thu, Jun 06, 2019 at 03:16:03PM +0200, Rolf Eike Beer wrote:
I have at least these 2 instances:
In file included from /tmp/e2/build/linux-4.9.180/include/drm/drm_vma_manager.h:28, from /tmp/e2/build/linux-4.9.180/include/drm/drmP.h:78, from /tmp/e2/build/linux-4.9.180/include/drm/drm_modeset_helper.h:26, from /tmp/e2/build/linux-4.9.180/include/drm/drm_atomic_helper.h:33, from /tmp/e2/build/linux-4.9.180/drivers/gpu/drm/tilcdc/tilcdc_drv.c:24: /tmp/e2/build/linux-4.9.180/include/linux/module.h:138:7: error: 'cleanup_module' specifies less restrictive attribute than its target 'tilcdc_drm_fini': 'cold' [-Werror=missing-attributes] 138 | void cleanup_module(void) __attribute__((alias(#exitfn))); | ^~~~~~~~~~~~~~ /tmp/e2/build/linux-4.9.180/drivers/gpu/drm/tilcdc/tilcdc_drv.c:757:1: note: in expansion of macro 'module_exit' 757 | module_exit(tilcdc_drm_fini); | ^~~~~~~~~~~ /tmp/e2/build/linux-4.9.180/drivers/gpu/drm/tilcdc/tilcdc_drv.c:748:20: note: 'cleanup_module' target declared here 748 | static void __exit tilcdc_drm_fini(void) | ^~~~~~~~~~~~~~~ In file included from /tmp/e2/build/linux-4.9.180/include/drm/drm_vma_manager.h:28, from /tmp/e2/build/linux-4.9.180/include/drm/drmP.h:78, from /tmp/e2/build/linux-4.9.180/include/drm/drm_modeset_helper.h:26, from /tmp/e2/build/linux-4.9.180/include/drm/drm_atomic_helper.h:33, from /tmp/e2/build/linux-4.9.180/drivers/gpu/drm/tilcdc/tilcdc_drv.c:24: /tmp/e2/build/linux-4.9.180/include/linux/module.h:132:6: error: 'init_module' specifies less restrictive attribute than its target 'tilcdc_drm_init': 'cold' [-Werror=missing-attributes] 132 | int init_module(void) __attribute__((alias(#initfn))); | ^~~~~~~~~~~ /tmp/e2/build/linux-4.9.180/drivers/gpu/drm/tilcdc/tilcdc_drv.c:756:1: note: in expansion of macro 'module_init' 756 | module_init(tilcdc_drm_init); | ^~~~~~~~~~~ /tmp/e2/build/linux-4.9.180/drivers/gpu/drm/tilcdc/tilcdc_drv.c:740:19: note: 'init_module' target declared here 740 | static int __init tilcdc_drm_init(void) | ^~~~~~~~~~~~~~~
In file included from /tmp/e2/build/linux-4.9.180/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c:17: /tmp/e2/build/linux-4.9.180/include/linux/module.h:138:7: error: 'cleanup_module' specifies less restrictive attribute than its target 'mpc52xx_lpbfifo_driver_exit': 'cold' [-Werror=missing-attributes] 138 | void cleanup_module(void) __attribute__((alias(#exitfn))); | ^~~~~~~~~~~~~~ /tmp/e2/build/linux-4.9.180/include/linux/device.h:1360:1: note: in expansion of macro 'module_exit' 1360 | module_exit(__driver##_exit); | ^~~~~~~~~~~ /tmp/e2/build/linux-4.9.180/include/linux/platform_device.h:228:2: note: in expansion of macro 'module_driver' 228 | module_driver(__platform_driver, platform_driver_register, \ | ^~~~~~~~~~~~~ /tmp/e2/build/linux-4.9.180/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c:581:1: note: in expansion of macro 'module_platform_driver' 581 | module_platform_driver(mpc52xx_lpbfifo_driver); | ^~~~~~~~~~~~~~~~~~~~~~ In file included from /tmp/e2/build/linux-4.9.180/arch/powerpc/include/asm/io.h:27, from /tmp/e2/build/linux-4.9.180/include/linux/io.h:25, from /tmp/e2/build/linux-4.9.180/include/linux/irq.h:24, from /tmp/e2/build/linux-4.9.180/arch/powerpc/include/asm/hardirq.h:5, from /tmp/e2/build/linux-4.9.180/include/linux/hardirq.h:8, from /tmp/e2/build/linux-4.9.180/include/linux/interrupt.h:12, from /tmp/e2/build/linux-4.9.180/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c:12: /tmp/e2/build/linux-4.9.180/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c:581:24: note: 'cleanup_module' target declared here 581 | module_platform_driver(mpc52xx_lpbfifo_driver); | ^~~~~~~~~~~~~~~~~~~~~~ /tmp/e2/build/linux-4.9.180/include/linux/device.h:1356:20: note: in definition of macro 'module_driver' 1356 | static void __exit __driver##_exit(void) \ | ^~~~~~~~ /tmp/e2/build/linux-4.9.180/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c:581:1: note: in expansion of macro 'module_platform_driver' 581 | module_platform_driver(mpc52xx_lpbfifo_driver); | ^~~~~~~~~~~~~~~~~~~~~~ In file included from /tmp/e2/build/linux-4.9.180/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c:17: /tmp/e2/build/linux-4.9.180/include/linux/module.h:132:6: error: 'init_module' specifies less restrictive attribute than its target 'mpc52xx_lpbfifo_driver_init': 'cold' [-Werror=missing-attributes] 132 | int init_module(void) __attribute__((alias(#initfn))); | ^~~~~~~~~~~ /tmp/e2/build/linux-4.9.180/include/linux/device.h:1355:1: note: in expansion of macro 'module_init' 1355 | module_init(__driver##_init); \ | ^~~~~~~~~~~ /tmp/e2/build/linux-4.9.180/include/linux/platform_device.h:228:2: note: in expansion of macro 'module_driver' 228 | module_driver(__platform_driver, platform_driver_register, \ | ^~~~~~~~~~~~~ /tmp/e2/build/linux-4.9.180/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c:581:1: note: in expansion of macro 'module_platform_driver' 581 | module_platform_driver(mpc52xx_lpbfifo_driver); | ^~~~~~~~~~~~~~~~~~~~~~ In file included from /tmp/e2/build/linux-4.9.180/arch/powerpc/include/asm/io.h:27, from /tmp/e2/build/linux-4.9.180/include/linux/io.h:25, from /tmp/e2/build/linux-4.9.180/include/linux/irq.h:24, from /tmp/e2/build/linux-4.9.180/arch/powerpc/include/asm/hardirq.h:5, from /tmp/e2/build/linux-4.9.180/include/linux/hardirq.h:8, from /tmp/e2/build/linux-4.9.180/include/linux/interrupt.h:12, from /tmp/e2/build/linux-4.9.180/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c:12: /tmp/e2/build/linux-4.9.180/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c:581:24: note: 'init_module' target declared here 581 | module_platform_driver(mpc52xx_lpbfifo_driver); | ^~~~~~~~~~~~~~~~~~~~~~ /tmp/e2/build/linux-4.9.180/include/linux/device.h:1351:19: note: in definition of macro 'module_driver' 1351 | static int __init __driver##_init(void) \ | ^~~~~~~~ /tmp/e2/build/linux-4.9.180/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c:581:1: note: in expansion of macro 'module_platform_driver' 581 | module_platform_driver(mpc52xx_lpbfifo_driver); | ^~~~~~~~~~~~~~~~~~~~~~
So this needs a6e60d84989fa0e91db7f236eda40453b0e44afa, which needs c0d9782f5b6d7157635ae2fd782a4b27d55a6013, which can't be applied cleanly because a3f8a30f3f0079c7edfc72e329eee8594fb3e3cb is missing in 4.9.
I have applied a6e60d84989fa0e91db7f236eda40453b0e44afa and modified it to directly use __attribute__((__copy__(initfn))) and (exitfn), which fixes the build for me.
I just added some patches for gcc9 to 4.14 and 4.19, are you really going to want to build it on 4.9?
If so, I can try to fix this up...
thanks,
greg k-h
On Thu, Jun 06, 2019 at 05:27:46PM +0200, Greg KH wrote:
On Thu, Jun 06, 2019 at 03:16:03PM +0200, Rolf Eike Beer wrote:
I have at least these 2 instances:
In file included from /tmp/e2/build/linux-4.9.180/include/drm/drm_vma_manager.h:28, from /tmp/e2/build/linux-4.9.180/include/drm/drmP.h:78, from /tmp/e2/build/linux-4.9.180/include/drm/drm_modeset_helper.h:26, from /tmp/e2/build/linux-4.9.180/include/drm/drm_atomic_helper.h:33, from /tmp/e2/build/linux-4.9.180/drivers/gpu/drm/tilcdc/tilcdc_drv.c:24: /tmp/e2/build/linux-4.9.180/include/linux/module.h:138:7: error: 'cleanup_module' specifies less restrictive attribute than its target 'tilcdc_drm_fini': 'cold' [-Werror=missing-attributes] 138 | void cleanup_module(void) __attribute__((alias(#exitfn))); | ^~~~~~~~~~~~~~ /tmp/e2/build/linux-4.9.180/drivers/gpu/drm/tilcdc/tilcdc_drv.c:757:1: note: in expansion of macro 'module_exit' 757 | module_exit(tilcdc_drm_fini); | ^~~~~~~~~~~ /tmp/e2/build/linux-4.9.180/drivers/gpu/drm/tilcdc/tilcdc_drv.c:748:20: note: 'cleanup_module' target declared here 748 | static void __exit tilcdc_drm_fini(void) | ^~~~~~~~~~~~~~~ In file included from /tmp/e2/build/linux-4.9.180/include/drm/drm_vma_manager.h:28, from /tmp/e2/build/linux-4.9.180/include/drm/drmP.h:78, from /tmp/e2/build/linux-4.9.180/include/drm/drm_modeset_helper.h:26, from /tmp/e2/build/linux-4.9.180/include/drm/drm_atomic_helper.h:33, from /tmp/e2/build/linux-4.9.180/drivers/gpu/drm/tilcdc/tilcdc_drv.c:24: /tmp/e2/build/linux-4.9.180/include/linux/module.h:132:6: error: 'init_module' specifies less restrictive attribute than its target 'tilcdc_drm_init': 'cold' [-Werror=missing-attributes] 132 | int init_module(void) __attribute__((alias(#initfn))); | ^~~~~~~~~~~ /tmp/e2/build/linux-4.9.180/drivers/gpu/drm/tilcdc/tilcdc_drv.c:756:1: note: in expansion of macro 'module_init' 756 | module_init(tilcdc_drm_init); | ^~~~~~~~~~~ /tmp/e2/build/linux-4.9.180/drivers/gpu/drm/tilcdc/tilcdc_drv.c:740:19: note: 'init_module' target declared here 740 | static int __init tilcdc_drm_init(void) | ^~~~~~~~~~~~~~~
In file included from /tmp/e2/build/linux-4.9.180/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c:17: /tmp/e2/build/linux-4.9.180/include/linux/module.h:138:7: error: 'cleanup_module' specifies less restrictive attribute than its target 'mpc52xx_lpbfifo_driver_exit': 'cold' [-Werror=missing-attributes] 138 | void cleanup_module(void) __attribute__((alias(#exitfn))); | ^~~~~~~~~~~~~~ /tmp/e2/build/linux-4.9.180/include/linux/device.h:1360:1: note: in expansion of macro 'module_exit' 1360 | module_exit(__driver##_exit); | ^~~~~~~~~~~ /tmp/e2/build/linux-4.9.180/include/linux/platform_device.h:228:2: note: in expansion of macro 'module_driver' 228 | module_driver(__platform_driver, platform_driver_register, \ | ^~~~~~~~~~~~~ /tmp/e2/build/linux-4.9.180/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c:581:1: note: in expansion of macro 'module_platform_driver' 581 | module_platform_driver(mpc52xx_lpbfifo_driver); | ^~~~~~~~~~~~~~~~~~~~~~ In file included from /tmp/e2/build/linux-4.9.180/arch/powerpc/include/asm/io.h:27, from /tmp/e2/build/linux-4.9.180/include/linux/io.h:25, from /tmp/e2/build/linux-4.9.180/include/linux/irq.h:24, from /tmp/e2/build/linux-4.9.180/arch/powerpc/include/asm/hardirq.h:5, from /tmp/e2/build/linux-4.9.180/include/linux/hardirq.h:8, from /tmp/e2/build/linux-4.9.180/include/linux/interrupt.h:12, from /tmp/e2/build/linux-4.9.180/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c:12: /tmp/e2/build/linux-4.9.180/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c:581:24: note: 'cleanup_module' target declared here 581 | module_platform_driver(mpc52xx_lpbfifo_driver); | ^~~~~~~~~~~~~~~~~~~~~~ /tmp/e2/build/linux-4.9.180/include/linux/device.h:1356:20: note: in definition of macro 'module_driver' 1356 | static void __exit __driver##_exit(void) \ | ^~~~~~~~ /tmp/e2/build/linux-4.9.180/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c:581:1: note: in expansion of macro 'module_platform_driver' 581 | module_platform_driver(mpc52xx_lpbfifo_driver); | ^~~~~~~~~~~~~~~~~~~~~~ In file included from /tmp/e2/build/linux-4.9.180/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c:17: /tmp/e2/build/linux-4.9.180/include/linux/module.h:132:6: error: 'init_module' specifies less restrictive attribute than its target 'mpc52xx_lpbfifo_driver_init': 'cold' [-Werror=missing-attributes] 132 | int init_module(void) __attribute__((alias(#initfn))); | ^~~~~~~~~~~ /tmp/e2/build/linux-4.9.180/include/linux/device.h:1355:1: note: in expansion of macro 'module_init' 1355 | module_init(__driver##_init); \ | ^~~~~~~~~~~ /tmp/e2/build/linux-4.9.180/include/linux/platform_device.h:228:2: note: in expansion of macro 'module_driver' 228 | module_driver(__platform_driver, platform_driver_register, \ | ^~~~~~~~~~~~~ /tmp/e2/build/linux-4.9.180/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c:581:1: note: in expansion of macro 'module_platform_driver' 581 | module_platform_driver(mpc52xx_lpbfifo_driver); | ^~~~~~~~~~~~~~~~~~~~~~ In file included from /tmp/e2/build/linux-4.9.180/arch/powerpc/include/asm/io.h:27, from /tmp/e2/build/linux-4.9.180/include/linux/io.h:25, from /tmp/e2/build/linux-4.9.180/include/linux/irq.h:24, from /tmp/e2/build/linux-4.9.180/arch/powerpc/include/asm/hardirq.h:5, from /tmp/e2/build/linux-4.9.180/include/linux/hardirq.h:8, from /tmp/e2/build/linux-4.9.180/include/linux/interrupt.h:12, from /tmp/e2/build/linux-4.9.180/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c:12: /tmp/e2/build/linux-4.9.180/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c:581:24: note: 'init_module' target declared here 581 | module_platform_driver(mpc52xx_lpbfifo_driver); | ^~~~~~~~~~~~~~~~~~~~~~ /tmp/e2/build/linux-4.9.180/include/linux/device.h:1351:19: note: in definition of macro 'module_driver' 1351 | static int __init __driver##_init(void) \ | ^~~~~~~~ /tmp/e2/build/linux-4.9.180/arch/powerpc/platforms/52xx/mpc52xx_lpbfifo.c:581:1: note: in expansion of macro 'module_platform_driver' 581 | module_platform_driver(mpc52xx_lpbfifo_driver); | ^~~~~~~~~~~~~~~~~~~~~~
So this needs a6e60d84989fa0e91db7f236eda40453b0e44afa, which needs c0d9782f5b6d7157635ae2fd782a4b27d55a6013, which can't be applied cleanly because a3f8a30f3f0079c7edfc72e329eee8594fb3e3cb is missing in 4.9.
I have applied a6e60d84989fa0e91db7f236eda40453b0e44afa and modified it to directly use __attribute__((__copy__(initfn))) and (exitfn), which fixes the build for me.
I just added some patches for gcc9 to 4.14 and 4.19, are you really going to want to build it on 4.9?
If so, I can try to fix this up...
And if you want this, you should look at how the backports to 4.14.y worked, they did not include a3f8a30f3f00 ("Compiler Attributes: use feature checks instead of version checks"), as that gets really messy...
thanks,
greg k-h
On Thu, Jun 6, 2019 at 5:29 PM Greg KH greg@kroah.com wrote:
And if you want this, you should look at how the backports to 4.14.y worked, they did not include a3f8a30f3f00 ("Compiler Attributes: use feature checks instead of version checks"), as that gets really messy...
I am confused -- I interpreted Rolf's message as reporting that he already successfully built 4.9 by applying a6e60d84989f ("include/linux/module.h: copy __init/__exit attrs to init/cleanup_module") and manually fixing it up. But maybe I am completely wrong... :-)
Cheers, Miguel
On Thu, Jun 06, 2019 at 08:25:28PM +0200, Miguel Ojeda wrote:
On Thu, Jun 6, 2019 at 5:29 PM Greg KH greg@kroah.com wrote:
And if you want this, you should look at how the backports to 4.14.y worked, they did not include a3f8a30f3f00 ("Compiler Attributes: use feature checks instead of version checks"), as that gets really messy...
I am confused -- I interpreted Rolf's message as reporting that he already successfully built 4.9 by applying a6e60d84989f ("include/linux/module.h: copy __init/__exit attrs to init/cleanup_module") and manually fixing it up. But maybe I am completely wrong... :-)
"manually fixing it up" means "hacked it to pieces" to me, I have no idea what the end result really was :)
If someone wants to send me some patches I can actually apply, that would be best...
thanks,
greg k-h
On Thu, Jun 6, 2019 at 8:59 PM Greg KH greg@kroah.com wrote:
"manually fixing it up" means "hacked it to pieces" to me, I have no idea what the end result really was :)
If someone wants to send me some patches I can actually apply, that would be best...
I will give it a go whenever I get some free time :)
Cheers, Miguel
Am Samstag, 8. Juni 2019, 14:00:34 CEST schrieb Miguel Ojeda:
On Thu, Jun 6, 2019 at 8:59 PM Greg KH greg@kroah.com wrote:
"manually fixing it up" means "hacked it to pieces" to me, I have no idea what the end result really was :)
If someone wants to send me some patches I can actually apply, that would be best...
I will give it a go whenever I get some free time :)
I fear this has never happened, did it?
Eike
On Fri, Aug 02, 2019 at 10:17:04AM +0200, Rolf Eike Beer wrote:
Am Samstag, 8. Juni 2019, 14:00:34 CEST schrieb Miguel Ojeda:
On Thu, Jun 6, 2019 at 8:59 PM Greg KH greg@kroah.com wrote:
"manually fixing it up" means "hacked it to pieces" to me, I have no idea what the end result really was :)
If someone wants to send me some patches I can actually apply, that would be best...
I will give it a go whenever I get some free time :)
I fear this has never happened, did it?
I do not think so, I'm still building 4.9.y and 4.14.y and 4.19.y with gcc8 because of these issues :(
thanks,
greg k-h
On Fri, Aug 2, 2019 at 10:17 AM Rolf Eike Beer eb@emlix.com wrote:
Am Samstag, 8. Juni 2019, 14:00:34 CEST schrieb Miguel Ojeda:
On Thu, Jun 6, 2019 at 8:59 PM Greg KH greg@kroah.com wrote:
"manually fixing it up" means "hacked it to pieces" to me, I have no idea what the end result really was :)
If someone wants to send me some patches I can actually apply, that would be best...
I will give it a go whenever I get some free time :)
I fear this has never happened, did it?
No. Between summer, holidays and a conference I didn't get to do it.
Done the minimal approach here:
https://github.com/ojeda/linux/commits/compiler-attributes-backport
Tested building a handful of drivers with gcc 4.6.4, 8.3.0 and 9.1.1.
Greg, I could backport the entire compiler_attributes.h, but given this is stable, we are supposed to minimize changes, right?
I tried to imitate what you do in other stable patches, please check the Cc:, Link: lines and the "commit ... upstream" just in case.
HTH,
Cheers, Miguel
On Fri, Aug 02, 2019 at 12:19:33PM +0200, Miguel Ojeda wrote:
On Fri, Aug 2, 2019 at 10:17 AM Rolf Eike Beer eb@emlix.com wrote:
Am Samstag, 8. Juni 2019, 14:00:34 CEST schrieb Miguel Ojeda:
On Thu, Jun 6, 2019 at 8:59 PM Greg KH greg@kroah.com wrote:
"manually fixing it up" means "hacked it to pieces" to me, I have no idea what the end result really was :)
If someone wants to send me some patches I can actually apply, that would be best...
I will give it a go whenever I get some free time :)
I fear this has never happened, did it?
No. Between summer, holidays and a conference I didn't get to do it.
Done the minimal approach here:
https://github.com/ojeda/linux/commits/compiler-attributes-backport
Tested building a handful of drivers with gcc 4.6.4, 8.3.0 and 9.1.1.
Greg, I could backport the entire compiler_attributes.h, but given this is stable, we are supposed to minimize changes, right?
I tried to imitate what you do in other stable patches, please check the Cc:, Link: lines and the "commit ... upstream" just in case.
If only those 2 patches are all that is needed, nice! I'll gladly take them, can you send them to me (and cc: the stable list) in email so I can queue them up for the next round of releases after this one?
thanks,
greg k-h
On Fri, Aug 2, 2019 at 12:33 PM Greg KH greg@kroah.com wrote:
On Fri, Aug 02, 2019 at 12:19:33PM +0200, Miguel Ojeda wrote:
On Fri, Aug 2, 2019 at 10:17 AM Rolf Eike Beer eb@emlix.com wrote:
Am Samstag, 8. Juni 2019, 14:00:34 CEST schrieb Miguel Ojeda:
On Thu, Jun 6, 2019 at 8:59 PM Greg KH greg@kroah.com wrote:
"manually fixing it up" means "hacked it to pieces" to me, I have no idea what the end result really was :)
If someone wants to send me some patches I can actually apply, that would be best...
I will give it a go whenever I get some free time :)
I fear this has never happened, did it?
No. Between summer, holidays and a conference I didn't get to do it.
Done the minimal approach here:
https://github.com/ojeda/linux/commits/compiler-attributes-backport
Tested building a handful of drivers with gcc 4.6.4, 8.3.0 and 9.1.1.
Greg, I could backport the entire compiler_attributes.h, but given this is stable, we are supposed to minimize changes, right?
I tried to imitate what you do in other stable patches, please check the Cc:, Link: lines and the "commit ... upstream" just in case.
If only those 2 patches are all that is needed, nice! I'll gladly take them, can you send them to me (and cc: the stable list) in email so I can queue them up for the next round of releases after this one?
Done! Please double check, since I am not used to send to stable.
Cheers, Miguel
On Fri, Aug 02, 2019 at 12:39:38PM +0200, Miguel Ojeda wrote:
On Fri, Aug 2, 2019 at 12:33 PM Greg KH greg@kroah.com wrote:
On Fri, Aug 02, 2019 at 12:19:33PM +0200, Miguel Ojeda wrote:
On Fri, Aug 2, 2019 at 10:17 AM Rolf Eike Beer eb@emlix.com wrote:
Am Samstag, 8. Juni 2019, 14:00:34 CEST schrieb Miguel Ojeda:
On Thu, Jun 6, 2019 at 8:59 PM Greg KH greg@kroah.com wrote:
"manually fixing it up" means "hacked it to pieces" to me, I have no idea what the end result really was :)
If someone wants to send me some patches I can actually apply, that would be best...
I will give it a go whenever I get some free time :)
I fear this has never happened, did it?
No. Between summer, holidays and a conference I didn't get to do it.
Done the minimal approach here:
https://github.com/ojeda/linux/commits/compiler-attributes-backport
Tested building a handful of drivers with gcc 4.6.4, 8.3.0 and 9.1.1.
Greg, I could backport the entire compiler_attributes.h, but given this is stable, we are supposed to minimize changes, right?
I tried to imitate what you do in other stable patches, please check the Cc:, Link: lines and the "commit ... upstream" just in case.
If only those 2 patches are all that is needed, nice! I'll gladly take them, can you send them to me (and cc: the stable list) in email so I can queue them up for the next round of releases after this one?
Done! Please double check, since I am not used to send to stable.
Yes, got them, thanks! I'll queue them up next week for the next round of releases and let you know if I have any problems with them.
thanks again,
greg k-h
On Fri, Aug 2, 2019 at 12:33 PM Greg KH greg@kroah.com wrote:
On Fri, Aug 02, 2019 at 12:19:33PM +0200, Miguel Ojeda wrote:
On Fri, Aug 2, 2019 at 10:17 AM Rolf Eike Beer eb@emlix.com wrote:
Am Samstag, 8. Juni 2019, 14:00:34 CEST schrieb Miguel Ojeda:
On Thu, Jun 6, 2019 at 8:59 PM Greg KH greg@kroah.com wrote:
"manually fixing it up" means "hacked it to pieces" to me, I have no idea what the end result really was :)
If someone wants to send me some patches I can actually apply, that would be best...
I will give it a go whenever I get some free time :)
I fear this has never happened, did it?
No. Between summer, holidays and a conference I didn't get to do it.
Done the minimal approach here:
https://github.com/ojeda/linux/commits/compiler-attributes-backport
Tested building a handful of drivers with gcc 4.6.4, 8.3.0 and 9.1.1.
Greg, I could backport the entire compiler_attributes.h, but given this is stable, we are supposed to minimize changes, right?
I tried to imitate what you do in other stable patches, please check the Cc:, Link: lines and the "commit ... upstream" just in case.
If only those 2 patches are all that is needed, nice! I'll gladly take them, can you send them to me (and cc: the stable list) in email so I can queue them up for the next round of releases after this one?
At least for that particular problem, yeah -- I haven't done a full allmod.
By the way, I just checked 4.14.y and I noticed you had already backported it, although going for another solution:
+#if GCC_VERSION >= 90100 +#define __copy(symbol) __attribute__((__copy__(symbol))) +#endif
and then:
+#ifndef __copy +# define __copy(symbol) +#endif
Cheers, Miguel
On Fri, Aug 02, 2019 at 01:00:30PM +0200, Miguel Ojeda wrote:
On Fri, Aug 2, 2019 at 12:33 PM Greg KH greg@kroah.com wrote:
On Fri, Aug 02, 2019 at 12:19:33PM +0200, Miguel Ojeda wrote:
On Fri, Aug 2, 2019 at 10:17 AM Rolf Eike Beer eb@emlix.com wrote:
Am Samstag, 8. Juni 2019, 14:00:34 CEST schrieb Miguel Ojeda:
On Thu, Jun 6, 2019 at 8:59 PM Greg KH greg@kroah.com wrote:
"manually fixing it up" means "hacked it to pieces" to me, I have no idea what the end result really was :)
If someone wants to send me some patches I can actually apply, that would be best...
I will give it a go whenever I get some free time :)
I fear this has never happened, did it?
No. Between summer, holidays and a conference I didn't get to do it.
Done the minimal approach here:
https://github.com/ojeda/linux/commits/compiler-attributes-backport
Tested building a handful of drivers with gcc 4.6.4, 8.3.0 and 9.1.1.
Greg, I could backport the entire compiler_attributes.h, but given this is stable, we are supposed to minimize changes, right?
I tried to imitate what you do in other stable patches, please check the Cc:, Link: lines and the "commit ... upstream" just in case.
If only those 2 patches are all that is needed, nice! I'll gladly take them, can you send them to me (and cc: the stable list) in email so I can queue them up for the next round of releases after this one?
At least for that particular problem, yeah -- I haven't done a full allmod.
By the way, I just checked 4.14.y and I noticed you had already backported it, although going for another solution:
+#if GCC_VERSION >= 90100 +#define __copy(symbol) __attribute__((__copy__(symbol))) +#endif
and then:
+#ifndef __copy +# define __copy(symbol) +#endif
But it still doesn't work for 4.14.y and 4.19.y, so we are probably missing something there. So if you want to fix that up, I'd appreciate patches to do so :)
thanks,
greg k-h
On Fri, Aug 2, 2019 at 1:25 PM Greg KH greg@kroah.com wrote:
But it still doesn't work for 4.14.y and 4.19.y, so we are probably missing something there. So if you want to fix that up, I'd appreciate patches to do so :)
Hm... For 4.19.y and 4.14.y, I cannot see the init/exit_module warnings under GCC 9.1.1. What do you mean it does not work?
Cheers, Miguel
On Fri, Aug 02, 2019 at 03:01:13PM +0200, Miguel Ojeda wrote:
On Fri, Aug 2, 2019 at 1:25 PM Greg KH greg@kroah.com wrote:
But it still doesn't work for 4.14.y and 4.19.y, so we are probably missing something there. So if you want to fix that up, I'd appreciate patches to do so :)
Hm... For 4.19.y and 4.14.y, I cannot see the init/exit_module warnings under GCC 9.1.1. What do you mean it does not work?
I see a ton of warnings on those kernels today. I'll look into it next week after I apply your patches to see what's missing.
thanks,
greg k-h
On Fri, Aug 2, 2019 at 5:56 PM Greg KH greg@kroah.com wrote:
I see a ton of warnings on those kernels today. I'll look into it next week after I apply your patches to see what's missing.
Yeah, the objtool ones -- I thought you were referring to the -Wmissing-attributes that Rolf asked about (I am not sure why Rolf has those as -Werror rather than warnings, though).
I can take a look at the objtool ones and see if applying some of the patches helps, although I have never looked into how objtool works, so no promises :)
Cheers, Miguel
On Fri, Aug 02, 2019 at 06:55:53PM +0200, Miguel Ojeda wrote:
On Fri, Aug 2, 2019 at 5:56 PM Greg KH greg@kroah.com wrote:
I see a ton of warnings on those kernels today. I'll look into it next week after I apply your patches to see what's missing.
Yeah, the objtool ones -- I thought you were referring to the -Wmissing-attributes that Rolf asked about (I am not sure why Rolf has those as -Werror rather than warnings, though).
I can take a look at the objtool ones and see if applying some of the patches helps, although I have never looked into how objtool works, so no promises :)
I think I got it working now, all looks good for 4.9.y, 4.14.y and 4.19.y for gcc9 so far. I'll leave 4.4.y alone :)
thanks,
greg k-h
On Mon, Aug 5, 2019 at 1:55 PM Greg KH greg@kroah.com wrote:
I think I got it working now, all looks good for 4.9.y, 4.14.y and 4.19.y for gcc9 so far. I'll leave 4.4.y alone :)
You are welcome! I am glad we can now use gcc 9 easily. I will be keeping a look into gcc 10. :)
Cheers, Miguel
Am Donnerstag, 6. Juni 2019, 20:59:00 CEST schrieb Greg KH:
On Thu, Jun 06, 2019 at 08:25:28PM +0200, Miguel Ojeda wrote:
On Thu, Jun 6, 2019 at 5:29 PM Greg KH greg@kroah.com wrote:
And if you want this, you should look at how the backports to 4.14.y worked, they did not include a3f8a30f3f00 ("Compiler Attributes: use feature checks instead of version checks"), as that gets really messy...
I am confused -- I interpreted Rolf's message as reporting that he already successfully built 4.9 by applying a6e60d84989f ("include/linux/module.h: copy __init/__exit attrs to init/cleanup_module") and manually fixing it up. But maybe I am completely wrong... :-)
"manually fixing it up" means "hacked it to pieces" to me, I have no idea what the end result really was :)
If someone wants to send me some patches I can actually apply, that would be best...
Hi all,
the patch I actually used was this:
diff --git a/include/linux/module.h b/include/linux/module.h index 8fa38d3e7538..f5bc4c046461 100644 --- a/include/linux/module.h +++ b/include/linux/module.h @@ -129,13 +129,13 @@ extern void cleanup_module(void); #define module_init(initfn) \ static inline initcall_t __maybe_unused __inittest(void) \ { return initfn; } \ - int init_module(void) __attribute__((alias(#initfn))); + int init_module(void) __attribute__((__copy__(initfn))) __attribute__((alias(#initfn)));
/* This is only required if you want to be unloadable. */ #define module_exit(exitfn) \ static inline exitcall_t __maybe_unused __exittest(void) \ { return exitfn; } \ - void cleanup_module(void) __attribute__((alias(#exitfn))); + void cleanup_module(void) __attribute__((__copy__(exitfn))) __attribute__((alias(#exitfn)));
#endif
So the final question is: do we want 4.9.x to be buildable with gcc 9.x? If yes then we can probably get this patches into shape.
Eike
On Wed, Jun 12, 2019 at 09:19:15AM +0200, Rolf Eike Beer wrote:
Am Donnerstag, 6. Juni 2019, 20:59:00 CEST schrieb Greg KH:
On Thu, Jun 06, 2019 at 08:25:28PM +0200, Miguel Ojeda wrote:
On Thu, Jun 6, 2019 at 5:29 PM Greg KH greg@kroah.com wrote:
And if you want this, you should look at how the backports to 4.14.y worked, they did not include a3f8a30f3f00 ("Compiler Attributes: use feature checks instead of version checks"), as that gets really messy...
I am confused -- I interpreted Rolf's message as reporting that he already successfully built 4.9 by applying a6e60d84989f ("include/linux/module.h: copy __init/__exit attrs to init/cleanup_module") and manually fixing it up. But maybe I am completely wrong... :-)
"manually fixing it up" means "hacked it to pieces" to me, I have no idea what the end result really was :)
If someone wants to send me some patches I can actually apply, that would be best...
Hi all,
the patch I actually used was this:
diff --git a/include/linux/module.h b/include/linux/module.h index 8fa38d3e7538..f5bc4c046461 100644 --- a/include/linux/module.h +++ b/include/linux/module.h @@ -129,13 +129,13 @@ extern void cleanup_module(void); #define module_init(initfn) \ static inline initcall_t __maybe_unused __inittest(void) \ { return initfn; } \
- int init_module(void) __attribute__((alias(#initfn)));
- int init_module(void) __attribute__((__copy__(initfn))) __attribute__((alias(#initfn)));
/* This is only required if you want to be unloadable. */ #define module_exit(exitfn) \ static inline exitcall_t __maybe_unused __exittest(void) \ { return exitfn; } \
- void cleanup_module(void) __attribute__((alias(#exitfn)));
- void cleanup_module(void) __attribute__((__copy__(exitfn))) __attribute__((alias(#exitfn)));
#endif
So the final question is: do we want 4.9.x to be buildable with gcc 9.x? If yes then we can probably get this patches into shape.
Eventually, yes, we (or at least I) will want to build 4.9.x with gcc 9.x. We went through this same process for gcc 8.x as all of my builder test machines switched their default version of gcc...
thanks,
greg k-h
linux-stable-mirror@lists.linaro.org
-
Greg KH -
Miguel Ojeda -
Rolf Eike Beer