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

[Stafford Horne <shorne at gmail dot com>]

On Mon, Sep 17, 2018 at 04:07:44PM +0100, Nick Clifton wrote:
> Hi Stafford,
> 
> > Does anyone have concerns with these patches?  Mostly they are for openrisc
> > parts only.
> 
> Sorry for the long silence - I have been very busy of late.
> 
> The patch series looks basically fine to me, so I have no concerns there.
> There are a few minor formatting glitches, but nothing serious.

Will you be able to point them out?  Even just some hints?  We have tried to
follow conventions, but there might be some missed spots.  I will go over
everything again just in case and run any formatting tools I have, but any tips
will be helpful.

> I do not see any need to add extra document for the new relocs, unless you
> have created new assembler pseudo-ops to generate them.  (I did not see any
> code to add such operators, but I may have missed something).

As Richard mentioned we have added a few, see PATCH 3/4 in cpu/or1k.opc the
change:

	(parse_reloc): Add new po(), gotpo() and gottppo() for LO13 relocations.

Is this what you mean?  I will look into adding the documentation for these.

> I do have one question though.  Is there a need to be able to distinguish 
> between binaries that use the new l.adrp instruction and those that don't.
> For example if a library is built using the new instruction but then it is
> linked into an executable which is supposed to run on silicon which does
> not support the new instruction, should the linker issue an error ?  If so,
> how does it detect this situation ?

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.

-Stafford