[Bug plugins/108634] [13 regression] 'undefined symbol: tree_code_type' when building kernel GCC plugins since r13-5431-gb0241ce6e37031
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108634
--- Comment #7 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:be6195c7e7adc7465214a0dc347c592822713c3f
commit r13-6730-gbe6195c7e7adc7465214a0dc347c592822713c3f
Author: Jakub Jelinek
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
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.
[Bug plugins/108634] [13 regression] 'undefined symbol: tree_code_type' when building kernel GCC plugins since r13-5431-gb0241ce6e37031
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108634
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:4c599ae6e081496466cada6f97b0d4687a6d765a
commit r13-6577-g4c599ae6e081496466cada6f97b0d4687a6d765a
Author: Jakub Jelinek
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
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.
[Bug plugins/108634] [13 regression] 'undefined symbol: tree_code_type' when building kernel GCC plugins since r13-5431-gb0241ce6e37031
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108634 --- Comment #5 from Jakub Jelinek --- https://gcc.gnu.org/pipermail/gcc-patches/2023-February/611180.html
[Bug plugins/108634] [13 regression] 'undefined symbol: tree_code_type' when building kernel GCC plugins since r13-5431-gb0241ce6e37031
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108634 --- Comment #4 from Sam James --- Patch sent to kernel: https://lore.kernel.org/linux-hardening/20230201230009.2252783-1-...@gentoo.org/T/#u
[Bug plugins/108634] [13 regression] 'undefined symbol: tree_code_type' when building kernel GCC plugins since r13-5431-gb0241ce6e37031
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108634 --- Comment #3 from Andrew Pinski --- Not a GCC bug. plugins need to compiled with the same C++ settings as what GCC was compiled with.
[Bug plugins/108634] [13 regression] 'undefined symbol: tree_code_type' when building kernel GCC plugins since r13-5431-gb0241ce6e37031
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108634 Sam James changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from Sam James --- 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.
[Bug plugins/108634] [13 regression] 'undefined symbol: tree_code_type' when building kernel GCC plugins since r13-5431-gb0241ce6e37031
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108634 --- Comment #1 from Arsen Arsenović --- 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
