[Bug target/113855] [14 Regression] __gcc_nested_func_ptr_{created,deleted} exports from 32-bit libgcc_s.so.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113855 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #9 from H.J. Lu --- Fixed.
[Bug target/113855] [14 Regression] __gcc_nested_func_ptr_{created,deleted} exports from 32-bit libgcc_s.so.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113855 --- Comment #8 from GCC Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:67ce5c97167a60cb845b9f3f55186c00fc5df078 commit r14-8990-g67ce5c97167a60cb845b9f3f55186c00fc5df078 Author: H.J. Lu 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 H.J. Lu 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113855 --- Comment #7 from Jakub Jelinek --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113855 --- Comment #6 from GCC Commits --- The master branch has been updated by Iain D Sandoe : https://gcc.gnu.org/g:5e39897ee2c73938fa940c4792d987608aeeebcd commit r14-8931-g5e39897ee2c73938fa940c4792d987608aeeebcd Author: Iain Sandoe Date: Sat Feb 10 14:44:41 2024 + 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113855 --- Comment #5 from Jakub Jelinek --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113855 --- Comment #4 from Iain Sandoe --- Created attachment 57378 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57378=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113855 --- Comment #3 from Iain Sandoe --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113855 --- Comment #2 from Jakub Jelinek --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113855 --- Comment #1 from Iain Sandoe --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113855 Jakub Jelinek changed: What|Removed |Added Target Milestone|--- |14.0 Priority|P3 |P1 Keywords||ABI CC||iains at gcc dot gnu.org
