Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

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

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
12 changes: 7 additions & 5 deletions spec/abi.dd
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -697,11 +697,13 @@ $(GNAME TypeTuple):

$(H2 $(LNAME2 function_calling_conventions, Function Calling Conventions))

$(P The $(D extern (C)) and $(D extern (D)) calling convention matches the C
calling convention
used by the supported C compiler on the host system.
Except that the extern (D) calling convention for Windows x86 is described here.
)
$(P Functions with $(D extern (C)) linkage matches the C calling
convention used by the supported C compiler on the host system.)
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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


$(P Functions with $(D extern (D)) linkage matches the calling
convention used by $(D extern (C)) functions with the parameters
pushed in the reverse order, except for 32-bit x86 architecture, which
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

@ibuclaw ibuclaw Nov 10, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

GDC is spec conformant. ;-)

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

is described here.)

$(H3 $(LNAME2 register_conventions, Register Conventions))

Expand Down