Fix the stackoverflow test output checks

[janvorli]

The System.Threading.ThreadHelper.ThreadStart can tail call the
System.Threading.ExecutionContext.RunInternal (and some other methods in
the runtime as well) and thus it would not be visible on the stack
trace. So the fix is to not to look at the System.Threading.ThreadHelper.ThreadStart
in the stack trace and use a method in the test itself instead. Since
the test is compiled with optimizations disabled, JIT should not do any
"interesting" things.

Close #35878

[BruceForstall]

LGTM.

Would it be worthwhile adding a comment to the SecondaryThreadStart function about the requirement that it appear on the stack trace, and thus we require/expect the JIT not to optimize it away due to the fact the test is build without optimization? Should you annotate it NoOptimization as well?

[janvorli]

I can annotate all the methods involved with the NoOptimization. I was thinking that disabling optimizations on the project level is sufficient.

[BruceForstall]

You're right that disabling on the project level is sufficient. I was thinking that annotating the specific functions makes it more explicit and possibly protects the test against changes to the build process (and maybe allows it to run if built optimized?)

[janvorli]

It seems that marking all of the methods that should show up on the call stack with NoInlining should be sufficient, right? Or is the NoOptimization a better option?

[BruceForstall]

To be honest, I never remember the answer to that. @AndyAyersMS Can you help?

[AndyAyersMS]

NoInlining should be sufficient.