Skip to content

Conversation

@sielicki
Copy link

dlsym(RTLD_NEXT, ...) may legally return any entrypoint which eventually finds its way into the requested symbol, in any library appearing in load-order after the current library. Load order can be messy in HPC runtime environments, or due to inconsistencies introduced by vendor toolchains and vendor packaging mechanisms.

All current intercepts are expected to resolve to libc, so just do an explicit search inside libc to prevent accidentally resolving eg: PLT stubs.

Fixes: #11451


Marked as WIP for now.

dlsym(RTLD_NEXT, ...) may legally return any entrypoint which eventually
finds its way into the requested symbol, in any library appearing in
load-order after the current library. Load order can be messy in HPC
runtime environments, or due to inconsistencies introduced by vendor
toolchains and vendor packaging mechanisms.

All current intercepts are expected to resolve to libc, so just do an
explicit search inside libc to prevent accidentally resolving eg: PLT
stubs.

Fixes: ofiwg#11451
Signed-off-by: Nicholas Sielicki <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

libfabric "patch" routines corrupt the procedure linkage table (PLT) on AARCH64 under Cray MPICH MPI_Init

1 participant