Conversation
No changes to any of the files. Not added to the build. TEST_IMG: ubuntu/dotnet-build TEST_CMD: safe ./projects/dotnet/build-runtime.sh Change-Id: I80174799bb833c0edd517bfb9e7b57dd114f0ab7 Jira: ENTLLT-6871
TEST_IMG: ubuntu/dotnet-build TEST_CMD: safe ./projects/dotnet/build-runtime.sh Jira: ENTLLT-6871 Change-Id: Ic5445f3378ac9d3fa4e79d4ae1649504819d27e2
TEST_IMG: ubuntu/dotnet-build TEST_CMD: safe ./projects/dotnet/build-runtime.sh Jira: ENTLLT-6871 Change-Id: Ifa04a618ccb50ee906eb10dead9dd4fbe4a3b736
a74nh
pushed a commit
that referenced
this pull request
Sep 9, 2024
* bug #1: don't allow for values out of the SerializationRecordType enum range * bug #2: throw SerializationException rather than KeyNotFoundException when the referenced record is missing or it points to a record of different type * bug #3: throw SerializationException rather than FormatException when it's being thrown by BinaryReader (or sth else that we use) * bug #4: document the fact that IOException can be thrown * bug #5: throw SerializationException rather than OverflowException when parsing the decimal fails * bug #6: 0 and 17 are illegal values for PrimitiveType enum * bug #7: throw SerializationException when a surrogate character is read (so far an ArgumentException was thrown)
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR provides an example of how VIXL could be used within coreclr.
VIXL is a Simulator, Assembler and Disassembler for Aarch64 and AArch64.
It is used by the following projects:
It has a detailed test suite and bug fixes / requests from the above projects have fed back into VIXL.
Writing Assemblers and Dissemblers requires a lot of work and are subject to subtle bugs. VIXL was specifically written to help development across open source projects.
In coreclr there is already a fully working assembler for Arm64 core instructions plus NEON. There is currently no assembler for SVE. AIUI, there is no proper disassembler within coreclr (ie one that can print the instructions at any arbitrary address).
The initial PR is split into three commits:
The first is a bulk import of the AArch64 Assembler and Disassembler from VIXL. There are no code changes to the code being copied.
The second adds VIXL into the build and all the changes required for VIXL to compile. This requires various changes due to standard C++ libraries not being available. Some code remains commented out, some addition support has been added to the coreclr headers. This code is a little hacky.
The third adds some example usage of VIXL:
-- Add an assembler and disassmbler to the codegen object.
-- Use VIXL for codgen of shift nodes (this was randomly chosen).
-- At the end of codegen, disassemble the vixl buffer to the jit dump.
This appears to mostly work, but there is a memory corruption issue. When stepped through via a debugger, the shifts are correctly printed to the dump. Without a debugger, the thread vanishes before printing. I suspect an issue in my hacks.
Going forwards there are a number of ways this could be used. One solution would be to modify the VIXL code to use the same buffers as the Emit class. All SVE code would generate via VIXL. Then VIXL would be used to print the codegen buffer to the jit dump.
A more extreme version would be to just take the lowest level functions that emit the binary code, and modify them to look like the existing emit functions. Going in the other direction, the coreclr emit class could be replaced with the VIXL class.