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

[FX Coudert <fxcoudert@gmail.com>]

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?


> 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).


> Was there ever an attempt to provide a "generic" trampoline driven by
> a more complex descriptor?
> (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. 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.


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