Use EXTERNAL_C_FUNC for CONTEXT_CaptureContext on s390x#130294
Use EXTERNAL_C_FUNC for CONTEXT_CaptureContext on s390x#130294abhishekabhi73cc-design wants to merge 1 commit into
Conversation
dotnet-policy-service
Bot
added
the
community-contribution
|
LGTM |
| mvhhi CONTEXT_ContextFlags+2(%r2), ((CONTEXT_S390X | CONTEXT_FULL) & 0xffff) | ||
| mvhhi CONTEXT_ContextFlags(%r2), ((CONTEXT_S390X | CONTEXT_FULL) >> 16) | ||
| jg C_FUNC(CONTEXT_CaptureContext) | ||
| jg EXTERNAL_C_FUNC(CONTEXT_CaptureContext) |
There was a problem hiding this comment.
CONTEXT_CaptureContext is defined in this file. C_FUNC works fine in this asm code on all other architectures.
Why does s390x need EXTERNAL_C_FUNC?
There was a problem hiding this comment.
CONTEXT_CaptureContext is defined in this file, but as a global symbol. So according to default ELF symbol resolution rules, it still can be overridden by another definition in another ELF module earlier in the search order, and in that case, even the "local" call should go to the override symbol. Therefore the branch actually targets the PLT stub - this would be the case on other ELF/Linux platforms, too. (The resolution rules for Windows DLLs are different in that respect as I understand; there it would always target the locally-defined version of the symbol.)
Now, whether or not a branch targeting a PLT stub needs an explicit @plt marker depends on the platform-specific set of relocation types (and how strict the linker is in interpreting them). Even on s390x it usually works without the marker, but lld seems to be particularly picky here. In any case, adding the @plt marker is correct (and would be harmless even if unneeded).
4 participants
Replace C_FUNC with EXTERNAL_C_FUNC for CONTEXT_CaptureContext on s390x.
Using this ensures the correct symbol linkage.