On 10/12/22 02:03, Christoph Müllner wrote:
So we have the following atomics ABIs:
I) GCC implementation
II) LLVM implementation
III) Specified ABI in the "Code Porting and Mapping Guidelines"
appendix of the RISC-V specification
And presumably we don't have any way to distinguish between I and II at
the DSO or object level. That implies that if we're going to get to
III, then we have to mark new code. We obviously can't mark
pre-existing bits (and I may have implied we should do that in my
earlier message, my goof).
And there are two proposed solutions:
a) Finding a new ABI that is compatible with I) and II) is of course
a solution, but we don't know if and when such a solution exists.
b) Going to introduce III) causes a break and therefore needs special
care (e.g. let the user decide via command line flag or provide a
compatibility mode).
I don't see that a) and b) contradict each other.
Why not going for both:
-) Continue to work on a backward compatible solution
-) Enable the "new" ABI from the specification appendix via command
line flag
-) Reevaluate the situation in 12 months to decide the next steps
I would lean towards making the new, more correct, behavior the default
and having the old behavior enabled by a command line flag. But
otherwise what you're suggesting seems reasonable.
Jeff
