From: Martin Uecker <ma.uecker@gmail.com>
To: gcc-patches@gcc.gnu.org
Cc: iain@sandoe.co.uk
Subject: Re: [PATCH] core: Support heap-based trampolines
Date: Wed, 19 Jul 2023 11:04:35 +0200 [thread overview]
Message-ID: <e8acf6c19ddf24be1e081374838a8455fa886e73.camel@gmail.com> (raw)
In-Reply-To: <C11F4468-95C2-43BA-87E9-B5ADE9E6D964@sandoe.co.uk>
>
> > 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?
>
> 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
>
For reference, I proposed a patch for this in 2018. It was not
accepted because minimum alignment for functions would increase
for some archs:
https://gcc.gnu.org/legacy-ml/gcc-patches/2018-12/msg01532.html
> >> (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.
>
I think we need a solution rather sooner than later on all archs.
Martin
> > 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.
> >
> >
>
next prev parent reply other threads:[~2023-07-19 9:04 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-16 10:38 FX Coudert
2023-07-17 6:31 ` Richard Biener
2023-07-17 6:43 ` FX Coudert
2023-07-17 6:58 ` Iain Sandoe
2023-07-17 7:16 ` Iain Sandoe
2023-07-19 9:04 ` Martin Uecker [this message]
2023-07-19 9:29 ` Iain Sandoe
2023-07-19 10:43 ` Martin Uecker
2023-07-19 14:23 ` Iain Sandoe
2023-07-19 15:18 ` Martin Uecker
2023-08-05 14:20 ` FX Coudert
2023-08-20 9:43 ` FX Coudert
2023-09-06 15:44 ` FX Coudert
2023-09-14 10:18 ` Richard Biener
2023-09-16 19:10 ` Iain Sandoe
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e8acf6c19ddf24be1e081374838a8455fa886e73.camel@gmail.com \
--to=ma.uecker@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=iain@sandoe.co.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).