[PATCH 0/2] RISC-V: Fix the conflicting priv spec problems

[Nelson Chu <nelson.chu@sifive.com>]

Hi binutils,

The link compatibility problem is found by Jim in the following link,
https://sourceware.org/pipermail/binutils/2020-May/111307.html


There are two patches used to fix the compatibility problem,
* RISC-V: Don't generate the ELF privilege attributes when no CSR are used.
* RISC-V: The object without priv spec attributes can be linked with any object.

For the first patch, the assembler will generate the ELF priv spec attributes
only when,

1. We already set the ELF priv spec attributes in the assembly file.
(.attribute priv_spec/priv_spec_minor/priv_spec_revision number)

2. The CSR is explicitly used by the CSR instruction.  Then assembler will
generate the priv attributes by -mpriv-spec, --with-priv-spec or the default
setting (the newest spec).

The behavior is basically the same as before (the version controling patches
have not been applied), except the case 2 mentioned above.

Therefore, we still need the second patch, which allows to link the object
without any privilege set. That is, an object file without a priv spec
version set should be allowed to link with any other object file.  And when
the first linked object doesn't contain any priv set, then we should copy the
verison according to the next linked object.

I recover to the time before the version controling patches are not applied.
And I get the following ld testsuite result by adding CC_FOR_TARGET to run
the compiler needed cases.

 === ld Summary ===

# of expected passes            483
# of unexpected failures        14
# of expected failures          9
# of unsupported tests          180

Then I use "git pull" to test the upstream binutils (just build binutils and
use the previous compiler), and also get the same conflicting priv spec errors.

=== ld Summary ===

# of expected passes            350
# of expected failures          7
# of untested testcases         16
# of unsupported tests          170

After applying the first patch, the expected passes number is back.
The extra passed one is "map to directory", which is added recently in the
ld/testsuite/ld-scripts/map-address.exp.

=== ld Summary ===

# of expected passes            484
# of unexpected failures        14
# of expected failures          9
# of unsupported tests          180

Ane then I get the same result when applying the second patches with the first one
(extra 8 pass are the new testcases, used to check the second patch),

=== ld Summary ===

# of expected passes            492
# of unexpected failures        14
# of expected failures          9
# of unsupported tests          180


We can only use the second patch to fix the compatibility problem, but it is
hard to write testcases to test it (hard to generate an object without priv set).
So I suggest to apply the first patch too, and the behavior should be more make sence.

Thanks
Nelson