spec: abi: clarify calling convention for other architectures other than x86

[ljmf00]

Observing the assembly generated by the following source file in either DMD and
LDC:

extern (C) void ccall( size_t a, size_t b, size_t c );
extern (D) void dcall( size_t a, size_t b, size_t c );

//...

ccall( a, b, c ); // RDI, RSI, RDX
dcall( a, b, c ); // RDX, RSI, RDI

The parameters are passed in the reverse order in functions with extern(D)
linkage. Furthermore, on x86 the calling convention seems to be what is
described by the current subsections, not only matching Windows x86, but also
appears to be the same behaviour on System V ABI.

Fixes #20204 .

Signed-off-by: Luís Ferreira [email protected]

---

For more context: https://godbolt.org/z/sWz4x37bb

[dlang-bot]

Thanks for your pull request, @ljmf00!

Bugzilla references

Auto-close	Bugzilla	Severity	Description
✓	20204	normal	need to fix ABI about registers using

[ljmf00]

I still think that used by the supported C compiler on the host system is to vague

[ibuclaw]

Not really, parameters are just evaluated from left to right.

[ljmf00]

Can you elaborate? Look into the godbolt link and issue attached to the PR description for context. Maybe I expressed myself wrongly.

[ibuclaw]

The real intent is left to right evaluation of parameters.

Dmd passing arguments in reverse is just an implementation detail, because Walter doesn't want to use too many scratch registers to hold intermediate values before calling the function.

[ljmf00]

I don't think it is an implementation detail. If the specification is correct, then the compiler is behaving wrongly. I interpret implementation details as different implementation behaviour that doesn't affect specification conformance.

In practice, if I try to link a function generated by DMD with another binary generated by a compiler that generates a conformant convention call, bad things may happen, if the order matters, because the registers are reversed and therefore the parameters are passed wrongly.

[ibuclaw]

GDC is spec conformant. ;-)

https://godbolt.org/z/57KheoTKW

[ljmf00]

GDC is spec conformant. ;-)

godbolt.org/z/57KheoTKW

That is good to know and makes sense. So only LDC/DMD is wrong. What about the 32-bit x86 on GDC? Since the spec only mentions Windows, it is also conformant. I don't know about Windows x86 since I don't use Windows, but should we deviate from the standard calling convention there too?

[ibuclaw]

GCC only supports MinGW or Cygwin, so I only follow what is the ABI for that target.

[ljmf00]

GCC only supports MinGW or Cygwin, so I only follow what is the ABI for that target.

Doesn't MinGW try to mimic the same ABI as Windows? Anyway, it is not so explicit that way, so GDC seems to conform with it, only DMD and LDC do not. See dlang/dmd#13287 where we can discuss the problem more in-depth and a possible fix for this.

[ibuclaw]

extern(C) code may be compatible, but MinGW uses Itanium ABI for C++, not MSVC.

[kinke]

I've always regarded this as an ABI spec violation of both DMD and LDC, unfortunately not that simple to fix mainly because of existing DMD-style inline asm in druntime/Phobos and user code. If given the choice, I'd definitely fix the implementation rather than the spec.

[ljmf00]

I've always regarded this as an ABI spec violation of both DMD and LDC, unfortunately not that simple to fix mainly because of existing DMD-style inline asm in druntime/Phobos and user code. If given the choice, I'd definitely fix the implementation rather than the spec.

I agree with you because it doesn't make much sense. I don't get the rationale for the x86 special case either. On the other hand, changing the implementation make binaries incompatible leading to a huge breaking change with old shared objects.

I'm kinda divided here, to be honest, but inclined to the "clean way", which is to fix the implementation.

[kinke]

changing the implementation make binaries incompatible leading to a huge breaking change with old shared objects

That's not that big a deal, we have had numerous breaking ABI changes in the past, so binaries compiled with different compiler versions aren't expected to be compatible.

The only real problem I see is that efforts should probably be synchronized across DMD and LDC, in order to tell people that from D 2.100 on (or so), the params aren't reversed for extern(D) anymore (except for 32-bit x86), for both DMD and LDC. So if they've been accessing parameter registers directly in DMD-style inline asm, they need to adapt those, but it'll work with both DMD and LDC at least.

I'm more than happy to finally do this for LDC (I've had a go at this some 5 years ago already).

[kinke]

This parameter reversal has been a PITA at multiple occasions, e.g., dlang/dmd#11630.

[ljmf00]

changing the implementation make binaries incompatible leading to a huge breaking change with old shared objects

That's not that big a deal, we have had numerous breaking ABI changes in the past, so binaries compiled with different compiler versions aren't expected to be compatible.

The only real problem I see is that efforts should probably be synchronized across DMD and LDC, in order to tell people that from D 2.100 on (or so), the params aren't reversed for extern(D) anymore (except for 32-bit x86), for both DMD and LDC. So if they've been accessing parameter registers directly in DMD-style inline asm, they need to adapt those, but it'll work with both DMD and LDC at least.

I'm more than happy to finally do this for LDC (I've had a go at this some 5 years ago already).

Sure, I can see what I can do about it. I'm not into deep backend stuff like target codegen. What about the 32-bit x86? Why is the calling convention different there too?

This parameter reversal has been a PITA at multiple occasions, e.g., dlang/dmd#11630.

At a first glance, it appears to me that this is being fixed in the wrong place. This parameter reverse order behaviour appears to be intentional on the IR generation: https://github.com/dlang/dmd/blob/master/src/dmd/e2ir.d#L5261