[mono][llvm] Fix alignment of local vars

[BrzVlad]

klass->min_align specifies the alignment required by the class fields. For example a class/struct containing an int64 will require a minimum alignment of 8 byte for its storage, while a a class/struct containing an int8 will require a 1 byte alignment. build_named_alloca is used to allocate storage for a local var of a certain type so using klass->min_align is incorrect. We should use mono_type_size instead, as this is used throughout the runtime for this purpose. A var of object type should have the alignment sizeof (gpointer) since it is a pointer, completely unrelated to the class field layout.

Should fix #105251

[BrzVlad]

/azp run runtime-llvm

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[BrzVlad]

/azp run runtime-llvm

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[pavelsavara]

This will probably fix #106200

[steveisok]

nice @BrzVlad!

[pavelsavara]

Please consider back-port to Net8. I guess #106200 is real also there.

[BrzVlad]

@pavelsavara Do we have a strong suspicion that we have crashes there that are fixed by this ? While this seems relatively low risk to backport I'm not 100% convinced.

[pavelsavara]

I'm pretty confident that pointers which are misaligned on wasm shadow stack are invisible (unpinned) to GC.
I'm also pretty sure that AOT code dereferencing such stored pointers, which point to garbage after GC move.

I'm not confident that there are AOT applications in the wild, which hit this combo of GC move & bad alignment.
@lewing did you see any customer issue like that ?

We have many AOT crashes on Net9 CI pipeline.
I tracked down one of them to this root cause yesterday with @kotlarmilos on a call.
We can wait if many of them stop showing up in known build issues I linked to this in next few days.

[pavelsavara]

We have many AOT crashes on Net9 CI pipeline. We can wait if many of them stop showing up in known build issues I linked to this in next few days.

All of the CI issues are gone now AFAIK, meaning this has large positive impact.

@BrzVlad is this low risk enough to be backported to Net8 LTS ?
@lewing thoughts ?

[BrzVlad]

@pavelsavara I think this would be low risk enough to backport, however I feel like we should have some solid justification. Are there any GC crashes still happening regularly on specific test suites on .NET8 CI that we've seen fixed on .NET9 following this PR ? If we don't have such specific crashes I would rather not backport.