Fix finding entry point unwind record for a method with fragmented un…

[AndyAyersMS]

…wind

On Arm and Arm64 unwind records can only cover a limited range of code
(512K and 1MB respectively). So for methods larger than this the jit
will emit multiple "fragment" unwind records to cover the full method code
range. Only the first of these describes the behavior of the method prolog.

When mapping an offset back to a method's entry point unwind, make sure to
find this "root" unwind record instead of one of the internal fragments.

Fixes #19209.

[AndyAyersMS]

@janvorli PTAL
cc @BruceForstall

[BruceForstall]

LGTM.

Might be useful to add a header comment to EEJitManager::LazyGetFunctionEntry documenting that it will return the "root" RUNTIME_FUNCTION entry (containing the prolog).

Also, I guess it's ok you removed the comment above the --pFunctionEntry line, but I think it would be useful to leave it, also.

[AndyAyersMS]

@dotnet-bot test Ubuntu16.04 arm64 Cross Checked gcstress0xc Build and Test
@dotnet-bot test Ubuntu16.04 arm64 Cross Checked gcstress0xc_jitstress1 Build and Test
@dotnet-bot test Ubuntu16.04 arm64 Cross Checked gcstress0xc_jitstress2 Build and Test

[janvorli]

LGTM, thank you!

[janvorli]

@dotnet-bot test Ubuntu16.04 arm64 Cross Checked gcstress0xc Build and Test
@dotnet-bot test Ubuntu16.04 arm64 Cross Checked gcstress0xc_jitstress1 Build and Test
@dotnet-bot test Ubuntu16.04 arm64 Cross Checked gcstress0xc_jitstress2 Build and Test

[janvorli]

@dotnet-bot test Ubuntu16.04 arm64 Cross Checked gcstress0xc Build and Test
@dotnet-bot test Ubuntu16.04 arm64 Cross Checked gcstress0xc_jitstress1 Build and Test
@dotnet-bot test Ubuntu16.04 arm64 Cross Checked gcstress0xc_jitstress2 Build and Test

[AndyAyersMS]

Looking at GC stress failures

• b163200 is some other issue, was failing before this fix (#19464, #19986)
• generics/WaitCallback/thread23 seems like a new failure (perhaps the null issue Jan spotted -- will see if this repros once I address that)

[AndyAyersMS]

Latest push should fix the null issue and adds (restores) some comments.

@dotnet-bot test Ubuntu16.04 arm64 Cross Checked gcstress0xc Build and Test
@dotnet-bot test Ubuntu16.04 arm64 Cross Checked gcstress0xc_jitstress1 Build and Test
@dotnet-bot test Ubuntu16.04 arm64 Cross Checked gcstress0xc_jitstress2 Build and Test

[AndyAyersMS]

Sigh. Need to actually return the entry instead of always returning null. Will push a fix shortly.

[AndyAyersMS]

@dotnet-bot test Ubuntu16.04 arm64 Cross Checked gcstress0xc Build and Test
@dotnet-bot test Ubuntu16.04 arm64 Cross Checked gcstress0xc_jitstress1 Build and Test
@dotnet-bot test Ubuntu16.04 arm64 Cross Checked gcstress0xc_jitstress2 Build and Test

[AndyAyersMS]

Hmm, build issues for the GC stress legs... did not realize test legs can share a build leg like this.

12:24:14   bne_opt -> /mnt/j/workspace/dotnet_coreclr/master/arm64_cross_checked_ubuntu16.04_prtest/bin/tests/Linux.arm64.Checked/JIT/jit64/opt/regress/vswhidbey/223862/bne_opt/bne_opt.exe
12:24:15 Command execution failed with exit code 139.

@dotnet-bot test Ubuntu16.04 arm64 Cross Checked gcstress0xc Build and Test
@dotnet-bot test Ubuntu16.04 arm64 Cross Checked gcstress0xc_jitstress1 Build and Test
@dotnet-bot test Ubuntu16.04 arm64 Cross Checked gcstress0xc_jitstress2 Build and Test

[AndyAyersMS]

Remaining stress failures are all known issues

• GetGenerationWR (#19211)
• b163200 (#19464)

[AndyAyersMS]

@janvorli want to take one more look?

[janvorli]

@AndyAyersMS it looks good to me.