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

[Iain Sandoe <iain@sandoe.co.uk>]

> On 17 Jul 2023, at 07:43, FX Coudert <fxcoudert@gmail.com> wrote:
> 
> Hi,
> 
>> Since this affects the ABI of libgcc I think we don't want that part
>> to be user configurable but rather determined by
>> some static list of targets that opt-in to this config.
> 
> If I do that, do the Linux maintainers want Linux in or out?

Presumably that can be a target define, and can be opted in/out in libgcc/config.host (given that the target maintainer also needs to provide the builtins).

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

We did look at the “unused address bits” mechanism that Ada has used - but that is not really available to a non-private ABI (unless the system vendor agrees to change ABI to leave a bit spare) for the base arch either the bits are not there (e.g. X86) or reserved (e.g. AArch64).

Andrew Burgess did the original work he might have comments on alternatives we tried

>> (well, it could be a bytecode interpreter and the trampoline being
>> bytecode on the stack?!)
> 
> 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.

> Having something that works reliably across all targets, like you suggest, is a much bigger project that this patch, and I am not aware of any previous attempt at it.

The bytecode interpreter idea is neat;  (a) I wonder about performance and (b) it is, as FX says, a bigger project - certainly bigger than the voluntary Darwin time available :(

Iain

> 
> 
>> Otherwise I suggest to split the patch into libgcc, generic and target parts.
> 
>