Remove C FILE PAL wrappers

[jkoritzinsky]

Remove the PAL wrappers around the C FILE APIs and update locations that were using the existing features.

The existing PAL layer provides the following features:

• Explicit "Text" mode:
  • Normalize line endings on read from CRLF to LF
  • Specify 't' as part of the mode parameter to fopen
  • This was used by ildasm for writing. Writing with text mode in the PAL does nothing (as the line endings are already normalized). Replaced with an #ifdef to only use explicit text mode on Windows.
• Implicit "Text" mode:
  • Normalize line endings on read from CRLF to LF
  • This was used across the product, but only used in two places that might read files with CRLF-style line endings.
    • Text-based PGO.
      • This format is a non-shipping format that is used for debugging/diagnostics purposes.
      • Text editors on Windows now support LF-based line endings, so I updated this to use the explicit non-text mode so files produced in the future can be read on all platforms (like the existing behavior).
    • ildasm's handling for showing source-line information
      • ildasm explicitly checks for CRLF line endings even when using the PAL, so we don't need the PAL to handle this.
• EINTR errno results
  • EINTR errors can only occur in the syscalls used by the C file APIs when a syscall is interrupted by a signal handler not marked with SA_RESTART. All signal handlers CoreCLR installs are marked with SA_RESTART.
• Clear ferror errors with clearerr before each operation.
  • I couldn't really validate that we don't depend on this behavior today, but given the minimal usage of these APIs in the runtime (mostly reading files in /sys and /proc), I'm not particularly worried.
  • Most file-manipulation scenarios cases in the CoreCLR code-base use the Win32 PAL (CreateFile and family) instead of the C PAL.

[ryujit-bot]

Diff results for #98238

Throughput diffs

Throughput diffs for linux/arm64 ran on windows/x64

MinOpts (-0.01% to +0.00%)

Collection	PDIFF
libraries.pmi.linux.arm64.checked.mch	-0.01%

Details here

---

[ryujit-bot]

Diff results for #98238

Throughput diffs

Throughput diffs for linux/arm64 ran on linux/x64

MinOpts (-0.00% to +0.01%)

Collection	PDIFF
libraries.pmi.linux.arm64.checked.mch	+0.01%

Details here

---

[ryujit-bot]

Diff results for #98238

Throughput diffs

Throughput diffs for linux/arm64 ran on windows/x64

MinOpts (-0.00% to +0.01%)

Collection	PDIFF
libraries.pmi.linux.arm64.checked.mch	+0.01%

Details here

---

[ryujit-bot]

Diff results for #98238

Throughput diffs

Throughput diffs for linux/arm64 ran on windows/x64

MinOpts (-0.00% to +0.01%)

Collection	PDIFF
libraries.pmi.linux.arm64.checked.mch	+0.01%

Details here

---

[ryujit-bot]

Diff results for #98238

Throughput diffs

Throughput diffs for osx/arm64 ran on windows/x64

MinOpts (-0.00% to +0.01%)

Collection	PDIFF
libraries.pmi.osx.arm64.checked.mch	+0.01%

Details here

---

[janvorli]

EINTR errors can only occur in the syscalls used by the C file APIs when a syscall is interrupted by a signal handler not marked with SA_RESTART. All signal handlers CoreCLR installs are marked with SA_RESTART.

How about signal handlers installed by user code? E.g. custom host or 3rd party libraries?

[jkoritzinsky]

EINTR errors can only occur in the syscalls used by the C file APIs when a syscall is interrupted by a signal handler not marked with SA_RESTART. All signal handlers CoreCLR installs are marked with SA_RESTART.

How about signal handlers installed by user code? E.g. custom host or 3rd party libraries?

For signal handlers installed with the PosixSignalRegistration API, it looks like we're good. For custom hosts or 3rd party libraries that install signal handlers without SA_RESTART, we'd have a problem.

However, if the GC doesn't use the PAL headers (as you said in the later comments on some of the files), then the only places that use the fopen API are off-by-default logging scenarios, all of which other than DOTNET_ReadyToRunLogFile are Debug/Checked only, superpmi, or in non-CoreCLR processes like ilasm or ildasm. Everywhere else that does file manipulation uses the Win32 PAL, not the C APIs.

Therefore, I don't think we need to worry about EINTR error codes, especially as even the Mono runtime doesn't seem to check for them when using the C API instead of direct syscalls (they do check when directly calling write or open, but not fwrite or fopen).

[jkoritzinsky]

cc: @EgorBo for review of the text-based PGO format change (using LF line endings across all platforms instead of CRLF). We can also change this back and have it be LF on non-Windows and CRLF on Windows. I'd rather not support CRLF on non-Windows for this though.

[EgorBo]

Text PGO changes LGTM cc @AndyAyersMS @jakobbotsch hope it won't break any internal tooling for you

[ryujit-bot]

Diff results for #98238

Throughput diffs

Throughput diffs for windows/arm64 ran on windows/x64

MinOpts (-0.00% to +0.01%)

Collection	PDIFF
libraries.pmi.windows.arm64.checked.mch	+0.01%

Details here

---

[lambdageek]

especially as even the Mono runtime doesn't seem to check for them when using the C API instead of direct syscalls (they do check when directly calling write or open, but not fwrite or fopen).

Mono probably should check for EINTR in more places, to be honest - we're not a great role model for this.

(Although I'd guess we mostly use the FILE* apis in non-shipping debug scenarios and in the AOT compiler. The AOT compiler doesn't load arbitrary 3rd party native code and I'm not even sure if we set up our own signal handlers in it.)

[jkoritzinsky]

@janvorli do you have any more feedback here?

[janvorli]

LGTM, thank you!