Re: [2/5] C-SKY port: Backend implementation

[Jeff Law <law@redhat.com>]

On 07/24/2018 06:17 PM, Sandra Loosemore wrote:
> On 07/24/2018 03:24 PM, Jeff Law wrote:
>>>
>>>> Any thoughts on using the newer function descriptor bits rather than
>>>> old
>>>> style stack trampolines?
>>>
>>> Has that been committed?  I vaguely remembered discussion of a new way
>>> to handle nested functions without using the trampoline interface, but I
>>> couldn't find any documentation in the internals manual.
>> It did.  See TARGET_CUSTOM_FUNCTION_DESCRIPTORS and the (relatively few)
>> ports that define it.
> 
> Hmmm, I completely failed to make that connection from the docs -- the
> whole description of that hook is pretty gibberishy and I thought it was
> something for targets where the ABI already specifies some "standard
> calling sequence" using descriptors (C-SKY doesn't), rather than a
> generic alternative to executable trampolines.  Putting on my doc
> maintainer hat briefly, I can see this needs a lot of work.  :-(
Most likely :-)  So many things to do, so little time.


> 
> Anyway, is this required for new ports nowadays?  If so, I at least know
> what to search for now.  At this point I couldn't say whether this would
> do anything to fix the situation on ck801 targets where there simply
> aren't enough spare registers available to the trampoline to both hold
> the static link and do an indirect jump.
It's not required, but preferred, particularly if the part has an MMU
that can provide no-execute protections on pages in memory.  If the
target doesn't have an mmu, then it's of marginal value.

The key advantage it has over the old trampoline implementation is that
stacks can remain non-executable, even for Ada and nested functions.
That's a big win from a security standpoint.

Jeff