> On 17 Jul 2023, at 07:43, FX Coudert <fxcoud...@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.
>
>
