-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Big endian fixes for dotnet runtime #47981
Conversation
I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label. |
I note failures such as:
However, I had built runtime on my own 64-bit system with this patches and got a clean bill:
I am not sure why this is happening. |
That project builds for various configurations that don't have a built-in Span: runtime/src/libraries/System.Text.Encoding.CodePages/src/System.Text.Encoding.CodePages.csproj Line 5 in 45287ed
You could try adding a reference to System.Memory (it looks like you tried adding one, but it's in a section conditioned to only apply to some of the targets). |
Thanks, what about things like:
That seems a bit harder to fix if that reference isn't present. |
That's why you'd add the reference :) System.Memory provides the BinaryPrimitives type. |
No. System.Memory.dll includes the System.Buffers.Binary.BinaryPrimitives type. You would need to add something like:
to the project file, to include a package reference to the System.Memory package for the targets that don't have System.Memory in-box. That's not going to solve all of the issues you're hitting, though. For example, you've written code to use an overload of Stream.Read that simply doesn't exist in those previous versions. |
Thanks again. I'll add those lines. As I, presumably, can't emulate that previous build environment is it acceptable to amend this PR to generate another around of building and debug from that or is that a gratuitous use of the CI environment? |
You can. When you build from root, by default you're just building one specific target. You can either build the whole repo for multiple targets (e.g. |
Perfect! Thanks yet again. |
- Use Stream.Read(byte[] target, int offset, int length) instead of Stream.Read(Span) - Include System.Memory for older build levels - Enable BaseCodePageEncoding.netcoreapp.cs to use the Stream.Read(Span) method by giving it it's own ReadCodePageIndex() method
I found those errors to which you referred and have pushed some changes. I got a clean build using the
I am making the probably rash assumption that this is due to something missing on my build machine. I'll await the latest checks to see how it goes there. |
...ation.Formatters/src/System/Runtime/Serialization/Formatters/Binary/BinaryFormatterWriter.cs
Outdated
Show resolved
Hide resolved
Tagging subscribers to this area: @tarekgh, @krwq, @eiriktsarpalis, @layomia Issue DetailsA series of fixes that enable big endian running of the dotnet command. With these fixes and fixes in dotnet/runtimelab#650 the s390x run of the test suite results in 240 of 240 tests passing.
These fixes also address the problem described in issue #44805. Suggestion: area-System.Text.Encodings
|
src/libraries/System.Private.CoreLib/src/System/Text/Unicode/Utf8Utility.Transcoding.cs
Show resolved
Hide resolved
src/libraries/System.Text.Encoding.CodePages/src/System/Text/SBCSCodePageEncoding.cs
Outdated
Show resolved
Hide resolved
src/libraries/System.Text.Encoding.CodePages/src/System/Text/SBCSCodePageEncoding.cs
Outdated
Show resolved
Hide resolved
/azp run runtime |
Azure Pipelines successfully started running 1 pipeline(s). |
Previous CI run lost the artifacts somehow, so kicked off a new run. Hoping things will pass so that we can merge this in today. |
The Libraries Build windows allConfigurations x64 Debug failure is a known issue (fixed pending via #48074) and the build engineering team is on it. I'll ignore it for now while waiting for the rest to finish. |
Got it in. Thanks @nealef for your contribution! 🚀 |
Thanks! I think there'll be another installment after some more testing. |
A series of fixes that enable big endian running of the dotnet command. With these fixes and fixes in dotnet/runtimelab#650 the s390x run of the test suite results in 240 of 240 tests passing.
-- Big endian handling of widening to UTF16
-- Correct big endian extraction of UTF8 from two/four byte sequences
-- Correct detection of overlong rep for BE
-- Correct transcoding to UTF8 for BE
-- Remove debug message as we have run and verified the code
-- Remove debug message as we have run and verified the code
-- Include reference for use in BE code
-- Add code for BE reading of file header, code page header, and code page index
-- Remove debug message as we have run and verified the code
-- Add code for BE reading of code page index
-- Provide endian aware character reading
-- Endian aware code to map unicode to bytes
These fixes also address the problem described in issue #44805.
@eiriktsarpalis @layomia
Suggestion: area-System.Text.Encodings