Am Mittwoch, dem 19.07.2023 um 15:23 +0100 schrieb Iain Sandoe: > Hi Martin, > > > On 19 Jul 2023, at 11:43, Martin Uecker via Gcc-patches > > <gcc-patches@gcc.gnu.org> wrote: > > > > Am Mittwoch, dem 19.07.2023 um 10:29 +0100 schrieb Iain Sandoe: > > > > > On 19 Jul 2023, at 10:04, Martin Uecker <ma.uec...@gmail.com> > > > > wrote: > > > > > > > > > On 17 Jul 2023, > > > > > > > > > > > > > > > > You mention setjmp/longjmp - on darwin and other platforms > > > > > requiring > > > > > > > non-stack based trampolines > > > > > > > does the system runtime provide means to deal with this issue > > > > > > > like > > > > > an > > > > > > > alternate allocation method > > > > > > > or a way to register cleanup? > > > > > > > > > > > > There is an alternate mechanism relying on system libraries > > > > > > that is > > > > > possible on darwin specifically (I don’t know for other targets) > > > > > but > > > > > it will only work for signed binaries, and would require us to > > > > > codesign everything produced by gcc. During development, it was > > > > > deemed too big an ask and the current strategy was chosen (Iain > > > > > can > > > > > surely add more background on that if needed). > > > > > > > > > > I do not think that this solves the setjump/longjump issue - > > > > > since > > > > > there’s still a notional allocation that takes place (it’s just > > > > > that > > > > > the mechanism for determining permissions is different). > > > > > > > > > > It is also a big barrier for the general user - and prevents > > > > > normal > > > > > folks from distributing GCC - since codesigning requires an > > > > > external > > > > > certificate (i.e. I would really rather avoid it). > > > > > > > > > > > > Was there ever an attempt to provide a "generic" trampoline > > > > > > > driven > > > > > by > > > > > > > a more complex descriptor? > > > > > > > My own opinion is that executable stack should go away on all > > > > > targets at some point, so a truly generic solution to the problem > > > > > would be great. > > > > > > > > > > indeed it would. > > > > > > > I think we need a solution rather sooner than later on all archs. > > > > > > AFAICS the heap-based trampolines can work for any arch**, this > > > issue is about > > > system security policy, rather than arch, specifically? > > > > > > It seems to me that for any system security policy that permits JIT, > > > (but not > > > executable stack) the heap-based trampolines are viable. > > > > I agree. > > > > BTW; One option we discussed before, was to map a page with > > pre-allocated trampolines, which look up the address of > > a callee and the static chain in a table based on its own > > address. Then no code generation is involved. > > That reads similar to the scheme Apple have implemented for libobjc and > libffi. > In order to be extensible (i.e to allow the table to grow at runtime), it > means > having some loadable executable object; if that is implemented in a way shared > between users (delivered as part of the implementation) then, for Darwin at > least, it must be codesigned - which is somewhere I really want to avoid going > with GCC. > > > The difficult part is avoiding leaks with longjmp / setjmp. > > One idea was to have a shadow stack consisting of the > > pre-allocated trampolines, but this probably causes other > > issues... > > With a per-thread table, I *think* for most targets, we discussed in the team > maintaining a ’tide mark’ of the stack as part of the saved data in the > trampoline (not used as part of the execution, but only as part of the > allocation > mangement)… but .. > > > I wonder how difficult it is to have longjmp / setjmp walk > > the stack in C? This would also be useful for C++ > > interoperability and to free heap-allocated VLAs. > > … this would be a better solution (as we can see trampolines are a small > leak c.f. the general uses)? > > > As a user of nested functions, from my side it would also > > ok to simply add a wide function pointer type that contains > > address + static chain. This would require changing code, > > but would also work with Clang's blocks and solve other > > language interoperability problems, while avoiding all > > existing ABI issues. > > How does that work when passing a callback to libc (e.g. qsort?)
This would not work because it would be an ABI change, but because it solves a general problem and would plug a major language interoperability issue between C and all languages that have callable objects or nested functions, I think one could make a good case that such an extension goes into C standard together with a set of enhanced interfaces. I have an initial proposal here: http://www2.open-std.org/JTC1/SC22/WG14/www/docs/n2787.pdf One could combine this with other solutions where a user created trampoline with explicit allocation and deallocation calls such a wide pointer, i.e. one has a library function that takes a wide pointer and returns regular function pointer that points to an allocated trampoline the user has to free explicitely. BTW: having a GCC builtin that returns the static chain for a nested function so that it can later be used with __builtin_call_with_static_chain would also be helpful. > (Implementing Clang’s blocks is also on my TODO, but a different discussion > ;)) It would be nice to make this compatible. Martin > > > This seems to be a useful step forward; and we can add some other > > > mechanism to the flag’s supported list if someone develops one? > > > > I think it is a useful step forward. > > Assembled maintainers, do you think this is OK for trunk given the various > discussions above? > > thanks > Iain >
