Figure out how to handle dlsym with RTLD_NEXT
Nobody has claimed this yet.
- Dominant language
- C
- Stars
- 88
- Forks
- 31
- PR merge metrics
- No merged PRs in 30d
Description
The RTLD_NEXT parameter to dlsym has at least two issues with gotcha:
- When the symbol being passed to dlsym isn't wrapped: the behavior of dlsym with RTLD_NEXT changes based on the caller library. Wrapping dlsym will break this. We need to simulate the bottom level call as if coming from the top level caller.
- Calling dlsym with RTLD_NEXT can return a different "bottom-level symbol" than without. If the symbol is wrapped, should we return the same wrapper function with and without RTLD_NEXT? Should we support different stacks of wrappers?
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reproducing the two RTLD_NEXT cases described in the issue: an unwrapped symbol and a wrapped symbol. Trace how dlsym behavior depends on the caller library and compare the bottom-level symbol returned with and without RTLD_NEXT; done requires a decided handling strategy for both cases.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- c
- Domain
- operating-systems
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100