[NativeAOT/ARM] Bail out on IMAGE_REL_BASED_THUMB_BRANCH24 with >24-bit addends

[filipnavara]

... and let the linker generate thunks.

Fixes #97750

[ghost]

Tagging subscribers to this area: @agocke, @MichalStrehovsky, @jkotas
See info in area-owners.md if you want to be subscribed.

Issue Details

---

... and let the linker generate thunks.

Fixes #97750

Author:	filipnavara
Assignees:	-
Labels:	area-NativeAOT-coreclr
Milestone:	-

[jkotas]

let the linker generate thunks.

Is the linker guaranteed to find space to generate the thunks? How reliable is this fix?

[filipnavara]

Is the linker guaranteed to find space to generate the thunks? How reliable is this fix?

It is not guaranteed to find a space but it should be a hard fail if it does not. In practice I expect this should effectively double the size of code before the error is hit again (to 1 << 25 bytes).

We may investigate alternative mitigation strategies but this is the cheap way to increase the size limit.

[jkotas]

Are the thunks placed outside the managed code section? If they are part the managed code section, there may be fixes needed in the code manager to ignore them.

[filipnavara]

Are the thunks placed outside the managed code section?

That's a good question. They should not interleave with existing code and I assume they would have to be placed at the end of the same section as the code. That means they will not have reliable unwinding data, and that could be a problem (especially if it picks unwinding code from last method).

I'll put this back to draft for now and verify the assumptions later.

[filipnavara]

Are the thunks placed outside the managed code section?

The linker creates a separate .text.thunks section, so it should not interfere. The hijack signal handler can catch the thread inside the thunk but it will bail out since it's not in a managed code at that point.

[jkotas]

Thank you for checking