[Mono-dev] Number of elements in a fixed buffer
Zoltan Varga
vargaz at gmail.com
Wed Aug 12 03:00:02 UTC 2015
Hi,
Fixed buffers are a c# construct, the il code generared by the c#
compiler is not much different than the il code generated for this
declaration:
[StructLayout (LayoutKind.Sequential, Size=32)]
struct FooStruct {
double d;
}
The Size= argument is kinda hard to handle in the runtime since it has no
counterpart in the native ABIs, the native ABIs assume that structs are
made of consecutive fields. So I think the best way to handle this is to
special case it as you said.
Zoltan
On Tue, Aug 11, 2015 at 11:15 AM, Bill Seurer <seurer at linux.vnet.ibm.com>
wrote:
> The ELF ABI v2 changed how parameters that are structures are passed to
> functions and also how structures are returned. One of the changes is that
> if a structure parameter is completely made up of 8 or fewer doubles xor
> floats then the structure is passed in FPRs instead of GPRs.
>
> The condition "completely made up of" includes nested structures and
> arrays (i.e., fixed buffers in C# parlance). So
>
> public unsafe struct double_array4 {
> public fixed double f1[4];
> }
>
> needs to be passed in FPRs. This is in fact the structure I was
> experimenting with in the output I showed earlier.
>
> I can sort of detect this by the size of the field being 32 while only
> having one double member (size of 8) but that seems clumsy and possibly
> inaccurate. I figured that it should be possible to see that it is a fixed
> buffer (array) and that it has 4 elements.
>
> On 08/10/2015 11:32 AM, Zoltan Varga wrote:
>
>> Hi,
>>
>> The class has an internal valuetype which represents the fixed buffer,
>> and that valuetype has the FixedBufferAttribute.
>>
>> Runtime code generally doesn't need to care about fixed buffers, why is
>> this needed ?
>>
>>
>> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
>>
>> .class public sequential ansi sealed beforefieldinit double_array4
>>
>> extends [mscorlib]System.ValueType
>>
>> {
>>
>> .class sequential ansi sealed nested public beforefieldinit
>> '<f1>__FixedBuffer0'
>>
>> extends [mscorlib]System.ValueType
>>
>> {
>>
>> .pack 0
>>
>> .size 32
>>
>> .custom instance void
>>
>> [mscorlib]System.Runtime.CompilerServices.UnsafeValueTypeAttribute::.ctor()
>> = ( 01 00 00 00 )
>>
>> .custom instance void
>>
>> [mscorlib]System.Runtime.CompilerServices.CompilerGeneratedAttribute::.ctor()
>> = ( 01 00 00 00 )
>>
>> .field public float64 FixedElementField
>>
>> } // end of class '<f1>__FixedBuffer0'
>>
>> .field public valuetype double_array4/'<f1>__FixedBuffer0' f1
>>
>> .custom instance void
>>
>> [mscorlib]System.Runtime.CompilerServices.FixedBufferAttribute::.ctor(class
>> [mscorlib]System.Type,
>>
>>
>> int32) = ( 01 00 5A 53 79 73 74 65 6D 2E 44 6F 75
>> 62 6C 65 // ..ZSystem.Double
>>
>>
>> 2C 20 6D 73 63 6F 72 6C 69 62 2C 20
>> 56 65 72 73 // , mscorlib, Vers
>>
>>
>> 69 6F 6E 3D 34 2E 30 2E 30 2E 30 2C
>> 20 43 75 6C // ion=4.0.0.0, Cul
>>
>>
>> 74 75 72 65 3D 6E 65 75 74 72 61 6C
>> 2C 20 50 75 // ture=neutral, Pu
>>
>>
>> 62 6C 69 63 4B 65 79 54 6F 6B 65 6E
>> 3D 62 37 37 // blicKeyToken=b77
>>
>>
>> 61 35 63 35 36 31 39 33 34 65 30 38
>> 39 04 00 00 // a5c561934e089...
>>
>>
>> 00 00 00 )
>>
>> } // end of class double_array4
>>
>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>
>> On Mon, Aug 10, 2015 at 10:53 AM, Bill Seurer <seurer at linux.vnet.ibm.com
>> <mailto:seurer at linux.vnet.ibm.com>> wrote:
>>
>> The only mention of FixedBufferAttribute I see is in the C# code in
>> mcs.
>>
>> I looked through all the mono C code and I see several places where
>> MonoCustomAttrInfo is used but no where is it doing anything with
>> fixed buffers. Is there some documentation or more examples of what
>> is in the MonoCustomAttrInfo data for something like this?
>>
>> I experimented a bit and used mono_custom_attrs_from_class() to pull
>> the MonoCustomAttrInfo for the class. It looks like there are two
>> attributes.
>>
>> {num_attrs = 2, cached = 0, image = 0x10566ed0, attrs = 0x1061c630}
>>
>> So looking at the two attributes I see
>>
>> attrs[0]: {ctor = 0x1061cb10, data_size = 4, data = 0x3fffb7840e71
>> "\001"}
>> attrs[1]: {ctor = 0x1061c990, data_size = 4, data = 0x3fffb7840e71
>> "\001"}
>>
>>
>> The data fields are identical and are 01 00 00 00 or maybe the other
>> way around depending on what the field represents (this is a LE
>> machine).
>>
>> The ctors are
>>
>> (gdb) print cinfo->attrs[0].ctor->klass->name
>> $14 = 0x3fffb5b225b6 "UnsafeValueTypeAttribute"
>> (gdb) print cinfo->attrs[1].ctor->klass->name
>> $15 = 0x3fffb5b22281 "CompilerGeneratedAttribute"
>>
>> What do those represent?
>>
>>
>> On 08/06/2015 12:23 PM, Zoltan Varga wrote:
>>
>> Hi,
>>
>> The type has a FixedBufferAttribute custom attribute which
>> contains
>> the length of the array. There are some functions in reflection.c
>> like mono_custom_attrs_from_class () which can return
>> information about it.
>>
>> Zoltan
>>
>> On Thu, Aug 6, 2015 at 12:32 PM, Bill Seurer
>> <seurer at linux.vnet.ibm.com <mailto:seurer at linux.vnet.ibm.com>
>> <mailto:seurer at linux.vnet.ibm.com
>> <mailto:seurer at linux.vnet.ibm.com>>> wrote:
>>
>> In some code in mono/mini I need to figure out how many
>> elements
>> there are in a fixed buffer field in a struct, something
>> like this:
>>
>> public unsafe struct double_array4 {
>> public fixed double f1[4];
>> }
>>
>> So I'd need to know "4".
>>
>> I can get the MonoClass of the field from the MonoFieldType
>> and if I
>> print out the name I get
>>
>> Test_double.double_array4.<f1>__FixedBuffer0
>>
>> so it knows it is a fixed buffer. If I look at the fields
>> of the
>> struct in the above example there is just one and it's a
>> double.
>>
>> So how can I figure out the number of elements?
>>
>> Thanks!
>>
>>
>>
>> --
>>
>> -Bill Seurer
>>
>>
>>
>
> --
>
> -Bill Seurer
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ximian.com/pipermail/mono-devel-list/attachments/20150811/31899b6b/attachment-0001.html>
More information about the Mono-devel-list
mailing list