Support for statically linked CFS applications

[skliper]

Some platforms (RTEMS, for example) do not natively support the concept of dynamic module loading. Even on platforms that do offer this feature, it is sometimes beneficial to statically link anyway, at least in certain circumstances, since there is some extra runtime overhead when using a dynamically linked library vs. a statically linked library.

This will add the build infrastructure to do this, along with the necessary hooks to include statically linked modules into the PSP as well as CFS applications and libraries.

See also [cfs_psp:3] for the PSP enhancement to work with this.

[skliper]

Imported from trac issue 84. Created by jphickey on 2015-07-20T17:20:48, last modified: 2019-03-05T14:57:55

[skliper]

Trac comment by glimes on 2015-08-10 17:39:22:

This appears to be commit [changeset:da88492] which the Trac commit browser seems
to handle particularly badly. Suggest reviewers fetch the old and new versions
of the files manually and compare them using more flexible local tools.

I used this to get meld to do the comparison:
{{{
cd cfe
git checkout -b before 66df1cf
git checkout -b after da88492
git difftool before..after
}}}

To get meld involved, I have this in my ~/.gitconfig:
{{{
[diff]
tool = meld
}}}

The resulting display of the changes is much easier to understand.

edit: see [cfs_test:wiki:GitTipsAndTricks Git Tips and Tricks] for further thoughts. TLDR:
{{{
git config --global diff.tool meld
...
git difftool da88492^..da88492
}}}
only edited in here because someone might see the longer way, above,
which mucks with the checked-out image and leaves two branch labels
in the metadata.

[skliper]

Trac comment by glimes on 2015-08-11 12:33:24:

Accept.

[skliper]

Trac comment by glimes on 2015-08-11 12:35:59:

NOTE: requires coordinated integration of the [cfs_psp:3 PSP #34] changes.

[skliper]

Trac comment by sduran on 2015-08-24 17:18:30:

This looks ok. JSC did something similar a couple of year ago when working with RTEMS and ARINC653. I see cfe mods to support static apps. Where is the corresponding makefile/make rules/cmake mods to do the static build?

Why 0 and 2000?
CFE_ES_STATICENTRYTYPE_INVALID = 0,
CFE_ES_STATICENTRYTYPE_FIRST_VALID = 2000,

[skliper]

Trac comment by jphickey on 2015-08-24 21:54:39:

Clarification: there are two commits on this branch.

Commit [changeset:66df1cf] Implements the CMake stuff to make this all work - removes some preexisting code for "driver" support and replaces this with the static module - same thing but a little more generic.

Commit [changeset:da88492] is a follow-on change that allows a CFS application or library to be statically linked into the binary e.g. for RTEMS or another OS that does not have a native dynamic loader if you just don't want to use the dynamic loader.

Note that the web diff viewer for the above changeset (the second one) shows giant diffs due to whitespace changes because some chunks of code were wrapped in a conditional. Better to use a diff viewer that can ignore whitespace as Greg suggested above. meld is good and (if configured) can ignore whitespace by going into preferences - text filters tab and checking on "All whitespace".

[skliper]

Trac comment by jphickey on 2015-08-24 21:59:58:

To comment on the specific question above ....

Replying to [comment:4 sduran]:

Why 0 and 2000?
CFE_ES_STATICENTRYTYPE_INVALID = 0,
CFE_ES_STATICENTRYTYPE_FIRST_VALID = 2000,

This is merely a force of habit - zero should never be valid, and the first valid value should be something non-sequential. This reduces the likelihood of passing in a label from a different enumeration (these are all just integers after all) and having it be interpreted as something valid but different than intended. Of course it is still possible, just increases the chance that a mistake will be caught vs. having completely overlapping integers in enumerations everywhere

[skliper]

Trac comment by glimes on 2015-09-08 14:05:06:

The partial fix as reviewed on 2015-08-25 has been merged into development.
Leaving ticket state unchanged, as it is tracking additional changes.

[skliper]

Trac comment by glimes on 2016-02-25 10:17:32:

these will be fixed in CFE 6.5

[skliper]

Trac comment by glimes on 2016-03-09 15:12:48:

Commit [changeset:da88492] will be merged to development via ic-2016-03-08

This ticket will remain open per CCB discussion 2016-03-08
to track followup changes for Stack Size and Priority issues.

Review of this ticket turned up an issue to be tracked in ticket #173
as the CFE_ES_AppCreate function needs to be refactored.

[skliper]

Trac comment by jphickey on 2016-03-22 18:15:15:

Follow-on commit address stack size and priority: [changeset:015bf4e]

This has added into the ic-2016-03-22 merge

[skliper]

Trac comment by glimes on 2016-03-30 15:08:29:

development now includes ic-2016-03-22 merge.

[skliper]

Trac comment by jhageman on 2019-03-05 14:57:55:

Milestone renamed