Am Mittwoch, dem 19.07.2023 um 10:29 +0100 schrieb Iain Sandoe: > Hi Martin, > > > On 19 Jul 2023, at 10:04, Martin Uecker <ma.uec...@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? > > > > > > 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 > > Right - that was the one we originally looked at and has the issue > that it > breaks ABI - and thus would need vendor by-in to alter as you say. > > > > > > (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. > > 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. 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... 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. 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. > > 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. Martin > > Iain > > ** modulo the target maintainers implementing the builtins. > > >
