Re: [PATCH 3/3] or1k: gcc: initial support for openrisc

[Richard Henderson <rth at twiddle dot net>]

On 08/28/2018 07:13 AM, Jeff Law wrote:
> Your port defines instruction scheduling, so please check that you're
> emitting the proper barriers, particularly in your epilogue code.  In
> particular most ports need a barrier to prevent movement of register
> restores past the stack adjustment when the frame pointer is in use.

Oops, yes we had that in the "old" compiler, but
didn't replicate the barriers in the rewrite.

It's one of those "we didn't see it fail so we didn't fix it"
kind of things.

> Please consider using function descriptors rather than trampolines.
> This allows you to make the stack non-executable at all times which is
> good from a security standpoint.  The downside is the indirect calling
> mechanism has to change slightly to distinguish between a simple
> indirect call and one through a function descriptor (usually by having a
> low bit on to indicate the latter).  GIven this is an ABI change, now is
> probably the last opportunity to make this change.

We'll look into it.

> I didn't see any provision for long vs short branches.  How are branches
> to targets within the same function, but which are out of the range that
> can be encoded in a single instruction work?  Similarly how is this
> handled for function calls?  Note handling this gets even more complex
> with delay slots :(

26 bits, or +- 128MB, for all branches/calls.

You'd have to have a *really* big executable to overflow this.
I'd expect to fix out-of-range calls, if necessary, in the linker
with some sort of branch trampoline.

> I don't know if openrisc has any speculation capabilities.  Please
> define the SPECULATION_SAFE_VALUE hook appropriately for your
> architecture.  If you don't have speculation, define it to
> speculation_safe_value_not_needed.

None of the implementations do speculation.


r~