Linux 4.9.180 build fails with gcc 9 and 'cleanup_module' specifies less restrictive attribute than its target …
Subsystems (2)
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
Signature · 7 lines
Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source
Quoted 94 lines · Rolf Eike Beer
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); | ^~~~~~~~~~~~~~~~~~~~~~
Quoted 7 lines
So this needs
a6e60d84989fa0e91db7f236eda40453b0e44afa, which needsc0d9782f5b6d7157635ae2fd782a4b27d55a6013, which can't be applied cleanly becausea3f8a30f3f0079c7edfc72e329eee8594fb3e3cbis missing in 4.9.I have applied
a6e60d84989fa0e91db7f236eda40453b0e44afaand 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
Quoted 99 lines · Greg KH
Quoted 98 lines · Rolf Eike Beer
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 needsc0d9782f5b6d7157635ae2fd782a4b27d55a6013, which can't be applied cleanly becausea3f8a30f3f0079c7edfc72e329eee8594fb3e3cbis missing in 4.9.
Quoted 8 lines
Quoted 3 lines
I have applied
a6e60d84989fa0e91db7f236eda40453b0e44afaand 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
Quoted 4 lines · Greg KH
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
Quoted 11 lines · Miguel Ojeda
Quoted 4 lines · Greg KH
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 toinit/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
Quoted 6 lines · Greg KH
"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:
Quoted 8 lines · Greg KH
Quoted 5 lines
"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
Signature · 7 lines
Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source
Quoted 11 lines · Rolf Eike Beer
Am Samstag, 8. Juni 2019, 14:00:34 CEST schrieb Miguel Ojeda:
Quoted 8 lines · Greg KH
Quoted 5 lines
"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
Quoted 6 lines · Rolf Eike Beer
Am Samstag, 8. Juni 2019, 14:00:34 CEST schrieb Miguel Ojeda:
Quoted 4 lines · Greg KH
Quoted 3 lines
"manually fixing it up" means "hacked it to pieces" to me, I have no idea what the end result really was :)
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines
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
Quoted 20 lines · Miguel Ojeda
Quoted 6 lines · Rolf Eike Beer
Am Samstag, 8. Juni 2019, 14:00:34 CEST schrieb Miguel Ojeda:
Quoted 4 lines · Greg KH
Quoted 3 lines
"manually fixing it up" means "hacked it to pieces" to me, I have no idea what the end result really was :)
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines
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
Quoted 7 lines
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
Quoted 27 lines · Greg KH
Quoted 25 lines · Miguel Ojeda
Quoted 6 lines · Rolf Eike Beer
Am Samstag, 8. Juni 2019, 14:00:34 CEST schrieb Miguel Ojeda:
Quoted 4 lines · Greg KH
Quoted 3 lines
"manually fixing it up" means "hacked it to pieces" to me, I have no idea what the end result really was :)
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines
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?
Quoted 6 lines
Quoted 2 lines
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
Quoted 28 lines · Miguel Ojeda
Quoted 27 lines · Greg KH
Quoted 25 lines · Miguel Ojeda
Quoted 6 lines · Rolf Eike Beer
Am Samstag, 8. Juni 2019, 14:00:34 CEST schrieb Miguel Ojeda:
Quoted 4 lines · Greg KH
Quoted 3 lines
"manually fixing it up" means "hacked it to pieces" to me, I have no idea what the end result really was :)
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines
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?
Quoted 8 lines
Quoted 6 lines
Quoted 2 lines
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
Quoted 27 lines · Greg KH
Quoted 25 lines · Miguel Ojeda
Quoted 6 lines · Rolf Eike Beer
Am Samstag, 8. Juni 2019, 14:00:34 CEST schrieb Miguel Ojeda:
Quoted 4 lines · Greg KH
Quoted 3 lines
"manually fixing it up" means "hacked it to pieces" to me, I have no idea what the end result really was :)
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines
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?
Quoted 6 lines
Quoted 2 lines
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
Quoted 46 lines · Miguel Ojeda
Quoted 27 lines · Greg KH
Quoted 25 lines · Miguel Ojeda
Quoted 6 lines · Rolf Eike Beer
Am Samstag, 8. Juni 2019, 14:00:34 CEST schrieb Miguel Ojeda:
Quoted 4 lines · Greg KH
Quoted 3 lines
"manually fixing it up" means "hacked it to pieces" to me, I have no idea what the end result really was :)
Quoted 6 lines
Quoted 4 lines
Quoted 2 lines
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?Quoted 6 lines
Quoted 2 lines
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:
(quoted diff) +3
-0+#if GCC_VERSION >= 90100 +#define __copy(symbol) __attribute__((__copy__(symbol))) +#endifand then:
Review
Quoted 3 lines
(quoted diff) +3
-0+#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
Quoted 4 lines · Greg KH
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
Quoted 8 lines · Miguel Ojeda
Quoted 4 lines · Greg KH
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_modulewarnings 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
Quoted 3 lines · Greg KH
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
Quoted 5 lines · Miguel Ojeda
Quoted 3 lines · Greg KH
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.
Quoted 7 lines
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
Quoted 3 lines · Greg KH
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:
Quoted 12 lines · Miguel Ojeda
Quoted 10 lines · Greg KH
Quoted 3 lines
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 toinit/cleanup_module") and manually fixing it up. But maybe I am completely wrong... :-)
Quoted 5 lines
"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:
include/linux/module.h +2 -2
@@ -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
Signature · 7 lines
Rolf Eike Beer, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax +49 551 30664-11 Gothaer Platz 3, 37083 Göttingen, Germany Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 Geschäftsführung: Heike Jordan, Dr. Uwe Kracke – Ust-IdNr.: DE 205 198 055 emlix - smart embedded open source
Quoted 44 lines · Rolf Eike Beer
Am Donnerstag, 6. Juni 2019, 20:59:00 CEST schrieb Greg KH:
Quoted 12 lines · Miguel Ojeda
Quoted 10 lines · Greg KH
Quoted 3 lines
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 toinit/cleanup_module") and manually fixing it up. But maybe I am completely wrong... :-)Quoted 5 lines
"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:
include/linux/module.h +2
-2@@ -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
Quoted 2 lines
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