Misaligned memory writes at src/coreclr/vm/i386/cgenx86.cpp

[j123123]

This chunk of code

runtime/src/coreclr/vm/i386/cgenx86.cpp

Lines 973 to 980 in 1e322fd

	*p++ = 0x68;
	*(INT32 *)p = arg;
	p += 4;
	// push arg2
	*p++ = 0x68;
	*(INT32 *)p = arg2;
	p += 4;

definitely have undefined behavior because there are misaligned INT32 memory writes. This issue may also occur in other places in this file.
Clang with -fsanitize=undefined can catch this: https://godbolt.org/z/EeEzvfWsj

[MihuBot]

Possible related and/or duplicate issue:

• [x86/Linux] 16-byte stack alignment violation in JIT code #7123

[dotnet-policy-service]

Tagging subscribers to this area: @mangod9
See info in area-owners.md if you want to be subscribed.

[huoyaoyuan]

This is legacy code on x86 only, where unaligned access is working on implementations.

[jkotas]

unaligned access is working

It can stop working with the next clang update. We have seen number of instances where code with alignment issues started misbehaving after clang update. For example, #62170 or #97811 (this is not a complete list).

We have SET_UNALIGNED... macros to deal with unaligned access. The fix here is to use these macros.

[MichalPetryka]

This is legacy code on x86 only, where unaligned access is working on implementations.

Such pointer casting is UB in C++ and can generate invalid code even when always aligned.

[jkotas]

Such pointer casting is UB in C++ and can generate invalid code even when always aligned.

Yes, I know - strict aliasing. It is close to impossible to build a large low level project that is compliant with that. Unless Linux kernel figures out to make the code compliant with the strict aliasing, I do not think we care. Every C/C++ compiler out there either does not enable strict aliasing optimizations by default, or has a switch to disable them.

[j123123]

Every C/C++ compiler out there either does not enable strict aliasing optimizations by default, or has a switch to disable them.

In Clang and GCC __attribute__((may_alias)) can be used to disable strict aliasing for a specific type

[AaronRobinsonMSFT]

The compliant mechanism here would be to use memcpy. Compilers will elide the call if it doesn't matter, but retain it when it does.

https://godbolt.org/z/11cca35YK