Re: [PATCH] core: Support heap-based trampolines

[Martin Uecker <ma.uecker@gmail.com>]

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.uecker@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
>