Re: [PATCH 0/4] OpenRISC binutils updates and new relocs

[Stafford Horne <shorne@gmail.com>]

Hi Joel,


On Tue, Sep 18, 2018 at 2:07 PM, Joel Sherrill <joel@rtems.org> wrote:

>
>
> On Tue, Sep 18, 2018, 6:56 AM Nick Clifton <nickc@redhat.com> wrote:
>
>>
>> > As Richard mentioned we don't handle this.
>> >
>> > We have cases like this right now as well, i.e. binaries generated with
>> `l.mul`
>> > or `l.div` instructions will link fine into an executable that assume
>> those
>> > instrunctions should be emulated.  That doesn't throw an error and I
>> don't think
>> > it has been a problem.
>>
>> OK, well it is your target, so if you are OK with this then so be it.
>> I would recommend however thinking about a solution for the future,
>> should the
>> openRISC architecture gain more variants.  My suggestion would be to make
>> use
>> of ELF notes, as has been done with other ports.
>>
>
> Is there a way to avoid these instructions with GCC? As a general rule,
> for RTEMS we assume the code is properly generated for the target CPU and
> don't emulate missing instructions.
>
> Also for these cases, is there a flag implicitly set by GCC based on CPU
> specific flags to let assembly code.know not to use them.
>
> And are there mulilibs which do and do not use them?
>

To answer all, yes.  There were some recent openrisc mailing list
discussions on this. I have decided to add a new multilib flag -mclass1
-mclass2 (default is mclass1 instructions only) to  stop gcc from using any
class2 instructions.


> In the deeply embedded space, we assume the tools and user can generate
> code which doesn't need emulation traps. There is some responsibility on
> the toolchain to.make it possible.
>

Yes, We did think about this when we were writing the new port, but we are
only just implementing it now.  Check the GCC docs in the next patch
version I submit.

-Stafford