You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
The CFE core executable link process uses --whole-archive to ensure that all functions provided in libraries are actually linked into the executable.
Normally during a link procedure, if a compilation unit within a static library does not resolve any unresolved symbol (i.e. doesn't implement anything that is actually called by the application) it is dropped. However because CFE dynamically loads applications/libraries at runtime, this can be a problem if a particular API is only invoked by apps and not by CFE itself.
The --whole-archive linker flag does accomplish the goal of making sure all the APIs are linked in and available for application use, but it has problems:
The switch isn't really supported by CMake, it requires a backdoor approach to add it via target_link_libraries().
Adding using this method requires the full string of the exact option, which is specific to the GCC/LD toolchain paradigms Other toolchains might have a similar option, but would require patching the link line to support them.
Even when using GCC, the exact option string also differs depending on whether gcc or ld tool is used for the final link step. (In the former case, a -Wl, prefix is required to pass the option through to the linker stage). This has been a frequent issue for FSW target builds in that there is no reliable way to determine if this extra prefix is needed.
Describe the solution you'd like
A possible alternative would be to use the OSAL "static symbol" feature to pull in every API that should be available for application use.
Describe alternatives you've considered
Leave as-is.
Additional context
Downside of this approach is that it requires maintaining a separate list of every public API that CFE core + OSAL is supposed to contain. However, this is already (somewhat) done for unit test stubs.
The upside is that it can help catch errors of missing functions. This may become relevant if/when users are allowed to override parts of CFE with their own implementation (e.g. issue #554). If a required API is missing, this can detect it early and generate a linker error, whereas the current approach will get a runtime error only if/when an application is loaded that tries to use the missing API.
Requester Info
Joseph Hickey, Vantage Systems, Inc.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
The CFE core executable link process uses
--whole-archive
to ensure that all functions provided in libraries are actually linked into the executable.Normally during a link procedure, if a compilation unit within a static library does not resolve any unresolved symbol (i.e. doesn't implement anything that is actually called by the application) it is dropped. However because CFE dynamically loads applications/libraries at runtime, this can be a problem if a particular API is only invoked by apps and not by CFE itself.
The
--whole-archive
linker flag does accomplish the goal of making sure all the APIs are linked in and available for application use, but it has problems:target_link_libraries()
.gcc
orld
tool is used for the final link step. (In the former case, a-Wl,
prefix is required to pass the option through to the linker stage). This has been a frequent issue for FSW target builds in that there is no reliable way to determine if this extra prefix is needed.Describe the solution you'd like
A possible alternative would be to use the OSAL "static symbol" feature to pull in every API that should be available for application use.
Describe alternatives you've considered
Leave as-is.
Additional context
Downside of this approach is that it requires maintaining a separate list of every public API that CFE core + OSAL is supposed to contain. However, this is already (somewhat) done for unit test stubs.
The upside is that it can help catch errors of missing functions. This may become relevant if/when users are allowed to override parts of CFE with their own implementation (e.g. issue #554). If a required API is missing, this can detect it early and generate a linker error, whereas the current approach will get a runtime error only if/when an application is loaded that tries to use the missing API.
Requester Info
Joseph Hickey, Vantage Systems, Inc.
The text was updated successfully, but these errors were encountered: