FunctionArgument on June 2008 SDK

Question

Hello,

What happened with the Phx.Symbols.FunctionArgument on this new SDK? What should I do to make the following code work?

     Phx.Symbols.FunctionArgument functionArgument =
                            Phx.Symbols.FunctionArgument.New(funcSymbol, argsName, parameterId++);
     funcSymbol.AppendFunctionArgument(functionArgument);

Regards,
Guilherme Oliveira

Answer 1

Hi there,

I have the same question regarding this code:

 

Phx.Types.FunctionArgument ellipsisArg =

Phx.Types.FunctionArgument.New(typeTable,Phx.Types.FunctionArgumentKind.Ellipsis,

typeTable.UnknownType);

The documentation doesn't show that this functionality was deprecated but in browsing phxd.dll the class is clearly not there.

Thanks!

Take care,
John

Answer 2

More info...

The Phoenix SDK for June 2008 docs show that the FunctionArgument class is in the Phx.Symbols namespace. Browsing the phxd.dll assembly I don't find the class there, either... So I searched all of the assemblies and I can't find the class... Was the class lost somehow in this build - perhaps in an intended move between namespaces?

Take care,
John

Answer 3

We shuffed things around a bit (hopefully for the better). Unfortunately we didn't update the reference documentation in the July SDK (a mistake we won't make again). I've attached a description of the change we made which hopefully answers your questions..

Types:

1)      Types::FunctionArgument is renamed to Types::ParameterType (Parameters are what the function is expecting; arguments are the values that are actually passed by the caller.  This terminology is consistent with both .NET and C++.)

2)      Types::ParameterType is now a value type.  This makes function types smaller and removes the need for a Next field.

3)      The IsIn and IsOut properties have been removed from ParameterType.  These properties apply to a parameter symbol, not a parameter type.

4)      A new parameter kind has been added: VariableArgumentsCallSiteArgument.  This is to support the way the CLR encodes the types of arguments passed to varags methods.  It encodes a call to a varags method with a signature consisting of the normal method signature, followed by a sentinel byte, followed by the types of the additional arguments.  We were previously treating these as UserDefined parameters.

5)      The requirements of a well-formed function type have been tightened.  The requirements are:

a.       The This pointer must be the first parameter (this was already a requirement).

b.      The Ellipsis parameter, if present, must occur after all other parameters except for VariableArgumentsCallSiteArgument parameters.

c.       VariableArgumentsCallSiteArgument parameters may only appear on a VariableArguments function type, and only after the Ellipsis parameter.

d.      All UserDefined parameters must be in a contiguous range.

6)      We now assert that the type of an Ellipsis parameter is UnknownType.  This is what almost everyone was passing before, anyway.

7)      Most of the methods of FunctionBuilder for adding parameter types have been removed.  There are now only two methods for adding parameters: AppendParameterType and AppendReturnType.  Each method has two overloads: one explicitly specifies both the type and kind, and the other specifies only the type and uses UserDefined for the kind.

8)      The parameters of a FunctionType are now accessed via collections of type ParameterTypes.  These replaces the various GetNthBlah methods.  The collections are foreach-able and indexable.  The underlying ParameterType objects are stored in a single array on the FunctionType object.  The ParameterTypes collections merely index into that array.  The index into these collections is zero-based, unlike the one-based indexing of GetNthBlah.  Every place I had to change a call to GetNthBlah to an access to a collection, I had to remove either a +1 or a -1 anyway, so for the most part one-based indexing was only complicating things.

9)      Added the property FunctionType::ThisPointerType, rather than just having everyone call GetNthArgumentType(1).

10)   Added the method FunctionType::GetParameterTypeForArgumentIndex().  This retrieves the ParameterType for the specified argument index.  This is almost the same as ParameterTypes[index], except that any argument index corresponding to an argument passed to the ellipsis of a varargs function is mapped to the ellipsis ParameterType.

 

Symbols:

1)      Symbols::FunctionArgument is renamed to Symbols::ParameterSymbol.

2)      Each FunctionSymbol now has ParameterSymbol object for every parameter in its FunctionType, including hidden parameters, this pointers, etc.  To make sure the right ParameterSymbol objects get created, the ParameterSymbols are created only by the FunctionSymbol itself, via FunctionSymbol::CreateParameterSymbols().

3)      Added the properties ParameterSymbol::Type, ParameterSymbol::ParameterKind, and ParameterSymbol::ParameterType.

4)      Added the method FunctionSymbol::GetParameterSymbolForArgumentIndex(), analogous to FunctionType::GetParameterTypeForArgumentIndex().

5)      The ParameterSymbol objects of a FunctionSymbol are now accessed via collections of type ParameterSymbols, analogous to the ParameterTypes collections on FunctionType.

6)      Renamed ParameterSymbol::CustomAttributeSymbolList to AttributeSymbolList, since it also stores marshaling attributes.

7)      Moved the backing fields for ParameterSymbol::CustomAttributeSymbolList and ParameterSymbol::DefaultValueSymbol to a tear-off extension object, since most ParameterSymbols have neither attributes nor a default value.

8)      Removed the backing field for ParameterSymbol::MarshalAttributeSymbol, and find it in the attribute symbol list when requested instead.

 

IR:

1)      Added the property CallInstruction::ArgumentsWithParameters.  This returns a foreach-able collection for ArgumentWithParameter objects.  Each ArgumentWithParameter object combines the argument Operand with the ParameterType of the corresponding parameter from the FunctionType of the call, and the ParameterSymbol of the corresponding parameter from the FunctionSymbol, if available.  The mapping uses the same logic as FunctionType::GetParameterTypeForArgumentIndex(), i.e. any arguments passed to an ellipsis map to the ellipsis ParameterType/ParameterSymbol.  For a sample usage of this enumerator, see null-lattice.cpp, where we enumerate over the parameter types and destination operands of an EnterFunction instruction.

---

Architect - Microsoft Phoenix Project

Answer 4

Thanks Andy!

Answer 5

 Hey Andy,

You mentioned that the functionTypeBuilder only has 2 methods to add parameters - AppendParameterType and AppendReturnType.... It appears that these methods are called 'AppendParameter' and 'AppendReturnParameter' - is this correct?

Take care, and thanks!
John

Answer 6

Thanks!

Answer 7

I am running the latest version of phoenix. I tried to look for Types.ParameterType within the object explorer but with no luck. The only thing is the remotely close is Types.Parameter which has no "New" function defined. I would like to ask if the sdk has been changed again. Any help on this issue is greatly appreciated.

Answer 8

We haven't changed things since last July. Types.Parameter is a value class so it doesn't need a new, you can just allocate one on the stack.

---

Architect - Microsoft Phoenix Project

Answer 9

I use this code, i like to know if this is right.

Phx.Types.Parameter ellipsis = new Phx.Types.Parameter();
functionbuilder.AppendParameter(ellipsis.Type,Phx.Types.ParameterKind.Ellipsis);

I like to append a parameter of type ellipsis.

PD:I don't talk english very good, sorry for bad english.

Answer 10

This works for me:

Phx.Types.Table typeTable = Phx.GlobalData.TypeTable;
Phx.Types.Type ellipsisType = typeTable.UnknownType;
//...
funcTypeBuilder.AppendParameter(ellipsisType);

See Andy's note above that this parameter is required to be last (with the one noted exception).

Take care,
John