-
Notifications
You must be signed in to change notification settings - Fork 217
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OS_SymbolLookup
should also support local symbol lookup
#1204
Labels
Milestone
Comments
Really restores former functionality while still being able to unload the module (if loaded w/ global symbols this breaks). No API changes necessary. |
skliper
added a commit
to skliper/osal
that referenced
this issue
Jan 12, 2022
- Refactors symbol table searching to include both local and global symbol tables for POSIX - Renamed global search to generic since there isn't currently a use case for global only search
skliper
added a commit
to skliper/osal
that referenced
this issue
Jan 18, 2022
- Refactors symbol table searching to include both local and global symbol tables for POSIX - Renamed global search to generic since there isn't currently a use case for global only search
jphickey
pushed a commit
to jphickey/osal
that referenced
this issue
Aug 10, 2022
jphickey
pushed a commit
to jphickey/osal
that referenced
this issue
Aug 10, 2022
Fix nasa#1204, Use mask instead of cast to alter value
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
Getting symbol addresses are an integral part of MM and MD. For systems that load modules with local scope this could still be easily supported by looping through the modules w/o requiring app changes.
Currently it just looks for global or static symbols:
osal/src/os/shared/src/osapi-module.c
Lines 352 to 388 in 4cc6dbb
Describe the solution you'd like
Possibly just use OS_ForEach and loop through modules within OS_SymbolLookup, but on systems where local symbol table lookup just calls the global version that would waste cycles if a symbol doesn't exist since it would end up searching the global table for every module.
Consider a slight refactor... a generic OS_SymbolLookup_Impl could search just global on systems with only global, global and local on systems that support it. Really doesn't seem to be a use case for OS_GlobalSymbolLookup_Impl which only searches the global table... possibly remove?
Describe alternatives you've considered
None others.
Additional context
See MM and MD use of symbol lookup, helpful to get from global or local scope.
Requester Info
Jacob Hageman - NASA/GSFC
The text was updated successfully, but these errors were encountered: