[Bug target/113855] New: [14 Regression] __gcc_nested_func_ptr_{created,deleted} exports from 32-bit libgcc_s.so.1

[Bug target/113855] New: [14 Regression] __gcc_nested_func_ptr_{created,deleted} exports from 32-bit libgcc_s.so.1

[jakub at gcc dot gnu.org]

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

            Bug ID: 113855
           Summary: [14 Regression]
                    __gcc_nested_func_ptr_{created,deleted} exports from
                    32-bit libgcc_s.so.1
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

Seems when I build i686-linux trunk gcc,
__gcc_nested_func_ptr_{created,deleted}@@GCC_14.0.0 is not exported from
libgcc_s.so.1,
while when I build x86_64-linux trunk gcc,
__gcc_nested_func_ptr_{created,deleted}@@GCC_14.0.0
is exported from both 64-bit and 32-bit libgcc.
That looks wrong.
I guess given the trampoline_insns content it can't really work on ia32,
wonder if the whole file shouldn't be wrapped with #ifndef __x86_64__ or
similar for now.

[Bug target/113855] [14 Regression] __gcc_nested_func_ptr_{created,deleted} exports from 32-bit libgcc_s.so.1

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |14.0
           Priority|P3                          |P1
           Keywords|                            |ABI
                 CC|                            |iains at gcc dot gnu.org

[Bug target/113855] [14 Regression] __gcc_nested_func_ptr_{created,deleted} exports from 32-bit libgcc_s.so.1

[iains at gcc dot gnu.org]

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

--- Comment #1 from Iain Sandoe <iains at gcc dot gnu.org> ---
I was looking at making an i686 impl.

but we could also do as you suggest for gcc-14.

[Bug target/113855] [14 Regression] __gcc_nested_func_ptr_{created,deleted} exports from 32-bit libgcc_s.so.1

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Guess an ia32 implementation would be even better, shouldn't be that hard.

[Bug target/113855] [14 Regression] __gcc_nested_func_ptr_{created,deleted} exports from 32-bit libgcc_s.so.1

[iains at gcc dot gnu.org]

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

--- Comment #3 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #2)
> Guess an ia32 implementation would be even better, shouldn't be that hard.


I have a draft on one of my machines, I'll post it here tomorrow.

[Bug target/113855] [14 Regression] __gcc_nested_func_ptr_{created,deleted} exports from 32-bit libgcc_s.so.1

[iains at gcc dot gnu.org]

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

--- Comment #4 from Iain Sandoe <iains at gcc dot gnu.org> ---
Created attachment 57378
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57378&action=edit
patch under test

This implements the common case for an i386 trampoline (and, in this respect,
matches the expectations for x86_64 and aarch64).

---------- to explain the "common case" comment.

We still have work to do to generalise the heap trampoline implementation;

Several platforms have multiple trampoline implementations that can depend on
optimisations or protections.

At present, I considered:
 (1) - having the heap trampoline impl just deal with managing the storage.
 -- one would call a builtin to obtain a writeable trampoline area
 -- one would then use the inline existing trampoline impl to populate that
 -- one would then call to the heap management to apply conditions to make the
written trampoline executable (since most security models do not allow
writable+executable at the same time).

 -- although this model re-uses the existing trampoline in-line code-gen, I'm
not in favour of it (a) it means two calls to libgcc_s for each case + (b) the
inline code-gen is replicated which appears pointless code bloat since we have
failed to avoid an out of line function call already.

 (2) - having the caller of __gcc_heap_trampoline_created () pass sufficient
information for that function to alter the flavour of trampoline as needed.

  ( i) - we could add an extra argument to communicate this information (it
could be as simple as an enum, probably).
  (ii) - We could re-use the third argument (which is a pointer to a pointer)
to pass in a pointer to the data (or nullptr, for 'default' perhaps)

  -- in either case we need a new target hook that returns the relevant enum
(or other target-private data) to be passed to __gcc_heap_trampoline_created().

 (3) - perhaps using the existing in-line codegen into a scratch space and
passing that to __gcc_heap_trampoline_created ()
   -- not keen on this because:
    (a) the same comment about in-line code + out of line call.
    (b) if the trampoline uses relative branches (like the i386 common case)
then those need to be relocated, which then means that the
__gcc_heap_trampoline_created routine would have to match the relevant patterns
and do the relocation.

so, at the moment, (2) is my favoured approach - but more thinking might being
other ideas.

[Bug target/113855] [14 Regression] __gcc_nested_func_ptr_{created,deleted} exports from 32-bit libgcc_s.so.1

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Comment on attachment 57378
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57378
patch under test

s/jumpl/jmpl/

[Bug target/113855] [14 Regression] __gcc_nested_func_ptr_{created,deleted} exports from 32-bit libgcc_s.so.1

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Iain D Sandoe <iains@gcc.gnu.org>:

https://gcc.gnu.org/g:5e39897ee2c73938fa940c4792d987608aeeebcd

commit r14-8931-g5e39897ee2c73938fa940c4792d987608aeeebcd
Author: Iain Sandoe <iain@sandoe.co.uk>
Date:   Sat Feb 10 14:44:41 2024 +0000

    x86, libgcc: Implement ia32 basic heap trampoline [PR113855].

    The initial heap trampoline implementation was targeting 64b
    platforms.  As the PR demonstrates this creates an issue where it
    is expected that the same symbols are exported for 32 and 64b.

    Rather than conditionalize the exports and code-gen on x86_64,
    this patch provides a basic implementation of the IA32 trampoline.

    This also avoids potential user confusion, when a 32b target has
    64b multilibs, and vice versa; which is the case for Darwin.

            PR target/113855

    gcc/ChangeLog:

            * config/i386/darwin.h (DARWIN_HEAP_T_LIB): Moved to be
            available to all sub-targets.
            * config/i386/darwin32-biarch.h (DARWIN_HEAP_T_LIB): Delete.
            * config/i386/darwin64-biarch.h (DARWIN_HEAP_T_LIB): Delete.

    libgcc/ChangeLog:

            * config.host: Add trampoline support to x?86-linux.
            * config/i386/heap-trampoline.c (trampoline_insns): Provide
            a variant for IA32.
            (union ix86_trampoline): Likewise.
            (__gcc_nested_func_ptr_created): Implement a basic trampoline
            for IA32.

[Bug target/113855] [14 Regression] __gcc_nested_func_ptr_{created,deleted} exports from 32-bit libgcc_s.so.1

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I think we should keep this open until the -mx32 stuff is resolved, then it can
be closed.

[Bug target/113855] [14 Regression] __gcc_nested_func_ptr_{created,deleted} exports from 32-bit libgcc_s.so.1

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by H.J. Lu <hjl@gcc.gnu.org>:

https://gcc.gnu.org/g:67ce5c97167a60cb845b9f3f55186c00fc5df078

commit r14-8990-g67ce5c97167a60cb845b9f3f55186c00fc5df078
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Tue Feb 13 08:40:52 2024 -0800

    x86: Support x32 and IBT in heap trampoline

    Add x32 and IBT support to x86 heap trampoline implementation with a
    testcase.

    2024-02-13  Jakub Jelinek  <jakub@redhat.com>
                H.J. Lu  <hjl.tools@gmail.com>

    libgcc/

            PR target/113855
            * config/i386/heap-trampoline.c (trampoline_insns): Add IBT
            support and pad to the multiple of 4 bytes.  Use movabsq
            instead of movabs in comments.  Add -mx32 variant.

    gcc/testsuite/

            PR target/113855
            * gcc.dg/heap-trampoline-1.c: New test.
            * lib/target-supports.exp (check_effective_target_heap_trampoline):
            New.

[Bug target/113855] [14 Regression] __gcc_nested_func_ptr_{created,deleted} exports from 32-bit libgcc_s.so.1

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

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

--- Comment #9 from H.J. Lu <hjl.tools at gmail dot com> ---
Fixed.