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