When building kernel 6.1.9: ``` cc1: error: cannot load plugin ./scripts/gcc-plugins/randomize_layout_plugin.so: ./scripts/gcc-plugins/randomize_layout_plugin.so: undefined symbol: tree_code_type make[2]: *** [/var/tmp/portage/sys-kernel/gentoo-kernel-6.1.9/work/linux-6.1/scripts/Makefile.build:118: scripts/mod/devicetable-offsets.s] Error 1 make[2]: *** Waiting for unfinished jobs.... make[2]: *** [/var/tmp/portage/sys-kernel/gentoo-kernel-6.1.9/work/linux-6.1/scripts/Makefile.build:250: scripts/mod/empty.o] Error 1 make[1]: *** [/var/tmp/portage/sys-kernel/gentoo-kernel-6.1.9/work/linux-6.1/Makefile:1281: prepare0] Error 2 make[1]: *** Waiting for unfinished jobs.... make: *** [Makefile:231: __sub-make] Error 2 ``` This happens since r13-5431-gb0241ce6e37031 which changes the visibility (thanks to Arsen and pinskia for spotting this) of some of the symbols. It's unclear to me if this is a kernel or GCC issue though (should the kernel be using different methods in its plugin?)
The kernel's using wrong C(XX)FLAGS to compile the plugin. IMO, the best solution would be to dump $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) into a makefile that gets installed, so that plugins can use that
Oh, I see - I missed that bit -- I didn't realise they were passing anything at all. Let's take it up on the kernel side then.
Not a GCC bug. plugins need to compiled with the same C++ settings as what GCC was compiled with.
Patch sent to kernel: https://lore.kernel.org/linux-hardening/20230201230009.2252783-1-sam@gentoo.org/T/#u
https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611180.html
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:4c599ae6e081496466cada6f97b0d4687a6d765a commit r13-6577-g4c599ae6e081496466cada6f97b0d4687a6d765a Author: Jakub Jelinek <jakub@redhat.com> Date: Fri Mar 10 10:38:49 2023 +0100 tree: Use comdat tree_code_{type,length} even for C++11/14 [PR108634] The recent change to undo the tree_code_type/tree_code_length excessive duplication apparently broke building the Linux kernel plugin. While it is certainly desirable that GCC plugins are built with the same compiler as GCC has been built and with the same options (at least the important ones), it might be hard to arrange that, e.g. if gcc is built using a cross-compiler but the plugin then built natively, or GCC isn't bootstrapped for other reasons, or just as in the kernel case they were building the plugin with -std=gnu++11 while the bootstrapped GCC has been built without any such option and so with whatever the compiler defaulted to. For C++17 and later tree_code_{type,length} are UNIQUE symbols with those assembler names, while for C++11/14 they were _ZL14tree_code_type and _ZL16tree_code_length. The following patch uses a comdat var for those even for C++11/14 as suggested by Maciej Cencora. Relying on weak attribute is not an option because not all hosts support it and there are non-GNU system compilers. While we could use it unconditionally, I think defining a template just to make it comdat is weird, and the compiler itself is always built with the same compiler. Plugins, being separate shared libraries, will have a separate copy of the arrays if they are ODR-used in the plugin, so there is not a big deal if e.g. cc1plus uses tree_code_type while plugin uses _ZN19tree_code_type_tmplILi0EE14tree_code_typeE or vice versa. 2023-03-10 Jakub Jelinek <jakub@redhat.com> PR plugins/108634 * tree-core.h (tree_code_type, tree_code_length): For C++11 or C++14, don't declare as extern const arrays. (tree_code_type_tmpl, tree_code_length_tmpl): New types with static constexpr member arrays for C++11 or C++14. * tree.h (TREE_CODE_CLASS): For C++11 or C++14 use tree_code_type_tmpl <0>::tree_code_type instead of tree_code_type. (TREE_CODE_LENGTH): For C++11 or C++14 use tree_code_length_tmpl <0>::tree_code_length instead of tree_code_length. * tree.cc (tree_code_type, tree_code_length): Remove.
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:be6195c7e7adc7465214a0dc347c592822713c3f commit r13-6730-gbe6195c7e7adc7465214a0dc347c592822713c3f Author: Jakub Jelinek <jakub@redhat.com> Date: Fri Mar 17 08:44:19 2023 +0100 gdbhooks: Update gdbhooks.py for recent tree_code_type changes [PR108634] On Mon, Mar 13, 2023 at 04:15:12PM -0400, Jason Merrill wrote: > The r13-6577 change to use tree_code_type_tmpl in earlier C++ dialects broke > gdbhooks, which expects tree_code_type to always be available. I considered > trying to make gdbhooks more robust, but it seemed simpler to define > tree_code_type as a reference to the template. As I said earlier, I think it is better to tweak gdbhooks. The following patch does that, I've tested it now both with gcc 12 and older gcc as system compiler and the patch fixed the latter while keeping the former working as before. 2023-03-17 Jakub Jelinek <jakub@redhat.com> PR plugins/108634 * gdbhooks.py (TreePrinter.to_string): Wrap gdb.parse_and_eval('tree_code_type') in a try block, parse and eval 'tree_code_type_tmpl<0>::tree_code_type' instead if it raises exception. Update comments for the recent tree_code_type changes.