Bug 5405 - Struct layout on 32-bit MacOS doesn't match gcc
Summary: Struct layout on 32-bit MacOS doesn't match gcc
Alias: None
Product: Runtime
Classification: Mono
Component: JIT ()
Version: unspecified
Hardware: PC Mac OS
: --- normal
Target Milestone: ---
Assignee: Bugzilla
Depends on:
Reported: 2012-05-29 23:11 UTC by Mikayla Hutchinson [MSFT]
Modified: 2012-06-04 15:04 UTC (History)
4 users (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on GitHub or Developer Community with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Mikayla Hutchinson [MSFT] 2012-05-29 23:11:21 UTC
Mono's StructLayout.Sequential struct layout on i386 MacOS doesn't match gcc. AFAICT Mono align doubles to 8 bytes boundaries, and GCC aligns them to 4 bytes boundaries. This can be overcome by using Pack=4 but it's annoying to debug, and I'm worried about future x64 portability implications.
Comment 1 Zoltan Varga 2012-06-01 05:41:46 UTC
We have tests for this, and they run fine. Do you have a testcase ?
Comment 2 Mikayla Hutchinson [MSFT] 2012-06-01 13:08:16 UTC
Sure, here's a testcase: https://gist.github.com/f54bed27ad6324097ff5
Comment 3 Zoltan Varga 2012-06-01 14:31:27 UTC
The (int)&(f->b) returns the offset in the managed layout, not the unmanaged one.
Comment 4 Mikayla Hutchinson [MSFT] 2012-06-01 15:54:01 UTC
Sorry, I omitted the [StructLayout(LayoutKind.Sequential)] from the testcase. Fixed. However, it makes no difference.

Maybe I'm misunderstanding the MSDN docs, but aren't structs with explicit (e.g. Sequential) layout that contain only blittable fields supposed to be blittable types, and therefore have identical managed and unmanaged layout?
Comment 5 Zoltan Varga 2012-06-01 16:05:07 UTC
Its the other way around, structs with identical layout are blittable.
Comment 6 Mikayla Hutchinson [MSFT] 2012-06-01 16:23:01 UTC
That's strange, I can't find any docs that support that. Whereas http://msdn.microsoft.com/en-us/library/75dwhxf7.aspx says: "The following complex types are also blittable types: ...Formatted value types that contain only blittable types..." and http://msdn.microsoft.com/en-us/library/0t2cwe11.aspx indicates a type with LayoutKind.Sequential is "formatted".

Are the MSDN docs wrong/unclear or is this an undocumented Mono limitation?
Comment 7 Zoltan Varga 2012-06-02 06:11:54 UTC
Err, this was actually a bug, which was fixed by 706aaed7c772e00b9cec76f8452ef5f1cedfb5e6.
Comment 8 Zoltan Varga 2012-06-02 20:34:46 UTC
Do you need this patch on 2.10 ?
Comment 9 Mikayla Hutchinson [MSFT] 2012-06-04 15:04:47 UTC
It's not a big deal, I worked around it by setting Pack=4 for my structs already.