Enable including probestack::__rust_probestack on no_std windows targets

[wumb0]

Building a no_std project on windows still will generate calls to _chkstk/__chkstk so I'd like to be able to include __rust_probestack instead of having to either re-write my code to not have functions that large OR steal chkstk code from Visual Studio.

This is currently not possible because of the following assumption and code:

compiler-builtins/src/probestack.rs

Lines 45 to 46 in e6fd1b2

	// Windows already has builtins to do this.
	#![cfg(not(windows))]

This assumption is only true when building with std/msvcrt.

To add this functionality without breaking existing code a feature flag like force-probestack could be added (please suggest a more suitable name). That would be a pretty minimal code change and also solve the issue:

#![cfg(any(not(windows), feature="force-probestack"))]

The existing x86/x86_64 probestack code currently marked as uefi works fine on Windows, so some changes to the cfg statements will need to be made. I have some working code if a PR would be more desirable.

I suggest the feature flag over just enabling this by default on no_std targets to keep compatibility with existing uses of the crate.

Let me know there is already a way to do this, or if this suggestion is nonsense. Thanks!

[wumb0]

most likely related to #383.
Looks like it would revert changes made for #179

[bjorn3]

__rust_probestack isn't used for windows. __chkstk or ___chkstk_ms is used instead. These are defined in https://github.com/rust-lang/compiler-builtins/blob/e6fd1b272ff4cc34810e20126ffe17888a708f39/src/x86_64.rs.

[wumb0]

ah I didn't even see those there.
unfortunately, these are gnu only, not msvc. this is an edge case with no_std *-pc-windows-msvc.
perhaps the changes should be made to that portion of the crate then? thoughts?

[wumb0]

The comment on #403 that says __chkstk is included in ntdll so I should be linking against ntdll is valid here as well.
I did check and it is exported from ntdll.
My use case does not allow linking in external libraries (PIC shellcode, everything needs to be self-contained), but again, is outside the scope of this crate. Closing.