skliper
commented
2 years ago OK, this is a bad idea since you can't unload on Linux if the symbols are global.
Latest suggestion - use the symbol table lookup local API (if there is one). More research needed. Likely will create a new issue to address if needed.
Is your feature request related to a problem? Please describe. In Caelum, apps were switched to have local symbol scope when getting loaded (on systems that support it) to avoid discouraged design behaviors and possible issues with unloading/reloading if apps share symbols. Really libs should contain all global scope symbols used by other apps (and are still loaded with global scope) and are never unloaded (requires restart to modify).
https://github.com/nasa/cFE/blob/c161cf04fe7c5fd2f2a533ac1d7522b31191eab6/modules/es/fsw/src/cfe_es_apps.c#L418-L442
The down-side of this change is apps like MM, MD, CS all become more challenging to use when symbols are not available and a global symbol table dump won't include the app symbols. Although sharing symbols from a reloadable app is likely never a good idea due to the potential for executing or utilizing stale memory, there's definitely a trade related to maintenance/portability. Likely use case would be to compile w/ local app symbols to ensure apps are not sharing symbols, but then switch to global for testing and/or release build for systems that require it.
Describe the solution you'd like Add a configuration option to load apps with global or local scope (also helpful to have background as to why each might be selected). This also allows a system that supports local symbols to behave like a system that doesn't support it for simulation/portability purposes.
Describe alternatives you've considered Could add an option at in the startup config, but probably overkill to set at an app by app basis.
Additional context None
Requester Info Jacob Hageman - NASA/GSFC