Skip to content
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

Memory alignment issues in TIME (32bit, MCP750, CCSDS_VER_2 config) #666

Closed
skliper opened this issue May 4, 2020 · 7 comments · Fixed by #678 or #692
Closed

Memory alignment issues in TIME (32bit, MCP750, CCSDS_VER_2 config) #666

skliper opened this issue May 4, 2020 · 7 comments · Fixed by #678 or #692
Assignees
Labels
Milestone

Comments

@skliper
Copy link
Contributor

skliper commented May 4, 2020

Is your feature request related to a problem? Please describe.

/home/jhageman/cFS/cFS-GitHub/cfe/fsw/cfe-core/src/time/cfe_time_tone.c: In function 'CFE_TIME_Tone1HzTask':
/home/jhageman/cFS/cFS-GitHub/cfe/fsw/cfe-core/src/time/cfe_time_tone.c:1220: warning: cast increases required alignment of target type
/home/jhageman/cFS/cFS-GitHub/cfe/fsw/cfe-core/src/time/cfe_time_tone.c:1228: warning: cast increases required alignment of target type
/home/jhageman/cFS/cFS-GitHub/cfe/fsw/cfe-core/src/time/cfe_time_tone.c: In function 'CFE_TIME_Local1HzTask':
/home/jhageman/cFS/cFS-GitHub/cfe/fsw/cfe-core/src/time/cfe_time_tone.c:1437: warning: cast increases required alignment of target type

Describe the solution you'd like
Force alignment where possible without changing bits on the wire

Describe alternatives you've considered
Remove -Wcast-align for this build

Additional context
Note there are other alignment issues for other configuration options (#313, #314) but they don't show up for MCP750 with CCSDS Version 2 so aren't critical to 6.8.

Requester Info
Jacob Hageman - NASA/GSFC

@skliper skliper added the bug label May 4, 2020
@skliper skliper added this to the 6.8.0 milestone May 4, 2020
@skliper
Copy link
Contributor Author

skliper commented May 5, 2020

As of right now this is the final core code change for 6.8 - @jphickey

@jphickey
Copy link
Contributor

jphickey commented May 5, 2020

When I test this I get the same results on extended vs. non-extended headers.

I would not expect the setting of this config option to change the alignment requirements of packets as most packets do not contain a CFE_SB_MsgId_t directly.

The reason there are just a few warnings in this build is because most of the alignment warnings were resolved in issue #437 and these are simply all that are left.

@skliper
Copy link
Contributor Author

skliper commented May 5, 2020

When I test this I get the same results on extended vs. non-extended headers.

Yes, that's why it's an issue we need to address now. Extended headers only fixes the alignment warning for packets that contain CFE_SB_MsgId_t.

@skliper
Copy link
Contributor Author

skliper commented May 6, 2020

@jphickey could you clarify what's the hold-up on resolving this issue? Your comments above make it sound like we are not on the same page.

jphickey added a commit to jphickey/cFE that referenced this issue May 6, 2020
The "CFE_SB_CmdHdr_t" and "CFE_SB_TlmHdr_t" types were not defined
such that they would have compatible alignment with (and thereby allow
safe casting to/from) a CFE_SB_Msg_t type.

This changes the definition to be a union so that the types are
aligned correctly.
jphickey added a commit to jphickey/cFE that referenced this issue May 6, 2020
Update the CFE_ES_ShellTlm_t, CFE_TIME_ToneSignalCmd_t, and
CFE_TIME_FakeToneCmd_t to use the CFE_SB_TlmHdr_t/CFE_SB_CmdHdr_t
types to define the buffer, rather than a uint8 array.

This should not change the size, as it was already defined using
sizeof() this structure, but it will make it aligned correctly
which resolves the compiler warning.

Note that all CMD/TLM should really be defined this way, but
this only selectively changes the places that were actually
generating a compiler warning about this.  There is a risk
that padding will be added, but this change should not change
the padding or size of messages in 32-bit builds.
@jphickey
Copy link
Contributor

jphickey commented May 6, 2020

@jphickey could you clarify what's the hold-up on resolving this issue? Your comments above make it sound like we are not on the same page.

The challenge here was to come up with something that wouldn't just hide the fundamental flaw (i.e. address the actual alignment of the message structure at issue) but also wouldn't affect other messages. Hopefully the PR that I just submitted will be acceptable.

The fix I'm proposing is split into two commits, the first just makes the CFE_SB_CmdHdr_t/CFE_SB_TlmHdr_t types correctly aligned for how they are actually used. Note most message definitions do not use this type - they define the message header as a uint8 array based on the sizeof() this type (i.e. not aligned).

The second commit changes the header definition only on these particular message types that were generating warnings. This makes them aligned and fixes the warning.

Note the same thing should be done for all messages, because using a uint8[] array is inherently unsafe/incorrect as it is not aligned for anything. It is only because most payloads contain a uint32 somewhere that it isn't getting warned about elsewhere.

@jphickey
Copy link
Contributor

jphickey commented May 6, 2020

Also note this PR only fixes warnings within the FSW code. I'm still seeing several alignment cast warnings in the unit test code on my 32-bit test platform. Will submit a separate issue about that.

@jphickey jphickey added the CCB:Ready Ready for discussion at the Configuration Control Board (CCB) label May 6, 2020
@astrogeco astrogeco removed the CCB:Ready Ready for discussion at the Configuration Control Board (CCB) label May 6, 2020
@skliper
Copy link
Contributor Author

skliper commented May 6, 2020

Concurrence received on applying this pattern on all the messages, we'll manage the impact of tlm changes as part of this cycle.

astrogeco added a commit that referenced this issue May 8, 2020
Fix #666, alignment of CMD/TLM message definitions
astrogeco pushed a commit that referenced this issue May 8, 2020
Update the CFE_ES_ShellTlm_t, CFE_TIME_ToneSignalCmd_t, and
CFE_TIME_FakeToneCmd_t to use the CFE_SB_TlmHdr_t/CFE_SB_CmdHdr_t
types to define the buffer, rather than a uint8 array.

This should not change the size, as it was already defined using
sizeof() this structure, but it will make it aligned correctly
which resolves the compiler warning.

Note that all CMD/TLM should really be defined this way, but
this only selectively changes the places that were actually
generating a compiler warning about this.  There is a risk
that padding will be added, but this change should not change
the padding or size of messages in 32-bit builds.
astrogeco added a commit that referenced this issue May 8, 2020
Fix #666, alignment of CMD/TLM message definitions
CDKnightNASA added a commit to CDKnightNASA/cFE that referenced this issue May 11, 2020
CDKnightNASA added a commit to CDKnightNASA/cFE that referenced this issue May 11, 2020
CDKnightNASA added a commit to CDKnightNASA/cFE that referenced this issue May 11, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
3 participants