Skip to content
This repository has been archived by the owner on Jan 23, 2023. It is now read-only.

(Re)Enable NativeVarargs for CoreCLR #18373

Merged
merged 2 commits into from
Jun 11, 2018

Conversation

jashook
Copy link

@jashook jashook commented Jun 8, 2018

This will allow coreclr run programs which have native varargs.
It also re-enables the ArgIterator type for managed to managed native
vararg calls which will allow the use of the __arglist keyword.

This change also deletes a test which expects an invalid program exception
for native varargs usage.

Limitations:

NYI statements have been added for all Unix Targets.

With this change __arglist (native varargs) will be supported, but not
yet tested
on:

Amd64 Windows
x86 Windows
Arm32 Windows
Arm64 Windows

This change does not address re-enablabling native vararg tests. This will be done
in a seperate change.

See #18377 for on initial thoughts on varargs bringup on
unix platforms.

@jashook jashook force-pushed the enable_native_varargs branch 2 times, most recently from a1dcf8c to ce2fe51 Compare June 8, 2018 18:35
Copy link

@CarolEidt CarolEidt left a comment

Choose a reason for hiding this comment

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

LGTM

#ifdef _TARGET_UNIX_
// Currently native varargs is not implemented on non windows targets.
//
// Note that some targets like Arm64 Unix should not need much work as
Copy link
Member

Choose a reason for hiding this comment

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

The ABI is not the same for ARM64 Unix - we've discussed it together some time ago. And with Amd64, things are even more complex on unix - the variable args can be passed in registers, the va_list is a special structure containing the indices of the gen purpose / fp registers, etc.
Am I missing something?

Copy link
Author

Choose a reason for hiding this comment

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

The comment is addressing code generation. For arm64 unix the ABI for varargs is not different from the regular calling convention.

Copy link
Member

Choose a reason for hiding this comment

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

Ah, makes sense, I was somehow mislead into thinking you were comparing the actual windows and Unix abis.

return FALSE;
#else // UNIX_AMD64_ABI
#else // !UNIX_AMD64_ABI
Copy link
Member

Choose a reason for hiding this comment

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

The comment was correct - the convention in the VM is to always use the condition from the #ifdef, not the negation.

Copy link
Author

Choose a reason for hiding this comment

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

Ok will address.

@@ -132,54 +131,5 @@ public override bool Equals(Object o)
{
throw new NotSupportedException(SR.NotSupported_NYI);
}
#else
public ArgIterator(RuntimeArgumentHandle arglist)
{
Copy link
Member

Choose a reason for hiding this comment

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

You should keep this throwing implementation for Unix until/if the varargs are actually implemented for Unix

Copy link
Author

Choose a reason for hiding this comment

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

Is there a platform specific define that can be used here?

Copy link
Member

Choose a reason for hiding this comment

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

PLATFORM_UNIX or PLATFORM_WINDOWS

@@ -489,13 +489,6 @@ CEEInfo::ConvToJitSig(
IfFailThrow(sig.GetCallingConvInfo(&data));
sigRet->callConv = (CorInfoCallConv) data;

if ((isCallConv(sigRet->callConv, IMAGE_CEE_CS_CALLCONV_VARARG)) ||
Copy link
Member

Choose a reason for hiding this comment

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

We should continue throwing here for unix

@jashook jashook force-pushed the enable_native_varargs branch 2 times, most recently from d1974c4 to 17ec636 Compare June 8, 2018 22:51
@@ -1,114 +0,0 @@
// Licensed to the .NET Foundation under one or more agreements.
Copy link
Member

Choose a reason for hiding this comment

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

Should we keep these tests for Unix?

Copy link
Author

Choose a reason for hiding this comment

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

Personally I do not see the value of the test and conditionally excluding it by platform will be more work to undo later. If there are strong opinions to keep them then I can add them back.

Copy link
Member

Choose a reason for hiding this comment

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

This test would have caught the wrong ifdef that I have commented on...

Are we going to implement varargs support on Unix for next release? If yes, I do not have a problem with deleting these tests now. If not, we should keep them.

Copy link
Author

Choose a reason for hiding this comment

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

Fair point will add them back thank you.

@@ -489,12 +489,14 @@ CEEInfo::ConvToJitSig(
IfFailThrow(sig.GetCallingConvInfo(&data));
sigRet->callConv = (CorInfoCallConv) data;

#ifdef _TARGET_UNIX_
Copy link
Member

Choose a reason for hiding this comment

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

_TARGET_UNIX_ is JIT-specific define. Outside of JIT, we have PLATFORM_UNIX.

Copy link
Author

Choose a reason for hiding this comment

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

Thank you for catching this.

This will allow coreclr run programs which have native varargs.
It also re-enables the ArgIterator type for managed to managed native
vararg calls. This will allow the use of the __arglist keyword.

Limitations:

NYI statements have been added for all Unix Targets.

With this change __arglist (native varargs) will be supported, but not
yet tested on:

Amd64 Windows
x86 Windows
Arm32 Windows
Arm64 Windows

This change does not re-enable native vararg tests. This will be done
in a seperate change.
@jashook jashook closed this Jun 11, 2018
@jashook jashook reopened this Jun 11, 2018
Copy link

@briansull briansull left a comment

Choose a reason for hiding this comment

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

Looks Good
( with minor comments )

// Note that some targets like Arm64 Unix should not need much work as
// the ABI is the same. While other targets may only need small changes
// such as amd64 Unix, which just expects RAX to pass numFPArguments.
NYI("Morhing Vararg call not yet implemented on non Windows targets.");

Choose a reason for hiding this comment

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

Spelling: Morhing => Morphing

// the ABI is the same. While other targets may only need small changes
// such as amd64 Unix, which just expects RAX to pass numFPArguments.
NYI("Morhing Vararg call not yet implemented on non Windows targets.");
}
#endif

Choose a reason for hiding this comment

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

// TARGET_UNIX

picenka21 pushed a commit to picenka21/runtime that referenced this pull request Feb 18, 2022
* Enable NativeVarargs for CoreCLR

This will allow coreclr run programs which have native varargs.
It also re-enables the ArgIterator type for managed to managed native
vararg calls. This will allow the use of the __arglist keyword.

Limitations:

NYI statements have been added for all Unix Targets.

With this change __arglist (native varargs) will be supported, but not
yet tested on:

Amd64 Windows
x86 Windows
Arm32 Windows
Arm64 Windows

This change does not re-enable native vararg tests. This will be done
in a separate change.

Commit migrated from dotnet/coreclr@e600470
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants