[WIP] Uses memcpy in CustomAttributeParser to avoid SIGBUS in ARM

[parjong]

This commit attempts to replace explicit assignment in CustomAttributeParser with memcpy to avoid SIGBUS during loading xunit testcases (discussed in #6378)

This PR is under testing. Please do NOT merge this.

[parjong]

@jkotas Could you let me know if there is any document related with LIMITED_METHOD_CONTRACT and WRAPPER_NO_CONTRACT? I encountered some GC failuire after applying this PR:

FAILED   - [ 2935 :   84 sec ] GC/Features/HeapExpansion/bestfit-finalize/bestfit-finalize.sh
FAILED   - [ 2985 :    5 sec ] GC/Regressions/v2.0-beta2/460373/460373/460373.sh
FAILED   - [ 2988 :  227 sec ] GC/Regressions/v2.0-rtm/494226/494226/494226.sh

If there is any document, it would be very helpful.

@leemgs Please take a look. Is there any chance that your recent PR(s) to enable O3 in ARM/Linux resolves this issue?

CC @lemmaa

[jkotas]

GET_UNALIGNED_VALXXX is meant to be used for reads of unaligned values. If it does not work on Linux ARM, the fix should be make in GET_UNALIGNED_VALXXX, not by removing calls to it.

[parjong]

Thanks for your comment. I'll revise this PR per comment.

The code at line 35 and 42 (which directly access each byte) may cause this issue, but it seems that GET_UNALIGNED_VAL8 is missing currently. Is it intended?

[jkotas]

Accessing byte cannot be ever unaligned.

[parjong]

If GetU1 is called twice, m_pbCur will have an unaligned address, and thus I though that directly reading that region cause unaligned access. Please let me know if there is something that I misunderstood.

[janvorli]

Unaligned access means that it accesses address that is not aligned to the size of the data you are accessing. That's why byte access cannot ever be unaligned, as @jkotas has said.

[parjong]

@jkotas @janvorli Thanks for comments. I finally figured out what I misunderstood. I though that ARM requires 4-byte alignment even for byte access, but it isn't. As reported in #6378, this issue seems to be closely related with @leemgs issue.

[jkotas]

The contracts are documented in https://github.com/dotnet/coreclr/blob/master/Documentation/coding-guidelines/clr-code-guide.md, but I think that the failures you are seeing are not related to contracts.

[leemgs]

@leemgs Please take a look. Is there any chance that your recent PR(s) to enable O3 in ARM/Linux resolves this issue?

@parjong , Yes. Please refer to the report that I shared to fix unit-test failures of CoreCLR previously.

• The possible approaches - https://github.com/dotnet/coreclr/issues/5844#issuecomment-231530777
• The related patches that I have tried - https://github.com/dotnet/coreclr/issues/5844#issuecomment-231715755

[parjong]

I'll close this PR as PR #6379 resolves #6378, too.