[Bug plugins/108634] New: [13 regression] 'undefined symbol: tree_code_type' when building kernel GCC plugins since r13-5431-gb0241ce6e37031

[Bug plugins/108634] New: [13 regression] 'undefined symbol: tree_code_type' when building kernel GCC plugins since r13-5431-gb0241ce6e37031

[sam at gentoo dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108634

            Bug ID: 108634
           Summary: [13 regression] 'undefined symbol: tree_code_type'
                    when building kernel GCC plugins since
                    r13-5431-gb0241ce6e37031
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: plugins
          Assignee: unassigned at gcc dot gnu.org
          Reporter: sam at gentoo dot org
                CC: jakub at gcc dot gnu.org
  Target Milestone: ---

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?)

[Bug plugins/108634] [13 regression] 'undefined symbol: tree_code_type' when building kernel GCC plugins since r13-5431-gb0241ce6e37031

[arsen at aarsen dot me]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108634

--- Comment #1 from Arsen Arsenović <arsen at aarsen dot me> ---
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

[Bug plugins/108634] [13 regression] 'undefined symbol: tree_code_type' when building kernel GCC plugins since r13-5431-gb0241ce6e37031

[sam at gentoo dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108634

Sam James <sam at gentoo dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #2 from Sam James <sam at gentoo dot org> ---
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

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108634

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
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

[sam at gentoo dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108634

--- Comment #4 from Sam James <sam at gentoo dot org> ---
Patch sent to kernel:
https://lore.kernel.org/linux-hardening/20230201230009.2252783-1-sam@gentoo.org/T/#u

[Bug plugins/108634] [13 regression] 'undefined symbol: tree_code_type' when building kernel GCC plugins since r13-5431-gb0241ce6e37031

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108634

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
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

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108634

--- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
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.

[Bug plugins/108634] [13 regression] 'undefined symbol: tree_code_type' when building kernel GCC plugins since r13-5431-gb0241ce6e37031

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108634

--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
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.