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

[Jeff Law]

On 08/29/2018 03:29 PM, Richard Henderson wrote:
> 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.
Yea.  But we both know the pain of trying to track this down when it
finally exposes itself :-)

> 
>> 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.
Thanks.  I realize it may be too late, so I don't think it's a hard
requirement.  But it's worth looking into.

> 
>> 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.
More bits than expected :-)  I don't mind punting this until you have to
resolve it due to big executables.

> 
>> 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.
THen I think you can just define it to speculation_safe_value_not_needed.

As far as I'm concerned, you can commit this once the barriers &
speculation bits are fixed.  If you can avoid trampolines, that can be a
follow-up.  And long branches can definitely be punted until it's really
needed.

Jeff

ps. Any plans for glibc?  How complete is the qemu support?  I'm having
reasonable success building little chroot filesystems, then using qemu
to do bootstrap testing within those chroots.