public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
* [PATCH 0/2] RISC-V: Fix the conflicting priv spec problems
@ 2020-05-30  8:44 Nelson Chu
  2020-05-30  8:44 ` [PATCH 1/2] RISC-V: Don't generate the ELF privilege attributes when no CSR are used Nelson Chu
                   ` (2 more replies)
  0 siblings, 3 replies; 11+ messages in thread
From: Nelson Chu @ 2020-05-30  8:44 UTC (permalink / raw)
  To: binutils, jimw


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

^ permalink raw reply	[flat|nested] 11+ messages in thread

end of thread, other threads:[~2020-06-08 20:27 UTC | newest]

Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-30  8:44 [PATCH 0/2] RISC-V: Fix the conflicting priv spec problems Nelson Chu
2020-05-30  8:44 ` [PATCH 1/2] RISC-V: Don't generate the ELF privilege attributes when no CSR are used Nelson Chu
2020-06-04 16:51   ` Jim Wilson
2020-06-05  4:24     ` Nelson Chu
2020-05-30  8:44 ` [PATCH 2/2] RISC-V: The object without priv spec attributes can be linked with any object Nelson Chu
2020-06-04 17:23   ` Jim Wilson
2020-06-05  4:28     ` Nelson Chu
2020-06-04 22:23 ` [PATCH 0/2] RISC-V: Fix the conflicting priv spec problems Palmer Dabbelt
2020-06-05  5:41   ` Nelson Chu
2020-06-05  8:24     ` Kito Cheng
2020-06-08 20:27     ` Palmer Dabbelt

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).