TBL services using platform-scope values in table header definition #25
Assignees
Milestone
Comments
jphickey
added a commit
to jphickey/cFE
that referenced
this issue
Sep 13, 2019
To ensure consistency in the size of the CFE_TBL_FileHdr_t struct, this should be constrained to use only mission-scope definitions. Also simplifies the structure definitions by _NOT_ padding strings out to 32 bit multiples. The default size of the strings are already 32 bit multiples so this is just unnecessary complexity. There is also no major issue if not 32 bit aligned, as the compiler will add it automatically where needed. Add a note in the related cfe_mission_cfg.h descriptions to affected values, that these should be kept as a multiple of 4 to maintain alignment. Fixes nasa#25
jphickey
added a commit
to jphickey/cFE
that referenced
this issue
Sep 13, 2019
To ensure consistency in the size of the CFE_TBL_FileHdr_t struct, this should be constrained to use only mission-scope definitions. Also simplifies the structure definitions by _NOT_ padding strings out to 32 bit multiples. The default size of the strings are already 32 bit multiples so this is just unnecessary complexity. There is also no major issue if not 32 bit aligned, as the compiler will add it automatically where needed. Add a note in the related cfe_mission_cfg.h descriptions to affected values, that these should be kept as a multiple of 4 to maintain alignment. Fixes nasa#25
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
The
CFE_TBL_MAX_FULL_NAME_LENsize definition, which is used as part of theCFE_TBL_FileDef_tstructure, is partly based on theOS_MAX_API_NAMEvalue.The problem is that this value is platform scope and thereby configurable on a per-cpu basis. Therefore, the
OS_MAX_API_NAMEvalue can be (validly) different on each CPU in a multi-cpu deployment. This, in turn, means the table definition headers may be different on each CPU.Tools like
elf2cfetblandtblCRCTooldo not account for this possibility; when reading or writing the table header, they use a single definition. The definition that they use may or may not even match what the flight code uses at all, depending on how the mission is configured.To Reproduce
Configure a mission with two CPUs, and specify a different osconfig.h for each one (i.e. set TGT2_PLATFORM to something other than default). Change the value of
OS_MAX_API_NAMEfor the second CPU, and build all software.Observe that the
sizeof(CFE_TBL_FileDef_t)is now also different on CPU2 vs. CPU1. Tables generated byelf2cfetbland the CRC computed bytblCRCToolonly work in CPU1. CPU2 will not be able to load tables because of the incompatible header.Expected behavior
The
sizeof(CFE_TBL_FileDef_t)should remain consistent regardless of the platform-scope values used, because this is an external format shared between (at least) between ground systems and flight code.The
CFE_MISSION_MAX_API_LENmacro is a better choice here. It was introduced in a previous version of CFE for telemetry packets, but table files are effectively the same issue.Code snips
The problem definition is:
Furthermore, as this definition is only really for the header struct, it should be in cfe_tbl_filedef.h, not cfe_tbl.h. This allows external tools to include this definition without having to pull in the rest of CFE headers implicitly.
System observed on:
Ubuntu 18.04 (64-bit), kernel 5.0.0-23-generic
Reporter Info
Joseph Hickey, Vantage Systems, Inc.
The text was updated successfully, but these errors were encountered: